Re: cgit-lua: to jit or not to jit
On 14 Jan 2014 03:52, Andrew Starks andrew.sta...@trms.com wrote: On Monday, January 13, 2014, Jason A. Donenfeld wrote: On Tue, Jan 14, 2014 at 3:37 AM, Andrew Starks andrew.sta...@trms.com wrote: I don't have LuaJit installed and would not install it (and migrate everything I do over to it) just to use a library. By way of example, your library may as well have been written for Python, for as much good as it would be to me. By contrast, if you stick to the subset of 5.2 that 5.1 supports, and / or use a bit of the luacomp library, then anyone with lua 5.1, luajit or Lua 5.2 can use it. The question, from a user's perspective is: what benefit are you giving me, in exchange for locking me into luajit, as a dependency? Even if I am using Luajit, that doesn't mean that I don't need to support the current, mainline distribution and straight 5.1. So, I can't use your library as a dependency, if this were the case. It's easier for you if you like what the FFI gives you. Supporting the common subset and using luacompat, as necessary, is the simplest, for the user. IMHO, of course That's a fairly compelling opinion. The only thing against it is the temptation of using FFI in the default scripts that we ship with cgit. But I suppose for the sake of giving users choice later on, it might be best, as you've said, to continue to support both, and let the user choose. Jason, I also just remembered this: https://github.com/jmckaskill/luaffi Which is a luajit compatible FFI extension for Lua 5.1 and Lua 5.2, but 5.2 is listed as beta. It might be worth a shot, if it lets you gain some of those conveniences and keep a broad support base. Lua 5.2 support is fine for luaffi, but both are beta, and you have to fix the bugs yourself as it is only intermittently being developed (by me). The most important platform that LuaJIT is not available for is probably softfloat MIPS (eg openwrt). Justin ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: cgit-lua: to jit or not to jit
On Tue, Jan 14, 2014 at 4:51 AM, Andrew Starks andrew.sta...@trms.com wrote: I also just remembered this: https://github.com/jmckaskill/luaffi Which is a luajit compatible FFI extension for Lua 5.1 and Lua 5.2, but 5.2 is listed as beta. It might be worth a shot, if it lets you gain some of those conveniences and keep a broad support base. Excellent! Thanks Andrew. ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: cgit-lua: to jit or not to jit
* Jason A. Donenfeld: On Tue, Jan 14, 2014 at 3:10 AM, demetri demetri.spa...@gmail.com wrote: 1) PUC Lua works on more machines/architectures (though Mike has substantially closed the gap for most architectures people care about in a non-embedded non-mobile environment) Do you know what the gap is? LuaJIT supports x86, x86_x64, arm, ppc, e500, and mips. I guess that leaves, what? Sparc, AVR, ia64, ... other obscure ones? Hmm.. ppc64 and s390x. Neither one is particularly obscure. ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: cgit-lua: to jit or not to jit
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. Additionally, if you want/need to modify Lua, it is much easier to modify canonical Lua as opposed to LuaJIT. It is also easy to find Lua patches (power patches). On a similar vein, I would imagine auditing code for things like security or high availability would be easier with canonical Lua. (Look to Wikimedia Commons and Verisign talks about what they needed to accomplish.) If you or you have users that worry about this kind of thing, they may be more reassured if you retain compatibility with both. Thanks, Eric -- Beginning iPhone Games Development http://playcontrol.net/iphonegamebook/ ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: cgit-lua: to jit or not to jit
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 ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: cgit-lua: to jit or not to jit
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
Re: cgit-lua: to jit or not to jit
On Tue, Jan 14, 2014 at 3:12 AM, Tim Hill drtimh...@gmail.com wrote: LuaJIT is currently compatible with Lua 5.1, not 5.2 or the upcoming 5.3, and my understanding is the LuaJIT project has now forked from mainstream Lua and will not be staying in sync with anything past 5.1, so I would expect over time the two to diverge. AFAIK, LuaJIT supports 5.2 currently via the -DLUAJIT_ENABLE_LUA52COMPA flag and mentions it here http://luajit.org/extensions.html#lua52 . OTOH, their roadmap page says: As I've previously said, Lua 5.2 provides few tangible benefits. LuaJIT already includes the major new features, without breaking compatibility. Upgrading to be compatible with 5.2, just for the sake of a higher version number, is neither a priority nor a sensible move for most LuaJIT users. So I'm not sure what to think. ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: cgit-lua: to jit or not to jit
On Monday, January 13, 2014, Jason A. Donenfeld wrote: On Tue, Jan 14, 2014 at 3:12 AM, Tim Hill drtimh...@gmail.comjavascript:; wrote: LuaJIT is currently compatible with Lua 5.1, not 5.2 or the upcoming 5.3, and my understanding is the LuaJIT project has now forked from mainstream Lua and will not be staying in sync with anything past 5.1, so I would expect over time the two to diverge. AFAIK, LuaJIT supports 5.2 currently via the -DLUAJIT_ENABLE_LUA52COMPA flag and mentions it here http://luajit.org/extensions.html#lua52 . OTOH, their roadmap page says: As I've previously said, Lua 5.2 provides few tangible benefits. LuaJIT already includes the major new features, without breaking compatibility. Upgrading to be compatible with 5.2, just for the sake of a higher version number, is neither a priority nor a sensible move for most LuaJIT users. So I'm not sure what to think. I don't have LuaJit installed and would not install it (and migrate everything I do over to it) just to use a library. By way of example, your library may as well have been written for Python, for as much good as it would be to me. By contrast, if you stick to the subset of 5.2 that 5.1 supports, and / or use a bit of the luacomp library, then anyone with lua 5.1, luajit or Lua 5.2 can use it. The question, from a user's perspective is: what benefit are you giving me, in exchange for locking me into luajit, as a dependency? Even if I am using Luajit, that doesn't mean that I don't need to support the current, mainline distribution and straight 5.1. So, I can't use your library as a dependency, if this were the case. It's easier for you if you like what the FFI gives you. Supporting the common subset and using luacompat, as necessary, is the simplest, for the user. IMHO, of course -Andrew ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: cgit-lua: to jit or not to jit
On Tue, Jan 14, 2014 at 3:37 AM, Andrew Starks andrew.sta...@trms.com wrote: I don't have LuaJit installed and would not install it (and migrate everything I do over to it) just to use a library. By way of example, your library may as well have been written for Python, for as much good as it would be to me. By contrast, if you stick to the subset of 5.2 that 5.1 supports, and / or use a bit of the luacomp library, then anyone with lua 5.1, luajit or Lua 5.2 can use it. The question, from a user's perspective is: what benefit are you giving me, in exchange for locking me into luajit, as a dependency? Even if I am using Luajit, that doesn't mean that I don't need to support the current, mainline distribution and straight 5.1. So, I can't use your library as a dependency, if this were the case. It's easier for you if you like what the FFI gives you. Supporting the common subset and using luacompat, as necessary, is the simplest, for the user. IMHO, of course That's a fairly compelling opinion. The only thing against it is the temptation of using FFI in the default scripts that we ship with cgit. But I suppose for the sake of giving users choice later on, it might be best, as you've said, to continue to support both, and let the user choose. ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: cgit-lua: to jit or not to jit
On Monday, January 13, 2014, Jason A. Donenfeld wrote: On Tue, Jan 14, 2014 at 3:37 AM, Andrew Starks andrew.sta...@trms.comjavascript:; wrote: I don't have LuaJit installed and would not install it (and migrate everything I do over to it) just to use a library. By way of example, your library may as well have been written for Python, for as much good as it would be to me. By contrast, if you stick to the subset of 5.2 that 5.1 supports, and / or use a bit of the luacomp library, then anyone with lua 5.1, luajit or Lua 5.2 can use it. The question, from a user's perspective is: what benefit are you giving me, in exchange for locking me into luajit, as a dependency? Even if I am using Luajit, that doesn't mean that I don't need to support the current, mainline distribution and straight 5.1. So, I can't use your library as a dependency, if this were the case. It's easier for you if you like what the FFI gives you. Supporting the common subset and using luacompat, as necessary, is the simplest, for the user. IMHO, of course That's a fairly compelling opinion. The only thing against it is the temptation of using FFI in the default scripts that we ship with cgit. This is a great point, as well. Also, there are some spiciffic use cases where speed might be critical and luajit has some common cases where it really shines, no doubt. But I suppose for the sake of giving users choice later on, it might be best, as you've said, to continue to support both, and let the user choose. I'll also say that I will make it a point to check this out. I hadn't heard of the project before and it sounds interesting. -Andrew ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
Re: cgit-lua: to jit or not to jit
On Monday, January 13, 2014, Jason A. Donenfeld wrote: On Tue, Jan 14, 2014 at 3:37 AM, Andrew Starks andrew.sta...@trms.comjavascript:; wrote: I don't have LuaJit installed and would not install it (and migrate everything I do over to it) just to use a library. By way of example, your library may as well have been written for Python, for as much good as it would be to me. By contrast, if you stick to the subset of 5.2 that 5.1 supports, and / or use a bit of the luacomp library, then anyone with lua 5.1, luajit or Lua 5.2 can use it. The question, from a user's perspective is: what benefit are you giving me, in exchange for locking me into luajit, as a dependency? Even if I am using Luajit, that doesn't mean that I don't need to support the current, mainline distribution and straight 5.1. So, I can't use your library as a dependency, if this were the case. It's easier for you if you like what the FFI gives you. Supporting the common subset and using luacompat, as necessary, is the simplest, for the user. IMHO, of course That's a fairly compelling opinion. The only thing against it is the temptation of using FFI in the default scripts that we ship with cgit. But I suppose for the sake of giving users choice later on, it might be best, as you've said, to continue to support both, and let the user choose. Jason, I also just remembered this: https://github.com/jmckaskill/luaffi Which is a luajit compatible FFI extension for Lua 5.1 and Lua 5.2, but 5.2 is listed as beta. It might be worth a shot, if it lets you gain some of those conveniences and keep a broad support base. -Andrew ___ CGit mailing list CGit@lists.zx2c4.com http://lists.zx2c4.com/mailman/listinfo/cgit
