Re: Drawing the line between speed and simplicity/elegance

[Coda Highland <chighland@...>]

On Sat, May 9, 2015 at 3:56 PM, Brigham Toskin <brighamtoskin@gmail.com> wrote:
> On Sat, May 9, 2015 at 2:17 PM, Rena <hyperhacker@gmail.com> wrote:
>>
>> But Lua also has some overhead with calling into C, doesn't it? So
>> some common operations are faster in pure Lua than in C? I'm sure I've
>> heard that.
>
>
> If it's a relatively small piece of code, the cost of calling into C could
> be higher than the cost of just running it in Lua. On the other hand, luajit
> produces native machine code, which could easily call a C function with
> relatively little overhead; I'm not sure what that actually ends up looking
> like, with bookkeeping and state fixups and stuff. Plus, as pointed out
> earlier, calling C functions probably foils optimizer traces, so I'm not
> sure it'll even do it.
>
> Does anybody know? Is Mike around?
>

The JIT can't trace across C function calls because there are
absolutely no guarantees about the state of the world after a C API
function call -- the function could do anything. (The FFI circumvents
this issue by prohibiting access to the Lua state during an FFI
function call.) Having a C API function call will blacklist that part
of the code from the JIT compiler, which will slow down the entire
routine.

Mike's working on some stuff that would allow the JIT compiler to work
all the way up to a C API function call, make sure the Lua environment
is in sync (the JIT only updates the Lua state when it needs to,
preferring to keep as much work in the CPU registers and simple RAM
structures as possible until it's forced to flush it out), call the
function, and then resume JIT compilation on the next instruction.
He's not done with it yet, because doing this right is ridiculously
hard, and even if he WERE done with it, the overhead of bringing the
Lua state up-to-date is pretty heavy, so you'd still want to avoid it
if at all possible.

/s/ Adam