of Mops, jit and perl6
Leopold Toetsch
1) perl6 driver program arrived in CVS/languages/perl6
CAVEATS: it generates a lot of intermediate files:
($filename.{warn,imc,pbc,pasm[,c,o,tree,])
an may therefore clobber e.g. mops.c if you run
languages/perl6> perl6 -C ../../examples/mops/mops.p6
So please test it in a copy of your CVS tree.
NB: source is a mess, but I wanted a quick start to get it running.
Thanks to Sean, for prd-perl and many hints.
and finally: perl6 will currently run only in languages/perl6
2) Some Mops numbers, all on i386/linux Athlon 800, slightly shortend:
(»make mops« in parrot root)
[lt@thu8:~/src/parrot-007/examples/assembly]
$ ../../parrot mops.pbc
M op/s: 18.270783
$ ../../parrot -j mops.pbc
M op/s: 363.468516
$ ./mops
M op/s: 196.355836
[lt@thu8:~/src/parrot-007/examples/mops]
$ ./mops
M op/s: 366.106527
[lt@thu8:~/src/parrot-007/languages/perl6]
$ perl6 ../../examples/mops/mops.p6
Iterations: 1000000
M op/s: 0.303587
$ perl6 ../../examples/mops/mops.p6 -Rj # run jit
M op/s: 1.148392
[lt@thu8:~/src/parrot-007/examples/mops]
$ perl mops.pl
Iterations: 10000000
M op/s: 2.22
(Iteration count for mops.pl was reduced, patch sent)
Summary:
Program
Mops
perl5.005_03
2.2
perl6
0.3
perl6 jit 1.1
parrot interpreted 18
parrot compiled 200
parrot jit 363
plain c 366
Remarks:
- jit is a lot faster then compiled
- plain mops.c is only slightly faster the jit, i.e. 1%
- perl6-jit, albeit still totally unoptimized, doesn't compare too bad
to perl5
- mops is a silly test ;-)
3) jit detection was broken, patch is on the way to bugs-parrot.
Have fun,
leo
Dan Sugalski
>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
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Sean O'Rourke
> 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:
Melvin Smith
>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
Leopold Toetsch
> 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)
No, these Mopsen are pure run time.
As Sean alredy stated, code quality is to blame.
Times for individual steps are:
$ time perl6 --imc mops.p6
real 0m1.794s
user 0m1.690s
sys 0m0.100s
$ time ../imcc/imcc mops.imc mops.pasm
327 lines compiled.
Compiling assembly module mops.pasm
real 0m0.032s
user 0m0.020s
sys 0m0.000s
[lt@thu8:~/src/parrot-007/languages/perl6]
$ time perl ../../assemble.pl mops.pasm > mops.pbc
real 0m0.481s
user 0m0.470s
sys 0m0.010s
This adds up to 2.3s to get a perl6 program running.
leo
Leopold Toetsch
> At 10:44 AM +0200 7/28/02, Leopold Toetsch wrote:
>
>> 2) Some Mops numbers, all on i386/linux Athlon 800, slightly shortend:
> Just out of curiosity, I presume the (rather abysmal) perl 6 numbers
After the bugfix in perlarray.pmc I can bring you new numbers, which are
not that abysmal.
Changing the while loop in mops.p6 to:
$I4 = $I4 - $I3 # sub I4, I4, I3
- while ($I4>0); # if I4, REDO
+ while ($I4); # if I4, REDO
(which is more correct, comparing to e.g. mops.pl)
$ time perl6 -Rj mops.p6
Iterations: 1000000
Estimated ops: 2000000
Elapsed time: 1.032118
M op/s: 1.937763
real 0m3.357s
user 0m3.190s
sys 0m0.150s
We have already the same Mops as perl5, but additionaly 2.3 seconds
overhead. Just running the byte code is as fast as perl5.
Without jit, mops.p6 performs at 0.8 Mops.
leo
Melvin Smith
>Dan Sugalski wrote:
>>Just out of curiosity, I presume the (rather abysmal) perl 6 numbers
>overhead. Just running the byte code is as fast as perl5.
>
>Without jit, mops.p6 performs at 0.8 Mops.
While I don't mind worrying about the compile time numbers, it is probably
way, way too early to be placing any value on MOPS numbers. We just
barely got a compiler patched together with gum and tape before TPC
and the code generated is t-t-t-terrible. Some of it is Sean's frontend
and some is my backend. Toss in the fact that the VM still unoptimized
in many areas and we basically have a LOT of work cut out for us.
So lets archive these numbers, and see how much we can improve on them
and not get too depressed. :)
[Both the front and back end compilers are apt to be rewritten anyway]
-Melvin
Leopold Toetsch
> On Sun, 28 Jul 2002, Leopold Toetsch wrote:
[ Mops ]
>>plain c 366
> You didn't use -O3 while compiling mops.c, did you?
No. Just Makefile's options as defined.
But interesting idea. It makes the inner loop look like this:
..L492:
decl %ebx
jnz .L492
and doubles the Mops ;-)
> Daniel Grunblatt.
leo