Honestly, I would not suggest using LuaJIT by default. It doesn't have support for as many archs and systems as a pure C project like Lua, due to the assembly.

I say that having a Lua-based project in openFrameworks for over 10 years: I keep the Lua version up to date with the latest stable release, but make it possible for people to use LuaJIT. It definitely helps with realtime graphics on embedded systems, RPi for example.

On Oct 2, 2024, at 6:13 PM, pd-list-request@lists.iem.at wrote:

Message: 3
Date: Wed, 2 Oct 2024 18:13:32 +0200
From: Christof Ressi <info@christofressi.com>
Subject: [PD] Re: Lua in pd
To: pd-list@lists.iem.at
Message-ID: <b5a3d5d6-e548-43db-8863-8c3bd92812d1@christofressi.com>
Content-Type: multipart/alternative;
boundary="------------sin7OcxzKLJn12uvlllSAVsz"

LuaJIT is awesome, but is it a good idea to run a JIT on the audio 
thread? Compiling code is certainly not realtime safe and I think we 
have no control over /when /individual functions are being compiled. So 
while LuaJIT would give better performance, I assume it would have a 
larger worst-case latency. One the other hand, LuaJIT also has a faster 
bytecode interpreter (written in hand-optimized assembly). We could 
allow people to select the JIT compiler or the bytecode interpreter as a 
runtime option.

Side note: LuaJIT also supports a subset of Lua 5.2.

--------
Dan Wilcox
danomatika.com
robotcowboy.com