LÖVE

Posted: **Sun Jan 22, 2023 5:43 pm**

H!

I'm working on a old MacBook Air 2014, and sometimes I test the 'game' on the iMac M1.
And it was much slower.

Then I did bring the code down to a simple test case that everyone can run, and see the problem.
But I can fix it to not use threads.

The facts are:
- Love 11.4
- MacBook Air 2014 = elapsed time: 0.11
- Imac M1 = elapsed time: 1.45 !

When I don't use the Thread function and copy/past the pathfinding.lua code inside main.lua
- MacBook Air 2014 = elapsed time: 0.03
- Imac M1 = elapsed time: 0.01 !

Conclusion for me at this point:
- Never use threads for pathfinding / alias big tables, they can be a bottleneck.
- Maybe for small tables they can be use full for non important things like background stuff that not really needed.

But maybe it is a bug in SDL2/love2d?

main.lua

Code: Select all

function love.load()
    pathfinding = love.thread.newThread("pathfinding.lua")
    pathfinding:start()
end

function love.update(dt)
    local pathFindingResult = love.thread.getChannel("follow_path"):pop()
    if pathFindingResult then
        print(1)
    end
end

pathfinding.lua

Code: Select all

local x1, y1, x2, y2 = 0, 0, 480, 180

local collisionRectsTable = {}
table.insert(
    collisionRectsTable,
    {
        {a = 1, b = 2, c = 3, d = 4},
        {a = 1, b = 2, c = 3, d = 4},
        {a = 1, b = 2, c = 3, d = 4},
        {a = 1, b = 2, c = 3, d = 4}
    }
)
table.insert(
    collisionRectsTable,
    {
        {a = 1, b = 2, c = 3, d = 4},
        {a = 1, b = 2, c = 3, d = 4},
        {a = 1, b = 2, c = 3, d = 4},
        {a = 1, b = 2, c = 3, d = 4}
    }
)
table.insert(
    collisionRectsTable,
    {
        {a = 1, b = 2, c = 3, d = 4},
        {a = 1, b = 2, c = 3, d = 4},
        {a = 1, b = 2, c = 3, d = 4},
        {a = 1, b = 2, c = 3, d = 4}
    }
)
table.insert(
    collisionRectsTable,
    {
        {a = 1, b = 2, c = 3, d = 4},
        {a = 1, b = 2, c = 3, d = 4},
        {a = 1, b = 2, c = 3, d = 4},
        {a = 1, b = 2, c = 3, d = 4}
    }
)
table.insert(
    collisionRectsTable,
    {
        {a = 1, b = 2, c = 3, d = 4},
        {a = 1, b = 2, c = 3, d = 4}
    }
)
table.insert(
    collisionRectsTable,
    {
        {a = 1, b = 2, c = 3, d = 4},
        {a = 1, b = 2, c = 3, d = 4},
        {a = 1, b = 2, c = 3, d = 4},
        {a = 1, b = 2, c = 3, d = 4}
    }
)
table.insert(
    collisionRectsTable,
    {
        {a = 1, b = 2, c = 3, d = 4},
        {a = 1, b = 2, c = 3, d = 4},
        {a = 1, b = 2, c = 3, d = 4},
        {a = 1, b = 2, c = 3, d = 4}
    }
)

t = 1

local function isPointInCollision(x, y)
    for _, collisionRects in pairs(collisionRectsTable) do
        for _, rect in pairs(collisionRects) do
            t = t + 1
        end
    end
    return false
end

local x = os.clock()

local map = {}
for y = y1, y2 do
    map[y] = {}
    for x = x1, x2 do
        if isPointInCollision(x, y) then
            map[y][x] = 1
        else
            map[y][x] = 0
        end
    end
end

print(string.format("elapsed time: %.2f\n", os.clock() - x))
print(t)

love.thread.getChannel("follow_path"):push({bla = 1})

Greetings,
GCMartijn

Posted: **Sun Jan 22, 2023 6:05 pm**

On the M1 Mac, there's a problem in LuaJIT's arm64 backend. It has a very limited address range it can use to allocate memory for JIT-compiled code. The address range is shared across threads (and other C/C++ code can steal some of the range too), so it's really easy to use up the entire range. Once that happens LuaJIT gets really slow because it keeps trying to recompile code and failing.

There's a bug report in LuaJIT's issue tracker about it, but it doesn't seem like it'll be addressed in the near future: https://github.com/LuaJIT/LuaJIT/issues/285

One workaround is to turn off JIT compilation via jit.off().

----

That being said, it's likely for your code the more fundamental problem is inefficient use of threads rather than anything else. Just putting the same code on a thread won't make that code run any faster than it would on the main thread. Also putting a table into a channel copies it, and taking it out of the channel copies it again. Those copies aren't especially fast, so you'd want to minimize how much stuff is copied across threads in hot code.

(Also os.clock probably doesn't measure what you think it does - you can use love.timer.getTime.)

Posted: **Sun Jan 22, 2023 6:22 pm**

Ah jit.off() inside pathfinding.lua generate 0.03 on the iMac now.

But you are right, moving code from the main thread to another don't make any sense.
I did this 2 years ago, because there was a small problem inside the pathfinding, that was resulting in a small delay when the player want to move to another point. I did 'fix' that by start walking to the point, and calculate the path inside another thread...

Today I was refactoring this and fix the error, so the thread is not needed anymore.

Maybe you can add that issue to the love2d api docs for thread WARNING ARM64 , slow bottleneck use jit.off()

Thanks!

Posted: **Sun Jan 22, 2023 6:27 pm**

Now I'm wondering, I never understand that jit , or never read about it (maybe later). but for M1 (arm64) is it better to do for the whole program jit.off()?

Or in other words, my target is Mac, iPad, switch, pc.
Is it better (more stable) do turn jit off ?

LÖVE

1. Thread much slower then non thread. 2. Thread slower on much faster hardware

1. Thread much slower then non thread. 2. Thread slower on much faster hardware

Re: 1. Thread much slower then non thread. 2. Thread slower on much faster hardware

Re: 1. Thread much slower then non thread. 2. Thread slower on much faster hardware

Re: 1. Thread much slower then non thread. 2. Thread slower on much faster hardware