One more thing for luajit vs. lua - If you ship a plugin (.so, .dll, .dylib) using luajit, then the host application might not always work with it. If I'm not mistaken the lower 2GB (or 4GB?) must be allocated to luajit, (so even in 64-bit app, it needs the lower 32-bit address space - for lua allocated objects).
On Tue, Jan 14, 2014 at 12:50 PM, Coda Highland <[email protected]> wrote: > On Tue, Jan 14, 2014 at 12:50 PM, Coda Highland <[email protected]> wrote: >> On Tue, Jan 14, 2014 at 12:41 PM, Eric Wing <[email protected]> wrote: >>>> But perhaps there >>>> are some obvious downsides to this approach that I also am missing. >>> >>> Here are a few more potential downsides not mentioned so far. >>> >>> One is that iOS and Windows Store policies disallow JIT. While you can >>> disable this part in LuaJIT, most of the performance advantages >>> disappear when you do this. >> >> However, even with the JIT disabled, LuaJIT does tend to outperform >> Lua for a lot of use cases (Lua wins in a few cases) just by virtue of >> having an interpreter written in hand-tuned assembly. >> >> /s/ Adam > > Addendum: FFI still works on iOS at least, and probably WinRT. > > /s/ Adam > -- Dimiter "malkia" Stanev, ICQ: 21875894 [email protected] [email protected] _______________________________________________ CGit mailing list [email protected] http://lists.zx2c4.com/mailman/listinfo/cgit
