On Thu, Nov 01, 2001 at 12:18:18PM -0300, Daniel Grunblatt wrote:
> < while (pc) { DO_OP(pc, interpreter); }
> ---
> > just_do_it(interpreter,pc);
This is quite boring, I know, but could we have a definition of
this function? :)
(Also, I much prefer to see diffs in unified format - use
Look, now I'm rewriting a patch for pbc2c.pl which will use computed goto
*ONLY* in a few ops like jump or ret (or any other that modifies the
program flow) in all other cases it will stay with the actual goto model
which is ,in my opinion, the fastest.
# ./mops
Iterations:1
Estimated
OK then, here is the patch, of course I don't expect this to be commited
since it's crap but if you test it (please do it) and it's ok for everyone
I will rewrite it more efficiently.
*PLEASE* test it and give me some feedback.
Thanks in advance.
On Thu, 1 Nov 2001, Simon Cozens wrote:
> On Th
At 03:34 PM 11/1/2001 +, Leon Brocard wrote:
>Dan Sugalski sent the following bits through the ether:
>
> > For the Java-impaired (i.e. me :) what's the -Xint option do?
>
>It turns off the JIT (which is enabled by default).
Ah, thanks. Much as I hate it (because the numbers are so lousy) I t
On Thu, Nov 01, 2001 at 10:31:07AM -0500, Dan Sugalski wrote:
> So it looks like about a 2.5 speedup with computed goto. Cool.
Looks really good to me, too. Where's the patch? This should probably
go in as an alternate runops core.
--
The problem with big-fish-little-pond situations is that you
Dan Sugalski sent the following bits through the ether:
> For the Java-impaired (i.e. me :) what's the -Xint option do?
It turns off the JIT (which is enabled by default).
Leon
--
Leon Brocard.http://www.astray.com/
Nanoware...http://www.
Daniel Grunblatt wrote:
> I have tested times using computed goto in the interpreter and here are
> the results:
>
> # ./test_prog mops.pbc
> Iterations:1
> Estimated ops: 3
> Elapsed time: 8.604721
> M op/s:34.864582
Yes, I wrote a poor-man's computed goto versio
At 09:45 PM 10/31/2001 -0300, Daniel Grunblatt wrote:
>I have tested times using computed goto in the interpreter and here are
>the results:
>
># ./test_prog mops.pbc
>M op/s:34.864582
>
># java -Xint mops
>M op/s:30.950170356876555
>
>Just for the records, this is with the current
Daniel Grunblatt:
# I have tested times using computed goto in the interpreter
# and here are
# the results:
#
# # ./test_prog mops.pbc
## M op/s:34.864582
#
# # java -Xint mops
# M op/s:30.950170356876555
Holy $#!+...
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
I have tested times using computed goto in the interpreter and here are
the results:
# ./test_prog mops.pbc
Iterations:1
Estimated ops: 3
Elapsed time: 8.604721
M op/s:34.864582
# java -Xint mops
Iterations:1
Estimated ops: 3
Elapsed time: 9.6929
At 06:54 PM 10/30/2001 -0600, Kevin Huber wrote:
>The code density is one thing that surprised me. Even with 4 byte
>opcodes and arguments, pbc is very reasonable.
Code density's the place where perl's always had a big win. Either an
interpreter's got a very limited set of ops (to fit in a byte
> I have an Athlon 700 too. With these compiler flags:
>
> PERL-CFLAGS = -O3 -fomit-frame-pointer -pipe -s -march=pentium -ffast-math \
> -fexpensive-optimizations -fno-strict-aliasing \
> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
>
> I'm seeing 24 mops which puts Parrot even cl
At 09:46 AM 10/30/2001 -0500, Ken Fox wrote:
>Kevin Huber wrote:
> > This is a comparison of mops running on Parrot (-O6 on an Athlon 700)
> > versus Java JDK 1.4.0 beta 2 jitted and interpreted. You can see that
> > Parrot performance is very comparable to Java in interpreted mode.
>
>I have an
Kevin Huber wrote:
> This is a comparison of mops running on Parrot (-O6 on an Athlon 700)
> versus Java JDK 1.4.0 beta 2 jitted and interpreted. You can see that
> Parrot performance is very comparable to Java in interpreted mode.
I have an Athlon 700 too. With these compiler flags:
PERL-CFLAG
Kevin Huber sent the following bits through the ether:
> Parrot2Java which I will make available once I fix a few more bugs
> :-).
Oh, cute! I've been frustrating myself by trying to do it the other
way around (it'll happen eventually...). Optimising the stack
loads/saves will be the fun part
This is a comparison of mops running on Parrot (-O6 on an Athlon 700)
versus Java JDK 1.4.0 beta 2 jitted and interpreted. You can see that
Parrot performance is very comparable to Java in interpreted mode.
I've attached mops.class and mops.ksm, some disassembly output from
Kopi. mops.class was
16 matches
Mail list logo
