Any benchmarks on DOTS performance ideally from a Unity project converted to DOTS?

Wondering how performant DOTS is turning out to be. So, any benchmarks on DOTS performance ideally from a Unity project converted to DOTS?

 

Conversions aren't possible, only complete re-writes from the ground up. You know that. There is no converting.

But in the spirit of the question, compare:

https://assetstore.unity.com/packages/tools/physics/kinematic-character-controller-99131

with

https://assetstore.unity.com/packages/tools/physics/rival-dots-character-controller-195567

Both by the same author with largely the same content, but one of them is DOTS. The performance is so much better it's not actually comparable.

 

Do something in dots, and compare results with burst and threading enabled and disabled.

That's gives great sense of comparison.
Is not perfect but close enough.

 

Wasn't there some Unity benchmarks comparing the speed of DOTS or ECS when it first came out?

 

I remember there is benchmark somewhere, for specific data types. I.e vectors, floats, matrixes, etc. with classic and DOTS approach.
Also, as I mentioned, trying running DOTS samples without threading and burst, will shows you huge difference in performance.

You know, that certain methods can not be bursted, or multithreaded using DOTS. Hence is tough to compare such methods. Most likely, need rewrite that method completely, or whole utility, to accommodate DOTS.
Not simple task, but I already explained you that, in other thread.

 

I've got some actual stats on this!



In this case, DOTS performance is somewhere between 10x-25x superior. Not only is single-thread performance much better due to Burst and DoD, but it also scales with cpu thread count whereas monobehaviour stuff doesn't. And this isn't just a bunch of rotating cubes; it's character controllers doing physics queries and random data access all over the place (getting multiple components on ground entities every frame, etc....)

 

Excellent results, quite mind boggling. I have KCC so I probably should get Rival at some point when I get into DOTS!

 

That's pretty cool! How is submitting assets using DOTS like? Do they require to add some kind of "Not production ready" label due to the usage of DOTS? Because if not, this gives me more confidence on the future of DOTS. They can't just stop development when there are potentially lots of devs using DOTS assets, can they?

 

They don't do anything special for dots assets, but I kinda wish they did. I'm sure there's a lot of people who don't exactly know what dots entails, and will buy dots assets accidentally. That's money wasted for them, and risks of bad reviews for the publisher

 

Yeah, sounds about right.

 

I know at least one asset which is DOTS based, and is sold on asset store.
Sadly, it Bareły mentions DOTS at the end of description, as main core of the asset. It can be indeed misleading and confusing for any buyers.

If buyer don't know how to use, or tap into DOTS asset, that would be painful.

 

I used to, but now I'm so far behind DOTS and how to use it I feel lost again. And only a few months passed. Unfortunately no matter how much I want to switch it seems like a terrible business plan right now for me to do so. I wanted to buy Rival but I know it'll only sit on my hard drive for months while I wait for DOTS to stop changing.

At this point DOTS has a lot of situations where you can write bad DOTS code and not know it, so that affects my decision and also affects benchmarking.

 

I hope you don't mind, but I have to point out the irony of this comment on the backdrop of the complete lack of updates lately .
I do get your point overall though haha.

 

If you knew how to use dots a year ago, almost two, from a user api standpoint, don't worry as its largely the same as it is now.

You shouldn't feel like you're missing out at all though because you aren't. All the same things that it lacked before(lack of surrounding ecosystem, lackadaisical editor experience, little documentation, no communication of a roadmap) are all the same.

¯\_(ツ)_/¯

 

Oh your DOTS controller is out! I didn't realize. Time to get in with the 50% reduction.

 

I have a targeting system plugin, which supports both game objects and entities. Initially I build it on gamebjects and did an entity version of the same system. Basically a conversion.

My performance tests show that rough version of the game object based workflow allowed me to process about 14k gameobject targets at high framerates. With entities it was over 400k.

If a project can be converted, is completely up to how the project is build. If you have build the project using data oriented design to get some speed on the oop project, it might be possible to convert. Also some stuff can be converted more easily, some some others require complete rewrite

 

Cool so that a 28.5714 times boost in performance.

Some quick questions is the original version:

• Multithreaded?
• How many threads/cores does the test hardware have?
  
• Use Jobs?
• Batch based e.g. use structs or data in collections with a core manager object looping over them?
• Use Burst?
• Optimised in any other way?

As I have a theory at the moment that you could add Batching, Burst, Multitheading and optimisations easier than translating to DOTS and potentially get a very good boost in performance although not quit full DOTS.

The question is how much of a boost can we get and given the time and effort when is it worth DOTSifying part of our games?

 

You can get pretty far using Burst + Jobs system. The only differences really is that DOTS have a nice memory layout, maximizing CPU cache usage, and easier dependency management out of the box. However you can do a lot of that yourself although it's easy to get messy since depending on your use case you might have to use SoA layout instead of AoS, which can be a pain in OOP. I mean, after all the DOTS packages are written in C#.

https://en.wikipedia.org/wiki/AoS_and_SoA