LÖVE 11.4 - out now!

[veethree]

Awesome! Thanks guys

[slime]

Is there any way to detect the current running architecture (e.g. love.system.getArch() or something)?

You can use the jit.arch variable.

One note about arm64 support – LuaJIT 2.1's JIT code memory allocator has issues with arm64 that makes it run out of JIT compiler memory very easily (which won't crash your game but it will make it run slower). There's a workaround inside LÖVE to try to make as much memory possible available to it, but it's not perfect. Hopefully the situation improves in LuaJIT's source code soon.

[Jasoco]

The download link on the homepage still links to 11.3. I was able to just change the link to say 11.4 instead and downloaded it.

That said, wow, a native Silicon version really makes a difference for performance for me now. At least in g3d it seems to be faster. It's just nice to be native now. At least in my current project, zooming out to see the whole world with all the updating 3D models at once and I get 75FPS. In 11.3 through Rosetta it was dropping to like 30FPS. I'm impressed. Interesting though it didn't seem to make a difference in my old ray caster for speeding up the casting. Maybe it's mostly GPU performance boosts?

[ruairidx]

You can use the jit.arch variable.

Perfect, thank you!

One note about arm64 support – LuaJIT 2.1's JIT code memory allocator has issues with arm64 that makes it run out of JIT compiler memory very easily (which won't crash your game but it will make it run slower). There's a workaround inside LÖVE to try to make as much memory possible available to it, but it's not perfect. Hopefully the situation improves in LuaJIT's source code soon.

This is amazing; I knew something like this was going on and had a massive issue with it in this game (which is very wasteful with its memory and uses a lot of single-use tables), but had a lot of trouble diagnosing what exactly was going on so I could ask about it here. I ended up fixing it by turning jit off with jit.off() and I never had the issue again, but incredible to know what the actual issue was! Attached the full comment from my main.lua from over a month ago for your enjoyment.

Code: Select all

-- Game would slow to a crawl after about 30 seconds of match play
-- on M1 Pro. The cause was never truly found but it caused pairs()
-- invocations and table removals to become significantly slower (see
-- debug-timings branch).
-- After a lot of testing and trial and error, it was discovered that
-- disabling the JIT compiler would resolve the performance issues. It's
-- unclear why but presumably it involves the Apple Silicon compilation
-- of LuaJIT and will be fixed in future. Periodically, this line should
-- be reviewed to see if it's still necessary.
jit.off()

Thanks again mate!

[slime]

If you were using an old build of love 11.4 for macOS before, jit.off() might not be needed anymore (or at least I'd be curious if it is), since the workaround in love's source was added relatively recently.

[EngineerSmith]

Is there any way to detect the current running architecture

You can do it with ffi

Code: Select all

local ffi = require("ffi")
local is64Bit = ffi.abi("64bit") -- returns boolean type
-- argument "32bit" also works and will be the opposite of what "64bit" returns

[Gunroar:Cannon()]

Luajit /jit.on() work on Android now?

[slime]

No, LuaJIT's arm64 memory allocation issue affects Android as well but the workaround in love's source doesn't work there.

[ruairidx]

If you were using an old build of love 11.4 for macOS before, jit.off() might not be needed anymore (or at least I'd be curious if it is), since the workaround in love's source was added relatively recently.

I gave it a go; I unfortunately still got the performance hit without `jit.off()`, although anecdotally I think it's less severe than it was when I last tried with a dev build from github. I can PM you a .love if you plan to keep investigating and would find it helpful.

[slime]

Unfortunately I don't think there's much more that can be done in love's source code, since it's ultimately a limitation with LuaJIT's jit code memory allocator. There's a LuaJIT bug report about it here https://github.com/LuaJIT/LuaJIT/issues ... -285194907