Related articles |
---|
Native/VM languages borophyll@gmail.com (2008-08-25) |
Re: Native/VM languages marcov@stack.nl (Marco van de Voort) (2008-08-27) |
Re: Native/VM languages ldv@mail.com (ldv@mail.com) (2008-08-27) |
Re: Native/VM languages jeremy.wright@microfocus.com (Jeremy Wright) (2008-08-28) |
Re: Native/VM languages gah@ugcs.caltech.edu (glen herrmannsfeldt) (2008-08-28) |
Re: Native/VM languages torbenm@pc-003.diku.dk (2008-08-29) |
Re: Native/VM languages cr88192@hotmail.com (cr88192) (2008-08-30) |
[1 later articles] |
From: | borophyll@gmail.com |
Newsgroups: | comp.compilers |
Date: | Mon, 25 Aug 2008 21:40:27 -0700 (PDT) |
Organization: | Compilers Central |
Keywords: | interpreter, VM, Java, performance, question |
Posted-Date: | 26 Aug 2008 23:32:20 EDT |
While I know that it is possible for a language (such as Java) to be
compiled both natively and to bytecode to be run on a VM, I have read
that over time, a natively compiler Java program (AOT compiler) will
be less efficient than the same JIT-compiled Java program (http://
www-128.ibm.com/developerworks/java/library/j-rtj2/index.html).
While AOT-compiled code will have a faster start-up time and smaller
memory footprint than JIT compiled code, once the program has been
running for some time the JIT code will have better performance. The
article argues that this is because the compiler can optimize routines
to a level beyond that can be acheived using static compilation, by
using run-time knowledge.
The gist of the article is that JITted code will have better
performance than native code, even C/C++, but gives no figures to
indicate how much exactly. Does anyone have any solid figures/stats
on what percentage performance increase can be acheived by JIT code.
I am wanting to know if the benefits are significant. I am still to
be convinced that it is worthwhile, because you have to consider the
'warm-up' performance degradation, which is not always acceptable.
Regards,
B.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.