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

Questions about the LÖVE API, installing LÖVE and other support related questions go here.
Forum rules
Before you make a thread asking for help, read this.
Post Reply
gcmartijn
Party member
Posts: 134
Joined: Sat Dec 28, 2019 6:35 pm

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

Post by gcmartijn »

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
User avatar
slime
Solid Snayke
Posts: 3131
Joined: Mon Aug 23, 2010 6:45 am
Location: Nova Scotia, Canada
Contact:

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

Post by slime »

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.)
gcmartijn
Party member
Posts: 134
Joined: Sat Dec 28, 2019 6:35 pm

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

Post by gcmartijn »

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!
gcmartijn
Party member
Posts: 134
Joined: Sat Dec 28, 2019 6:35 pm

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

Post by gcmartijn »

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

Who is online

Users browsing this forum: charryxopow, Google [Bot] and 49 guests