What are the use cases for sharedtable when using it for parallel computation?
If I can pass arguments between two scripts via SendMessage under an actor, or via BindableEvents why would SharedTable and its registry be of any use?
It just simplifies data transaction. SharedTable should be way faster and way more convenient to use than events or actor messages when it comes to consolidating data between actors.
With SharedTable, each actor will just read and write a table. With events & messages, you have to send and listen to each data request, which comes with bandwidth issues. If you’re trying to consolidate data using events and messages, then you will also need a central “manager” script to communicate and interact between all actors. A SharedTable is already consolidated to begin with.
3 Likes
SharedTables definitely need more work to be properly feasible though, as despite Bindables being able to serialize and transmit Instances, SharedTables still cannot. On top of this, there are performance concerns with SharedTables, especially when dealing with nested SharedTables.
1 Like
I agree, but I believe SharedTable is more meant to be used for hardcore mathematics and number-crunching, like what parallelization is intended for. I personally use it as an actual data registry to keep track of which actor is responsible for which object with an ID system.
The performance implication is inevitable because it has to deal with thread synchronization and all that, but it should still be faster in some ways than sending pure events.
1 Like
This sounds like an interesting solution but how would this work? For my actor pool library I just keep track of free actors and assign eacb one an ID, which will then take a task that is in the current queue all using tables. Haven’t really found a use of shared tables with them.
It may not exactly suit your needs after explaining what it does, but here anyways:
Think of it more like an attendance. The SharedTable is an attendance sheet that tells you where the objects are and under which actor’s custody they belong to. The entire table is organized in a [objectID] = actorID manner.
Here’s an example of what it may look like:
{
["3c1fc069-e2ff-4f5b-866d-86b41ad16446"] = 1, --actor #1
["e8fa6a5a-200d-4ead-9ac6-7ddbfa455b83"] = 4, --actor #4
["21e5cd3a-c162-4f38-a6dc-55bb4c914d9d"] = 6, --actor #6
["d444520d-8afe-4a61-85c2-1d5a4b6885ce"] = 13, --actor #13
}
You just index the SharedTable with the ID of an object to determine which actor they belong to. Now that you know who is responsible for the object, you can ask and communicate directly with the “parent” actor to make changes to the object. And because this is a SharedTable, anyone can see the attendance and know what belongs to who at all times, and make changes at will.
1 Like
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.