4 ms·
"Blackhole" interpreter in PyPy: new optimization in PyPy 1.3
- yanowitz 16y agoFascinating article, I love compiler design. I wonder if code cache locality (of the interpreters) ever becomes and issue or is that level of concern irrelevant because that's ages away from being the bottleneck. What other issues (besides maintainability) does this approach have.
- megaman821 16y agoVery cool stuff, but in what situation does the code run the same for one thousand times or more and then all of a sudden cause a guard condition to fail. I know it must happen with some frequency, hence the blackhole interpreter, but what is the most common scenario?
- janzer 16y agoI'm not directly involved at all. But what comes to my mind is a loop exit condition or more accurately, and by definition I suppose, any trace exit.
- fijall 16y agoThe thing is in case of tracing you don't record all paths taken, just the one at the hot point. So say you have if that takes every path every second go, the JIT will compile just one path at first. Then the guard will fail every second iteration, hence the blackhole. Of course at some point JIT will realize guard fails often enough and will compile another path, so you'll get a tree. And so on...
- losethos 16y agoThis sounds like bull-shit. I did a compiler in losethos, http://www.losethos.com http://www.losethos.com and it's rediculous to think measuring how many loops before doing a true compile is useful. Trust-me, it's easier just to compile the whole thing. I made one compiler for LoseThos that is JIT or AOT and this is bull-shit about making multiple ones. If you have a JIT compiler, you certainly don't need to fuck around with an interpretor as well.