Golang Physics Performance

Hey, great video! What did you use to create your animations?

Yeah you go with clickbait just by calling your channel what it is. Bear in mind there is no such thing as time there is only speed. Time is concept of how much speed of human in relativity of position in space to the rotation of the earth and it's relative position in space has passed. Time is just a thing made up to get context for the brain that is unable to wrap it's mind around this law to make it more accessible :)

cool video!

Generics may run slower, but I don't think it is worth my time to rewrite the same code 49 times.

Why deleting the circle when you can just reset its position.

I just realized the whole video was a marp

Is there a way to integrate Arena, would love to see the benchmark just really hope it comes out of experiment tag

you had to compile it in release mode.

yes preach that shit my nigga. PREACH!

I've seen other comparisons like this, where C code that's been optimized over the last several decades and looks unlike a natural writing of the concept... is compared to rust code that's 10 minuets old. If you give both projects equal time that's one way, but I think equal in-depth knowledge would be a better comparison. I.E. if for Go you have to understand how the inlining system works you need to give rust a similar advantage and go panics/auto-fail if something can't be learned about rust of equal value.

nice video - i really like the ergonomics of developing with ECS and it's nice to see implementations in various languages.

I have some thoughts on your "why is bevy slower" description

a) That's probably the largest point - while you won't get much out of parallel queries (can't parallelize mutable access to the same data), Bevy can parallelize even the for loops inside a system, by using methods such as par_for_each(_mut)

b) 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.

c) The ECS benchmark 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. Sadly, i'm too lazy to run the benchmarks myself.

I’d like peoples to compare tools that are used for the same context, Rust & Go aren’t used to solve similar problems. Id rather see a Zig Vs Rust comparaison that would be very interesting.

I decided to follow because you included the code.

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

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.

If you like using assembly etc there's some optimization guides you might want to look at?
I don't know anything about golang but it'll tell you about how long different instructions take on different arcitecjtures, how many pipelines they have etc...

great video, mate. I sense loads of rusters will start attacking this video shortly 🤣🤣🤣🤣🤣🤣

Damn! This is so cool!!!

I 👍

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

Btw Rust also does bounds checking on arrays/slices

While you build Rome I'll use Unity's ECS and build games. Lol.

I didnt understand one bit just came for a Rust Vs Go Fight saw the graphs and liked the video 👍 Wish I were as knowledgeable as you 😅😅Too Hard for my brain to get these things 🙏 I should have read the word "physics" in the title and stayed away 😆

this is amazing!
thx for making and sharing

Did you run with optimisations enabled? / Rust release mode

Rust is a bunch of Mozilla SJW‘s radical leftist. You can‘t even type „hey guys“ on their forum as it is seen as sexist. Vote with what you use, Rust supports the radical gender-dysmorphia LGBTQ community.

People really like hating on GC'd langs, especially in gamedev but people stil use Unity(C#)/Unreal(Blueprints)/Godot(Gdscript) and they all use GC and/or interpreted langs on top of C/C++.

Anyways good job!

If you used Rust iterators instead of an index based for-loop, would it still generate bond checks?

Can you compare the best one with Julia?

How do you compile?

it's really awesome!

My main takeaway from this video: A naive code in non GC based languages will always outperform naive code in GC based languages.

I code in Rust, and didn't have any idea that Go code can be optimized this way. You have gone to such lengths to reduce GC checks in Go, it's mind blowing. Reminded me of Just-JS web framework.

I want to know your take on reducing GC overhead in highly concurrent Go applications. By GC overhead I mean the periodic cleanup of useless items taking up resources, as Rust has no GC to clean up.

Have you implemented spatial access (i.e. only iterating through objects that are within a certain distance from yourself)? If you have, I wonder if that explains the performance difference between the Rust and Go code once you added back in the finite health bounds, as I'm sure you didn't consider it in the rust implementation. Then again, it seems the Go and Rust implementations follow the same curve, just scaled differently, so perhaps you didn't consider it in the Go implementation either. In Rust, one option to do this is with the bevy_spatial plugin for Bevy, which allows you to perform spatial queries for performance (otherwise operations will be O(n^2). This might be an interesting and rewarding API implementation to pursue in your own engine. Also, I feel I should point out (tangentially to Errata No. 1) that in Rust, type aliases are considered to refer to the same type, so they will share monomorphizations in a similar way to how you described stenciling. Also, we do have dynamic dispatch in Rust by way of so-called "trait objects" using the dyn keyword.

Hey guys, isn’t it possible to use some kdtree instead of the second loop? It of course has nothing to do with rust vs go comparison, but a quick check for collisions looks like a problem solvable by a bettr data structure.

gcc vs llvm

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

Performance? C++

Rust with Go runtime (green threads + GC) would be my dream general purpose language.

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.

I've been meaning to try my hand at learning Go, because I think it could complement Rust pretty well and this video may just be the motivation I needed to get over that hill lol

cool video. New to the channel. How long have you been coding and how long have you been doing game dev?

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.

You should use goto instead of inlining. It is why FORTRAN is so good for a huge computation - GOTO.

Sorry for the impolite comments from some Rustaceans here. Great experiment! But as you mentioned, definitely curious about workloads with more disparate alloc. Hmm but in that case, maybe the allocator becomes a factor too, and in Rust you can change it from system default to jemalloc or mimalloc, so more variables to consider. It’s really hard to isolate only the ECS code to compare.
More than performance though I’m curious how much you feel the Rust style of using types helps you avoid errors or annoys you from progression. The more interesting trade off between Go and Rust is I think of Go, less static analysis for fast compile and more attention to debugging, versus of Rust, more static analysis (and annotation and API restrictions) for less debugging and slower compile.

Rust is for transvestites

No matter you will do, Rusties will glorify their language like they are in a cult. The marketing was for sure done correctly by big corporations for political reasons, not engineering ones. It's kinda sad to read in the comments to see how people discovering our tech industry are thinking.

Meanwhile Go and Zig are trying to take their time, as we should do in an engineering world.
If you want to have fun, you could have a native layer with Zig then bind your game logic in Go.
You will have remarkable results by using a bind of FLECS in Zig.
Go is not meant for video games due slower native calls.
Zig and Go works well together though.

Take your time to create useful, meaningful and timeless solutions.

Rust also does bounds checking. You can use the non-bounds checking api directly. But if you indexed directly into arrays in Rust, you are using bounds checks everywhere.

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.

Sure memory safety is great, but even std C++ iterators can have poor performance, depending on how you use it. Thanks to Rust's borrow checker, it can optimize iterators by not needing to do boundary checks, since it knows the size a head of time.

Using abstractions in Rust are often faster than explicit code. Of course it's not a silver bullet (e.g. there's no way to bailout early in an iterator closure).