Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How much do amd64 microarchitecture levels help in Go?

lemire.me

Post reply on HN
Print view View original

41–50 of 50 posts

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

#41

Post by wongarsu »

Someone wrote: post #32
throawayonthe wrote: post #16

Earlier quoted context omitted.

> 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,…

Yeah, but that's because of pragmatic choices to limit the scope of the tool. In the wider context of "I've long been surprised there isn't more multiversion stuff built right into every language compile" it's easy to imagine a compiler that can heuristically detect which functions would benefit from certain CPU features, and walk over the call graph to find locations for runtime feature detection that balance detection overhead with code duplication for the fallback functions. For example merging the feature detection of adjacent function calls, making sure feature detection is moved out of hot loops, etc.

Obviously this is much easier to imagine than to implement. And in some languages it might be made impossible by certain language features (function pointers might become tricky). But this is more or less what some people do by hand in Rust with the more manual is_x86_feature_detected macro, so there's no obvious reasons why compilers couldn't automate it in at least some languages.

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

#42

Post by monster_truck »

XorNot wrote: post #36
Someone wrote: post #33

Earlier quoted context omitted.

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.

Yes, and the maximally performant configurations are at odds with a usefully hardened security posture. This only gets more true as time goes on and additional mitigations pile up.

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

#43

Post by arghwhat »

pjmlp wrote: post #25
tgv wrote: post #14

Earlier quoted context omitted.

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.

Language !== Implementation, so no the title isn't correct. Go's selling point is definitely not performance.

Go's selling point is most definitely performance, but relative to implementation effort of a given application. This is opposed to languages that focus more on maximum performance at any cost to implementation, or maximum convenience at any cost to performance.

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

#44

Post by pjmlp »

arghwhat wrote: post #43
pjmlp wrote: post #25

Earlier quoted context omitted.

Language !== Implementation, so no the title isn't correct. Go's selling point is definitely not performance.

Go's selling point is most definitely performance, but relative to implementation effort of a given application. This is opposed to languages that focus more on maximum performance at any cost to implementation, or maximum convenience at any cost to performance.

Basically a political answer that answers nothing.

It isn't performance compiling, as that is only surprising for those that never used 90's compiled languages like Modula-2, Object Pascal, Clipper and co.

It isn't performance of code execution, as even GCCGO could beat the reference implementation, unfortunately now stagnant since no one cares to update it beyond Go 1.18.

And to go back to the article, as pointed out there,

> The Go toolchain does not currently generate any AVX512 instructions.

Thus leaving performance on the table.

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

#45

Post by speed_spread »

arghwhat wrote: post #43
pjmlp wrote: post #25

Earlier quoted context omitted.

Language !== Implementation, so no the title isn't correct. Go's selling point is definitely not performance.

Go's selling point is most definitely performance, but relative to implementation effort of a given application. This is opposed to languages that focus more on maximum performance at any cost to implementation, or maximum convenience at any cost to performance.

It's not the kind of performance expectations where processor-specific SIMD support really matters (although nice if it's there)

Go's performance goals are to have much faster runtime than any interpreted language and faster build times than most compiled languages. It's a reasonable stance.

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

#46

Post by nasretdinov »

pixelpoet wrote: post #40

These slop images he uses for his articles are so bad; here it says "accelation"...

I had to look hard to find any AI-generated images and I've only found one at the very top. I guess I've just developed "banner blindness" because I didn't even register that image...

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

#47

Post by coredog64 »

rob74 wrote: post #31
fweimer wrote: post #24

Earlier quoted context omitted.

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)?

Isn't there a thermal cost to AVX instructions? Or, thinking of other reasons, if you're splitting up physical hardware into a "vCPU", it it possible that AVX doesn't map cleanly?

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

#48

Post by fweimer »

tgv wrote: post #27
fweimer wrote: post #24

Earlier quoted context omitted.

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.

Or on purpose, because the CPUs with AVX are more expensive. Or historical: the hardware for this kind of service may have been old, and you can't tell people that if you buy today you get a processor with AVX, but tomorrow you may get one without. I haven't checked if they upgraded their low-cost options in a while.

You can try to execute POPCNT. If it does not fault, its presence is only hidden via CPUID.

Live migration support may be the reason why they stick to the baseline. That's most likely to be migratable across different CPU types. Although with a bit of effort, you can figure out what is support by your fleet and configure that into the hypervisors.

I'm skeptical that pre-SSE-4.2 etc. CPUs are economically viable for running customer workloads due to electricity costs.

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

#49

Post by kristianp »

Am4TIfIsER0ppos wrote: post #37
kristianp wrote: post #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.

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

Wow, that's interesting, apparently 10th gen Pentiums and Celerons don't have avx. The wonders of product segmentation. They apparently corrected course (and also gave consumers AVX-512) in the 11th gen: https://www.tomshardware.com/news/intels-latest-celeron-and-...

There's a related discussion on hn from 2020 about lack of AVX here https://news.ycombinator.com/item?id=24577069

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

#50

Post by arghwhat »

pjmlp wrote: post #44
arghwhat wrote: post #43

Earlier quoted context omitted.

Go's selling point is most definitely performance, but relative to implementation effort of a given application. This is opposed to languages that focus more on maximum performance at any cost to implementation, or maximum convenience at any cost to performance.

Basically a political answer that answers nothing. It isn't performance compiling, as that is only surprising for those that never used 90's compiled languages like Modula-2, Object Pascal, Clipper and co. It isn't performance of code execution, as even GCCGO could beat the reference implementation, unfortunately now stagnant since no one cares to update it beyond Go 1.18. And to go back to the article, as pointed ou…

> > The Go toolchain does not currently generate any AVX512 instructions. > > Thus leaving performance on the table.

This just misunderstands the documentation. Compilers do not generally emit much of any AVX512, and the docs are just stating that the Go toolchain itself never emits it at the current time.

Use of AVX512 instead usually comes from explicit intrinsics or handwritten assembly in the compilers you're thinking of, and it is the same in Go. There isn't much AVX512 code in the standard library, but it is there and the GOAMD64=v4 flag means that it does not have to use runtime CPUID feature detection.

External Go libraries like simdjson-go also actively use AVX512. AVX512 does nothing for code not written with SIMD in mind anyway.

Post reply on HN