Hello! Lluís Vilanova <vilan...@ac.upc.edu> skribis:
> Ludovic Courtès writes: > >> Hello! >> Lluís Vilanova <vilan...@ac.upc.edu> skribis: > >>> Still, this mail made me think if optimizations based on "tracing" (or any >>> kind >>> of runtime-based profiling) could be nested. Then you could start by >>> applying >>> the existing compiler optimizations, later generate a procedure/trace >>> version >>> dispatcher with unboxed operations (you can add new versions as they become >>> hot), and only at the end generate native code. > >> I’m not sure what you mean by “nested”. What tracing JITs and Nash do >> is collect execution traces, and trigger native code compilation once a >> given segment of code (a loop body) has been executed a number of times. >> The generated code is specialized according to that trace. > > By nesting I mean applying different optimizations at different thresholds, > but > all based on tracing the executed code. Aka, the hotter it gets, the more you > try to optimize it. > > Also, is it absolutely necessary to implement the tracing on the VM? Can't it > be > done by adding a new opcode to the VM to compute the statistics? Then you can > add that opcode to any region of code, like procedure or loop iteration > prologues. Also, then you can do so from a higher-level language that does > have > the concept of loops, instead of inferring them from jump offsets. Dunno. I like the hook approach because it’s very simple and orthogonal. From a Guile maintenance viewpoint, those hooks are something we can provide at no cost; conversely, providing a special opcode to gather traces would change a core aspect of Guile (the VM instruction set) and would be quite a commitment that we’d rather not make. Disclaimer: I haven’t worked on this and Atsuro would know the answer better. :-) Ludo’.
