Recommended Posts

hyiltiz    296

Been over 3 years since [1], so what are the roadblocks? Arguably LuaJIT got more mature but the game got richer so even more justifies aiming for performance.

 

 

Share this post


Link to post
Share on other sites
CarlZalph    3,455
12 hours ago, hyiltiz said:

Been over 3 years since [1], so what are the roadblocks? Arguably LuaJIT got more mature but the game got richer so even more justifies aiming for performance.

From that thread:

Quote

I have actually had to modify lua scripts for LuaJit to behave 100% identical. Taking all this (and some other things) into account, the risk and added complexity has outweighed the benefit.

In short LUAJIT would require refactoring their code and could add in more bugs.

I don't blame Klei for not wanting to use it.

  • Thanks 1

Share this post


Link to post
Share on other sites
hyiltiz    296

That was LuaJIT 3 years ago. Assuming LuaJIT got more feature complete over these years, it may be possible to migrate with minimal effort? As I understand, it is quite common to hack lua the language, aka its interpreter, for lrge lua apps to expose or adjust some internal behavior. If Klei also uses those methods, I wonder if those are still possible to apply to LuaJIT.

Share this post


Link to post
Share on other sites
hyiltiz    296

LuaJIT official site says [1] running lua 5.1 (DST runs lua5.1) compatible code with LuaJIT should require no changes to the source at all; that may not have been true a few years ago.

Quote
LuaJIT ought to run all Lua 5.1-compatible source code just fine. It's considered a serious bug if the VM crashes or produces unexpected results — please report this.

Known incompatibilities and issues in LuaJIT 2.0:

  • There are some differences in implementation-defined behavior. These either have a good reason, are arbitrary design choices or are due to quirks in the VM. The latter cases may get fixed if a demonstrable need is shown.
  • The Lua debug API is missing a couple of features (return hooks for non-Lua functions) and shows slightly different behavior in LuaJIT (no per-coroutine hooks, no tail call counting).
  • Currently some out-of-memory errors from on-trace code are not handled correctly. The error may fall through an on-trace pcall or it may be passed on to the function set with lua_atpanic on x64. This issue will be fixed with the new garbage collector.

[1] http://luajit.org/status.html

Edited by hyiltiz

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now