Alright, time to run some LuaJIT in my RISC-V emulator.
function fib(n, acc, prev)
if (n < 1) then
return acc
else
return fib(n - 1, prev + acc, acc)
end
end
print(fib(50, 0, 1))
$ ./rvlinux -P ~/github/LuaRiscvJIT/src/luajit -- test.lua
12586269025
>>> Program exited, exit code = 0 (0x0)
Runtime: 0.281ms (Use --accurate for instruction counting)
Pages in use: 429 (1716 kB virtual memory, total 2674 kB)
Calling C functions using the old stack API would cause the JIT to abort. In Garrysmod's case, that includes such simple operations as constructing and performing arithmetic on vectors.
So when I was building a high-performance voxel library for Garrysmod, I ended up splitting my hot code into chunks that the JIT compiler would usually be happy with. One fast loop to generate a mesh, then a slow loop to convert that into a mesh structure the engine wants. Very carefully designed methods for bit-packing trees of 12-bit integer voxel data into flat tables of floats.
We ran Lua for the entire core of a game in a 400kb preallocated on the PSP about 20 years ago. I know of many places that used it long before us.
RISC-V, as of current state of specs (RVA23/RVB23) has already caught up with x86-64 and arm64.
Still, It remains an order of magnitude simpler. And this is unlikely to change.
>So far that has never lasted.
There hasn't been that much innovation in the ISA space since the 80s. There's nothing to suggest there'll suddenly be.
In the first place, the way RISC-V specifications are developed does not invite experiments finding their way into ratified specifications. They can instead live in the encoding space reserved for custom extensions.
This is, of course, in direct contrast to what has been the norm in proprietary ISAs, where the vendor that controls the ISA typically adds "features" to it with abandon.
One of which doesn't require vector. I mean..
> has already caught up with x86-64 and arm64.
What's your actual measure for this?
> And this is unlikely to change.
Is anything is being manufactured in volume with actual specs I can look at?
> much innovation in the ISA space since the 80s. There's nothing to suggest there'll suddenly be.
If what you're suggesting is true then that's what suggests there would be. My pessimism exists for both.
> in direct contrast to what has been the norm in proprietary ISAs
That's because they have actual customers in volume.
Features e.g. hypervisor, cache control, security ...
> Is anything is being manufactured in volume with actual specs I can look at?
RVA23 was just ( I assume) ratified a few days ago on August 29, RVB23 is due December 26th, so actual chips in production, on boards you can buy, will be some time away.
There are several SoCs already out implementing RVA22+V. The CanMV-K230 board is a bit limited with only single core and 512 MB RAM and is only slightly cheaper than an 8 core, 256 bit vectors, 4 GB board with the K1 SoC such as the Banana Pi BPI-F3, which is also available with 8 or 16 GB RAM.
There are also already quite a number of other options to get the same SoC: Sipeed Lichee Pi 3A (or compute module 3A), Milk-V Jupiter (mini-ITX) or laptops including the MuseBook and DC-Roma II.
Those are all just a bit faster than a Raspberry Pi 3 or Zero 2 -- other than having more than 4 cores and much more than 0.5 or 1 GB RAM -- but several faster SoCs are coming soon. First the Eswin EIC7700 with 4 faster (~A75) cores but no V extension, coming on several boards Real Soon Now, then next year the SG2380 with 16 RVA22+V cores that should come in faster than the A76 in the Pi 5, Rock 5, Orange Pi 5.
https://github.com/LuaJIT/LuaJIT/issues/1013#issuecomment-16...
Seeing a project and a community functioning like this is simply inspiring.
> irrelevant or not-well-thought-out features
Looking for specific examples of these. The scoped finalization construct cited in a sibling comments is a great example of this. Are there more?
Wikipedia is also sticking to lua 5.1 with no plans to change (they do not use luajit but normal lua)
In Lua's versioning scheme, each 0.1 increment is a new major version. That means Lua 5.1 => 5.2 => 5.3 => 5.4 is similar to Python 2 => 3 => 4 => 5.
Also, adding support for risc-v is good news, well done!
Here are some numbers:
Lines of code: OpenJDK HotSpot (1.4M), LuaJIT: (92k)
Binary size: OpenJDK HotSpot server/libjvm.so (24MB), LuaJIT: (576KB)
Time to run "Hello, World": OpenJDK HotSpot (64ms), LuaJIT (3ms) (the JVM has improved here, it used to take hundreds of milliseconds)
For me personally, LuaJIT's small size and low overheads set a new standard for what I expect from JIT compiled runtimes.
I also find its small code base makes it approachable to learn from. I won't say that reading the code is easy, but I at least have confidence that whenever I have a question about fast interpreters or JIT compiling techniques, I can find the relevant part of the LuaJIT code and study it. Larger code bases can feel so sprawling that it's hard to ever find the snippet of code that will answer a question.
I think nowadays though, the landscape has changed quite a bit since when luajit was at its peak of popularity.
a) Lua is not necessarily the language one would always choose for scripting, in the first place. There's lots and lots of scripting languages to choose from these days. (It's also increasingly common nowadays for indie gamedev to happen entirely within a game editor, like Unity or Unreal, which provide their own scripting systems. That fact alone has killed a lot of interest in lua.)
b) If you do want to use lua, the features of the official implementation have progressed a lot since v5.1 (which luajit is pinned to), and its performance has improved over the years.
c) There are other competing lua and lua-adjacent implementations to consider as well, like OpenResty's luajit2 or Roblox's Luau.
You don’t really need these features cause Luas 5.x are mostly rehashes of the ideas rather than successive versions.
The team should have frozen it at 5.1, backport everything useful (yield across * basically) from 5.2 and call it done, only fixing bugs and tuning performance. That’s essentially what LuaJIT did/does.
Instead the “upstream” has 4 versions of the same thing with ecosystem and codebases fragmented as a UK flag, for no good reason. LuaJIT fixes that by being awesome, but lives under the shadow of n+1 stereotype, despite being a true engineering project rather than a chain of experiments. Tbh I’m glad I left Lua world many years ago.
for scripting I feel the new lua versions are great, still small, flexible and more powerful
It sounds so strange to me. Great in what? _ENV is the same setfenv() just in the other hand. Yielding across meta and C is nice, but should have been done in 5.1.6 regardless. __{pairs,ipairs} was just dancing around the same old tree as well. GC and interpreter improvements were independent of 5.x flavor and could be backported. Integers are pointless, sorry for the pun. 5.(n+1) may seem “more powerful”, but only because authors of Lua consciously leave 5.(n) undercooked. It’s adhd-rewrite-based development.
other than games, lua is very important to embedded systems
If you mean nodemcu, it stuck in 5.1 too. Everyone who did anything practical stuck in it, because they had shit to maintain. It’s very hard to explain to an innocent user why they have to periodically rewrite their scripts and bump fragile deps for this new “elle yu aeh” thing.
As of motivation, I guess the best source is their mailing list around release dates. It was hot every time. Idk if anyone blogged about it, maybe just ask there.
That being said, I use Lua on an architecture that LuaJIT doesn't support anyway – 68k.
---
[0]: https://love2d.org
[1]: https://lovr.org
Performance, size and compatibility. It's essentially a drop-in replacement for the stock Lua 5.1 implementation, with the same small size but with much higher performance. About the only downside compared to stock Lua 5.1 is that it's less portable.
However, development of LuaJIT almost stopped ~10 years ago, and only seems to be picking up again recently. In terms of the language it hasn't kept up with all the changes in Lua 5.2, let alone 5.3 or 5.4. And in terms of implementation, its performance is still impressive but no longer best-in-class compared to other dynamic-language JITs (e.g. for JavaScript).
LuaJIT's speed is very impressive, but the optimizations it can use are limited by its desire to remain lightweight.
It's understandable that JavaScript implementations, which don't have that restriction, can use different techniques and work out faster overall.
Sorry, you've lost me. What doesn't get used?