21–30 of 34 posts
Earlier quoted context omitted.
Out of curiosity what makes this such a big win for Python, but not so much for Lua or C-type languages?
I honestly don't know why it's not such a big deal for Lua, but given LuaJIT's performance, and knowing that it doesn't do escape analysis I know it must not be a big deal :) In Python it's a big deal because everything is boxed, and your inner loops just get bogged down with allocations, which are expensive compared to arithmetic operations.
The blog post touched on it briefly with regards to PyPy but I wanted to ask here since I'm sure someone knows a lot more than I do on this. I didn't follow unladen swallow very closely, but it seemed like an exciting project from the get-go. Its sad to see it go, but it appears its not in vain. I want to ask: What lasting effects did the work that went into Unladen Swallow have on any Python implementations (or any…
The primary legacy of Unladen Swallow (this was something that everyone agreed on at the VM summit at PyCon) were: a) improvements to LLVM for all users of its JIT, things like valgrind and GDB integration, lifting that 16 MB of machine code, and fixing various bugs, b) developing a cohesive set of benchmarks for the Python community, and c) drawing more attention to the idea of a fast Python.
The points about LLVM being designed for "static C-like languages" isn't totally on-point. There as an impedance mismatch between Python and LLVM, but it's less about dynamic versus static than it is about the nature of the stack frame. In LLVM, most optimizations operate on SSA values (the Value class in the LLVM IR). There is some support for CSE-ing loads, etc, but the effectiveness of that depends heavily on your…
Could you give an example of such a scenario? I'm having a hard time imagining what this means in code. I know that Python's scoping is a little weird, so this isn't really surprising...
The points about LLVM being designed for "static C-like languages" isn't totally on-point. There as an impedance mismatch between Python and LLVM, but it's less about dynamic versus static than it is about the nature of the stack frame. In LLVM, most optimizations operate on SSA values (the Value class in the LLVM IR). There is some support for CSE-ing loads, etc, but the effectiveness of that depends heavily on your…
The points about LLVM being designed for "static C-like languages" isn't totally on-point. There as an impedance mismatch between Python and LLVM, but it's less about dynamic versus static than it is about the nature of the stack frame. In LLVM, most optimizations operate on SSA values (the Value class in the LLVM IR). There is some support for CSE-ing loads, etc, but the effectiveness of that depends heavily on your…
I think the deeper problem is not that stuff like arithmetic is done by function calls, but that it is done by method calls. This requires points-to-analysis and a lowering to function calls first. Since this analysis will be very conservative for performance reasons, you want to steal more tricks. Tracing seems to be en vogue today.
Runtime type feedback (observing the actual type at call sites and doing optimistic compilation based on that) is more robust and predictable (your points-to analysis doesn't suddenly fail just because there is a single polymorphic use somewhere in the code). That in itself is orthogonal to tracing. Runtime type feedback was developed on whole-method compilers, after all. Tracing is neat, and it's in vogue because it gets you to a "good" optimizer with relatively little development cost, but you can do all the things tracing does in a whole-method compiler with more engineering work. On-stack replacement (necessary for doing optimistic compilation) is arguably easier in a tracing compiler, and is definitely the major thing missing in LLVM for dynamic language implementations.
But all of this is one step beyond the threshold problem. Even all these tricks don't help you if you can't reify your local variables as SSA values --- all that fancy LLVM machinery won't see anything to optimize.
The points about LLVM being designed for "static C-like languages" isn't totally on-point. There as an impedance mismatch between Python and LLVM, but it's less about dynamic versus static than it is about the nature of the stack frame. In LLVM, most optimizations operate on SSA values (the Value class in the LLVM IR). There is some support for CSE-ing loads, etc, but the effectiveness of that depends heavily on your…
> Python's lexical scoping semantics are a little bit wonky and there are lots of scenarios in which the thread's stack frame is reified as an object. Could you give an example of such a scenario? I'm having a hard time imagining what this means in code. I know that Python's scoping is a little weird, so this isn't really surprising...
Beyond that there are several places where you can introspect the activation. See: locals(), some of the fields in the code object, etc. Again, there may be implementation techniques you can use to get around this, but there isn't an obvious and clean mapping to SSA values as there is for Lisp-like languages.
Just curious, what are the "other ways"?
I wonder how much this includes teams within Google that have since started using Go for writing performance sensitive applications...
"Our potential customers [within Google] eventually found other ways of solving their performance problems that they felt more comfortable deploying." I wonder how much this includes teams within Google that have since started using Go for writing performance sensitive applications...
"Most Python code at Google isn't performance critical." What about AppEngine? The primary 'cloud' platform at Google.