On 23 April 2011 14:24, nalaginrut <nalagin...@gmail.com> wrote: > I think this simple solution could be a temporary substitute before a > AOT guile-compiler come out. To myself, I really want to use a AOT > compiler to do such a job(it's better for optimizing the code).
Just to clear up a seemingly common misconception. Those writing an aggressively optimising compiler like to see two things: 0. Information. The more code you can see at a time the better, as it enables you to see how functions are used; you can see this in whole-program AOT compilers and modern JIT compilers such as hotspot, which inlines very aggressively in order to obtain more data. Information about the data these functions get applied to can be useful as well, as can be seen from high-quality SQL query plan optimisers, and the latest linear algebra libraries. 1. Room to breathe. Once the language semantics are specified and what effects are user-visible can be determined, the rest of the universe is room to optimise! For example, memory models are now often chosen as a balance between sensible semantics for the programmer and behaviour that has small enough impact on the runtime. Now, the effect that these points are having on modern compiler and runtime design should tend towards: * AOT will get you half way there. In embedded systems it may be entirely suitable, but those environments are also the ones where whole-program compilation is possible. Where separate compilation is desired, there are often more opportunities to optimise as dependent modules are compiled, and even more opportunities once the working-set and cache size, typical loop bounds, branch popularity etc can be discovered, and many of these things may change across different program inputs, so static compilation is unlikely to reach the quality of code that dynamic compilation provides. * Where calls into unsafe code occur, the semantics of the operation are entirely unknown. Thus the optimiser needs to assume that the code may do absolutely anything it pleases. It can mean that what might have been loop invariant or heavily partially evaluated cannot be. To consider the impact that this actually has, the value bound to a symbol in the current module cannot be assumed to be constant across an external call, preventing inlining pretty much everywhere. What occasionally happens is that code written entirely within the language that a smart runtime is able to inspect tends to be faster than that which is in idiomatic C. -- William Leslie
