Hello, first of all, i want to clear out that i am not qualified to make comments on the subject. I am learning developer who is very inexperienced in game development and coding.
However i like to follow stuff happening related to Unity frequently mostly because i am enjoying to see things improve even if they do not affect my life immediately. An hour ago i was searching Youtube for latest Unity related videos, then i coincided into this video that attract my attention.
. This guy on the video compares DOTS performance vs hand-written code of his own on one of the DOTS sample projects.
I do not know what is to be expected or how much the results he demonstrate represents the reality. But we are talking about really huge performance difference. I would love to hear more experienced developers opinions about this including Unity dev teams.
Its not that i would try to do thing on my own if this performance comparison is realistic, first i just can’t and secondly i don’t want to put any extra effort anyway. But i want to know the limits and reality of performance deficiency using Unity over anything more optimal.
Suggest reading the DOTS forum posts because your question is answered there fully. Feel free to disclose your native language so people who have good experience in both languages can help you better.
Hi thank you for the reply. I looked a bit couldnt find the answer though. If we are talking about the language i have most experience with then it is C. Between C++ and C# i guess i like C# better.
The project in question is not so much an official Unity sample as much as it is a sample written by one guy in the Unity Evangelists team who is learning DOTS himself. Many of the algorithms are suboptimal but were easy to implement and he even made a comment about this himself.
The video creator has provided nothing regarding what algorithms or multithreading solutions he used. I suspect he is using superior algorithms and a serial-wide threading model which is what Unity’s ECS simple dependency mode does.
I suspect the hybrid renderer is the bottleneck in the Unity project. There are known performance issues when rendering large amounts of moving objects. It’s about 10x slower than what it should be which correlates well with the video. The good news is that this is still in preview and will be fixed, but also that Unity DOTS is modular enough that if you don’t like something, you can write your own replacement with as much effort as it would take to implement such a feature in a scratch C++ project.
Thank you, i was hoping to hear either that sample code wasnt optimized or at least hoping it was about an issue going to be fixed.
Definetely wouldnt want to hear that it was limit of the architecture because eventhough i am not invested in dots yet.
I plan to migrate coding in it when learning materials become more mainstream and stability is considered satisfactory by general consensus .Even if it would not reached its potential yet.
Nice! That link wasn’t there when I checked earlier.
It’s pretty much what I suspected. He’s using a better broadphase collision detection system, but a more expensive and more accurate narrow phase. Threading is similar too. He runs collision single-threaded but most transform-related things in parallel just like the Unity project. So collision and rendering appear to be the main differentiating factors.
As @DreamingImLatios said, collision, rendering and additonally, the ECS end simulation (TRSToLocalToWorld) are the bottlenecks.
I’m pretty sure those issues can be solved. Joachim already mentioned rendering improvements but I think those were for non-moving entities, so fingers crossed.
Anyone got burst to run in this with newest packages?
On that note, it would be great if those samples would be kept updated!
It’s throwing:
InvalidOperationException: Burst failed to compile the given delegate: Void InstantiateEntitiesExecute(Unity.Entities.EntityComponentStore*, Unity.Entities.Entity*, Unity.Entities.Entity*, Int32)
attribute: Unity.Burst.BurstCompileAttribute
from this line in EntityManagerChangeArchetype : InstantiateEntities = BurstCompiler.CompileFunctionPointer<InstantiateEntitiesDelegate>(InstantiateEntitiesExecute).Invoke;
2 things I saw:
They biggest improvement is to simply turn off shadows. Soft shadows for all the particles is quite heavy.
The TimedDestroySystem seems to be a bottleneck for the EndSimulationEntityCommandBufferSystem.
I’ve uploaded the project here: www.enzenebner.com/files/angrydots.rar
Not sure what’s going on. I never had such errors before and I just wanted to test the sample a little.
edit: Deleting the library folder and a full reimport has fixed the issue.
This behaviour is quite annoying TBH. Whatever is left when updating should be cleaned up.
The good thing is I get very acceptable frame timings (8ms in editor) even with a spread amount of like 50+.
So, updating will be worth it.
I think apart from the rendering, the problem is that ECS is not optimized for creating and destroying 100k entities within a fraction of a second. There’s a lot of overhead going on with EntityManager and chunk creation when doing structural changes and doing so is singlethreaded by design to make race conditions impossible. In a real usecase scenario you would probably try to keep/pool the entities and then hit a switch to reset them by iterating over them. This is where ECS really shines.
