ActorGroup2 is a rework of my original module ActorGroup, but heavily optimized to use buffers (as in a table to collect results, not a buffer), a single BindableEvent for results, callbacks, etc to ensure you can do heavy calculations fast.
Documentation:
Constructor
There is currently only 1 constructor for ActorGroups.
This constructor creates a new ActorGroup with a module (similar to the ParallelScheduler module), and an amount of workers made count (so for example if count was 128, 128 workers (Actors) would be made.)
This method assigns each value in the assignments table to a worker, and calls callback with the results once it is done.
Note that the number of assignments cannot be more than the number of workers, because as said before, each value is assigned to exactly 1 worker.
This is a utility method to split an array of assignments into batches based on the number of workers.
Useful if your existing code doesn’t implement batches, but you still want to use them.
ActorGroup:Destroy()
Removes the ActorGroup from memory.
ActorGroup Best Practices
For the purposes of doing heavy calculations, it is recommended to make your module able to handle multiple calculations at once.
For example, this is reading a 500x500 stud region of Terrain with this best practice in mind, completed in 0.4s:
Not only is it slower, it also requires more workers (because each value in the assignments table passed in :BulkWork() is assigned to exactly 1 worker.)
Reading a 1000x1000 stud region of Terrain completed in 0.5s!
Update: Added the :BatchAssignments() method to conveniently batch an assignment array into multiple nested arrays containing those assignments. Very useful if you want to do stuff in bulk but don’t want to modify existing logic
I feel like it might be more beneficial (especially with the nature of what this aims todo) to use Promise for more consistent/predictable results overall with Parallel Threading overall.
In the end, this module does seem cool for sure and not using Promises isn’t a deal breaker for me and I might go through and use it (and if not; this will be a great resource for me to look into for my own custom solution that wouldn’t see a open source release!)
i can’t seem to get an updated version of this? inserting the rbxm seems to insert the first release, evidenced by the function still being named BulkWork and having Promise packed in.
the packagelink says its version number 1 and i can’t do anything to change it. and when i insert it studio prints “Error AutoUpdating Package: Request Failed” to the output
I also have my own parallel luau library. I’ve tested a couple of benchmark methods, and just scaling a vector3 region doesn’t really showcase the full power of the parallelism, since its just multiplication and addition, just some light calculation that can be done (maybe faster) in serial
Yeah… not gonna lie I was just kinda too lazy to make something like a voxel engine for demonstration purposes xd, I am currently working on a semi-random world gen utilizing this module though, so once it’s done I’ll show it off as a nice demonstration… for now though that’s all I have right now
True, I’ve tried to come up with a simple yet powerful demo, but all I could do is some ASCII Shader (stupid editableimage getting locked behind a id verification wall)
Hello, because of some issues I am unfortunately unable to release the next update, however just know it will contain buffers and better ways to share information ive found
If your raytracing uses raycasts you can indeed just have alot of actors working to compute those raycasts then send the result back, do note that if your module returns a tuple it will be packed as a table in the final results table
I would also keep in mind the best practices i mentioned in the post, make sure each actor can handle multiple things because the amount of workers you can use on Roblox is very restricted
Also, this can be even faster with proper actor scheduling however thats inside the next update which i am unable to release yet because my laptop is broken
