Helping to make LuaJIT faster | Hacker News Reader

Helping to make LuaJIT faster

blog.cloudflare.com

32 pointsIcyApril7 comments

Isn’t this the exact opposite of what Mike Pall wants for LuaJIT?

>> “Although we've not done a huge amount of direct LuaJIT research, we've always tried to stay abreast of its development”

I can’t find the post in the list-serv but I recall Mike Pall fairly adamant that he wants the project to be taken over by someone who:

A. Has contributed substantially and understands the internals of LuaJIT and

B. Not to make poor design decisions that other VM have historically made.

C. Be dedicated to LuaJIT

This Kings College London group who’s being funded to lead this admits they have no prior expertise on LuaJIT and they are mainly aware of only other JIT/VM.

Also, since Kings College London is an academic institution - doesn’t that mean that you’ll never have a consistent core team working on LuaJIT because students are just going to cycle through the school in order graduate.

Please take my comments coming from a place of caring. LuaJIT is really a marvel at how much it does in such a small code base.

Just to be clear, the team at King's is not taking maintainership of LuaJIT. The team is, however, interested in benchmarking and VM performance.

Tom Fransham, a recent addition to the team, will be benchmarking and improving LuaJIT. Tom has prior experience in hacking LuaJIT, e.g. intrinsics and GC.

Kings College London is an academic institution - doesn’t that mean that you’ll never have a consistent core team

Not necessarily. Matthias Felleisen has been working on Racket (and MzScheme) for decades and several of the core contributors to Racket (e.g. Mathew Flatt) are hacking on it in academia. On the other hand, Racket is their baby and that may not be the case with LuaJIT in the culture of Kings College...Racket is bootstrapped in academia by it's pedagogical hat and its facilitation of programming language research.

KCL isn't taking over LuaJIT from Mike. They are researching improvements to the JIT performance.

This sounds like amazing news. LuaJIT being given a future direction by people who know what they're doing & have additional bright ideas to add, funded by Cloudflare.

I mean... wow. Sure, we'll see how things go, but as a user this signifies that LuaJIT now actually has a future.

I don't need it to be faster, I need it to stop crashing whenever I try to stuff over 2GB into memory.

I hear ya.... try:

* Building with LJ_GC64 mode. [1]

It is newer but people are using it and it has been merged by Mike Pall into v2.1. Still beta though.

* Using FFI to allocate large objects or large pools of small objects.

I made some simple containers to help with the FFI parts [2] and also a (not recently updated) jemalloc binding [3] to help tune memory usage. Here's a gist I made with some experimental results [4].

[1] https://github.com/LuaJIT/LuaJIT/issues/25

[2] https://github.com/neomantra/lds

[3] https://github.com/neomantra/luajit-jemalloc

[4] https://gist.github.com/neomantra/9122165

Reply on news.ycombinator.com