[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Lua version census - the results!
- From: nobody <nobody+lua-list@...>
- Date: Tue, 4 Feb 2020 18:03:14 +0100
On 02/02/2020 18.12, Steve Litt wrote:
What is LuaJIT stagnation? Is LuaJIT not effective for versions
after 5.1?
*snip*
I'd say for an application needing speed (not bottlenecked by the
user), this makes LuaJIT very relevant.
Unless you need coroutines that can yield across C calls.
And only if your data set is small enough… if you need to deal with
large amounts of data, you'll have to use 5.3 – LuaJIT still has the 2GB
limit. (I'm not even sure if it has the emergency GC yet… some of my
"small large" programs barely fit in 2GB and they randomly die unless I
insert manual collectgarbage() calls before large allocations… Fun!)
And if you don't need 64-bit integers, or you're willing to deal with
the weird version in LuaJIT (and you write numbers as strings plus a
parsing function, or else it's ok if your code is LuaJIT-only because
Lua doesn't do 'ULL' suffixes on numbers but LuaJIT needs them or else
it's rounded into a double.) (Oh and you don't need 64-bit bitops or
you're willing to make your own…)
And it also won't work if you want to use debug hooks on a separate
coroutine (e.g. abort after N instructions or on any attempted
call, for safely un-dumping some values).
And… (etc.)
* * *
I personally don't really use LuaJIT anymore… when I need speed, it's
either for dealing with large amounts of data (which automatically
disqualifies LuaJIT…[1]) or I'm doing brute (generally mathy)
computations. And then it either involves bit operations (where I'd
rather write Lua 5.3 or C with real operators than use the bit library),
or it's vector math… and getting that really fast means reusing vectors
instead of constantly throwing them away, which means you're not using
operators but functions ADD( a, b[, target] ) etc., which means you're
effectively writing weird assembly, only it's still slower than actual
assembly… so just let the C compiler do the work?
Sometimes the ffi is nice for exploration, but apart from that… It's
been one time too many that input data is "a few MB at most" and then
actually there's one file that's a few hundred MB and LuaJIT just OOMs
out and you'd have to completely rewrite the program… So I generally
end up writing 5.3, and very occasionally pushing hot loops to C (mostly
speed is just fine as-is).
-- nobody
[1] Technically you could allocate stuff outside the preciousss 2GB
region and indirectly access stuff… but… ugh!