Hacker News Reader

Comment by gigatexal | Hacker News Reader

If you need AVX/AVX2/AVX512 then go intel. Otherwise this AMD chip would be my choice for most applications.

I'd say it's a bit early to be making statements like that; Zen 2 has native 256 bit vector units, and might yet do OK with AVX2 code vs Intel processors.

AVX512 though, even if you don't use the full width registers (eg to avoid throttling), the new instructions are very useful and not at all present on Zen 2. I wouldn't be surprised if Zen 3 kept 256 bit vector units, but supported the AVX512 instruction set.

Moreover, AVX2 operates at full frequency on Zen 2. AVX-512 heavily downclocks CPU; not sure about AVX2 loads on Intel right now (some people complained about AVX2 throttling on Skylake X).

I thought I read somewhere that Zen 2 will downclock based on heat, rather than simple instruction set heuristics. I can't find a source though, so take that as hearsay for now.

Intel CPUs do downclock for both avx and avx-512. Many motherboards let you configure that in the bios.

I bought both a 9940X and a (delidded) 7980XE for avx-512 intensive workloads. I use a water cooler with a 360mm radiator. The bios for these (overclockable) chips contains "AVX Offset" and "AVX512 Offset" parameters. I haven't really tested avx loads, but the avx512 downclock is necesary. They run at 70-80C when running all cores at 3.5GHz in avx512 heavy loads. I don't want to push the temperatures further than that. I don't think there's any practical way to avoid having to downclock. It does gives a sizeable speed boost overall (for those workloads).

Re: this thread I'd bet those avx512 workloads will be faster as avx2 workloads running on two 64 core CPUs with avx2 than one 56 core CPU with avx512, all else equal. But it sounds like, instead of all else being equal, things like IPC favor Zen2.

EDIT: If folks happen to be interested, I compared a bunch of different "^" (aka, "pow") functions in Julia, running on my 9940X here: https://discourse.julialang.org/t/slow-arbitrary-base-expone...

Someone else shared results with their Ryzen 2950X here: https://discourse.julialang.org/t/workstation-advice-for-mos...

The vectorized versions were those with "sleef" or "xsimd" in their name. They tended to be 1.5 to 3 times faster, while the nonvectorized versions were 1.25 to 1.35 times faster on the 9940X.

Some of my other code is likely to show a much bigger difference. For example, many small matrix multiplication operations get to take advantage of avx512's masks to vectorize efficiently, as well as the fact avx512 has 32 instead of 16 floating point registers to hold larger matrix blocks in registers, increasing the vfma to vmov ratio.

I suspect the 3.2x difference in speed in the "jsleefpowcob!" benchmark is because of the register counts. I suspect with avx512 the compiler was able to avoid register spills, while with avx2 it had to reload a lot of data on each loop iteration.

The biggest problem with avx512 IMO is that compilers seem bad at taking advantage of it (eg, they never use masks) unless you babysit them / write code with vectorization constantly in mind.

gcc for example will not use 512 bit vectors by default. You must explicitly specify "-mprefer-vector-width=512". My tests (mostly just the Polyhedron Fortran benchmarks, as a set of numerical code) seemed to confirm that gcc (gfortran) was doing the right thing.

Meaning unless you intend to go low level and use it yourself (which can be a rewarding hobby!), or have workloads where optimized libraries exist, you won't see any benefit from avx512.

No, bad idea. Test or check reviews for your common workloads first, then choose. New Zen cores quite powerful and there are many gotchas with AVX execution. In most cases I can see AMD would be better overall or offer good value.

I agree and I plan to.

Indeed. With any microarchitecture (or ISA) change (and Intel -> AMD is a huge architectural one) you need to test your workloads. You'll find all sort of odd and surprising performance differences caused by throttling, the way caches behave, the way libraries choose code paths, various inter-core latencies, and so on.

At least this is a move that doesn't require a full recompile.

I'm not sure intel has advantage in avx 2 with the new ryzen. That said I got this information from some unsourced comment in hacker news, it might be totally wrong.

Didn‘t intel start segmenting their processor on avx support? So only the expensive processors get avx512?

What software is typically able to take advantage of these instructions?

My use case is solving large LP/MIP problems for power markets, do those algorithms benefit?

Not serve-y but RPCS3 benefits a lot from those.

Depends on the structure of your problem. Some lend themselves well to vectorization, others not nearly as much. Or at least the needed vectorized solvers are not yet available for some problem structures.

Try to use perf-tools to determine how you're currently using these execution units, and then you can look how much it might help. Rule of thumb: double the bitwidth of vector instructions gets you 80% more speed, instead of the theoretical 100%.

Those languages where the tensor/array is the fundamental unit: such as the APL family. J and K have optimized builds using AVX.

does avx512 bring that much of a perf advantage ?

For software that takes advantage of it it does.

Any commonly used software that benefits from AVX-512?

Video editing, audio mastering, games.

Games!? No Man's Sky had trouble with SSE 4.1 being a requirement, and ended up patching it out... let alone AVX, AVX2, or AVX512.

Typically, games won't take advantage of new instruction sets until it's ready to be a minimum requirement, as otherwise you need to maintain two code paths, the benefit of which is only to be speeding up execution on what are already the more powerful CPUs.

What games can benefit from AVX512?

Not now obviously as it is not mainstream yet, but AVX512 makes developer's life way easier than older AVX sets. So I see no reason why game engine developers wouldn't use them in the future. For now only some server-specific workloads use AVX512.

It's going to be a long, long time - at least a decade. I'd go as far as to say "never" is plausible, depending on how ARM penetration plays out.

If the consoles go ARM before AVX-512 has been standard on new PCs for years, it may just not be worth it.

Except it dosent because there are 4+ mutually incompatible versions of AVX instruction sets.

Gotta love the price segmentation.

And AVX512L should further improve that.

Some LLVM compilers produce code that (possible with GCC too) can jit itself on a per function on first execution e.g. -march=native so no branches required.

This requires good planning of the game, i.e. this reduces inlining so one needs to be careful with putting the important bits in the JITted code

Practically no-one in the industry uses this, or the icc system that builds multiple versions of functions in the same exe.

It might work in theory, but it increases the cost of testing too much for it to be worth it.

I'm just saying that it exists.

I saw it the other day and was amazed I hadn't seen it before.

If you're referring to ifuncs, they aren't doing anything like "JIT itself": your rtld simply calls your function to decide which version of the function you want to call and updates the PLT.

FreeBSD kernel uses ifuncs for SMAP, XSAVE, ERMS (Enhanced REP MOVSB/STOSB), RDSEED.

I don't know what they call it normally, but I noticed a magic symbol attribute in the LLVM d compiler that invoked a jit at runtime (-dynamic* something like that)

Edit: I checked and they're not ifuncs

Not an authoritative list but a graphics benchmark and an x264 encoder at least according to this https://forums.anandtech.com/threads/avx-512-what-software-u...

Rarely. It has serious throttling issues as well.

I appreciate your tautological answer. I was more looking at concrete examples with % differences in benches :)

Well, it includes some masking instructions that allow algorithms to use vectorization in cases where it's not natively processing vectors. The benefit should be similar to the thread-local control flow stack introduced in the Volta microarchitecture of Nvidia.

Reply on news.ycombinator.com