11–20 of 23 posts
Earlier quoted context omitted.
Insofar as PGO helps inlining.
I have hunch PGO does detect when bound check can be eliminated.
Because what the IT infrastructure needs is more CVEs.
Question from someone trying to get better at Go: _before_ going all in with unsafe pointer operations, would it make sense to write a function harness & profile it with/without the -B flag to determine the actual impact of bounds check?
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…
> 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).
The article is correct, but this code is only valid for platforms that allow unaligned access.
You can get the full list of platforms that Go considers safe for this from unalignedOK here: https://go.dev/src/cmd/compile/internal/ssa/config.go
You want the intersection of unalignedOK with little endian.
Earlier quoted context omitted.
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…
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 pit…
Question from someone trying to get better at Go: _before_ going all in with unsafe pointer operations, would it make sense to write a function harness & profile it with/without the -B flag to determine the actual impact of bounds check?
Like, I have a hardcoded 1024-byte buffer, my loop is hardcoded so its index increases modulo 1024, it can never run off the end any more than you can overtake your own bike chain?
Is there any way in Go to selectively turn off bounds checking for a block, function or module? E.g. in Nim I can just do: proc littleEndian(b: openarray[byte]): uint32 = {.push boundChecks: off.} return uint32(b[0]) or (uint32(b[1]) shl 8) or (uint32(b[2]) shl 16) or (uint32(b[3]) shl 24) {.pop.} And GCC is smart enough to reduce it to a single operation: 000000000000bf80 : bf80: 8b 07 mov (%rdi),%eax bf82: c3 ret
For more general Go practitioners like me, is there any harness/tooling I can bring into my projects to identify these bottlenecks (aside from profiling if any). More specifically, tooling that identifies workflows that actually have greater changes to be fine with 'unsafe'.