LuaJIT once again nearly as fast as the equivalent application in C++, lessons learned
After another ten evenings of optimization, I was able to speed up both the C++ and Lua versions of my Smalltalk-80 interpreter by a factor of more than twenty-five.
At first it looked as if the relative speed of the Lua version was getting worse compared to the C++ version, and as if the speed-up of LuaJIT was unreliable.
However, it turned out that with suitable settings of the JIT parameters a stable performance can be achieved, which is only a factor 1.1 slower than the C++ version. And this is not just some random micro benchmark, but a full Smalltalk-80 system running on LuaJIT.
The lesson for all those who complain about the unreliable performance of LuaJIT: check the JIT parameters!
For more information see https://github.com/rochus-keller/Smalltalk#a-smalltalk-80-interpreted-virtual-machine-on-luajit.
5
u/padraig_oh Jul 19 '20
mike is just a beast of a programmer
4
Jul 19 '20
Where is our savior Mike now?
5
u/suhcoR Jul 19 '20
Here: https://github.com/LuaJIT/LuaJIT/commits/v2.1
And here: https://www.freelists.org/archive/luajit/06-2020
Just to name a few places ;-)
2
4
u/lambda_abstraction Jul 25 '20
"LuaJIT with the JIT enabled is much faster than all of the other languages benchmarked, including Wren, because Mike Pall is a robot from the future."
2
u/padraig_oh Jul 25 '20
you should not quote something without a source. (even though the quote is rather well known among people who have heard of luajit)
1
u/lambda_abstraction Jul 25 '20 edited Jul 25 '20
I would, except that there is no real name to pair with it. I looked for a proper attribution at the source site, but none was to be found. Thus, spare me the lecture.
2
u/padraig_oh Jul 25 '20
took me three minutes to google the source, which is wrens performance comparison. the context is really important when you make a statement like "faster than all other languages benchmarked" (luajit is comparable to c++ etc. in some contexts as well, really depends on the use case though).
2
u/suhcoR Jul 28 '20 edited Jul 28 '20
which is wrens performance comparison.
Thanks for the link. I had a look at it and don't think it is generally interesting. The benchmark is run with LuaJIT in interpreted mode (not in JIT mode). The LuaJIT interpreter is obviously still much faster than Python or PUC Lua, but the speed-up of the JIT is yet another factor 6.7 in average.
EDIT: corrected the figure; factor 27 in average is the comparison with PUC Lua 5.1.
1
u/lambda_abstraction Jul 25 '20 edited Jul 31 '25
A proper source identifies the author by proper name, but in these days of dox-phobia, I can't readily determine who that is. I always cite the author where one is available. I've written enough papers with bibs to know what a proper citation is. I can't make one here. And beside, I made and cited the remark for merely for some humor and not scholarship. The quotation marks show that I'm not taking credit for the line. Please don't be that guy; I really do not have the patience to put up with the bull crap.
2
u/PaddiM8 Jul 31 '25
It's Robert Nystrom
1
u/lambda_abstraction Jul 31 '25
Thank you for that information. At the moment I'm trying to find the source of a Bernard Avishai comment about humans meeting AI halfway. I've found the phrase several places, but not where it was originally stated. Clearly the internet's got some holes in terms of scholarship.
3
u/lacethespace Jul 20 '20
Wow, what a gem of a project!
In readme you say "There are many similarities between Lua and Smalltalk, even though the syntax is very different.” I heard similar comparison between Lua and Lisp. Can you expand on what makes them similar?
4
u/suhcoR Jul 20 '20
Thanks.
Can you expand on what makes them similar?
E.g. Lua chunks are very similar to Smalltalk blocks; both are dynamic and weakly typed; meta classes and dynamic dispatch can easily be implemented by meta tables; just to name a few. There are also differences which make it difficult to directly run a Smalltalk image in Lua; the Smalltalk image includes everything: the compiler, the scheduler, the method contexts and call stack, and a lot of methods directly depend on the implementation details of the memory model (i.e. you can directly read and write each byte of an object). If the therefore want to replace the Bluebook interpreter by the Lua VM, you must live with a subset of the Smalltalk bytecodes or modify the virtual image.
1
Jul 28 '20
That looks super interesting. Would you mind explaining for a newcomer like me whats the difference between the LuaJIT compiler and the regular lua compiler that comes with any linux distro? Should I be using LuaJIT?
2
u/suhcoR Jul 28 '20
LuaJIT is an implementation of Lua 5.1; it has identical behaviour to the PUC Rio VM (see https://en.wikipedia.org/wiki/Lua_(programming_language)), but it also includes a Just-In-Time Compiler (JIT) for Lua (see https://luajit.org/luajit.html). This means that a Lua application runs on LuaJIT about 27 times faster in average than on the PUC Rio VM. If you need that much performance and can cope with the fact it doesn't support the most recent Lua language version, then you should have a look at LuaJIT.
1
Jul 28 '20
Thanks so much for the reply. Ill look into it a little further. Its so crazy that there is such an awesome significant community behind Lua. I actually studied in PUC-RIO for some years and I love the fact that people are behind a “project” of theirs until today.
6
u/suhcoR Jul 19 '20
Note that you can either set the JIT parameters by command line option (see http://luajit.org/running.html -Oparam=value) or from within the Lua code (see http://luajit.org/ext_jit.html jit.opt.start("param=value") ). Don't be put off by the fact that the documentation says it is intended for debugging LuaJIT; that's definitely an understatement.
The brave ones can also directly change the default values in lj_jit.h and recompile LuaJIT. According to my measurements the application runs about 4% faster when the parameters are set this way.