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
@_sandeepnambiar8 ай бұрын
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!
@DerrickTheFork8 ай бұрын
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
@laundmo8 ай бұрын
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.
@_sandeepnambiar8 ай бұрын
@@laundmo yep thank you for re-iterating the my main findings. ecs performance might be irrelevant to the choices here.
@josephdelgado76446 ай бұрын
can you post the source for the modified versions?
@doce36098 ай бұрын
Love the Acerola black screen reference
@WitherBossEntity8 ай бұрын
Nice testing. Your repo is also useful for comparing these two ECS implementations ergonomics-wise.
@_sandeepnambiar8 ай бұрын
I agree! I'm planning to do exactly that in the next video. Compare the ergonomics of bevy vs unity dots.
@alinmgheorghe5 ай бұрын
I think an official marriage between Unity and Rust would make the most difference and blow out of the park the other competitors.
@Caellyan4 ай бұрын
Rust has bevy, and Unity has its weird licensing. Not really something that would benefit game quality long term.
@piot8 ай бұрын
Again, thanks for your hard work! I really hope that people see this and switch to Rust
@_sandeepnambiar8 ай бұрын
Thank you for your kind words Peter! This means a lot and is very encouraging for me.
@lets.build.cool.things8 ай бұрын
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 🙏🏼
@_sandeepnambiar8 ай бұрын
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:
@BossGxngOfficial7 ай бұрын
This is awesome 😲
@OskarNendes5 ай бұрын
Now do a Rust + modern opengl versus Unity.
@Rogue_788 ай бұрын
TLDR: Bevy is better
@_sandeepnambiar8 ай бұрын
Yes and no. In my opinion, performance should not be a metric (yet) to switch.
@Boxing_Gamer4 ай бұрын
@@_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_Js3 күн бұрын
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
@_sandeepnambiar8 ай бұрын
Hmm that's a good idea. I could probably run these on a virtual machine on the cloud and get metrics from them.
@mehowop8 ай бұрын
@@_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-zo3ts8 ай бұрын
Nambiar ? Malayali anooo😅
@_sandeepnambiar8 ай бұрын
yes sir! :)
@Don-zo3ts8 ай бұрын
@@_sandeepnambiar 🤩👋
@u9vata8 ай бұрын
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.
@_sandeepnambiar8 ай бұрын
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.
@laundmo8 ай бұрын
@@_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.
@Tarodev8 ай бұрын
Could you please share the source that demonstrates Godot achieving performance comparable to an ECS? I find this doubtful.
@u9vata8 ай бұрын
@@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...
@odo4325 ай бұрын
@@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.