> 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 closer to Java. Do those
> flags improve your times? I top out at about 21.8 with your flags, and about the same with some optimization flags I've used before: -I./include -s -O3 -fomit-frame-pointer -pipe -Wall -mpentiumpro -march=pentiumpro -funroll-loops -fexpensive-optimizations -fno-strict-aliasing -ffast-math -fschedule-insns2 -mwide-multiply I'm running egcs-2.91.66 which could be older than your compiler, or my computer may just be a little slower than yours! I get from 398-402 with pbc2c. > When you run mops.pbc through pbc2c what kind of performance do > you get? > > I have a feeling that Parrot will end up with higher code density > than a JVM so performance in "real world" cases will be better. Of > course most of the effort in Java is going into JIT, so shooting for > JVM interpreter speeds is likely to be shooting way too low. I'm agree. I was just curious if it was in the ballpark. mops isn't really a good benchmark either. The code density is one thing that surprised me. Even with 4 byte opcodes and arguments, pbc is very reasonable. I don't think it will be possible to get within an order of magnitude of C or Java+JIT without a JIT or some precompilation to native code, though I would be interested to see how a better dispatch or alternate register file scheme works. I haven't had much opportunity to analyze the interpreter, but it sounds like you guys are much more knowledgeable. Writing a VM from the bottom up sounds like a great opportunity to make optimization easier, rather than, say, trying to make a Java VM fast where you're stuck with a legacy virtual machine architecture. -Kevin
