Earlier quoted context omitted.
Bulldozer significantly outperformed Sandy Bridge on the workloads which it was designed to be good at, which is multi-threaded integer workloads, like compiling the Linux kernel. https://www.phoronix.com/scan.php?page=article&item=amd_fx81... https://www.phoronix.com/scan.php?page=article&item=amd_fx83... If Linus' attitude of "I'd rather have more cores" and "FP doesn't really matter" were representative of market…
Are we looking at the same benchmarks? In the first they're comparing an 8-core Bulldozer to Sandy Bridge with 4 cores and no hyperthreading and it's basically even, sometimes it wins by a small margin on the threaded ones. In the second the 3770K has 4 cores with hyperthreading and that makes it look even worse. If they were actually getting twice the integer performance per module as Intel was getting per core then…
Linus Torvalds on AVX512
111–120 of 124 posts
Re: Linus Torvalds on AVX512
#112Earlier 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. 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 d…
Re: Linus Torvalds on AVX512
#113Earlier quoted context omitted.
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 d…
He likely has ~zero hands on experience with SIMD or AVX512 as those aren't used in his precious kernel.
More importantly, the kernel needs to support context switch between userspace applications that use SIMD registers. So it touches a bunch of critical data structures and event handlers.
Re: Linus Torvalds on AVX512
#114Earlier quoted context omitted.
I am looking at it of the point of view of joe/jane developer that cannot tell head from tail regarding vector programming and doesn't even know what compiler intrinsics are for, and use languages that don't expose them anyway.
Well those people will never be getting the most out of their CPUs to begin with.
Re: Linus Torvalds on AVX512
#115Earlier quoted context omitted.
ARM/RiscV with many cores...that's what i wrote, if you don't need a gpu you don't need one, if you need SVE you integrate it or use a co-Processor :)
SVE isn't in a co-processor, I guess is the point. There's a lot more to Fugaku than SVE (whether or not you think that's a version of avx512), though. No DDR is suggestive.
Thanks for reading.
Re: Linus Torvalds on AVX512
#116Earlier quoted context omitted.
You must be young. Home PC CPUs from my youth drew only single digit watts. They didn't require any fan until the Pentium.
Indeed: 386, introduced 1985: http://www.cpu-world.com/CPUs/80386/Intel-A80386-16.html Typical/Maximum power dissipation: 1.85 Watt / 2.3 Watt And even no Pentium III 1999-2003 needed more than around 30 W: https://en.wikipedia.org/wiki/List_of_Intel_Pentium_III_micr...
Re: Linus Torvalds on AVX512
#117Earlier quoted context omitted.
They exist today, but they were added after AVX. Every year we figure out how to cram more transistors on a cubic cm, and once the low hanging fruit was added and we knew how to add more transistors, we decided to start putting more and more specific functions. That is the point of Linus. He would have preferred to use that increase in transistor count for other things, like more cache.
More cache has diminishing returns, because cache wants to be as close as possible to the core logic. And modern CPU's are mostly cache anyway. Special-purpose blocks for common compute tasks are quite cheap.
Skylake is less than 30% cache. However internally it's 512bus, thanks to avx-512 - which could be considered suboptimal.
Re: Linus Torvalds on AVX512
#118Since this thread is of the second freshness, we won't merge.
Re: Linus Torvalds on AVX512
#119AVX-512's fantastic breadth is born out of an actual need to free compilers from constraints imposed by programs in virtually every mainstream language. All of these describe programs for an academic-machine rooted in a scalar instruction model. Without any further performance from increasing cycles over time the target has to become instructions-per-cycle and even operations-per-instruction. The limitations on ILP and the expense of powering circuitry to achieve it has been well studied for the past two decades. The failure to realize it is evident in the failure of Netburst. Linus believes that the frontend of CPU's have a lot more to give; perhaps best exhibited with his refutation of CMOV (https://yarchive.net/comp/linux/cmov.html).
Today's programming languages haven't evolved to make things easier on programmers to describe non-scalar code. On the other hand, power constraints, and now security constraints haven't made things easier for hardware to efficiently execute scalar code. Perhaps AVX-512 is as naive a bet as Itanium, if not it might be just the missing piece compilers need that they didn't have twenty years ago.
Re: Linus Torvalds on AVX512
#120Earlier quoted context omitted.
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.
Disclaimer: I work on AMD ROCm, but my opinions are my own. There's also HIP[1], which can be used as a thin wrapper around CUDA, or with the ROCm backend on AMD platforms. It doesn't yet match CUDA in either breadth of features or maturity, but it's getting closer every day. [1]: https://github.com/ROCm-Developer-Tools/HIP
I wish all the GPU companies would get together and make a standard based on C++ and stick with it.