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/

Reply via email to