Live data from Hacker News

Linus Torvalds on AVX512

phoronix.com

71–80 of 124 posts

Re: Linus Torvalds on AVX512

#71
post #18

What are the forces in chip design that are at play here? Over the last 10-15 years, fabs have continued to fit more and more logic gates per unit area, but haven't reduced the power consumption per gate as much. As a result, if you fill your modern chip with compute gates, you cannot use them all at once because the chip will melt. Or at least you can't have them all running at max clock rates. One solution is to in…

The main problem is software, with GPGPUs you need to explicitly program for them, while with stuff like AVX there is this implicit hope that you just code as always and the compiler will take care of the rest via auto-vectorization and PhD level optimization algorithms. Because outside artificial intelligence, graphics and audio, there is little else that common applications would use the GPGPU for, so the large maj…

> while with stuff like AVX there is this implicit hope that you just code as always and the compiler will take care of the rest via auto-vectorization and PhD level optimization algorithms

No. I recently could really, really have used the packed saturated integer arithmetic and horizontal addition in AVX2 (but my old machine doesn't support it) and even better, the same but 512 bits wide on AVX512. It would only have been 6 or 7 instructions, if that, but it was inner loop, and mattered. Using compiler intrinsics would have been fine. I think you're looking at things too narrowly.

Re: Linus Torvalds on AVX512

#72

What are the forces in chip design that are at play here? Over the last 10-15 years, fabs have continued to fit more and more logic gates per unit area, but haven't reduced the power consumption per gate as much. As a result, if you fill your modern chip with compute gates, you cannot use them all at once because the chip will melt. Or at least you can't have them all running at max clock rates. One solution is to in…

> Over the last 10-15 years, fabs have continued to fit more and more logic gates per unit area, but haven't reduced the power consumption per gate as much. Kids these days get 8 cores for a 100W TDP. When I was a boy, 100W got you a single core. And you didn't get dynamic frequency scaling, so it'd be putting out that heat all the time . (We also had to walk to school barefoot in the snow, uphill both ways)

You must be young. Home PC CPUs from my youth drew only single digit watts. They didn't require any fan until the Pentium.

Re: Linus Torvalds on AVX512

#73
post #60

Earlier quoted context omitted.

MSL, CUDA and SYSCL are C++ with extra topping. Also one of the reasons CUDA won developer love is that it fully embraced polyglot programming on the GPU.

None of those are both portable and widely available on end user machines, which is needed for games CUDA seems nice, but being Nvidia only makes it a total dead end.

Windows and iOS gaming community with disagree will that statement.

Or are you speaking about the 1% Linux users on Steam?

Re: Linus Torvalds on AVX512

#74

Are Intel just delaying the inevitable? Is it safe to say (even today) that a slow GPU will crunch big matrices faster than a fast CPU? And that's before we get to price/performance. So all that's left is the bottleneck around PCIe which, in theory, leaves the CPU with an advantage only for small datasets - which we don't really care about anyway (because they happen quickly). Maybe the tradeoff is somewhere interest…

In the article they quote Linus speculating that the increased core count of CPUs will achieve the same thing as AVX512 without the problems. I have read comments on HN that if cores keep increasing on CPUs they might be able to replace GPUs for some of the tasks as GPUs (or CUDA in particular) have quirks that CPUs don't have. AVX512 in particular has issues. Using it slows down the CPU so actual wall clock benefits…

For general purpose computing maybe. For gaming the GPUs contain special operations for texture lookup and what not that would be very expensive in a CPU.

Re: Linus Torvalds on AVX512

#75
post #49

Earlier quoted context omitted.

He has the history correct. Most of the CPUs that x86 beat in the market had superior FP performance; SPARCs, Alphas, PA-RISC, Itanium, etc. > When's the last time he actually did anything with a computer? According to Linus he completes about 30 pull requests a day. Some multiple of that in kernel builds. His $1900 32 core Threadripper speeds that process a great deal and FP contributes little to nothing. Today peop…

He has the history correct. Most of the CPUs that x86 beat in the market had superior FP performance; SPARCs, Alphas, PA-RISC, Itanium, etc. This isn't a discussion about history, it's a discussion about SIMD FP instruction sets. Maybe we should all be astronomers and thermodynamicists writing bespoke finite element simulations and have a deep appreciation for the wonders of floating point ISAs, but that's just not t…

This discussion is about avx512, which has shown to have some issues compared to other solutions. Nobody is claiming FP is garbage or that we don't ever need SIMD.

Regarding Linus: he is almost always right. He has had more hands-on experience than everyone in this thread combined. I trust his judgement, he has earned it by being consistently correct while his opposition has just complained and eventually failed to deliver themselves.

Re: Linus Torvalds on AVX512

#76
post #49

Earlier quoted context omitted.

He has the history correct. Most of the CPUs that x86 beat in the market had superior FP performance; SPARCs, Alphas, PA-RISC, Itanium, etc. > When's the last time he actually did anything with a computer? According to Linus he completes about 30 pull requests a day. Some multiple of that in kernel builds. His $1900 32 core Threadripper speeds that process a great deal and FP contributes little to nothing. Today peop…

He has the history correct. Most of the CPUs that x86 beat in the market had superior FP performance; SPARCs, Alphas, PA-RISC, Itanium, etc. This isn't a discussion about history, it's a discussion about SIMD FP instruction sets. Maybe we should all be astronomers and thermodynamicists writing bespoke finite element simulations and have a deep appreciation for the wonders of floating point ISAs, but that's just not t…

Fixed point audio decoding is common, actually. In general, floating point math makes sense when dealing with computations in a range spanning different orders of magnitude, where one cares about relative precision. This describes a lot of what we use computers for, but fixed point math is a lot more efficient and makes sense for simpler cases.

Re: Linus Torvalds on AVX512

#77

What are the forces in chip design that are at play here? Over the last 10-15 years, fabs have continued to fit more and more logic gates per unit area, but haven't reduced the power consumption per gate as much. As a result, if you fill your modern chip with compute gates, you cannot use them all at once because the chip will melt. Or at least you can't have them all running at max clock rates. One solution is to in…

>but haven't reduced the power consumption per gate as much.

That is simply not true. You can run the 64 Core on EPYC 2 all at once at 3Ghz all with Air Cooling.

At every node they have reduced power consumption that is also one reason you see continuous performance improvement.

Re: Linus Torvalds on AVX512

#78
post #49

Earlier quoted context omitted.

He has the history correct. Most of the CPUs that x86 beat in the market had superior FP performance; SPARCs, Alphas, PA-RISC, Itanium, etc. > When's the last time he actually did anything with a computer? According to Linus he completes about 30 pull requests a day. Some multiple of that in kernel builds. His $1900 32 core Threadripper speeds that process a great deal and FP contributes little to nothing. Today peop…

He has the history correct. Most of the CPUs that x86 beat in the market had superior FP performance; SPARCs, Alphas, PA-RISC, Itanium, etc. This isn't a discussion about history, it's a discussion about SIMD FP instruction sets. Maybe we should all be astronomers and thermodynamicists writing bespoke finite element simulations and have a deep appreciation for the wonders of floating point ISAs, but that's just not t…

What he said and I quote;

>AVX2 is much more than enough.

Re: Linus Torvalds on AVX512

#79
post #4

I for one would be delighted by having more caches or wider backends instead of AVX512, but I don't want SIMD to be pushed into GPUs. It'd be better to do the reverse - to push forward the asymmetric core idea and move more GPU functionality into lots of simpler cores tuned for SIMD at the cost of single thread performance.

Here are some shots of the Mask Registers https://travisdowns.github.io/blog/2020/05/26/kreg2.html#the... If seems like they just keep that area mostly empty in processors without that feature, at least for the processors related to the one pictured. Not really sure how much cache that would be effective could fit without a major overhaul, but likely a chip designer or enthusiast would. This could be why Linus focuse…

From a quick glance at the proportions and considering not only the register files are halved, but also the vector EUs, I'd expect a 25% increase in L3 or a 50% in L2. That and some lessened thermal constraints.

Re: Linus Torvalds on AVX512

#80
post #70

FP matters (especially with SIMD) It matters to image/video/audio processing It matters to simulations It matters to 3D models/rendering It matters to games So it's not "just benchmarks", people actually want to do stuff with it Sure, AVX512 might not be the greatest way of doing it, and it might be better to just make the existing instructions go faster, that might work

It's a matter of perspective. Back in the day, CPUs didn't come with FPUs and the latter were optional co-processors. The idea in the x86-world always was to "outsource" special requirements to dedicated hardware (FP co-processors, GPUs, sound cards, network cards, hardware codec cards, etc.), instead of putting them on the CPU package (like ARM-based SoCs). So it's different philosophies entirely - tightly integrate…

FP coprocessors "only" existed because the processes weren't advanced enough to have them inside the chip, but they were a natural extension (they were married to the instruction set of the chip - it wasn't a product, it was a feature)

At the old days there were minor competitors to the x87 family that died quickly. (For reference: https://en.wikipedia.org/wiki/X87#Manufacturers )

For the rest yeah, it kinda makes sense to have them customizable.

Post reply on HN