Re: cgit-lua: to jit or not to jit

["Jason A. Donenfeld" <Jason@...>]

On Tue, Jan 14, 2014 at 3:34 AM, William Ahern
<william@25thandclement.com> 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