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 <chighl...@gmail.com> wrote: > On Tue, Jan 14, 2014 at 12:50 PM, Coda Highland <chighl...@gmail.com> wrote: >> On Tue, Jan 14, 2014 at 12:41 PM, Eric Wing <ewmail...@gmail.com> 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 mal...@mac.com mal...@gmail.com _______________________________________________ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
