Golang Physics Performance

In this video I spent some time benchmarking my ECS (Entity Component System) framework against the popular Rust ECS, Bevy. We had to do some performance analysis and optimize a few things, but all things considered, we ended up doing pretty well. Specifically, we optimized by doing bounds check elimination (BCE), inlining, and using the recently released Go generics
// Socials
⁍ Twitter: bit.ly/UnitOfTimeOnTwitter
⁍ Discord: / discord
// Code
⁍ Go Code: github.com/unitoftime/ecs/blo...
⁍ Rust Code: github.com/unitoftime/experim...
// Good Article
⁍ PlanetScale: planetscale.com/blog/generics...
// Errata
1. Calling Monomorphization "The other end of the spectrum" from GC shape stenciling is a bit overblown. Go stencils (ie monomorphizes) its generics based on the GC shape, so there still is some monomorphization happening which can give you nice performance gains for things with different GC shapes. The actual "Other end of the spectrum" is probably something like doing a full dictionary-based boxing and doing no stenciling at all.
2. Why does Bevy Run Slower than Go?
I apologize for not covering this in the video. I think number 1 and 2 are probably the biggest contributors to Bevy running slow.
a. Bevy has A LOT more features than my ECS, each of those features might contribute to a global optimization for most cases, but in my benchmark contribute to a slowdown. I expect that most people aren't disabling multithreading and the system scheduler and manually executing every game loop.
b. Bevy has a few different layers at which you can use the ECS, I'm not a bevy expert, so I may have written the code in an abnormal way where bevy ran slower than it usually would have. Very specifically, Bevy seemed to slow down the more I started adding and deleting components, I'm not sure the limitation there, but I thought it was notable.
c. Bevy isn't the fastest Rust ECS framework according to this: github.com/rust-gamedev/ecs_b... - I learned this actually kind of recently after all my code was written for bevy
d. Pointed out by laundmo in the comments:
1. "by default, bevy uses what it calls "Table" storage for components - this is fast to iterate but slow to update. In use cases where you might want to add/remove components a lot, you can switch to SparseSet storage on a per-component basis." - I didn't know this, but it does align with what I saw where Bevy slowed down once I started deleting entities every frame.
2. "The ECS benchmark [in errata C] you mentioned is outdated by 2 years, and was also recently archived to represent this. Bevy has had multiple optimizations since then. I see you using bevy_ecs 0.7 - in 0.9 there were some decent performance improvements which would be interesting to see."

[@tsalVlog]

I gave up on Go to switch to Rust -- primarily because they were taking way too long to release generics. Rust has a very rapid, but stable, release cycle, and Go will get left in the dust. Which is unfortunate, I believe it's one of the best languages we have for programming, but the speed at which limitations are removed is hurting the adoption.

[@LongestYardstick]

To be fair, Cart, the guy who started Bevy, is pretty freaking brilliant.

[@32zim32]

Performance is nearly identical, but go is definitely easier and fun to write code than rust. Go wins

[@sohn7767]

Amazing that you got a GC language running this fast

[@jongxina3595]

Good video. Makes me sad so many Rust programmers cant see past "ohh Go has GC so it must be slower than Rust". Specially on something like this where garbage collection isnt particulary common.

[@markhaus]

Near native performance iterators would be so damn nice in go but I can kind of understand why they’re resistant to adding them. Their whole mantra is simplicity and sometimes performance gets sacrificed to it. And for most things people use go for it’s actually a pretty nice trade off

[@nikoladd]

Rust basically implies most of what you were optimizing manually in Go. Borrow checker and exhaustive compile time checks allow for that as a default.

[@ruslankhisamov9891]

thanks for helpful comparsion

[@midda7]

it's really awesome!

[@jeffreylean]

Not a game programmer myself, but I do write go in my day to day work. Learnt alot from this video about go code optimization. Do you have a compiled resource on where I can learn more on this topic?

[@dealloc]

Rust iterators and its other zero-cost abstractions are what makes it so good in my opinion. Being able to write more readable code, and less of it, and get more optimized code than I could've written explicitly myself is just a win-win.

[@valera2010_cool]

For a 5 minutes video it packs a whopping amount of great insights. Thanks a lot

[@RayBarrera]

Excellent work! Working on a VERY similar problem at the moment and watching your process has been helpful, if for nothing else, to validate some decisions I've made along the way.

[@toukaK]

this is amazing!

[@luiscarlosjayk]

Nice research, thanks for sharing!

[@askii2004]

This is awesome content! It's pretty cool seeing how well Go did, and I really was expecting to see a bigger difference between the two. I guess in the case of this particular simulation it makes sense that GC wouldn't be too big of an issue.

[@Matt-ln6mx]

Great video, super informative!

[@0runny]

An excellent video showing how Golang can be fast if memory is correctly managed. It would be really interesting to get an update using the latest versions of Golang, specifically using (PGO) Profile Guided Optimisation.

[@shichiha6138]

damn your mic got so much better since I've seen your "building the slowest ECS framework" video

[@Dorumin]

4:00