[5701652400]

probably you do not need to do any of that.

better at Go to ship apps — none of that needed. actually opposite. the less complexity and low level details you hardcode yourself, the better. chances are, this low-level tech debt will bite you back when you have no time to deal with it. keep it simple.

better at Go to work with internals of Go/compilers/runtime — yes, but do you plan to ship one? or why it is needed at all? or do you work at Go core at Google?

[lou1306]

Better at Go for automated reasoning tools, this means quite a lot of array lookups within tight loops. I asked because I noticed some AI agents quickly want to jump on the "eliminate all bounds checks" wagon as soon as the low-hanging optimization fruits have been picked, and it takes some hard data to put some sense into them. My question really was: is this kind of preliminary profiling enough, are there other pitfalls of arrays/slices in Go I am missing, etc.

> probably you do not need to do any of that.

Indeed, I find that at least in my case, on a pretty average Intel machine these checks add very little overhead, especially compared to the benefits. I do not really understand how the examples in the blog post can get 100% (1st one) or even 10% (2nd one) faster.

(And yeah, I know that the obvious solution is to develop these tools in C/C++: I am just exploring the capabilities of Go in that space).

[ahk-dev]

My guess is the 100% case is one of those situations where the benchmark is almost entirely measuring the tiny function itself. If half the instructions are bounds checks and branches, removing them can easily double throughput in a microbenchmark. I'd be curious what happens once that function is part of a larger pipeline where memory access or other work dominates.