Unladen Swallow Retrospective
qinsb.blogspot.com
Unladen Swallow Retrospective
1–10 of 34 posts
Re: Unladen Swallow Retrospective
#2The 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 other languages)? What "legacy" was left?
Re: Unladen Swallow Retrospective
#3The 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.
Re: Unladen Swallow Retrospective
#4Somewhat relevant to the topic - Mike Pall discusses (2009) the usage of llvm for lua - he's not ditching the approach, just pointing out the difficulties, and why he took on making luajit the way it is:
Re: Unladen Swallow Retrospective
#5Somewhat relevant to the topic - Mike Pall discusses (2009) the usage of llvm for lua - he's not ditching the approach, just pointing out the difficulties, and why he took on making luajit the way it is: http://lua-users.org/lists/lua-l/2009-06/msg00071.html
A big one Mike misses (because it isn't as critical for Lua AFAIK) is escape analysis. For PyPy our aggressive escape analysis can bring huge wins on things like numeric code and some types of string processing, but no static compilers really do this type of optimization, because it's not very important in C-type languages.
Re: Unladen Swallow Retrospective
#6The 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…
[deleted]
Re: Unladen Swallow Retrospective
#7Somewhat relevant to the topic - Mike Pall discusses (2009) the usage of llvm for lua - he's not ditching the approach, just pointing out the difficulties, and why he took on making luajit the way it is: http://lua-users.org/lists/lua-l/2009-06/msg00071.html
A big one Mike misses (because it isn't as critical for Lua AFAIK) is escape analysis. For PyPy our aggressive escape analysis can bring huge wins on things like numeric code and some types of string processing, but no static compilers really do this type of optimization, because it's not very important in C-type languages.
Out of curiosity what makes this such a big win for Python, but not so much for Lua or C-type languages?
Re: Unladen Swallow Retrospective
#8Earlier quoted context omitted.
A big one Mike misses (because it isn't as critical for Lua AFAIK) is escape analysis. For PyPy our aggressive escape analysis can bring huge wins on things like numeric code and some types of string processing, but no static compilers really do this type of optimization, because it's not very important in C-type languages.
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.
Re: Unladen Swallow Retrospective
#9Earlier quoted context omitted.
A big one Mike misses (because it isn't as critical for Lua AFAIK) is escape analysis. For PyPy our aggressive escape analysis can bring huge wins on things like numeric code and some types of string processing, but no static compilers really do this type of optimization, because it's not very important in C-type languages.
Out of curiosity what makes this such a big win for Python, but not so much for Lua or C-type languages?
I can't speak for Lua, but for C, it's because all memory management is handled explicitly by the programmer - that precludes optimizations where dynamic allocation is replaced with stack allocation. The C compiler isn't free to change such things, and most C programmers already perform that optimization without thinking about it. (I don't mean to imply that state of affairs is a good thing, it's just so ingrained in a C programmer that they don't think of it as an optimization.)
Also, since C allows access to raw-memory by design, it can't guarantee that, say, my memory allocation in function f() isn't touched by my funky pointer-arithmetic in function g(). (Perhaps in theory it could, but in practice this problem is mind-blowingly difficult.)
Re: Unladen Swallow Retrospective
#10See also Collin's comment on the post: http://qinsb.blogspot.com/2011/03/unladen-swallow-retrospect...