From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Tue, 14 Jan 2014 03:45:27 +0100 Subject: cgit-lua: to jit or not to jit In-Reply-To: <20140114023403.GA31401@wilbur.25thandClement.com> References: <20140114023403.GA31401@wilbur.25thandClement.com> Message-ID: On Tue, Jan 14, 2014 at 3:34 AM, William Ahern wrote: > The 2GB memory limit on 64-bit was a huge blocker at my work. We almost > immeditely ran afoul of it and have chosen to stabilize on Lua 5.2 for one > of our cloud services. (On 16-way SMP, 32GB RAM boxes it's more important to > be able to scale up and out then to have JITd loops, especially when the > most performance sensitive code is in C anyhow.) > > I suspect that if you ended up trying to write a full OpenSSL wrapper using > LuaJIT's FFI that you wouldn't save very much time and effort. I say that as > someone having written the most comprehensive OpenSSL bindings in Lua: > > http://25thandclement.com/~william/projects/luaossl.html > > Things might be different if you just bound one or two interfaces. LuaJITs > FFI excels at that sort of ad hoc interface binding. But for full-blown > bindings things get more complicated. OpenSSL, for example has a ton of > preprocessor generated tags. Also, string and buffer management can be made > significantly more efficient in C, so when you're aggregating results into a > large buffer before pushing onto the Lua stack, it's easier to get good > performance with C code. For larger or complex modules the payoffs with > LuaJIT FFI diminish. So it all depends on your context. How sophisticated > will your bindings be? In this case, it'd just be calculating an md5 of an email address to display a gravatar. So at the moment, super simple. Good point about the cost of aggregation for bigger uses, though. Generally, our use case is -- cgit spits out a bunch of HTML. Sometimes sysadmins might want to modify it on the fly based on various pieces of information -- for example, adding a gravatar image next to mentions of an author based on email address -- in which case, the admin codes up a simple lua file [1]. Super super simple usage. > > Because Lua is emebedded in your project it's not that big of deal to just > settle on LuaJIT. Having to deal with the different versions is more of a > problem for a module writer, where you run into problems with differences > across versions and implementations--e.g. GC (Lua 5.2 has ephemeron tables) > or internals (e.g. FILE* handles). > > That's a good point, okay. [1] http://git.zx2c4.com/cgit/tree/filters/email-gravatar.lua