Live data from Hacker News

How much do amd64 microarchitecture levels help in Go?

lemire.me

31–40 of 50 posts

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

#31
post #24
post #21

Earlier quoted context omitted.

My main problem was that our hosting company offers cheap Linux servers, but with a shared CPU that even doesn't support v2. We pay more now, but you could still run into that problem.

It's likely this is a hypervisor misconfiguration. Either way, one has to wonder what kind of mitigations for cross-tenant leakage they are missing.

Either it's a misconfiguration, or it's intentional (only providing a "bare-bones" machine for the lowest price level, even if the underlying hardware would support more)?

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

#32
post #5

Earlier quoted context omitted.

> 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

I see I wasn’t clear enough. The tool I discussed generates multiple binaries and then packs all of them into a single binary. I was referring to the former.

https://github.com/ronnychevalier/cargo-multivers:

“After building the different versions, it computes a hash of each version and it filters out the duplicates (i.e., the compilations that gave the same binaries despite having different CPU features). Finally, it builds a runner that embeds one version compressed (the source) and the others as compressed binary patches to the source. For instance, when building for the target x86_64-pc-windows-msvc, by default 4 different versions will be built, filtered, compressed, and merged into a single portable binary.

When executed, the runner uncompresses and executes the version that matches the CPU features of the host.”

Hopefully (and likely) the patches will not be too large, but for 6 binary compiler flags, you’d still have 2⁶ binaries.

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

#33
post #5

Earlier quoted context omitted.

> 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

AFAIK, that wasn’t solely a matter of picking the optimal compilation flags. It also included profile-guided optimizations and kernel tweaks.

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

#34

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.

The fragmentation of AVX-512 is a legacy problem.

All the CPUs introduced after Ice Lake (Q3 2019), with the exception of Cooper Lake (Q2 2020; a server CPU with a modest installed base), which support any kind of AVX-512, support all the AVX-512 subsets of Ice Lake (which has very important additions over V4).

This includes all AMD Zen 4, Zen 5 and Zen 6 CPUs, which form the bulk of the non-server CPUs that support AVX-512. Thus 6 years have passed since the introduction of an AVX-512 CPU that is not compatible with Ice Lake (and 7 years since any such CPU that was in widespread use).

Both Intel and AMD have stated that from now on features will be added to AVX-512 (a.k.a. AVX10), not deleted, which will allow in the future the testing of the AVX10 version number to be sufficient for determining CPU capability in this domain.

It would make sense to define a V5 level that includes all instructions of Ice Lake and also a V6 level, corresponding to AVX10.1 (Intel Granite Rapids) or to AVX10.2 (Intel Diamond Rapids).

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

#35

I would have thought you’d need to explicitly code to match the cpu capabilities to your application, for maximum benefit.

This is what you should always do when you know on which computers you will run the program, like I do when writing programs for my own computers.

If you are a software vendor, or even just a contributor to some open-source program, you must make some compromise between program performance and its ability to run without modifications on an as large number of computers as possible.

Therefore you must either avoid any features available only in newer computers, or you must have some kind of processor capability detection at run time, followed by the selection of appropriate program variants.

You might not afford to prepare enough program variants, so it is likely that you would still choose to not support the most recent computers.

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

#36
post #33

Earlier quoted context omitted.

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

AFAIK, that wasn’t solely a matter of picking the optimal compilation flags. It also included profile-guided optimizations and kernel tweaks.

Doesn't that get into the domain of a distro like Gentoo though? (Or sort of Nix as well) - rebuild everything to precisely target your actual architecture.

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

#37

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.

Here is a CPU from 2020 that does not support AVX nor AVX2 https://www.intel.com/content/www/us/en/products/sku/199288/... very low budget and probably not common but this is why one might choose not to require AVX2

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

#38

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?

Diminishing returns apply to ISA extensions only on average, not for individual applications.

Most of the recent additions in processor instruction sets are intended for relatively niche applications.

In such cases, other applications will not be affected at all, but the specific application that is the target, for example a certain cryptographic algorithm or AI inference, may be accelerated many times when using the new ISA version instead of the old ISA version.

Moreover, it is frequent that compilers are not smart enough to take advantage of such ISA extensions, so it is not enough to change the compilation flags, but you need to rewrite some library to get the full performance benefit. For example, many recent x86_64 CPUs have IFMA instructions (integer fused multiply-add instructions), which allow the use of the floating-point multipliers for doing arithmetic operations with big integer numbers (the advantage is that modern CPUs have many more FP multipliers than integer multipliers). This can accelerate a lot the computations with big numbers, but you need a complete carefully-written library that uses such instructions, you cannot just recompile some programs for making them run faster.

From time to time it may still happen that some ISA extension has a wider applicability, being able to accelerate many applications, possibly just by recompilation, like Intel hopes to happen with the APX extension that will arrive early next year, in the Intel Nova Lake and Diamond Rapids CPUs.

Most non-professional computer users are biased toward single-threaded application performance, where diminishing returns have already been seen for more than 2 decades.

On the other hand for multi-threaded application throughput, we have not reached yet any diminishing returns. The throughput per CPU socket has continued to increase in geometric progression every year until now. The only serious problem is that starting around 10 years ago, from the days of Intel Kaby Lake and Coffee Lake, the price of computers has started to increase and the increase rate has accelerated recently.

So now the possible throughput for a given computer size becomes less and less relevant in comparison with the throughput per dollar, and for the throughput per dollar it appears that we have already entered the region of diminishing returns (i.e. with unlimited budget you can still buy computers whose throughput increases in geometric progression each year, but the computers that you can actually still afford have a throughput that increases much slowlier).

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

#39
post #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.

Yes, it's in the platform options. You can specify --platform linux/amd64/v3 for a v3 image.
Post reply on HN