"Blackhole" interpreter in PyPy: new optimization in PyPy 1.3

http://morepypy.blogspot.com/2010/06/blackhole-interpreter.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+PyPyStatusBlog+%28PyPy+Status+Blog%29&utm_content=Google+Reader

by stephenjudkins • 16 years ago

30 4 16 years ago

morepypy.blogspot.com

yanowitz• 16 years ago

Fascinating 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• 16 years ago

Very 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• 16 years ago

I'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• 16 years ago

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

"Blackhole" interpreter in PyPy: new optimization in PyPy 1.3

Related Stories