4 ms·

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 li

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.

haberman 16y ago
Out of curiosity what makes this such a big win for Python, but not so much for Lua or C-type languages?
- kingkilr 16y ago
  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.
  - beagle3 16y ago
    LuaJIT being a trace compiler, escape analysis in implicit. As long as a value stays (say) int or float, the code to handle it stays int or float. If for whatever reason it switches type, the code will change to accommodate that -- but as long as the types (and/or values) stay the same, the machine code to handle them will take advantage of that.
    - kingkilr 16y ago
      It's absolutely not true that escape analysis is implicit in tracing: https://bitbucket.org/pypy/extradoc/raw/63e4617062b2/talk/pepm2011/bolz-allocation-removal.pdf https://bitbucket.org/pypy/extradoc/raw/63e4617062b2/talk/pe...
  - rayiner 16y ago
    It's not a big deal for LuaJIT because it uses a clever tagging format that can hold a boxed 64-bit float in a register.
  - deleted 16y ago
    [deleted]
- scott_s 16y ago
  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.) See http://en.wikipedia.org/wiki/Escape_analysis http://en.wikipedia.org/wiki/Escape_analysis
malkia 16y ago
Mike said he'll be working on escape analysis to decrease the garbage collection if I remember correctly...
- malkia 16y ago
  I take this back. I've read all Mike's post in the lua mailing list, and found the reference where he talks about it, and in fact as not considering it (yet) it was from old posting in 3/14/2006 5:50PM: "* Garbage collection and heap allocation put Lua at a speed disadvantage to languages with manual memory management. The impact is less in Lua than other dynamic languages because of typed-value storage and immutable shared strings. Adding a custom memory allocator to the Lua core could be beneficial. Complex solutions like escape analysis are not on my radar for LuaJIT (yet). "
pbiggar 16y ago
That's interesting. In Java, escape analysis wasn't really a win from a memory perspective when there were good GCs involved. Why is it different in Python/PyPy?

haberman 16y ago

Out of curiosity what makes this such a big win for Python, but not so much for Lua or C-type languages?

kingkilr 16y ago
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.
- beagle3 16y ago
  LuaJIT being a trace compiler, escape analysis in implicit. As long as a value stays (say) int or float, the code to handle it stays int or float. If for whatever reason it switches type, the code will change to accommodate that -- but as long as the types (and/or values) stay the same, the machine code to handle them will take advantage of that.
  - kingkilr 16y ago
    It's absolutely not true that escape analysis is implicit in tracing: https://bitbucket.org/pypy/extradoc/raw/63e4617062b2/talk/pepm2011/bolz-allocation-removal.pdf https://bitbucket.org/pypy/extradoc/raw/63e4617062b2/talk/pe...
- rayiner 16y ago
  It's not a big deal for LuaJIT because it uses a clever tagging format that can hold a boxed 64-bit float in a register.
- deleted 16y ago
  [deleted]
scott_s 16y ago
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.) See http://en.wikipedia.org/wiki/Escape_analysis http://en.wikipedia.org/wiki/Escape_analysis

malkia 16y ago

Mike said he'll be working on escape analysis to decrease the garbage collection if I remember correctly...

malkia 16y ago
I take this back. I've read all Mike's post in the lua mailing list, and found the reference where he talks about it, and in fact as not considering it (yet) it was from old posting in 3/14/2006 5:50PM: "* Garbage collection and heap allocation put Lua at a speed disadvantage to languages with manual memory management. The impact is less in Lua than other dynamic languages because of typed-value storage and immutable shared strings. Adding a custom memory allocator to the Lua core could be beneficial. Complex solutions like escape analysis are not on my radar for LuaJIT (yet). "

pbiggar 16y ago

That's interesting. In Java, escape analysis wasn't really a win from a memory perspective when there were good GCs involved. Why is it different in Python/PyPy?