Unity DOTS vs Bevy - A Performance Comparison

No video

Unity DOTS vs Bevy - A Performance Comparison

Рет қаралды 19,627

Sandeep Nambiar

Күн бұрын

Пікірлер: 41

@user-iw1gy7ev6e 8 ай бұрын

Sorry, but if you are doing such a thing, do it correctly. There are a few issues here: - you used a renderer, which makes little sense for this comparison - your Unity implementation has serious memory leaks - your Unity project was set to use Mono instead of IL2CPP - you didn't disable vsync I downloaded the repo and fixed the issues myself. I removed the renderer from both entirely, fixed the memory leaks in Unity, set it to build with IL2CPP instead of Mono and disabled vsync. On dual E5-2690v2 (DDR3) with 500.000 units: - Unity 105 FPS, 30% CPU usage, 460mb RAM - Bevy 49 FPS, 34% CPU usage, 1496mb RAM On i9-14900k (DDR5) with 1.000.000 units: - Unity 152 FPS, 87% CPU usage, 803mb RAM - Bevy 69 FPS, 60% CPU usage, 2914mb RAM

@_sandeepnambiar 8 ай бұрын

oh this is great! thanks for the feedback! I'll incorporate them and try this again. and maybe drop a line to the bevy discord as well about this. would you mind opening a pr for these changes so that I can run this too! I'm especially curious about the memory leaks!

@DerrickTheFork 8 ай бұрын

I'm curious: did you make any optimizations to the Unity version besides turning off cameras, IL2CPP, vsync and fixing memory leaks? I did a refactor of the Unity version as well because I was seeing a bunch of issues with it, but at the end of the day, despite seeing improvements on the Unity side, Bevy was still performing better. There are optimizations that could've been done to the unity version, like using custom transform parenting, removing all mesh renderer components (reducing archetype sizes), getting rid of structural changes 100%, or just changing the way logic is done, but I avoided that because then I would've had to do the same in Bevy for fairness. I'm mostly interested in knowing if that's what you did

@laundmo 8 ай бұрын

i'm pretty sure if anyone truly cared they could speed up the bevy side again, by quite a lot. 3gb RAM sounds a lot like theres quite a few components on the entities which might not need to be there, for example. after all, benchmarking perf optimisations is a game you can play ad infinitum. all this tells me is that both are super fast enough, and to consider other factors because ECS performance clearly is not a issue.

@_sandeepnambiar 8 ай бұрын

@@laundmo yep thank you for re-iterating the my main findings. ecs performance might be irrelevant to the choices here.

@josephdelgado7644 6 ай бұрын

can you post the source for the modified versions?

@doce3609 8 ай бұрын

Love the Acerola black screen reference

@WitherBossEntity 8 ай бұрын

Nice testing. Your repo is also useful for comparing these two ECS implementations ergonomics-wise.

@_sandeepnambiar 8 ай бұрын

I agree! I'm planning to do exactly that in the next video. Compare the ergonomics of bevy vs unity dots.

@alinmgheorghe 5 ай бұрын

I think an official marriage between Unity and Rust would make the most difference and blow out of the park the other competitors.

@Caellyan 4 ай бұрын

Rust has bevy, and Unity has its weird licensing. Not really something that would benefit game quality long term.

@piot 8 ай бұрын

Again, thanks for your hard work! I really hope that people see this and switch to Rust

@_sandeepnambiar 8 ай бұрын

Thank you for your kind words Peter! This means a lot and is very encouraging for me.

@lets.build.cool.things 8 ай бұрын

Could you share a profiling capture comparison from both engines please? Pretty absurd to compare one engine with unlocked fps and actual frame timings against a vsynced one always showing 16 ms update time. Thank you 🙏🏼

@_sandeepnambiar 8 ай бұрын

Yes that makes sense. :) I'll add that to the description over the weekend. You can also run the projects btw, there is a link the description. I agree I kind of messed up with the vsync. But it really doesn't matter imo. Going below 16ms was the test I was going for. Thank you for your feedback though. I'll add more details for future videos. :pray:

@BossGxngOfficial 7 ай бұрын

This is awesome 😲

@OskarNendes 5 ай бұрын

Now do a Rust + modern opengl versus Unity.

@Rogue_78 8 ай бұрын

TLDR: Bevy is better

@_sandeepnambiar 8 ай бұрын

Yes and no. In my opinion, performance should not be a metric (yet) to switch.

@Boxing_Gamer 4 ай бұрын

@@_sandeepnambiarit should be because at one point you'll need that performance..and c sharp just can't deliver.

@odo432 Ай бұрын

@@Boxing_Gamer C# can get fairly close to C++ performance. Especially with Span and SIMD operations.

@Victor_Js 3 күн бұрын

Unity3d very bad, no NET8. C# NET 8 + Native Memory + Parallel ForEach = Rust performance. There are a lot of game engines that support NET 8, specifically 4. All with the performance of Bevy because they support NET 8 without garbage collection GC. I also did tests and I speak with authority. Unity3d 3D is outdated, it will take years to have modern NET

@v037_ 8 ай бұрын

These perfomances are important for slow devices, your computer runs too fast, try that profiling on a cheap ass old laptop with an intel core duo

@_sandeepnambiar 8 ай бұрын

Hmm that's a good idea. I could probably run these on a virtual machine on the cloud and get metrics from them.

@mehowop 8 ай бұрын

@@_sandeepnambiar You can make custom power plan with maximum state of cpu set to 1% ( so your cpu clock will stay at possible lowest clock, on my i5-4690 its 800mhz ). You can also use some cpu benchmark ( cpu-z have nice stress test ) and than by changeing state % you can create bunch of profiles with different maximum cpu clock.

@Don-zo3ts 8 ай бұрын

Nambiar ? Malayali anooo😅

@_sandeepnambiar 8 ай бұрын

yes sir! :)

@Don-zo3ts 8 ай бұрын

@@_sandeepnambiar 🤩👋

@u9vata 8 ай бұрын

I am honestly not impressed. Know handcrafted C++ stuff that can go 10x to 100x faster than dots so kind of expected bevy to be at least half of that but it looks like rust seem so fast mostly to javascript people not c++ hiperf people..... Also Godot without ecs-ing does often close to dots which also shows how not optimal it is. But of course its often more than enough honestly anyways.

@_sandeepnambiar 8 ай бұрын

yep i was surprised as well. i maybe expected more. but its early days for bevy. i'm sure it gets faster in the future. I'm also sure that a handcrafted rust game would go extremely fast as well.

@laundmo 8 ай бұрын

@@_sandeepnambiarbevy has so far not focused too much on raw ECS speed. more on general performance for common game systems like transform hierachies and animations on the CPU side. the main dev of Flecs, a very performant C++ ECS, hangs around the bevy discord regularily and also did performance benchmarks, none of which show a 10x difference.

@Tarodev 8 ай бұрын

Could you please share the source that demonstrates Godot achieving performance comparable to an ECS? I find this doubtful.

@u9vata 8 ай бұрын

@@Tarodev IT was here on YT somewhere. And yes it was on-par (but lower performance). Godot was somewhere between Unity perf and ECS perf in tests of "when moving around x objects starts to lag". Seriously closer to ecs than to unity default... Ecs is really not that hugely powerful - only when compared to the unity default which is really bad architecture. You can go watch non-ecs C++ codes easily beating ECS in same scenario so this is not a miracle - neither this makes ECS bad or anything... it was a step in good direction...

@odo432 5 ай бұрын

@@Tarodev The only way to achieve this is with C++ and utilising Godot's low-level API (eg Rendering Server). I did use Arch ECS + MultiMesh in Godot and achieved slightly better performance than Unity Entities + DrawMeshInstanced (similar to what you did in your performance comparison video). I in fact reverse engineered Unity's Systems to work with Godot and Arch (which was surprisingly easy as Arch was inspired by Unity ECS). Rendering 100k cubes at 80+fps. Obviously when utilising Unity DOTS or DrawMeshInstancedIndirect Unity completely trumps Godot. But I thought it was still impressive nonetheless. Absolutely no chance you could achieve this using the default OOP.