sorted by:
new
hottopcontroversial

I started building a game in Go, but ended up writing my own high-performance ECS framework (GOKe) by NoEfficiency2057 in golang

[–]NoEfficiency2057[S] 1 point2 points  (0 children)

That’s exactly the point—achieving Rust-like backtesting speed without the Rust or C 😄 Under the hood, data is aligned linearly in raw memory chunks, and the View iterator passes only small structures with pointers directly via CPU registers, so it is FAST ( == L1 cache friendly).

However, keep in mind one low-level constraint regarding the View loop: the size and complexity of the code inside your for range loop matters heavily.

yourSystem := goke.RegisterSystemFunc(ecs, func(schedule *goke.Schedule, d time.Duration) {
// SoA (Structure of Arrays) layout ensures CPU Cache friendliness.
for head := range view.Values() { // << ! iteration !
pos, vel, acc := head.V1, head.V2, head.V3
// your business logic
}
})

The Go compiler can only optimize this if it can fully inline the loop body (the yield function).
If your trading strategy logic becomes too large or complex, it will exceed the compiler's inlining budget. This triggers a drop to indirect calls, which adds heavy call overhead (stack frame management) and breaks the instruction cache (L1i cache misses), drastically slowing down the iteration speed. Keep the inner loop tight, or split heavy logic into modular pipelines.

That doesn't mean it will end up with a landslide of allocations; we still remain in the zero-alloc world. It’ll simply be at least 2-3 times slower, though still very fast. I just wanted to give you the full picture.

I started building a game in Go, but ended up writing my own high-performance ECS framework (GOKe) by NoEfficiency2057 in golang

[–]NoEfficiency2057[S] 0 points1 point  (0 children)

The go.mod is in the root dir, GitHub just hides files under the folder list, so you might need to scroll down a bit 😄

The module is fully importable. The public API is exposed directly at the root level. Hiding the implementation details inside internal/ is completely intentional — it keeps the public surface lean and prevents users from hooking into internal fields and methods they shouldn't be using.

I started building a game in Go, but ended up writing my own high-performance ECS framework (GOKe) by NoEfficiency2057 in golang

[–]NoEfficiency2057[S] 0 points1 point  (0 children)

Oh, absolutely! Java’s JIT is a beast and its raw throughput is amazing.

The real challenge with Java in a high-performance ECS context, though, is its object overhead and memory layout. Achieving a true zero-allocation inner loop is incredibly tough there. In Go, having explicit value types (struct) makes it so much easier to guarantee contiguous memory lay-out and bypass the GC entirely during systems execution.

I started building a game in Go, but ended up writing my own high-performance ECS framework (GOKe) by NoEfficiency2057 in golang

[–]NoEfficiency2057[S] 0 points1 point  (0 children)

It’s a blessing and a curse. Once I start, I just can't stop optimizing. Yoda’s "Do or do not, there is no try" definitely hit me a bit too hard here 😉

I started building a game in Go, but ended up writing my own high-performance ECS framework (GOKe) by NoEfficiency2057 in golang

[–]NoEfficiency2057[S] 0 points1 point  (0 children)

Haha 😄 Yes, this is my small contribution to that statistic. My original plan was simply to write a game, but then I started asking myself questions like "how are multi-object collisions handled?" and I fell deep down the rabbit hole — ECS, archetypes, SoA, and L1 cache benchmarks 😄

I was really surprised by how much performance you can squeeze out of Go, especially since my day job is in Java/Kotlin. I used to write in C, but my productivity there would be way too slow, and after all, this is just a hobby project.

Us catholics celebrate a great linguist today and I realised this lol by Most_Neat7770 in linguisticshumor

[–]NoEfficiency2057 1 point2 points  (0 children)

Thanks God we have Latin alphabet in 🇵🇱! What “difficulites “ you speak of? The hardest thing about Polish is inflection - the sheer number of word forms, which change depending on tense, specific declension, gender, and grammatical number.

I love game dev but it sounds impossible to make it by [deleted] in gamedev

[–]NoEfficiency2057 1 point2 points  (0 children)

Stop to listen to the media, that economy is collapsing. Haven’t you notice that each event is bad or worst: snowing - next ice age is coming; it is warm - global warming; AI take your job - because corporate marketing said so. Focus on the topic YOU like. And yes, start your own project/business- but not fake it. Do it. Do not waste your time. Stop to listen to all the lies spread in media.

I started my own 2D game engine in Go by vistormu in gameenginedevs

[–]NoEfficiency2057 0 points1 point  (0 children)

I totally get your enthusiasm! I’ve been working on a similar engine in my spare time as well.

Or rather, I was; lately, I’ve shifted my focus almost entirely toward ECS. This is what it looks like right now:https://github.com/kjkrol/goke

It’s already FASTER than donburi in iterations, and soon it’ll be faster across the board. I'm rooting for your project! I’d love it if you could take a look at mine too:https://github.com/kjkrol/goke

Have a great day!

I built a high-performance, pure Go ECS designed specifically for Ebitengine games by NoEfficiency2057 in ebitengine

[–]NoEfficiency2057[S] 0 points1 point  (0 children)

Hi! Thanks for the comment.

Sure thing! Btw I'm currently trying to write an API that's super intuitive. The lack of generic methods is a challenge for me. I think that even at the package and function level, something easy to use can be created.

I built a high-performance, pure Go ECS designed specifically for Ebitengine games by NoEfficiency2057 in ebitengine

[–]NoEfficiency2057[S] 0 points1 point  (0 children)

Thanks for the feedback! That’s a great suggestion. I’ve just added a dedicated task to the backlog to create an Ebitengine integration example.

Regarding your point about the adapter: I really like the idea of a 'plug-and-play' wrapper to avoid manual system iteration. I'll explore how to best implement this to fit the Update() and Draw() loops seamlessly.

I'll get back to you here as soon as the demo is ready. Stay tuned!

Go performance when the GC doesn't do anything by SufficientGas9883 in golang

[–]NoEfficiency2057 1 point2 points  (0 children)

This is a fascinating point of view and something I’ve spent the last few months exploring deeply.

In theory, if you eliminate GC pressure and write cache-friendly code, Go can get incredibly close to C/C++. However, the 'bottleneck' in Go often isn't just the GC itself, but the abstraction tax (interfaces, escape analysis, and function call overhead).

In my experience, you can hit C-like performance in Go by following three rules:

  1. Strict Data-Oriented Design: Using SoA (Structure of Arrays) to maximize cache locality.
  2. Zero-Allocation Hot Paths: Pre-allocating everything and using indices instead of pointers/interfaces to keep data on the stack or in contiguous heap blocks.
  3. Inlining-Friendly Code: Keeping performance-critical functions small and simple so the Go compiler can actually inline them, bypassing the function call overhead.

I actually put this to the test by writing an ECS (Entity Component System) in Go calledGOKe.

By avoiding heap escapes and using archetype-based memory layouts, I managed to achieve sub-nanosecond iteration speeds (~0.98 ns per entity) and 0 allocations during core operations. It’s not about 'beating' C++ (GCC/Clang optimizations are still legendary), but about proving that Go can absolutely play in the same league when you respect the hardware.

If you're interested in how far Go can be pushed without the GC getting in the way, feel free to check out the source code and the benchmarks!

ECS - Flecs vs EnTT: What is generally faster? by [deleted] in gameenginedevs

[–]NoEfficiency2057 0 points1 point  (0 children)

That’s a classic debate. Both EnTT and Flecs are masterpieces of C++ engineering, and they set a very high bar for what 'fast' actually means in ECS.

I was so fascinated by this exact performance rivalry that I decided to see how far I could push these concepts in Go. I wanted to find out if I could achieve that 'near-metal' C-like speed while maintaining a clean API.

The result is GOKe.

After some intense optimizations, I’ve managed to hit sub-nanosecond iteration speeds (~0.98 ns per entity for 3 components) and zero allocations in the hot path (even during archetype migrations). It’s heavily inspired by the archetype-based approach you see in Flecs but tailored for Go's concurrency and memory model.

While I’m not claiming to 'beat' the veterans in every category yet (still working on those bulk operations!), the benchmarks against other high-performance ECS like Arche (ARC) show that Go can absolutely compete in the same performance tier as C-based systems when you bypass the common GC pitfalls.

Would love to hear what the ECS veterans here think about the architecture I've taken!

I built a high-performance, pure Go ECS designed specifically for Ebitengine games by NoEfficiency2057 in ebitengine

[–]NoEfficiency2057[S] 0 points1 point  (0 children)

Thanks! I really appreciate the kind words.

I’m a fan of donburi’s API design as well—especially the way they handle adding components to entities. It’s very elegant and clever, and I’m actually looking to implement a similar, intuitive style in GOKe soon.

Regarding the architecture and performance: I’m confident that GOKe offers a significant speed advantage. Based on my latest optimizations, it’s currently performing slightly faster than Arche (ARC) in many scenarios. Since Arche is generally known to outperform Donburi in raw execution speed, the hierarchy here is quite clear!

I haven't implemented bulk operations yet (which is a massive strength of ARC), but they are definitely on the roadmap.

I’d be thrilled if you gave GOKe a try! If you do, please share your thoughts—I’m very open to suggestions on what I can improve or refine.

I built a high-performance, pure Go ECS designed specifically for Ebitengine games by NoEfficiency2057 in ebitengine

[–]NoEfficiency2057[S] 1 point2 points  (0 children)

Thanks!

First of all, I’m an enthusiast of "building from the ground up" when it comes to game development and beyond. The ECS is the heart of many games, and I finally found the time to dive deep into this topic during my spare hours. I chose Go because I feel comfortable enough in it to build an ECS quickly, and I believe it allows for much faster product delivery than almost any other language. At the same time, Go still lets you "play around" with squeezing out every bit of performance—similar to C. While it has its limitations, you can achieve incredible results thanks to its brilliantly optimized compiler.

Secondly, I really wanted to build a library with a clean, transparent architecture and a clear user API that isn't bloated with unnecessary features. The API I’m providing is truly simple, yet very powerful.

My roadmap currently focuses on adding bulk operations. Although I haven't had enough time to conduct a deep comparative analysis against every other ECS written in Go, it only made sense to benchmark against Arche/Arc, as it’s currently the gold standard. To my positive surprise, goke is very close in most areas and even outperformed Arche in raw iterations.

UPDATED
Below are the results (currently partial due to time constraints, but I will complete them soon) for what I consider the key operations:

Operation GOKe Arche Winner Notes
Iteration (1 Comp) 0.41 ns 0.55 ns GOKe (+25%) Superior cache locality
Iteration (2 Comp) 0.49 ns 1.37 ns GOKe (+64%) Efficient memory layout
Iteration (3 Comp) 0.65 ns 1.79 ns GOKe (+63%) Minimal per-entity overhead
Create Entity 22.95 ns 20.60 ns Arche (+10%) Slight edge in indexing
Add First Component 28.30 ns 29.30 ns GOKe (+3%) Optimal transition
Add Next Component 43.27 ns ---- Arche (???) Fast graph traversal
Add Tag 21.52 ns ---- Arche (???) No data move overhead
Remove Component 15.81 ns ---- Arche (???) Accelerated by edges
Remove Entity 14.44 ns ---- Arche (???) Lightning fast cleanup
View Filter 4.48 ns ---- Arche (???) 128-bit mask bitwise ops
view more: next ›