3 ms·

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

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