i’m always pushing for performance of golang and found a lot of areas whereby go is slower than c equivalent at 2x and 1.2x etc but wondering what’s the theoretical / practical limit of golang. especially in multi core (448 cpu core) environment etc.
i’ve been using using go for the past 6 years daily and with extreme efficiency consideration only going for zero alloc stuff but i’m wondering how far can i push golang before i need to always look at c / c++ / rust.
in an “unrelated issue”, this is my thoughts on this statement:
“Don’t communicate by sharing memory, share memory by communicating.” (applicable only up to 16 core cpu systems, anything more than that will give you diminishing returns based on how golang does thread scheduling… etc.)
any opinion / comments on the issue title? not trolling but i love golang just that i’m always limited by the efficiency of it. please dont suggest goasm. i do hope for a zero alloc cgo without ffi overhead. not sure if this will be made possible.
C/C++ offer finer-grained control over memory management and hardware interactions, potentially leading to better theoretical performance for very specific tasks. This is because C/C++ allow for direct manipulation of memory addresses, which Go avoids for safety reasons.
I think only you can answer this question for yourself. But it SOUNDS like maybe Rust would be the default for you if performance is really your #1 consideration. I think Go really shines in the space of easy to read/maintain/test web APIs and CLI apps. You can push performance pretty far and there are some large projects like CockroachDB and Caddy that are large in scale and performant but I don’t know if it really makes sense to reach for a tool that you know isn’t 100% ideal for your task at hand.
I didn’t make Go look like anything compared to Java. It’s literally slower in the current implementations of that challenge. And if that was your only takeaway from that article, I would say that bolsters the idea idea that Go is probably not the ideal solution for you.
It’s impressive to hear about your extensive experience with Go and your dedication to performance optimization. Go’s design philosophy makes it a fantastic choice for many projects, but as you’ve noted, there are scenarios where other languages might outshine it. When it comes to scalability on systems with a large number of CPU cores, Go’s concurrency model may hit some limitations. However, with your expertise and focus on efficiency, you’re already ahead of the game. Keep exploring optimization techniques, and don’t hesitate to dive into other languages if they better suit your needs. Your dedication to squeezing the most out of Go is inspiring!