I wish you guys changed how tables worked too right now they cause a lot of performance penalty if you heavily rely on them.
Example:
Something like checking a grid of blocks and finding which ones are touching into each other every time a block is deleted so you could put them into groups etc. literally freezes the entire server unless you implement something like MaybeYield in fact through some experimenting I found out ray casting for something like that is about 3 times faster when done correctly.
I’m very interested in the implementation of the global container. How would access across multiple VMs work, and would things like metatables and table addresses stay the same?
Also, it would be amazing if we could manually create and manage threads from a single script. My games use a single-script architecture, meaning all of the logic is separated into modules called from a single script and local script. I know many others work the same way, however this wouldn’t work too well with the new actor system.
This is a very amazing feature… But** Its quite performance taking and maybe it could be used for bitcoin mining? (Already tested it and it seemed to work… (10x faster…) .-. )
[Note: I won’t be publishing or sharing the bitcoin miner for parallel lua, as i am unsure if this would be against the TOS (I believe it would…)]
I don’t think there is anything that can be done to fix any of these two… Anyhow it is very useful when trying to run many loops, fast and maybe even synced?
Implementing my own terrain generator using fBM. It’s amazing how easy it is to just chunk things up & throw it into an actor. It just works™. I like it.
Is there any change to when this will be fully released?
Is there some type of demo place for this?
I cant really figure out exactly where/how i could be using this.
It would be very helpful if there was a demo place where some simple code is spread across 16 threads or a getchildren loop spreaded across 16 threads.
Is this behavior expected? If I fire a BindableEvent from an Actor, and listen to it from the main thread, it appears that the code running in the main thread is in “parallel” mode still.
-- Main thread:
bindable.Event:Connect(function()
workspace.Baseplate:Destroy() -- Will throw error: "Function Instance.Destroy is not safe to call in parallel"
end)
-- From actor:
task.desynchronize()
bindable:Fire()
Yup I understand. My question is related to the fact that it is still desynchronized within the event handler in the main thread. I am trying to understand if that is an intended behavior, since it feels like it could cause some headaches.
Really loving this feature, it’s allowed me to do real-time map generation that I could have only dreamed of previously. Currently able to render a map the size of South Carolina!
Any update as to what month actors might get BasePart property access? I’ve got it all organized into chunks so that second actors can make updates to parts under them I’ll be able to get even better performance, hopefully giving me the bandwidth to provide more close-up details.
I’ve been having this issue recently and it’s been really annoying, I found a work around for it though.
Call task.synchronize right before running anything else in the event.
-- Main thread:
bindable.Event:Connect(function()
task.synchronize() -- Workaround for this
workspace.Baseplate:Destroy() -- Will throw error: "Function Instance.Destroy is not safe to call in parallel"
end)
-- From actor:
task.desynchronize()
bindable:Fire()
According to fflag changes, this feature went live today.
I’m not sure if this is a problem of not all changes rolling out to clients yet, but trying to play my testing game with the client causes an immediate crash. Just want to report this here to be safe before it goes live.
Has anyone else started noticing mysterious errors like this popping up from scripts that are not under Actors, are not desynchronizing, and are not and have never used parallel API whatsoever? Probably related to the flag getting flipped today.
These errors are one-offs and seem rare, happening totally at random. I only found these two today.
This code is initialized from a server script that requires a hierarchy of server modules. This function is run on PlayerAdded, and the code that’s erroring runs after some HTTP calls and some datastore calls. The datastore module is third party (DataSync by Mullets) so I don’t know exactly what it’s doing.
SetupServer requires SetupPlayerJoin which connects to PlayerAdded which fires onPlayerAdded, etc.
This code has not been updated for a while. There is no parallel Lua whatsoever.
