[CVS ci] indirect register frame 1 - 5
Leopold Toetsch
registers. The last patch also introduces a new define in
include/parrot/settings.h:
#define INDIRECT_REGS 0
It's default value is still off. But turning it to 1 will use the
indirect access of Parrot registers through a pointer.
With that setting turned on, Parrot still compiles cleanly on i386/linux
and ppc/OS X. It fails a lot of tests though, because e.g. coroutines
don't have a separate register set yet.
But this setting is not intended to run tests - there is no register
frame stack yet. This additional indirection should just test, if Parrot
still compiles cleanly.
The mentioned JIT platforms with explicit access to registers will fail
and need patching for example.
If you try to compile Parrot with that setting tuned on, don't forget to
"make clean".
Thanks,
leo
Dan Sugalski
>A serious of patches has now eliminated all direct usage of Parrot
>registers. The last patch also introduces a new define in
>include/parrot/settings.h:
>
>#define INDIRECT_REGS 0
>
>It's default value is still off. But turning it to 1 will use the
>indirect access of Parrot registers through a pointer.
>
>With that setting turned on, Parrot still compiles cleanly on
>i386/linux and ppc/OS X. It fails a lot of tests though, because
>e.g. coroutines don't have a separate register set yet.
What're we looking at for performance impact on mops.pasm and the
other simple benchmarks? (We've apparently been slowly slowing down
over the past months, which I'm not happy about)
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Leopold Toetsch
> What're we looking at for performance impact on mops.pasm and the
> other simple benchmarks?
I didn't look yet. Compiling optimized takes ages here :) Anyway:
Estimate performance impact:
JIT mops.pasm 0 (i386, PPC)
CGP mops.pasm 0 - 1%
plain mops.pasm 0.5% (PPC) - 3% (i386)
The numbers for the plain function core are from docs/nanoparrot.c with
and w/o -DINDIRECT.
> ... (We've apparently been slowly slowing down
> over the past months, which I'm not happy about)
Pure function call speed decreased by ~300%. Taking now max. 3% and
catching up with function call speed is worth the effort.
If anyone wants to try: all run cores except JIT should be able to run
the mops benchmark with INDIRECT_REGS enabled.
leo
Leopold Toetsch
> What're we looking at for performance impact on mops.pasm and the other
> simple benchmarks?
I've now JITted mops.pasm (and other code) running with indirect
register access. It did slow down, but not because the additional
indirection (all inner loop code is still in registers), its's because
of the darned alignment problem on my old Athlon.
Due to the indirect register addressing, the code is a bit longer now,
which moved the loop to <jit_func + 190>. Rearranging the initialization
code (using shorter instructions) brought the loop to <jit_func+162>,
where it's executing as fast as before.
parrot -C mops.pasm runs (unoptimized build) still at 82.7 MOPS on my
800 Mhz - no remarkable slowdown to 83.0 w/o indirection. Perl and
Python are at 2 MOPS for that benchmark - raw execution speed (opcode
dispatch) isn't a problem.
leo