Live data from Hacker News

How much do amd64 microarchitecture levels help in Go?

lemire.me

11–20 of 50 posts

Re: How much do amd64 microarchitecture levels help in Go?

#11
post #5

Earlier quoted context omitted.

I've long been surprised there isn't more multiversion stuff built right into every language compiler; I would have thought Intel would be very motivated to get more binaries lighting up the features they add to their expensive top line CPUs. But yeah no, on the whole cost of the checks and duplicated binary size aren't seen as worth it, so instead it's piecemeal implementations mostly in numeric packages like eigen…

> so instead it's piecemeal implementations mostly in numeric packages like eigen and lapack. Because that’s where the user-noticeable gains can be made. Using popcount in code you run once is going to shave off, maybe, 100 cycles. That isn’t worth the extra cycles of that approach. Also, FTA: “and arguably the whole scheme should be replaced by finer-grained feature detection” . Such feature detection would lead to…

Based on the now-deprecated Clear Linux it does seem that these optimizations add up [0] and so maybe we should be considering them more broadly?

[0] https://www.phoronix.com/review/clear-linux-48p-ubuntu/6

Re: How much do amd64 microarchitecture levels help in Go?

#12
I'm surprised that Go doesn't default to AVX2 support by now, considering that Haswell started shipping in mid 2013.

Speaking of Dr Lemire's suggestion of a V5 architecture level, would that make any sense given the fragmentation of AVX512? None on Intel consumer devices, but it is on the last few generations of AMD.

Re: How much do amd64 microarchitecture levels help in Go?

#13
arguably the whole scheme should be replaced by finer-grained feature detection.

This seems like a strange thing to say. Fine grained feature detection was around long before "microarchitecture levels" and never went away. The microarchitecture levels were introduced because they were easier to use.

Re: How much do amd64 microarchitecture levels help in Go?

#14
post #9

Nothing, because this is a compiler question, not a language one.

One of Go's selling points is performance. Another is easy deployment on a lot of platforms. This post is interesting from that perspective.

Edit: to address your literal remark: so even the title is correct, if you think of a programming language as more than its syntax.

Re: How much do amd64 microarchitecture levels help in Go?

#15

This is one of the clearest example of diminishing returns I've ever seen. It comes up everywhere. I wonder if this is a natural law, or emergent behavior of complex systems?

The last level is simply unused at this time.

https://go.dev/wiki/MinimumRequirements#:~:text=The%20Go%20t...

Re: How much do amd64 microarchitecture levels help in Go?

#16
post #5

Earlier quoted context omitted.

I've long been surprised there isn't more multiversion stuff built right into every language compiler; I would have thought Intel would be very motivated to get more binaries lighting up the features they add to their expensive top line CPUs. But yeah no, on the whole cost of the checks and duplicated binary size aren't seen as worth it, so instead it's piecemeal implementations mostly in numeric packages like eigen…

> so instead it's piecemeal implementations mostly in numeric packages like eigen and lapack. Because that’s where the user-noticeable gains can be made. Using popcount in code you run once is going to shave off, maybe, 100 cycles. That isn’t worth the extra cycles of that approach. Also, FTA: “and arguably the whole scheme should be replaced by finer-grained feature detection” . Such feature detection would lead to…

> Also, FTA: “and arguably the whole scheme should be replaced by finer-grained feature detection”. Such feature detection would lead to a combinatorial explosion of different binaries.

the thread is about runtime detection tbf

Re: How much do amd64 microarchitecture levels help in Go?

#17
> That is a 43% reduction, and it is free: no source change, just a compiler flag.

It's not entirely free; the cost is that the resulting binary will no longer run on processors that lack the instruction. Which, admittedly, is ≈2007 or older. But still! I have a 2012 CPU still in service, and as much as I'd love to obsolete it, gestures at the price tag of RAM these days.

… a 2012 CPU is surprisingly competitive relative to today's tech, too, I'd add. The gap between 2012 and 2026 is nothing compared to the equivalent gap between 1998 and 2012: 1998 is like 500MHz single-core, 32-bit. 2012 is 4 core, 8 hyper threads, 64-bit, 3.5 GHz. (… perhaps more remarkably, my next-oldest machine, a 2017 laptop, is only 2.8 GHz, with the same 4(/8) cores. It also uses like half the power, too. That's mostly the "laptop" bit, though.)

(That same CPU is also incapable of "v3".)

Re: How much do amd64 microarchitecture levels help in Go?

#18
Does Docker have uarch level support? I think similar to arch level, it could be beneficial being able to pull a v4 image.

Ubuntu started allowing defaulting to v3 packages, and I opted in. I already use the -C native to enable AVX512 when compiling binaries for local use. This matters a lot for compute/analytics workloads in my experience.

Re: How much do amd64 microarchitecture levels help in Go?

#19
I think the more critical question is how well compiler writers can update the heuristics which identify the instruction sequences that benefit from the architectural features. Last I looked, Intel has several thousand intrinsics which must be explicitly invoked to make use of specific features.

I suspect that heavily optimised code either uses intrinsics or carefully written assembler code.

Re: How much do amd64 microarchitecture levels help in Go?

#20

I think the more critical question is how well compiler writers can update the heuristics which identify the instruction sequences that benefit from the architectural features. Last I looked, Intel has several thousand intrinsics which must be explicitly invoked to make use of specific features. I suspect that heavily optimised code either uses intrinsics or carefully written assembler code.

I think both AMD and Intel employ and/or fund GCC and LLVM developers to add support for each new architecture. Compiler and product release schedules are independent so the target and tuning support in the latest compiler release may be slightly behind or even ahead of the latest microarchitecture release. GCC 16.1 has support for Zen 6, which has even been released, yet. (https://gcc.gnu.org/gcc-16/changes.html#x86)
Post reply on HN