DaanVanYperen
commented
2 years ago Actually i dont know if it makes sense to post this here... i get the feeling that artemis is quite dead and the only contribuer left is @DaanVanYperen
Contribution is more sporadic than I'd like, sure. @junkdog considers artemis-odb to be largely feature complete. We're effectively in maintenance mode.
Generic multithreading is probably not going to happen given the effort required. Since any multithreading solution is so use-case specific your best bet is to ask for suggestions on the LibGDX discord ECS channel.
Some related tickets: https://github.com/junkdog/artemis-odb/issues/609 https://github.com/junkdog/artemis-odb/issues/610 https://github.com/junkdog/artemis-odb/issues/518
Actually i dont know if it makes sense to post this here... i get the feeling that artemis is quite dead and the only contribuer left is @DaanVanYperen
We all know that artemis is not thread safe and therefore provides no feature which allows us to use it in an multithreaded environment.
But multithreading & jobs are actually quite important for games. Especially when you use artemis for an multiplayer server ( like i do ). So i would really, really, really like to see a feature which allows us to process entities in jobs and multiple threads.
Unity does a great job utilizing multiple cores for their ecs Unitys-JobSystem. And i would love to see a similar build in way in artemis.
There multiple ways of doing this ( after quick Research )
There two states, the past state and the present state. The past is read only and the present is write only. All jobs and multithreaded code operate on the past and write into the state. This is it basically, it prevents racing conditions. Of course some systems still need to run after other ones but thats something we will never prevent fully, so dependencys are still a think. The biggest problem is that components are objects in java... which makes it use a lot of ram. Easier and more efficient in langauges like c, c++ and c#. Requires a artemis rework i guess.
Another way is to implement read & write locks. This way artemis could auto generate a dependency graph to check which systems can run parallel and which do depend on other ones. The problem here is that this requires a artemis rework and new tags.
@All(ComponentType.Read, ComponentType.Write)
@All(ComponentType.Read, ComponentType.Write)
Those two could run parallel.
@All(ComponentType.Read, ComponentType.Write)
@All(ComponentType.Read, ComponentType.Read)
The second system would be forced to wait for the first one to complete its multithreaded jobs.
We simply split up the iterations for each system. Lets say we have 10000 entities to process in one system. It would simply create... lets say 5 jobs. The first one would process entities 0-200, the second one 201-400 and so on. This way we could split up the work for being processed parallel to each other. On the end of the system we would wait for the jobs to complete. Is not really multithreaded, its more like splitting the work for faster processing. Would not require a artemis rework atleast.
Kinda like 3. But we dont split up the iterations this time. Each system may spawn in multiple jobs ( which are processing entities ) and we wait for them to complete before invoking the next system. The difference is that theres no iteration splitting. One job would iterate over ALL transforms for example, the other one over all Rotations and Transforms and depends on the first one. Would also not require a artemis rework... but still not real multithreading.
Thats all the ways i have found to implement multithreading to ecs. And it would be great to see them in here. Would be great if someone would have the time for this.