Parallel Luau [Version 2 Release]

[tnavarts]

You need to write for i, v in st do ... without the ipairs for it to work, not for i, v in ipairs(st) do ...

[Tomi1231 (Chilly28)]

Thanks, for the answer
I never knew tables could be itterated without using ipairs or pairs…

It might be good idea to make it clearer in the documentation, although I did not notice, but the SharedTable documentation does have an example with for loops that doesn’t use pairs or ipairs

[nooneisback]

It would be nice if we could designate ModuleScripts as non parallel safe without using janky methods like using attributes to check if it was required more than once. 2 or more actors trying to require a library inside a ModuleScript that stores data in a table is just inviting trouble.

[Bam_Sori]

I hope Model:GetScale() is changed to WriteParallel.
When calculating the size or position to be applied, my game calculates in parallel for performance.
But you must use task.syncronize before to get the scale of the model.
I hope :GetScale() will be available in parallel in the next update

[Bam_Sori]

Bug related to SharedTable keys.

SharedTables cannot properly set a key as a string if it contains non-standard spaces.
Any characters following a space in the key string are removed.

Example code:

local st = SharedTable.new()

local arbitraryString = string.pack( "f", 1 )
print(`"{arbitraryString}"`) --> "  �?"

st[arbitraryString] = "arbitraryValue"
print( st[arbitraryString] == st[""] ) --> true
for k in st do
	print(`"{k}"`) --> ""
end

local arbitraryString = string.pack( "I f", 1, 1.4)
print(`"{arbitraryString}"`) --> "   33�?"

st[arbitraryString] = "arbitraryValue"
print( st[arbitraryString] == st[""] ) --> true
for k in st do
	print(`"{k}"`) --> ""
end

Repro

• test place: Shared Table Key String Bug - Roblox
  
  

[technology1111 (rustfanboy)]

I have been experimenting with SharedTables and have came to the conclusion that you cannot insert/remove values in a SharedTable.

local st = SharedTable.new()
table.insert(st, 1) -- wont work
-- no SharedTable.insert

table.remove(st, 1) -- wont work
-- no SharedTable.remove

This is vital in working with arrays in SharedTables.

[rep_movsb]

@Bam_Sori Thank you for reporting this issue with string keys that contain an embedded null character. This is a bug, and we’ll work to get a fix into an upcoming release.

@technology1111 Thank you for this suggestion; we are considering further enhancements to the SharedTable API and have these on our list of things to consider.

[Skidouski (caseoh)]

Hello, this is honestly one of the greatest updates for me personally, I can finally do heavy computations on separate threads! So I haven’t fully studied parallel luau yet, but I have some questions regarding if multi threading is possible on server side scripts. Does Roblox servers utilize multiple threads? Because if Roblox servers run on 1 core and 1 thread there would be no possibility for multi threading, because there is only 1 thread if I am correct? Please correct me if I am incorrect.

[jake_4543 (Jakey)]

Any updates as to if this could be made parallel safe?

At the moment I have to employ the use of two seperate functions to get TransformedWorldCFrame in a performant manor, if this was to be made parallel safe I would greatly appreciate it!

[Wingboy0]

Any chance that BasePart.CFrame, Bone.CFrame/Transform and BulkMoveTo() could become parallel write safe? being able to directly modify bulk amounts of objects positions in the world would be a huge improvement

[bigtheangry]

adding onto this, PivotTo would be a great benefit too

[BubasGaming]

I heard somewhere (i don’t remember where) that roblox server has 32 cores. I might be wrong tho. But i am pretty sure it has more than a 1 core.

[xtremsk8rs2]

This is a great update, I just have one problem. I want to send messages to actors in parallel, but this seems to be impossible as the messages seem to only get processed once the current parallel work is finished.

I would assume that once the message is sent, it gets received and processed immediately. If this were true, then Returned Garbage should play at the same time as Secondary Parallel Garbage.
Instead it seems to wait until all the parallel work is finished before processing any messages that were sent.

I wonder if it is possible to make it so that the message is processed instantly, given that the listening thread is sleeping. Or if not, if it may be possible in the future.

Main code

local actor=script.Parent.Parent.Folder.Actor

task.wait(2)
debug.profilebegin("Serial Garbage")
for i=1,500000 do
	local m=math.pow(math.random(),math.random())
end
debug.profileend()

actor:SendMessage("Do Work")

script.Parent:BindToMessageParallel("Return",function()
	debug.profilebegin("Returned Garbage")
	for i=1,500000 do
		local m=math.pow(math.random(),math.random())
	end
	debug.profileend()
end)
task.desynchronize()


debug.profilebegin("Parallel Garbage")
for i=1,500000 do
	local m=math.pow(math.random(),math.random())
end
debug.profileend()

Here is the secondary code (Unzipper1)

script.Parent:BindToMessageParallel("Do Work",function()
	debug.profilebegin("Parallel Garbage")
	for i=1,500000 do
		local m=math.pow(math.random(),math.random())
	end
	debug.profileend()
	script.Parent.Parent.Parent.Actor:SendMessage("Return")
	debug.profilebegin("Secondary Parallel Garbage")
	for i=1,500000 do
		local m=math.pow(math.random(),math.random())
	end
	debug.profileend()
end)

[AxisAngle (AxisAngles)]

Maybe DeferredMoveTo(parts, cframes)?

Can’t write in parallel, but maybe doing the Lua-C bridge part of the MoveTo in parallel would make a big enough difference that it would be worth it.

[CoderJoey (Joey)]

We have tried to utilize Parallel Luau for the last 6 months in Pet Simulator 99. We launched our game utilizing SharedTables, only to find out that they were synchronized in a way that completely kills performance. Every single query to a SharedTable value results in locking (every individual query.) There is presently no way to communicate back to the main game thread other than utilizing BindableEvent, SharedTable, or attributes. All of which have compromises. We ended up using BindableEvent.

SharedTable is utterly useless and negatively effects performance and battery usage due to the way it was implemented. It was implemented as an ‘deep atomic map’ or ‘deep locked map’ in which every single query to any key or sub-key results in locking/atomic access.

Give us a way to communicate back and forth in an efficient manner between sync/parallel threads. There is simply too much hand holding to make this feature useful.

For context: we were trying to figure out why our pets were so poorly performant. Upon a lot of benchmarking and isolating things - we found that SharedTable’s were responsible for a 2x slow down which resulted in a 8 parallel executors being equivalent to 4, 2 being equivalent to 1 - etc.

[RaterixRGL (Raterix)]

I agree, I’ve had a lot of trouble with this.

How’s your experience with using _G for your shared table?