Parallel Lua Beta

Updates Announcements
, ,
#144

Is there any word on the development process on this feature? There’s no official 2022 roadmap as far as I’m aware.

#145

Will SetPrimaryPartCFrame and PivotTo be supported to run in parallel in the future?
Having these work in parallel would let us generate block voxel worlds fast, there’s probably many other use cases for this but this is what I tried to do with it.

image

#146

Late reply but, do the math in parallel execution then position everything in serial execution.

Edit: Note that you will see performance gains by using parts that already exist and not Instance.new(), but that isn’t exactly practical, if you do have an upper limit on the voxel count, you could use that.

2 Likes
#147

Is there any update to parallel writing?

1 Like
#148

Any update on when parallel lua may release? I have many projects that use parallel lua and i would love to see this get released to the public

3 Likes
#149

Same here. When is this going to be released? It’s in beta stage for over a year :slight_smile:

3 Likes
#150

This won’t actually help that much. Yes the calculations are much faster, but when blocks are being placed, it’s still as slow as can be. The difference in the end is negligible. But if blocks could be calculated and placed in parallel, that’s when you’d see a real difference. With that being said, I’m still waiting for this as it’s critical for my current project.

2 Likes
#151

Hi!
A question, is it possible to do this pattern?

HeartBeat on main thread → Fire off 100 actors do some work using BindableEvents and ConnectParallel
HeartBeat on main thread → Suspends (not waits) until the actors are all finished

My initial idea would be something like:

local count = 0
callback = Instance.new("BindableEvent")
callback.Invoke:Connect(function(results)
   count-=1
end)


for _,actorEvent in pairs(actors) do
   actorEvent:Fire(work, callback)
   count+=1
end

--somehow suspend, not wait, until count = 0?

(and the actor would just call callback:Fire() in its own bindable event )

2 Likes
#152

Could something like this work?

local ParallelTask = {}
ParallelTask.__index = ParallelTask

function ParallelTask.new()
    local self = setmetatable({}, ParallelTask)
    
    self.count = 0
    self.callback = Instance.new("BindableEvent")
    
    -- We need to connect this here, because some actors may fire immediately after.
    self.callback.Event:Connect(function()
        self.count -= 1
    end)
    
    return self
end

function ParallelTask:fire(actors, ...)
    for _, event in pairs(actors) do
        event:Fire(...)
    end     
end

function ParallelTask:wait()
    while self.count ~= 0 do
        self.callback.Event:Wait()
    end
end

function ParallelTask:Destroy()
    self.callback:Destroy()
end

return ParallelTask
#153

Thats nifty - but what I’m hoping to do is be able to kick off a bunch of actors - just as you’ve shown - but instead of :wait() I want to :suspend() until they’re done, not yielding.

Not sure it’s currently possible.

For context, I have a task that usually happens in heartbeat every frame that takes 16ms, but I would like to reduce that to 8ms by splitting it across two actors, but otherwise everything stays in serial.

#154

What’s the difference between suspending and yielding? In my mind they are the same.

1 Like
#155

When you yield, other coroutines on the main thread can execute.

When you suspend, the whole thread is paused until the condition is met.

--terrible spinlock suspend
while(SomeCondition() == false) do
end

vs


event:wait()
1 Like
#156

I’m a bit confused by what you mean as neither will stop other coroutines on the thread as long as they were executed prior. The only difference I see is how the yield is handled and possibly (and more importantly) timing.

#157

I don’t want any further coroutines on the main thread to resume while I wait for the actors.

#158

That makes sense, I was just a bit confused by your explanation as they both effectively yield. But anyway, I’m still waiting for actors to support property editing so I can continue with my project.

#159

its still working?
cause ive tested and, for me, its not.

#160

I have a newer stable version here:

3 Likes
#161

Thank you very much!
For sure it will help me

#162

Hello! I’m also working on a game involving infinite terrain generation and I would like to understand how you are using it with parallel lua. From my tests generating scripted terrain isn’t thread safe. Id be interested in knowing more of how it was done. Not sure how you make more than 1 thread unless you manually create a few hundred actors.
If you are interested here is what I have so far: Procedural Game Test - Roblox

#163

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.