On 12/05/2010 04:58 PM, Subbu Sastry wrote:
On Dec 4, 9:08 am, Rémi Forax<[email protected]> wrote:
On 12/04/2010 03:08 PM, Guillaume Laforge wrote:
On Sat, Dec 4, 2010 at 13:51, Charles Oliver Nutter
<[email protected]<mailto:[email protected]>> wrote:
[...]
> This is equivalent to implement your own EA + inlining
> in your runtime instead of relying on the EA done by hotspot.
Perhaps, except that implementing my own EA + inlining is a lot harder
:) My primary goal with JRuby optimization is to just get all the
pieces in the right place so that the JVM can do the rest. I don't
want to write my own optimizers if I can help it.
What about writing your own VM? ;-)
Because
I don't want to write a generational copy-collector GC
in fact, I don't want to debug it :)
I don't want to write a register allocator
+ all the optimizations done on SSA nodes
I don't want to know how to implement memory
fences on multiple hardware architectures.
I don't want to do all that stuff alone with no
community support.
That's why I use the JVM.
But this approach has one main drawback.
The input of the VM is the bytecode is typed [1],
like any assembler.
So any runtime of a dynamic language has only one
thing to do, transform the dynamic language to
a typed bytecode.
I am not convinced that this is fully true. I think for all
practical purposes, as far as implementing languages on top of the VM,
we can forget the fact that the JVM is actually software and treat it
as an implementation target. Much in the same way that CPU micro-
architectures implement a whole host of sophisticated optimizations to
speed up the execution of machine code, and that doesn't eliminate the
need to implement a whole host of optimizations in the JVM, I dont
think you get performance for free simply because you target the JVM.
Just as a CPU frees the JVM implementer from having to implement
certain kind of optimizations (because of branch prediction, caches,
instruction scheduling, etc.), the JVM frees the dynamic language
implementer from having to worry about certain kind of opts (GC,
allocation, targetting a large variety of CPUs, etc). The JVM cannot
optimize the semantics of the dynamic language. That is the job of
the VM that is implemented on the JVM. I agree that the VM has to be
judicious about what it does, but that is no different from the JVM
having to be judicious about what it does based on the characteristics
of the CPU it is targetting. So, while the JVM is extremely smart, it
can optimize only so much (till the JVM get so smart as to realize the
promise of the Futamura projections :) at which time implementers of
dynamic languages can satisfy themselves with writing an interpreter).
So, while it is true that the runtime of a dynamic language has to
transform the dynamic language to a typed bytecode, I think it also
means that the rntime has to implement any optimizations (inlining,
type guards, unboxing, EA, etc.) in the dynamic language VM which the
JVM cannot see through.
My first point is that the ability to statically type a dynamic
language is a silver bullet optimization. So it's a must have.
Otherwise, the runtime should not try to implement any optimizations
but a selective list known to improve the performance.
By example, implementing loop-unrolling is stupid, the JVM already
does a great job here.
So the question at 1.000.000 $ is which optimization should be
implemented ?
Subbu.
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.
