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?
>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.
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.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2008:
http://www.complang.tuwien.ac.at/anton/euroforth/ef08.html
|
