On 27 August 2013 04:30, Jonathan S. Shapiro <[email protected]> wrote: > On Mon, Aug 26, 2013 at 9:12 AM, Bennie Kloosteman <[email protected]> > wrote: >> Im not really convinced by the JIT model anymore ..the promised >> optomizations seem to have stalled or require so much time to work out that >> its inpractical to use in a JIT . > > > I'm not sure what promised optimizations you refer to. The original JITS > merely promised that compiling was better than interpreting, which it > generally is. Later ones played with trace-driven inlining and optimization. > The payoff for that was less clear. Then you get to hotspot, which is trying > to do value driven optimizations. That's a line whose benefit has always > seemed dubious to me, and my opinion on that goes all the way back to the > Ungar's early work on self. It seemed to me then that the desire for > value-driven optimization was motivated by Self's refusal of static typing, > and that this was a case of one bad decision mandating a second one to > justify the first one. Robert McNamara would have approved.
It's also an argument about composition. For someone working on dynamic language runtimes, this seems most obvious; if you provide me with a directive that I can attach to my source code that says 'unroll this loop' or 'partially evaluate against this argument', you might think you've done a good job, but if I can't then provide that same feature to the client program it's only half of a solution. Why should the data that a compiler take advantage of be limited to types and some airy-fairy determination of loop bounds? > But on a less snarky note, I'm not aware of any work on static > metacompilation in such languages. There are definitely cases where > value-driven optimization is a big win, but I haven't seen any work that > would clearly tell me which cases those are. I'm inclined to wonder whether > these are the cases that metacompilation handles well. Now I know that lisp people would probably talk about string formatting or regex when the grammar is constant and the great speed-up you get. We had an oddly excited blog post about getting the same sort of speedup in pypy for constant grammars and format strings. What other grammar structures might we be able to optimise for? The case I might make is that something that understands deeply the nature of code - the compiler - might be able to do a better job at recognising patterns that it can optimise than someone writing a compiler macro, because there only needs to be one compiler. This is vaguely what value-driven optimisations are about and why they are important. > Just to be clear, I do know that the hotspot technology can do things that > metacompilation cannot. The bit I'm not clear about is what the real payoff > is. Finding decent heuristics about the quality of value-driven optimisations is still really an open question AFAIK. I also think that choice of object representation and high-level features can severely impact the quality of those features, to the point where such heuristics don't apply very widely. As an example, early releases of pypy's current jit kept a version number on the class, so that if people did anything that could invalidate either inlined methods or the shape maps that shortcut attribute lookup, dependant code would be recompiled on entry. Of course, mutation of class attributes is not that uncommon. The result was that benchmarks are easy to create that spend /most/ of their time compiling, because the class version number guard fails on every iteration, just because some count variable changed. Stories about code explosion in PE systems are not uncommon either. Blah blah premature optimisation this extensive templating that - neither the hacker nor the compiler really knows what is going to give the better result in the typical case and probably nobody really does. -- William Leslie Notice: Likely much of this email is, by the nature of copyright, covered under copyright law. You absolutely may reproduce any part of it in accordance with the copyright law of the nation you are reading this in. Any attempt to deny you those rights would be illegal without prior contractual agreement. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
