HN Explorer

11 comments

[ 0.26 ms ] story [ 13.6 ms ] thread
5701652400
does profile guided optimisation reduce these checks?
lou1306
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?
archargelod
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 <littleEndian_u0__session95202695079520951784538200>:
        bf80:       8b 07                   mov    (%rdi),%eax
        bf82:       c3                      ret
naruhodo
I like reading articles like this, but as per usual, I also find these articles frustrating to read because they don't specify calling conventions[0] (which are many and varied) - particularly the allocation of arguments to registers and the stack frame.

Articles about GoLang assembly language[1] are particularly vexing because the instruction parameters are bass-ackwards - source, destination - like AT&T syntax, but register references are missing their % sigil and so appear to be MASM-style[2].

Authors blogging from deep inside some technical tent should take pity on readers who are not so deeply in the tent and offer a brief primer on assumed knowledge.

Any mistakes in the above should be viewed as confirmation of my confusion.

[0] https://en.wikipedia.org/wiki/X86_calling_conventions

[1] https://go.dev/doc/asm#x86

[2]https://en.wikipedia.org/wiki/X86_assembly_language

abnercoimbre
Yeah that’s the infamous curse of knowledge.. it’s quite hard to imagine oneself as a beginner again (although the skill can be learned.)
ianeff
This was great, thank you!
pjmlp
> As I already complained I wish Go had the nobounds compiler hint but it doesn't, so the only viable option we are left with is using unsafe pointer arithmetic.

Because what the IT infrastructure needs is more CVEs.

ncruces
The article should note this: it's important that you don't go adding other/all little endian platforms to that go:build line.

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.

molecularman
Thank you. I've added your comment to the essay.
espetro
Nice article Andrii. I see from previous articles <https://blog.andr2i.com/posts/2026-06-22-optimization-catalo...> that you can identify and validate bottlenecks which you can optimize.

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'.

molecularman
Thanks! Good question, I don't think such a tool exists. Such a tool would require a mathematical proof of an invariant that all the accesses are in bounds. The closest thing is the compiler's own bounds-check elimination proof engine. It eliminates the check when it can prove the checks aren't necessary and sometimes you can help it with hints like `_ = b[i+3]`. But then you don't need unsafe at all, which is the point: unsafe is the last resort.