Dan Sugalski wrote:
Oh, yeah, lots of spilling. In a hacked up version of the PIR I see 50
spills in the main routine.
Brrr. It would definitely help, if you can use lexicals or gloabals, so
that you don't have that much long-ranged variables - and of course
splitting the beast if possible.
l
At 12:30 PM +0100 1/6/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
Optimized for speed, at least.
I'm finding that large subs seem to give imcc headaches. I'm not sure
if it's O(n^2) or O(2^n) headaches, but definitely issues.
Live analysis and register allocation are the
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Optimized for speed, at least.
> I'm finding that large subs seem to give imcc headaches. I'm not sure
> if it's O(n^2) or O(2^n) headaches, but definitely issues.
Live analysis and register allocation are the main problems. The former
is O(n_lines * n_va
At 10:59 AM 1/5/2004 -0500, Dan Sugalski wrote:
Optimized for speed, at least.
I'm finding that large subs seem to give imcc headaches. I'm not sure if
it's O(n^2) or O(2^n) headaches, but definitely issues. At the moment I've
got parrot churning on some pir code and it's taking quite a while. F
On Mon, 5 Jan 2004 10:59:18 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>I know IMCC's being redone, and we're nowhere near close to
>optimized,
That was my guess
> but I think it'd be worth it to get a handle on what sorts
>of things are likely to trigger off exponential time compiles when
Optimized for speed, at least.
I'm finding that large subs seem to give imcc headaches. I'm not sure
if it's O(n^2) or O(2^n) headaches, but definitely issues. At the
moment I've got parrot churning on some pir code and it's taking
quite a while. Final time tally:
real41m46.978s
user21
