Re: optimizing with feedback, was Native/VM languages

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.
http://docs.hp.com/en/B3901-90023/ch02s16.html#bgbdgifg


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
application.


Because Kevin's presentation was an invited keynote session, there is no
paper in the conference proceedings, but his slides are available at
http://www.cgo.org/cgo2006/html/StoodleyKeynote.ppt




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.


Jeremy

Return to the comp.compilers page.
Search the comp.compilers archives again.