Re: Lua in pd

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, [email protected] wrote:
> 
> Message: 3
> Date: Wed, 2 Oct 2024 18:13:32 +0200
> From: Christof Ressi <[email protected] <mailto:[email protected]>>
> Subject: [PD] Re: Lua in pd
> To: [email protected] <mailto:[email protected]>
> Message-ID: <[email protected] <mailto:[email protected]>>
> 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/>

---
[email protected] - the Pure Data mailinglist
https://lists.iem.at/hyperkitty/list/[email protected]/message/7JF5JGRODPP2BPKZ2P6BU2ZQUXSNFNNX/

To unsubscribe send an email to [email protected] mailing list
UNSUBSCRIBE and account-management -> https://lists.iem.at/