Re: Announcing moonslice luv*, and lhttp_parser

[Tim Caswell <tim@...>]

On Wed, Oct 10, 2012 at 4:31 PM, Coda Highland <chighland@gmail.com> wrote:
> On Wed, Oct 10, 2012 at 2:14 PM, Tim Caswell <tim@creationix.com> wrote:
>> On Wed, Oct 10, 2012 at 4:06 PM, Coda Highland <chighland@gmail.com> wrote:
>>> On Wed, Oct 10, 2012 at 1:57 PM, Richard Hundt <richardhundt@gmail.com> wrote:
>>>> However, ØMQ aside, why does the presence of a coroutine scheduler on top contribute to it being "more than just libuv bindings"?
>>>
>>> Read that as "more than just a bare-bones wrapper around libuv" and it
>>> may make more sense to you. Yes, it's a set of bindings to libuv, but
>>> it's a high-level binding, not a low-level one.
>>
>> In my opinion, C bindings should only do what you can't do in lua.
>> Especially highly debated topics like async API style.  Adding
>> coro-sugar on top can be done in pure lua.  If I do the bindings
>> right, than Richard should be able to put my library inside his if he
>> so chose.
>>
>> Also, I've found that in JIT engines, the more logic you push to lua,
>> the more it can optimize.  I know this is very true for V8 and
>> JavaScript.  I expect the same to be true to some extent for luajit.
>
> This is very true for LuaJIT; Mike has said so a number of times on
> the LuaJIT mailing list: the JIT can't do much optimization if you're
> calling functions implemented using the Lua C API, and it's usually
> more efficient to implement generic callback-based algorithms entirely
> in Lua instead of writing the function in C and invoking a Lua
> callback inside that.
>
> There IS a major caveat to be noted, though, that is highly relevant
> to this discussion: LuaJIT has (1) a limited number of callback slots
> available, (2) can't optimize calls from C to Lua (e.g. for a
> callback-based architecture).
>
> What this means in practice is that you probably want some sort of
> Lua-side dispatcher so you can minimize the number of callbacks passed
> to C functions in order to avoid exhausting those slots and do more
> work Lua side, but even so there are some nuances that I personally am
> not fully familiar with.
>
> Of course, LuaJIT has one even bigger catch you want to observe: You
> should almost certainly use the FFI instead of Lua C API bindings,
> because the JIT *can* optimize across FFI calls. This probably means
> having separate Lua and LuaJIT versions of luv that expose the same
> API but use the FFI where available.

I don't think ffi bindings would be faster since there are so many
callbacks in libuv's API.  While ffi calls are faster than C calls in
luajit, they are much slower when callbacks are involved.  I'm
sticking to plain C API bindings for luv.

-Tim