Re: of Mops, jit and perl6
At 10:44 AM +0200 7/28/02, Leopold Toetsch wrote: >2) Some Mops numbers, all on i386/linux Athlon 800, slightly shortend: >(»make mops« in parrot root) Just out of curiosity, I presume the (rather abysmal) perl 6 numbers include time to generate the assembly and assemble it--have you tried running the generated code by itself as a test? (At the moment, the assembler's rather slow) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: of Mops, jit and perl6
On Mon, 29 Jul 2002, Dan Sugalski wrote: > Just out of curiosity, I presume the (rather abysmal) perl 6 numbers > include time to generate the assembly and assemble it--have you tried > running the generated code by itself as a test? (At the moment, the > assembler's rather slow) It's mostly the parser that's slow, not the assembler (about a second's worth of startup time to load the grammar and do a bunch of initialization). But even without that, I'd suspect that the perl6 numbers would suck, since the compiler does some pretty heavy pessimization. For example, I included the main loop at the end of the email, showing a number of painful things, including: - spilling inside the loop - re-initializing the constant zero on every iteration - putting things in PMC's only to take them out again Some of these would be easy to fix, but I think things need to advance more in the "features" and "stability" departments before going for speed. /s L_14: L_17: new P6, .PerlUndef set I0, 0 set P9, P31[1] #FETCH set N0, P9 new P0, .PerlUndef set P0, 0 set N1, P0 gt N0, N1, L_19 branch L_comparison18 L_19: set I0, 1 L_comparison18: set P6, I0 if P6, L_while_body20 branch L_while_end13 L_while_body20: L_15: new P6, .PerlUndef set P9, P31[1] #FETCH set P2, P31[3] #FETCH sub P6, P9, P2 clone P9, P6 set P31[1], P9 #STORE branch L_14 L_16: L_while_end13:
Re: of Mops, jit and perl6
At 07:57 PM 7/29/2002 -0700, Sean O'Rourke wrote: >On Mon, 29 Jul 2002, Dan Sugalski wrote: > > Just out of curiosity, I presume the (rather abysmal) perl 6 numbers > > include time to generate the assembly and assemble it--have you tried > > running the generated code by itself as a test? (At the moment, the > > assembler's rather slow) > >It's mostly the parser that's slow, not the assembler (about a second's >worth of startup time to load the grammar and do a bunch of The assembler _is_ still slow. It is faster than it was, but slow nonetheless, and unacceptable for "on the fly" assembly. Also, IMCC is to blame for some of the poor quality of the generated code. Eventually it will do proper loop invariant optimization among other things. Things can only get better from here. -Melvin
