Le 26/05/2010 00:26, Rémi Forax a écrit :
Le 25/05/2010 20:27, Charles Oliver Nutter a écrit :
I'm sure this doesn't need pointing out, but performance numbers for
an experimental new language that carries none of the baggage of
existing languages (especially languages not originally written for
the JVM) is a bit suspect :)
You're right.
I've designed the language to perform well on JVM and
not port an existing language.
It's unfair :)
Going on to claim that JVM language developers' "house is burning"
because your language has started to do math faster (and not
drastically faster, I'd add; even Java's only 4x faster than JRuby on
this benchmark) is probably going a bit far.
It don't only do math faster. I do all codes that use primitives faster.
math is just an example.
I have a small problem. I currently hit easily the limit of 10
argument max for a method handle imposed by the current state
of the jdk7 that why I have to limit the test to only small benchmarks.
Of course you've seen numeric benchmarks I wrote for the dynamic
language Surinx that were many times faster than JRuby, but of course
Surinx wasn't Ruby and I wouldn't claim that there's something Surinx
was doing (using JSR292) that could potentially improve JRuby the same
amount. Duby now supports dynamic invocation and performs very well
with JSR-292, but again there's no real comparison...it's not Ruby.
My point is not that JSR292 directly help to have better performance,
it most probably will. But above all, it drastically simplify the code
of the runtime
and let us to focus on what is in my opinion more important i.e provide
good profile type information to the VM.
I you write a runtime compiler that is able to optimize/deopt and reopt
when necessary based on type profiling.
You will get a boost. This is applicable for any dynamic languages.
JSR-292 is obviously very exciting work, especially if it can optimize
primitive call paths straight through without any boxing along the way
(something that's very difficult for most dynlangs on JVM). Are you
able to get the same performance using the 292 backport on Java 6?
Those of us with users need to continue supporting the JVMs they
run...
No, I haven't the same perf with the backport.
The perf are better :)
1.3178402348194146E24
real 0m16.291s
user 0m18.500s
sys 0m0.179s
Rémi
Hum, I was a little bit optimistic about the perf of the backport.
Perf are not good for short time lived script.
(phpr16.sh -> phpr for 1.6 VM, phpr.sh -> phpr for 1.7 VM)
[fo...@localhost phpreboot]$ time bin/phpr16.sh
test/testtraceoptimistic2.phpr
61075
0123456789101112131415161718192021222324252627282930313233343536373839...
real 0m2.004s
user 0m3.633s
sys 0m0.196s
[fo...@localhost phpreboot]$ time bin/phpr.sh
test/testtraceoptimistic2.phpr
61075
0123456789101112131415161718192021222324252627282930313233343536373839...
real 0m0.296s
user 0m0.277s
sys 0m0.088s
Rémi
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.
