
LuaJIT 2.0.3 - kul_
http://luajit.org/changes.html
======
just2n
Do most games that use Lua for scripting (addons, UI, possibly game logic)
actually use LuaJIT?

As far as I could tell, 100% of the AAA titles that use it that I tested (3 in
total) did not. And in profiling, Lua was actually consuming a lot of CPU
relatively.

That confuses me given how easy it is to use LuaJIT over the reference, and
how vital performance in these environments is _.

_ Games, contrary to the beliefs of dense hiring managers, disconnected
producers, and even designers, are performance critical applications --
achieving a mere 30 FPS and > XX+ms input latency on hardware 5 years in the
future in the enthusiast category, on the order of $4000+, is an absolute
failure. Every gamer I've ever met (thousands, thousands upon thousands,
hundreds that I know well) is extremely sensitive to performance. Performance
is king. If a game looks a little shitty but runs AMAZING, it is better than a
game that looks AMAZING but runs a little shitty. Hell, it's even better than
a game that looks WTFAMAZING and runs pretty well. We only start caring about
the looks, typically, when performance is sufficient. So if we can dial the
game's graphics up while maintaining performance, we get happy. Enthusiasts
love it when they can dial all the way to max settings and _still_ play the
game at 60+ fps and unnoticeable input lag. So running your render loop and
lua on the same thread (a WTF in itself) and not using LuaJIT is a huge WTF.

~~~
justincormack
I think people are gradually switching over. There may be some porting
involved, people may have lots of Lua code for older versions. Plus depending
what you are doing the JIT may not speed things up (and you can't use it on
many consoles); the 2.1 has a lot of string functions accelerated that would
break jitting in 2.0. But someone has just paid for a PS4 port, so clearly
many people are using it...

~~~
tomlu
It has worked on PS3 + Xbox360 for some years now and is significantly faster
than vanilla Lua. I've no idea why more games haven't picked it up.

~~~
pjmlp
Religion. It will take ages to move game developers away from C and C++ to
other languages.

Similar to how much it has taken them to move from Assembly to C and C++.

~~~
justincormack
No, they use Lua a lot. The discussion was about LuaJIT vs Lua...

------
pavanky
Curios how many people here actually use Lua ? What are the applications you
are using it for ? I know it is used a bit in the gaming industry for
scripting purposes, but I am not aware of anything else.

We use it internally to map some of the functions in our library to OpenGL.

~~~
neomantra
I've used Lua in the realm of quantitative finance for years. Early on, it was
primarily a flexible configuration tool, embedded in a complex event
processing system.

With the advent of LuaJIT 2, I've used it standalone for analyzing many many
millions of messages per day in real-time, then feeding resultant datasets to
other more batteries-included environments which aren't near as fast (e.g.
Python, Matlab) or to datastores like Redis and Mysql

I also use OpenResty for web applications (risk management apps, charting, and
other visualizations), often pulling from those same datastores. OpenResty is
a joy to work with and is crazy fast.

I make heavy use of the FFI both for library bindings (including system calls)
and general C structure use. The messages mentioned above are represented as
C-structures and are efficiently processed by LuaJIT. I find myself often
writing Lua scripts to do networking programs rather than C. Check out
`ljsyscall`.

Dealing with memory has definitely been a stumbling point, but once I built
enough scaffolding to deal with it (including using jemalloc), it has been
clear sailing. Now I store millions of objects taking many GB of memory
without significant GC pressure using FFI-based HashMaps and Vectors.

Also understanding how to keep the code in the JIT (versus the interpreter)
has taken some artistry -- e.g. examinging the output of -jv and -jdump.

Although this thread is about LuaJIT 2.0.3 release, I use the LuaJIT 2.1
branch which has many enhancements; I especially appreciate the string
improvements and trace stitching.

~~~
lukego
Cool. I found the hash maps and jemalloc binding on Github via your profile.
That's something I imagine we will need in Snabb Switch eventually. Now we
know where to find it! Thanks.

~~~
neomantra
jemalloc really improved my situation. Before it, I would run a study and then
randomly get an out-of-memory error despite having relatively low number/size
of GC objects... my FFI objects were snagging space from them. Switching
allocations to jemalloc (which LDS makes easy to do) alleviated the problem
entirely.

I've been eyeing SnabbSwitch for a while -- I use OpenOnload extensively, so
appreciate what you are doing.

------
deutronium
I really wish I could use LuaJIT, but unfortunately the memory limitations of
it means I can't (I'm aware of FFI).

~~~
justincormack
You really need more than 2G of heap? And can't use ffi? There were some posts
to the mailing list that seemed to have a genuine issue, but most use cases do
not.

~~~
deutronium
Yes, I've posted on the mailing list regarding it before.

~~~
justincormack
Ah ok that was you...

------
mjcohen
And then there is LuaTex: "LuaTeX is an extended version of pdfTeX using Lua
as an embedded scripting language."

See luatex.org.

