LÖVE 11.4 - out now!

General discussion about LÖVE, Lua, game development, puns, and unicorns.
User avatar
veethree
Inner party member
Posts: 877
Joined: Sat Dec 10, 2011 7:18 pm

Re: LÖVE 11.4 - out now!

Post by veethree »

Awesome! Thanks guys ☺️
User avatar
slime
Solid Snayke
Posts: 3166
Joined: Mon Aug 23, 2010 6:45 am
Location: Nova Scotia, Canada
Contact:

Re: LÖVE 11.4 - out now!

Post by slime »

ruairidx wrote: Tue Jan 04, 2022 6:05 pmIs 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.
User avatar
Jasoco
Inner party member
Posts: 3727
Joined: Mon Jun 22, 2009 9:35 am
Location: Pennsylvania, USA
Contact:

Re: LÖVE 11.4 - out now!

Post by 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
Prole
Posts: 5
Joined: Sun Nov 28, 2021 6:49 am
Contact:

Re: LÖVE 11.4 - out now!

Post by ruairidx »

slime wrote: Tue Jan 04, 2022 6:30 pm You can use the jit.arch variable.
Perfect, thank you!
slime wrote: Tue Jan 04, 2022 6:30 pm 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!
User avatar
slime
Solid Snayke
Posts: 3166
Joined: Mon Aug 23, 2010 6:45 am
Location: Nova Scotia, Canada
Contact:

Re: LÖVE 11.4 - out now!

Post by 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.
User avatar
EngineerSmith
Prole
Posts: 38
Joined: Thu Dec 02, 2021 11:38 am
Contact:

Re: LÖVE 11.4 - out now!

Post by EngineerSmith »

ruairidx wrote: Tue Jan 04, 2022 6:05 pm 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
User avatar
Gunroar:Cannon()
Party member
Posts: 1142
Joined: Thu Dec 10, 2020 1:57 am

Re: LÖVE 11.4 - out now!

Post by Gunroar:Cannon() »

Luajit /jit.on() work on Android now?
The risk I took was calculated,
but man, am I bad at math.

-How to be saved and born again :huh:
User avatar
slime
Solid Snayke
Posts: 3166
Joined: Mon Aug 23, 2010 6:45 am
Location: Nova Scotia, Canada
Contact:

Re: LÖVE 11.4 - out now!

Post by slime »

No, LuaJIT's arm64 memory allocation issue affects Android as well but the workaround in love's source doesn't work there.
ruairidx
Prole
Posts: 5
Joined: Sun Nov 28, 2021 6:49 am
Contact:

Re: LÖVE 11.4 - out now!

Post by ruairidx »

slime wrote: Tue Jan 04, 2022 6:55 pm 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.
User avatar
slime
Solid Snayke
Posts: 3166
Joined: Mon Aug 23, 2010 6:45 am
Location: Nova Scotia, Canada
Contact:

Re: LÖVE 11.4 - out now!

Post by 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
Post Reply

Who is online

Users browsing this forum: No registered users and 7 guests