
RaptorJIT 1.0: Lua implementation for high-perf low-level system programming - ingve
https://github.com/raptorjit/raptorjit/releases/tag/v1.0.0
======
posnet
An interesting part of this project, other than improving the already
excellent LuaJIT is the Studio[1] tooling (made with Pharo smalltalk[2] and
nix[3]) that has been built around debugging JIT performance issues.

Luke Gorrie, one of the main contributes has been live streaming its
progress.[4]

[1] [https://github.com/studio/studio/](https://github.com/studio/studio/)

[2] [https://pharo.org/](https://pharo.org/)

[3] [https://nixos.org/nix/](https://nixos.org/nix/)

[4]
[https://www.youtube.com/watch?v=MQyxXSPXcwg](https://www.youtube.com/watch?v=MQyxXSPXcwg)

------
placebo
The level of experience, talent and expertise required to dive into LuaJIT
development and following Mike Pall's stepping down from active development of
it was cause for concern that this would be the end of the road (some even
decided to abandon Lua as a result). My optimism grew when I saw this project
(and the quotes at the end of it's github page, which capture the issue
perfectly) - very glad to see this release and hope the momentum just gets
bigger.

~~~
DarkWiiPlayer
That's pretty much how I felt as well. I've come across this some weeks ago,
and I'm still not sure if this will be a worthy LuaJIT successor.

------
armitron
I'm very happy to see this. For those who are not familiar with Luke Gorrie,
he has done many interesting things whilst tightly orbiting around languages
that lack popular appeal.

Erlang, Common Lisp, Forth and now Lua and Smalltalk, it takes a certain kind
of thinking to go against the grain like that. Besides following his output
for years and being inspired by him, I've always admired Luke for blazing his
own path in the programming wilderness.

------
usgroup
So great to see this ... The slow roll of LuaJIT, made me despair a bit that
Lua would ever see a thriving JIT project. Hopefully this will be it...

If you haven't tried Lua, do. You can be up and running in about 3-4 hours,
writing useful things. Try writing your next utility script or command line
tool in Lua.

------
mitchtbaum
I've looked at luajit, terra, and now raptorjit; and I always come to the same
conclusions.

1) this is the wrong optimization (more below)

2) Rio's runtime is very good (enough for now, at least)

3) the next big step like this is to make an interpreter in Rust, not
necessarily a parser/ast generator, but just a runtime, and I'm not in a rush
for this

the right optimization is to do low-level work in a systems language.. in my
case Rust, where rLua has a great wrapper for puc Lua. only use Lua as a
scripting language to call those lower level functions.

right now on github, you can see my Lua bindings to Rust's libraries for web
server, web client, libsodium functions, jinja rendering, string transforms,
set operations, and more. all of that work is done in Rust, and controlled by
Lua. it's faster than any Lua you've ever seen.

[https://github.com/foundpatterns/torchbear](https://github.com/foundpatterns/torchbear)

~~~
DarkWiiPlayer
You clearly don't understand terra then. Terra _is_ a system language that
mimics Luas syntax and uses it as a preprocessor. The only thing that makes it
different from, say, C, is that the compiler can actually run the code it
generates immediately, and outputting an enclosed executale is an option, but
not the default.

As for PUC Lua, yes, it's perfectly ok for most things when you're mostly
scripting and using C for the heavy lifting anyway, like when you're building
a scripting language into an already existing game engine or program.

LuaJIT was always meant to fill the in-between role (which is, arguably, the
broadest one) where you can't be bothered to write a full C application to
host your Lua code but still need more speed than you get by just running a
whole program in PUC Lua.

~~~
mitchtbaum
> where you can't be bothered to write a full C application to host your Lua
> code

This Rust code I linked to is an application framework. It makes several of
Rust's most powerful libraries available to Lua, which should greatly improve
development speed. I'm using it to build an event-based Lua web framework on
top of it. (also there) Development of other network applications should also
be very smooth, afaics.

~~~
justincormack
Yeah thats a different use case somewhat like a modern version of openresty
but built around a set of libraries rather than inside Nginx. There may still
be a case for some applications for a jit compiler for the Lua parts but that
depends on the application.

------
otabdeveloper1
Does this still only support 2 Gb of RAM?

([https://stackoverflow.com/questions/35155444/why-is-
luajits-...](https://stackoverflow.com/questions/35155444/why-is-luajits-
memory-limited-to-1-2-gb-on-64-bit-platforms))

~~~
lukego
No, that restriction is gone. Peter Cawley did the hard work and added
optional support for 64-bit heaps to LuaJIT upstream [1] and RaptorJIT adopted
that exclusively i.e. dropped the 32-bit heap option which involved a LOT of
#ifdef'ery in thousands of lines of assembler code.

[1]
[https://www.youtube.com/watch?v=ZeaDk9ElKws](https://www.youtube.com/watch?v=ZeaDk9ElKws)

~~~
otabdeveloper1
Last I checked (which was a year or more ago), 64-bit GC for LuaJIT is an
experimental and buggy feature. Do people actually use it in production? Since
which version of LuaJIT?

~~~
lukego
The bugs have been shaken out now and it works fine in production. That's true
at least on x86-64 with common build options and the latest LuaJIT prerelease.

------
lowry
Most of the changes are removals of architectures other than x86_64. What a
joke.

~~~
LeifCarrotson
To be fair, when I was using Lua a decade ago, LuaJIT mostly only supported
Linux and x86-64. Mike was adding new architectures and variants on request
and when people would pay him to do so, while the core was both mostly
sufficient and still improving. Those 50,000 lines did come after x86-64, if
you wanted to move the project in a different direction it seems sensible to
strip them out, make your changes. As long as your changes a rent too drastic,
it should be comparatively easy to put them back in.

~~~
justincormack
Each architecture had a hand coded interpreter. The plan is to write a
portable interpreter in C.

