Multithreading Best Practices/Tips about simpleecs HOT 8 OPEN

Yeah pretty much, the idea is that a world corresponds to a unity scene. Load a new scene create a new world associated with it, just kept things simple. And from memory unity scenes aren't thread independent so there wasn't really a need for mine to be, but you can easily imagine the kind of hell you'll be in if your player and any other persistent entity id's kept changing xD

I highly encourage this, I wanted to keep things simple so it was hackable and people could adjust it to their needs. It's why there is no concept of systems since I think that concept is better implemented in context to the environment your using it in.

from simpleecs.

Unfortunately the simplicity of the library comes from being single threaded only so I don't really recommend using multiple threads. Doing any structural changes like setting or removing components or creating and destroying entities from anywhere other than the main thread will break everything. Even using different worlds is not safe to use in a multi-threaded context.

However if all you are doing is updating component values in unrelated queries, that should be safe to do.
My biggest recommendation is to only work on 1 query per a thread, and try to make the queries mutually exclusive.
e.g query1 has A not B and query2 has B not A, although so long as your not writing to the the same component across different threads it should be fine. And if you are using a thread pool, only do a handful of queries so you can make doubly sure they don't overlap. Then block on the main thread until they are done before moving on to the next batch.

from simpleecs.

Thanks for the insight! I actually took the Boids sample from DefaultECS and recreated it with SimpleECS using Parallel.For (not ideal, just a naive test). Since the only actions are updating (overwriting) components it didn't appear to "break". It had slightly less FPS than DefaultECS at 1-4 threads but better FPS with 5+ threads (overall SimpleECS was more stable, and definitely easier to write). I will try to write down results and upload to GitHub.

I'd also like to try to improve the multithreading experience, so I've got two areas of question:

1. Is there a specific reason for multiple worlds not being thread safe? Do you think it would be difficult to update it (a fork of your repo) so that world are totally independent (constructor instead of factory)?
2. The queuing inside Query#ForEach is great to work with, and that concept is a common solution to multithreading. Do you think it's possible to reuse StructureEventHandler to create a buffer/recorder that can be used in other threads and then applied on the main thread?

from simpleecs.

1. Simply because I didn't need it to be :) At the moment all the entity location data is stored in a single static array. This is to keep each entity small since each entity only needs to store it's index to that array and what version it is. This also has the benefit when transferring between worlds the IDs stay the same . The simplest solution would be to move that data to the world itself and have the entities store an index to which world it's in. That does add an extra level of indirection and increases each entity's memory footprint though, but is pretty trivial to implement.

2. I haven't thought too deeply about this, but it may be possible. My initial thought is to make an array or dictionary of the StructureEventHandler and when you do a structural change it's just added to the handler at the current thread id.
   User code would then be as simple as calling world.CacheStructuralEvents(true) before your multi-threading code and setting it to false when done.

I'll do some experiments and see how it goes.

from simpleecs.

That makes a lot of sense, especially with the feature of transferring between worlds. In my side projects I don't typically encounter a need to create multiple worlds. What scenarios lead you to using multiple worlds? Did that stem from the previous Unity integration?

I did start to edit a local copy to see how much work it would be to make worlds fully independent (no transfer). It's not too bad, but definitely a significant deviation from your current codebase (World_Info merges into World, Entities get stored on World, and I have a bad habit of reformatting/renaming). I am going to fork your repo and use it as a learning tool/custom tailored ECS (almost identical API though). I am happy to share details/utils/changes and definitely collaborate on new features.

from simpleecs.

Like I said, it's a very well organized project, definitely "welcoming" to those who want to learn more about ECS architecture.

Would you be interested in a PR that adds unit tests? I've updated my fork to use a solution and projects, and before I go messing with the internal API I want to have automated tests to ensure the public API still works as intended.

from simpleecs.

Actually, unit tests are passing one at a time, but not when run together since the underlying state (worlds, entities, etc.) is all shared. It's probably actually finding some bugs in the logic for creating worlds and/or creating entities.

I will setup my repo with unit tests and create a branch for your original source (no changes) so you can take a look if you are interested.

from simpleecs.

Sounds good 👍

from simpleecs.