I think all the points that the author complains about are valid. I believe some libraries like Arrow chose a completely different approach to supporting Go altogether: https://github.com/apache/arrow-go#performance . They effectively compile C code to Go assembly and thus avoid paying the cost of cgo, and get the benefits of having a lot more control over performance and data structures layout that C gives. I am obviously not suggesting that the author should do the same, but it's just a confirmation that achieving the last 50% of the performance is indeed sometimes an impossibly hard task in Go
I think all the points that the author complains about are valid. I believe some libraries like Arrow chose a completely different approach to supporting Go altogether: https://github.com/apache/arrow-go#performance . They effectively compile C code to Go assembly and thus avoid paying the cost of cgo, and get the benefits of having a lot more control over performance and data structures layout that C gives. I am obviously not suggesting that the author should do the same, but it's just a confirmation that achieving the last 50% of the performance is indeed sometimes an impossibly hard task in Go
Nice! Now the question is: How many classic Reynolds boids can you run on 1 CPU at 60FPS, without using any go routines?
I managed to get around 8192 using Serge Skoredin's approach from the blog post last year: https://skoredin.pro/blog/golang/cpu-cache-friendly-go
Also tried some of the techniques in this blog post, and managed to squeeze a bit more with the insights from your post.