Parallel Lua Resumption Point

When I call task.desynchronize when does the post code run? For example if I

Heartbeat:ConnectParallel(function()
--parallel tasks
task.desynchronize()
--serial tasks
end)

As what point during the execution frame would serial tasks run? can someone draw out a visual too that would help, thanks.

From one of my projects:


Parallel always come before serial in the same frame.

So I have tasks in the regular heartbeat ie

Heartbeat:Connect(function()
--do task
end)

Where should that run?

I’ve managed to parallel parts of my code, but for some reason even though the tasks are parallized, they take longer than they would in serial so in the end its literally no performance gain, maybe even at performance lost.

Testing with 8 players in studio test each “DB” is a task for each player.

I parallize it and even though it’s parallized the tasks are taking much longer than they would in serial. Each parallel task in that image has the exact same code as the one with the label “DB” in the first image.

Do you have any reason why this might be? I’m using a big shared table and indexing a lot. Might it be the VM is slower when in parallel?

This post might give you more insight into Parallel LUA.

Try profiling more specific parts of the code to see where the bottleneck is coming from. It usually comes from data bandwidth, but could be something else.

Generally you want to minimize data transaction in multithreading, so you should find a different way of approach if your current solution involve a lot of data moving around.

So I’ve successfully parallized my code. I found out the situation was that I was using shared tables, and updating the value had to update it among other actors’ vms as well. I didn’t need to use this. I ditched shared tables.

However, I still have a scalability issues with player count. The more players the more I have to “prepare” the data to be sent to an actor’s vm by SendMessage. Currently trying to negotiate this issue but I’m having a hard time. This is ultimately my bottleneck.

Each “DB” is a player phase that sets up the necessary information to send to the actors.

task.desynchronize() will start parallel, not go into serial.

Are you writing to SharedTable during parallel execution? You should only do it in the serial phase. Temporarily store what needs to be written in a local table and then after resynchronizing the thread you apply the changes to the SharedTable.

Is it one event per thread per frame? You should also consider using some kind of data compression to hopefully lower the overall bandwidth (and thus bottleneck). For example, encode all your data into a string and use LZW.