Nicely written.

Interesting that you mention that the optimization tricks a compiler does by knowing types at compile time go away. I remember reading not long ago in a post by Steve Yegge (yes I do have too much free time that Java's JIT compiler strips away all compile-time information and uses the run-time information to generate even better optimized bytecode.

The forebear of all this being of course, as you mention, Smalltalk, which from what I've read has an excellent run-time optimized interpreter.

Interesting times coming
Orestis Markou | Homepage | 08/08/14 - 10:51 pm | #

Well, the Java JIT is based on Strongtalk...

Those who claim that dynamic languages may be able to run faster than statically typed languages is because much more is known about a dynamic language at runtime than is known about code in a statically typed language at compile time though.

The principle still holds currently though. With a statically typed language, when you call 'x.method()' the 'runtime' (or compiler) knows the address of 'method' since it is statically bound.

With Python or a dynamic language there are a complex set of rules about how to find the method. Polymorphic inline caches are one of the techniques that can be used to optimize this - most of the time a method lookup will return the same method, and you only have a cache miss on the rare occasions that the most dynamic features of the language are used.
Michael Foord | Homepage | 08/08/14 - 11:16 pm | #

In Jython, str and unicode both use java.lang.String to back their storage, although unicode is surrogate aware. This means we use 16 bit chars to store 8 bits of info, which is rather wasteful. And with the latest version of 2.5, we then carefully ensure all encode/decodes from str to unicode will go through the same codecs as specified by Python, etc. This even leads to the same ridiculous scenario, as seen recently in Django, that we cannot in general use cStringIO safely for unicode. Unfortunately fixing that would lead to other problems.

So it's a bunch of bother to ensure compatibility. Needless to say, going to 3.0 would be rather welcome for this aspect alone. But that's going to be a while!
Jim Baker | Homepage | 08/08/15 - 2:35 am | #

... "Having said that"

Twice
Anonymous | Homepage | 08/08/15 - 7:32 am | #

frames are not an implementation detail. Others mentioned are. One of the reasons why is that, is because you cannot build a debugger at app-level not having frame access and python is meant to be ultimately introspectible language.

Cheers,
fijal
fijal | 08/08/16 - 9:09 am | #

I disagree - stack frames are necessarily an implementation detail of the interpreter internals. IronPython is debuggable with .NET debugging tools for example. It doesn't yet have as good 'frame level' introspection as CPython - but hopefully that will come.
Michael Foord | Homepage | 08/08/16 - 1:04 pm | #

If it has such a level, you'll simply implement CPython's stack trace API on top of that. Easy. That's exactly the way pypy's jit works. It does not have any stack frames, but knows info how to reconstruct them if needed.
fijal | 08/08/17 - 10:29 am | #

Yeah - I hope the IronPython team implement a 'proxy frame' solution so that we can use the tracing API. They haven't been in any hurry to do that so far... (They do that for stack traces in exceptions though.)
Michael Foord | Homepage | 08/08/18 - 2:08 pm | #

you're repeating yourself in the post as another commenter mentioned as well. Or was that intended :D
thijs | Homepage | 08/08/27 - 2:13 pm | #

Ha - thanks. I hadn't understood what the previous commenter meant... Fixed now.
Michael Foord | Homepage | 08/08/27 - 2:47 pm | #