Anton Ertl <anton@[EMAIL PROTECTED]
> wrote:
> Andrew Haley <andrew29@[EMAIL PROTECTED]
> writes:
> >Anton Ertl <anton@[EMAIL PROTECTED]
> wrote:
> >
> >> Another Java myth I have read is that the JIT results in faster code
> >> than possible with static compilation, because:
> >
> >> 1) It knows exactly which CPU it is compiling for, whereas a static
> >> compiler typically generates code that runs on all CPUs and does not
> >> run too badly on any of them (and maybe even optimized for a
different
> >> one than you have).
> >
> >> 2) It knows how the program is used at run-time and can optimize for
> >> that usage, and adapt to changing usage patterns.
> >
> >> Yet, these advantages do not seem to outweigh the overheads of JIT
> >> ompilation. AFAIK Andrew Haley is still working on static Java
> >> compilation.
> >
> >I am, but I don't think that these really are myths. There's no doubt
> >in my mind that run-time optimizations can be a spectacular win.
> Sure they can be. But are they, in the typical case?
I think so. I don't know for certain.
> >It's hard to compare, because programming styles are so different
> >with Java and languages that don't usually use GC and aren't
> >type-safe, for example C++.
> Since you are working on static Java compilation, and others on
> run-time compilation, it seems quite simple to compare, no? Just
> run the same program once with GCJ and once with
> Hotspot/J9/whatever.
Hotspot will win that one for sure, unless the program doesn't run for
long. It's using essentially the same optimization framework as any
other modern compiler, and it has more information about the program.
But that doesn't tell you much about the approaches: the programs
written by experts in Java and C/C++ are very different because the
tools they use and their styles are so very different.
> Concerning differences in performance between Java and C++,
> programming style issues certainly play a role (I call that
> "idiomatic (in)efficiency"), but there's also built-in
> (in)efficiency (e.g., not being able to embed objects directly in
> arrays in Java) and other effects. However, I believe that
> idiomatic (in)efficiency dominates.
So do I.
Andrew.
|
