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-requ...@lists.iem.at wrote: > > Message: 3 > Date: Wed, 2 Oct 2024 18:13:32 +0200 > From: Christof Ressi <i...@christofressi.com <mailto:i...@christofressi.com>> > Subject: [PD] Re: Lua in pd > To: pd-list@lists.iem.at <mailto:pd-list@lists.iem.at> > Message-ID: <b5a3d5d6-e548-43db-8863-8c3bd9281...@christofressi.com > <mailto:b5a3d5d6-e548-43db-8863-8c3bd9281...@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 <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>
--- pd-list@lists.iem.at - the Pure Data mailinglist https://lists.iem.at/hyperkitty/list/pd-list@lists.iem.at/message/7JF5JGRODPP2BPKZ2P6BU2ZQUXSNFNNX/ To unsubscribe send an email to pd-list-le...@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.iem.at/