[HN Gopher] LuaJIT PR: Add Support for RISC-V 64
___________________________________________________________________
LuaJIT PR: Add Support for RISC-V 64
Author : ignota
Score : 99 points
Date : 2024-09-08 10:57 UTC (12 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| fwsgonzo wrote:
| Wow, that's an impressive PR with very well written and succinct
| code. Macro-fusion too! B-extension support!? I see some RORIWs
| in there.
|
| Alright, time to run some LuaJIT in my RISC-V emulator.
| fwsgonzo wrote:
| 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)
|
| It's definitely working!
| xeonmc wrote:
| Can this be embedded into a game engine to enable performant
| Lua scripting?
| extrememacaroni wrote:
| That's literally one of the main uses of luajit.
| _cogg wrote:
| You used to have to be extremely careful to keep the JIT
| happy, but I think this has been partially solved in LuaJIT
| 2.1.
|
| 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.
| mardifoufs wrote:
| It it still true that generating bindings for luajit is
| easier than with plain Lua? When I used it for a toy
| project that was the main reason I chose luajit,
| especially since the project was written in c++.
| _cogg wrote:
| Writing bindings isn't something I have a lot of
| experience with. The main difference I'm aware of is the
| FFI system, which creates bindings from C headers, and
| will result in faster calls with good JIT support. I
| assume it introduces some extra security challenges if
| you care about that. You'll still probably need to write
| some wrappers, either C-side or Lua-side if you want a
| nice API. I know there are other tools for creating
| bindings, but again, not my area of expertise.
| krapp wrote:
| In my experience it very much is. Most of the LuaJIT code
| I write is just metatable classes around C libraries like
| SDL. Just being able to write C structs and lua functions
| is a dream. Having to manually deal with the stack from
| C-side is a PITA.
| vvanders wrote:
| Can? It always has been :).
|
| 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.
| fwip wrote:
| I think parent is asking specifically about luajit, not
| just Lua the language.
| krapp wrote:
| Yes, Luajit.
| a1o wrote:
| Uhm, I remember LuaJIT used to be frozen in Lua 5.1, is it still
| the case or is it now synced to the latest Lua release?
| tristan957 wrote:
| I believe it is mostly still the case, but some features from
| newer Lua revisions have been added.
| mardifoufs wrote:
| I think the LuaJIT maintainers have some issues with recent
| additions to the language, and with the direction that the Lua
| team has taken. So yes, frozen to 5.1 for the foreseeable
| future except for some features from more recent versions.
| matheusmoreira wrote:
| I can't seem to find any information about this. What issues
| did LuaJIT maintainers have with upstream Lua?
| edflsafoiewq wrote:
| https://github.com/LuaJIT/LuaJIT/issues/929
| mardifoufs wrote:
| The issue linked in the sibling comment is the main one,
| but for a specific example of them having reservations
| about a feature in a more recent version, there's this:
|
| https://github.com/LuaJIT/LuaJIT/issues/1013#issuecomment-1
| 6...
| matheusmoreira wrote:
| That's an awesome example, thank you. I'm making my own
| language and it's hard to overstate how thorny the
| evaluator and call stack code can get once seemingly neat
| features are added. I'll try to avoid making the same
| mistakes. I agree with him that implicit scopes for
| resource management serve no purpose in a dynamic
| language.
| upofadown wrote:
| I think we can concede that there is a legitimate language fork
| here. I personally was not all that happy with the extent of
| the changes in 5.3. I would be just as happy at 5.1.
| bawolff wrote:
| It seems like each version of lua is kind of a separate
| language.
|
| Wikipedia is also sticking to lua 5.1 with no plans to change
| (they do not use luajit but normal lua)
| pansa2 wrote:
| > _It seems like each version of lua is kind of a separate
| language._
|
| 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.
| Alifatisk wrote:
| What's the deal with LuaJit? Why is it celebrated so much? I
| searched around a bit and they all talked about it being very
| fast, is that it? Performance?
|
| Also, adding support for risc-v is good news, well done!
| wsc981 wrote:
| It's used in LOVE [0] (and LOVR [1] as well, I think) for this
| very reason. The Lua code for a game will be quite performant.
|
| ---
|
| [0]: https://love2d.org
|
| [1]: https://lovr.org
| 3eb7988a1663 wrote:
| Also NeoVIM
| pansa2 wrote:
| > _is that it? Performance?_
|
| 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).
| wavemode wrote:
| It's widely regarded as a highly performant and very well-
| engineered runtime for a popular language. For a long time it
| was the go-to implementation you would reach for if you a)
| wanted lua scripting (common in game development) and b) wanted
| high performance.
|
| 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.
| wruza wrote:
| b)
|
| 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.
| mardifoufs wrote:
| I'm more familiar with luajit than Lua itself (as a project
| I mean). I'd be curious to know more about the
| fragmentation that vanilla Lua has. I know the issues that
| the luajit devs have with the features themselves but I
| wonder how and why those are decided and implemented. Is
| there an article or blog that goes into more details?
| Google isn't helping me here haha.
| synergy20 wrote:
| The integer and bitwise addition are pretty nice, lua5.2+
| adds more complexity for luajit to upgrade and sync with,
| but for scripting I feel the new lua versions are great,
| still small, flexible and more powerful. other than games,
| lua is very important to embedded systems.
| edflsafoiewq wrote:
| It's also tiny (like half a meg compiled) and has some nice
| extensions, like one of the best FFIs in any language.
| haberman wrote:
| LuaJIT completely upended my view of what a JIT compiler could
| be. I always thought that JVM-like overheads were inevitable
| for high-performing JIT compilers. When I saw how small and
| low-overhead LuaJIT is, I was blown away.
|
| 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.
| sroussey wrote:
| It's small size and fast performance means it can be
| implemented in a webserver (OpenResty's luajit2.1) where you
| can write code that would tap into the TLS handshake and write
| a custom implementation (like connecting to a database of
| certificates because you serve 10s of millions of domains).
| matheusmoreira wrote:
| Yes, performance. It got to the point that there are languages
| out there that compile to Lua or LuaJIT VM bytecode directly
| just to take advantage of the LuaJIT implementation. Apparently
| it's so good it spawned a separate language when the people at
| PUC-Rio started taking Lua in a direction that LuaJIT didn't
| want to follow.
| snvzz wrote:
| RISC-V is rapidly growing the strongest ecosystem.
| akira2501 wrote:
| It's the newest ecosystem. They all seem strong when they are
| uncomplicated. So far that has never lasted.
___________________________________________________________________
(page generated 2024-09-08 23:00 UTC)