Add LuaJit as a language options

[duckafire]

Replace Lua with LuaJit is a BAD IDEA (I understand it), but why?

• Simple: LuaJit is at v5.1, while Lua (used by Tic80) is at v5.3, so downgrade the version WILL BREAK a lot of cartridge (what is awful).

But if LuaJit is added as an option of language? Like Ruby, JavaScript, ...

-- script: luajit

This would resolve the "problem" (about add LuaJit), and it should add a new (and faster) interpreter to Lua.

That said; why does not it do?

Note

I can try to do this, but I really do not know where to start. If you have some tip about how I can to do this, know that I'm all ears.

Tip

See too:
[FR] Use LuaJIT instead of regular LUA?
Use LuaJIT to run lua cartridges

[Skeptim]

I can try to do this, but I really do not know where to start. If you have some tip about how I can to do this, know that I'm all ears.

I am not competent on this but I guess you could have a look at a PR that added an other language in the past to see where to start.

[RobLoach]

Compiling both at the same time may be a challenge. Are you running into performance issues with Lua to warrant this change?

[duckafire]

Compiling both at the same time may be a challenge. Are you running into performance issues with Lua to warrant this change?

There are two reason to this issue:

1. High performance of JIT can help some developers with "big" projects (mainly fun things, like 3D graphic pseudo-engines).
2. I really like of performance (the greater the better).

Note

Yes, I already had problems with performance, but it was a long time, when I was starting in programming, so I do not have certainty if the problem was the interpreter performance, or if it was my code.

This is not a BIG problem it must to be fixed now, it is just a suggestion of a guy that loves speed.

Maybe, a day, I can try implement this, but I cannot do this now (I am a little busy).

But, why can this be hard? How much similary are the Lua, and LuaJIT API (to C)??

[Kaleidosium]

I'm somewhat skeptical with this proposal, one objection I have is that LuaJIT cannot JIT-compile to WebAssembly at runtime. Since the web player is a massive part of TIC-80's sharing ecosystem, the web version would have to fall back to LuaJIT's interpreter mode, so for web users, it wouldn't have much of a performance boost, thus defeating the purpose of adding LuaJIT (at least for them). And as far as I know, this is from a limitation of WASM itself, so there's nothing we can really do to bypass it.

[duckafire]

[...] LuaJIT cannot JIT-compile to WebAssembly at runtime.

I did not think of that.

Well, about this, it looks like there is no what can be
done about this, unless someone want to create a fork of
LuaJIT to add WASM compilation (spoiler: it is not
worth it).

This fact reduce quite the benefits to include this feature,
but it does not overturn all them. It still can be a good
addition.

Since the web player is a massive part of TIC-80's sharing ecosystem, the web version would have to fall back to LuaJIT's interpreter mode, so for web users, it wouldn't have much of a performance boost, thus defeating the purpose of adding LuaJIT (at least for them).

Based in a SUPER superficial research made by me: LuaJIT
Interpreter no-JIT is fastest than PUC-Lua Interpreter
(used by Tic80). So, if I am not wrong, it will be faster
then Lua even in WEB.

[Kaleidosium]

Faster by how much? I'm not sure if the additional maintenance burden is worth it if we can't even utilize the full JIT, why should we bother?

[duckafire]

Faster by how much?

I do not have a number for you, but I have this.

[imsys]

Playing on a Trimui Smart Pro, I can basically play all games without problem. (compiling with -Ofast and -DCMAKE_BUILD_TYPE=Release).
The games that gets a bit slow in some sections are EMUUROM and Ghost.
It would be nice to find ways to improve the performance, but hardware is also getting better to the point that we don't need to worry that much, but I still would like more performance if possible. But I wonder if there is any other performance bottleneck that could be improved before thinking of LuaJIT.