|Re: Native/VM languages firstname.lastname@example.org (glen herrmannsfeldt) (2008-08-28)|
|Re: optimizing with feedback, was Native/VM languages email@example.com (Jeremy Wright) (2008-08-29)|
|From:||Jeremy Wright <firstname.lastname@example.org>|
|Date:||Fri, 29 Aug 2008 12:50:22 +0000 (UTC)|
|Posted-Date:||29 Aug 2008 12:37:56 EDT|
Glen Herrmannsfeldt wrote:
> How about instead the ability to save profile information after
> running a program, or cumulatively after multiple runs, and then use
> that for a static recompilation.
That is exactly what static compilers that use PDF do today - e.g.
The problem is that at some point one decides to use that information to
build the "production" binary, and you stop collecting flow data. If the
characteristics of the application change your flow information may not be
representative. Worse happens if the data initially used were unrepresenative
in some fashion.
Kevin Stoodley gave an example of such an issue. If memory serves correctly,
in the example given, the path for alloc(10000) was particularly optimized
because of an artefact of the test data.
Which reminds me of another point Kevin made. In Unix at least, many parts
of the OS are in user space - so for instance most of alloc is in user space,
calling the system sbrk() if required. Kevin advocated these parts of the
OS should also be able to be dynamically recompiled to adapt to the
Because Kevin's presentation was an invited keynote session, there is no
paper in the conference proceedings, but his slides are available at
It is a pain that scheduling startegies, and even the ISA, change over time
within chipsets. Unfotunately, unlike compiler writers, hardware engineers
occasionally make the wrong choice ;-) and have to make a different choice
in the next chipset.
Return to the
Search the comp.compilers archives again.