lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


There were several areas where performance would be critical and that JIT optimization would almost certainly be a significant advantage.

One of my development rules is (a) Don't pre-optimize until you know it's too slow and (b) If you know that specific parts of the code in Lua will be constantly called and they are critical then (c) If it will be difficult to back-engineer if you're wrong then go ahead and pick the optimal performance path.

There are a couple bits of Node9 code in Lua that are constantly executed.

1. A minimal scheduler component that interacts with the C kernel.  This executes on every Lua coroutine context switch.
2. The code that remaps the global variable references to make them application-specific.  That way global references can't break out of the application.

LuaJIT 2.0.x significantly reduces the overhead for remapping global application variables.  I did spend a good deal of time profiling the overhead for global remapping.  LuaJIT 1.x was significantly faster than C-Lua.   I think LuaJIT 2.x was about 40% faster than that.

Regarding NetBSD: I see now that you're actually talking about the NetBSD kernel scripting.  Scripted kernels are a relatively new thing (at least to me) and I see that you're one of the primary contributors to the project that I read about (along with Roberto).  I'm not sure how you would leverage the Inferno functionality inside of the BSD kernel itself.  I'll read more from the link.  Kernel scripting is definitely an interesting area of exploration.  Node9 is technically a scripted kernel (or will be), but it's hosted.  :)









On Thu, Jun 11, 2015 at 5:43 PM, Lourival Vieira Neto <lourival.neto@gmail.com> wrote:
> Thanks.  This is a project that I thought just needed to be written so I
> funded it personally :)

Great attitude =).

> To answer your question regarding C-Lua.  Yes.  I considered a C-Lua only
> implementation, but I didn't think the performance
> trade-off vs the additional platforms would be worth it.  That's just me.
> For someone else it might be well worth it.

Sure; I'm just curious if you ran benchmarks and identified Lua as a
bottleneck for your particular use case or if you had significant
gains.

> Isn't LuaJIT available for NetBSD? I thought LuaJIT worked on any relatively
> free x86 unix-like.

Not for the kernel. Also, NetBSD is not an OS exclusively for x86.
If you want to take a look in our work on Lua in kernel, here is a
reference [1].

[1] http://www.netbsd.org/~lneto/dls14.pdf

> If you wanted to port it to a C-Lua only architecture you would have to
> re-write the interfaces that LuaJIT FFI creates automatically.  Other than
> that it wouldn't be too hard.  Perhaps we could create a C-Lua only option
> that selected that interface.

It would be great =).

--
Lourival Vieira Neto