Odd JIT timings
Dan Sugalski
performance numbers. Here's an interesting timing.
no jit: 24.9 seconds
with jit: 33.6 seconds
This is... odd. And on PPC, FWIW, and I'm not sure if it happens on x86.
Someone care to check it out and poke around a bit?
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Douglas Hunter
> I just gave a run of examples/assembly/mops_p.pasm, getting some
> performance numbers. Here's an interesting timing.
>
> no jit: 24.9 seconds
> with jit: 33.6 seconds
>
> This is... odd. And on PPC, FWIW, and I'm not sure if it happens on x86.
I'm pretty new to this, so I apologise if this is useless information.
perl assemble.pl examples/assembly/mops_p.pasm > mops_p.pbc
./parrot mops_p.pbc
Iterations: 100000000
Estimated ops: 200000000
done
Elapsed time: 53.746114
M op/s: 3.721199
./parrot -j mops_p.pbc
Iterations: 100000000
Estimated ops: 200000000
done
Elapsed time: 4.450022
M op/s: 44.943598
I'm running Linux 2.4.19 on x86, gcc 3.2. My Parrot is a fresh
checkout/build within the past hour.
>
> Someone care to check it out and poke around a bit?
'Fraid I probably wouldn't be of much use there.
Douglas
Leopold Toetsch
> I just gave a run of examples/assembly/mops_p.pasm, getting some
> performance numbers. Here's an interesting timing.
>
> no jit: 24.9 seconds
> with jit: 33.6 seconds
>
> This is... odd. And on PPC, FWIW, and I'm not sure if it happens on x86.
>
> Someone care to check it out and poke around a bit?
$ languages/imcc/imcc examples/assembly/mops_p.pasm
Iterations: 100000000
Estimated ops: 200000000
done
Elapsed time: 20.521627
M op/s: 9.745816
$ languages/imcc/imcc -j examples/assembly/mops_p.pasm
Iterations: 100000000
Estimated ops: 200000000
done
Elapsed time: 3.261104
M op/s: 61.328924
It depends on implemented functions in JIT. i386 has a bunch of vtable
functions JITed (which isn't too hard to do).
leo
Daniel Grunblatt
> I just gave a run of examples/assembly/mops_p.pasm, getting some
> performance numbers. Here's an interesting timing.
>
> no jit: 24.9 seconds
> with jit: 33.6 seconds
>
> This is... odd. And on PPC, FWIW, and I'm not sure if it happens on x86.
>
> Someone care to check it out and poke around a bit?
CG vs JIT (running with non jitted opcdes) wins CG, always.
Daniel Grunblatt.
Dan Sugalski
Ah, OK. No function preambles/postambles in the CG case. Hrm, time to
go learn PPC assembly, I guess... :)
Bruce Gray
>At 11:55 AM -0300 1/24/03, Daniel Grunblatt wrote:
>>On Friday 24 January 2003 04:43, Dan Sugalski wrote:
>>> I just gave a run of examples/assembly/mops_p.pasm, getting some
>>> performance numbers. Here's an interesting timing.
>>>
>>> no jit: 24.9 seconds
>>> with jit: 33.6 seconds
>>>
>>> This is... odd. And on PPC, FWIW, and I'm not sure if it happens on x86.
>>>
>>> Someone care to check it out and poke around a bit?
>>
>>CG vs JIT (running with non jitted opcdes) wins CG, always.
>
>Ah, OK. No function preambles/postambles in the CG case. Hrm, time to
>go learn PPC assembly, I guess... :)
IBM hosts a tutorial on Linux PowerPC assembly, with links to
instruction set, ABI, and optimization:
http://www-106.ibm.com/developerworks/linux/library/l-ppc/
You were probably joking, but my knee jerked :)
--
Hope this helps,
Bruce Gray
Dan Sugalski
Yow! Cool, thanks!
Leopold Toetsch
> At 11:55 AM -0300 1/24/03, Daniel Grunblatt wrote:
>> CG vs JIT (running with non jitted opcdes) wins CG, always.
> Ah, OK. No function preambles/postambles in the CG case. Hrm, time to go
> learn PPC assembly, I guess... :)
Ne need to have a deep understanding of $arch's assembly for
implementing the vtable calls. It's almost only:
- prepare stack frame
- push value
- push address
- call a vtable function indexed by x
- get return value (opt)
- save return value (opt)
s. jit/i386/jit_emit.h:Parrot_jit_vtable_*()
Of course, you should know, how to prepare arguments for function calls
and call a function. But debugging an -O3 compiled parrot and "stepi"
does help a lot - so did I learn it ;-)
And of course:
$perldoc docs/jit.pod
/Debugging
leo
Dan Sugalski
Heh, I'm not worried--it certainly won't be the first assembly
language I've learned. :) Just a matter of getting the time to do it,
which is the bigger problem. Pity the automagic .s parsing code in
JITv1 didn't ultimately work out...
Leopold Toetsch
> At 8:14 PM +0100 1/24/03, Leopold Toetsch wrote:
>> Of course, you should know, how to prepare arguments for function
> Heh, I'm not worried--it certainly won't be the first assembly language
> I've learned. :)
I knew that.
> Just a matter of getting the time to do it, which is
> the bigger problem.
And guessed this too :-)
> ... Pity the automagic .s parsing code in JITv1 didn't
> ultimately work out...
Trial to (ab?)use gcc for generating JIT code, probably.
But:
mops.pasm:
JIT/i386
~800 MOps at 800 MHz Athlon i.e. 1 op/cycle
gcc -O3 (native code) ~300 Mops
Of course this doesn't give real time program values, but shows some
optimization potential for tight loops where loop variables can be
reduced to bo native integers.
And of course JIT code is not "J" like just, one code segment get's
JITed and no there is no run loop, all instructions need the space they
occupy, which is currently (size in bytes, with PBC size in ops):
jit.c:838
/* estimate size needed
* 10 times pbc code size seems to be enough for i386
*/
... but computers tend to have more RAM, and the more the fast.
leo