|Native/VM languages email@example.com (2008-08-25)|
|Re: Native/VM languages firstname.lastname@example.org (Marco van de Voort) (2008-08-27)|
|Re: Native/VM languages email@example.com (firstname.lastname@example.org) (2008-08-27)|
|Re: Native/VM languages email@example.com (Jeremy Wright) (2008-08-28)|
|Re: Native/VM languages firstname.lastname@example.org (glen herrmannsfeldt) (2008-08-28)|
|Re: Native/VM languages email@example.com (2008-08-29)|
|Re: Native/VM languages firstname.lastname@example.org (cr88192) (2008-08-30)|
|Re: Native/VM languages email@example.com (glen herrmannsfeldt) (2008-09-03)|
|From:||Jeremy Wright <firstname.lastname@example.org>|
|Date:||Thu, 28 Aug 2008 14:45:39 +0000 (UTC)|
|Posted-Date:||28 Aug 2008 17:33:40 EDT|
Kevin Stoodley, also of IBM, presented this basic thesis at CGO 2006
in New York, though he generalized it to all languages.
His key points were
1. dynamic compilers can generate code for the precisely the chipset
being used. Most compilers generate code aimed at the common subset of
slightly different models, with scheduling that is hopefully good on
all, but not necessarily optimal on any.
2. profile directed feedback is a very powerful optimisation. Dynamic
compilation does automatically and does it particularly well because
the data set used for the profiling is the live run. The standard
"compile ; run collecting data; recompile with PDF" cycle can suffer
from artefacts in the data set used to "train" the PDF.
A dynamic compiler certainly can produce better code than an AOT
compiler. There is nothing to stop a dynamic compiler doing all the
static analysis a static compiler would do, and save this information
for use by the dynamic compilation system. The question is whether the
dynamic compiler will in practice produce better code, and whether
this offsets the start up and recompilation overhead.
Return to the
Search the comp.compilers archives again.