61–70 of 124 posts
Here's an article about JITing x86 to AVX-512 to fuzz 16 VMs per thread:
https://gamozolabs.github.io/fuzzing/2018/10/14/vectorized_e...
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.
I really don't know if that would help much. Better cache management might give more bonus than just bigger caches or higher bandwidth.
Intel's FP performance sucked (relatively speaking), and it matter not one iota. Because absolutely nobody cares outside of benchmarks. Today I learned that even Linus Torvalds has a bozo bit. [1] When's the last time he actually did anything with a computer? 1: https://en.wikipedia.org/wiki/Bozo_bit
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…
As for the rest, you are wrong, AVX/512 is not just floating point by any means, and floating point is used by more than just scientific workloads.
Games/simulations/modeling software etc all can make heavy use of floating point.
Intel's FP performance sucked (relatively speaking), and it matter not one iota. Because absolutely nobody cares outside of benchmarks. Today I learned that even Linus Torvalds has a bozo bit. [1] When's the last time he actually did anything with a computer? 1: https://en.wikipedia.org/wiki/Bozo_bit
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…
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 the real world.
Bullshit. Pure, unrefined organic bullshit. I can't begin to imagine why you, or Linus, or anyone even remotely conversant with computers would think this way. This attitude isn't just stupid, it's dangerously stupid. Influential people listen to Linus, and in this case, they shouldn't.
Ever play a modern computer or console game? You're soaking in floating-point math. Ever do anything with graphics at all, for that matter? Run Photoshop or GIMP? That's all floating-point math under the hood... any nontrivial image processing work would be nightmarish without it. People used to spend hundreds of dollars on math coprocessors just to run Photoshop and similar creativity apps in the days before modern CPUs became fast enough to (apparently) be taken for granted.
Ever play an MP3 on your PC, never mind a video? Do you think that any mainstream software implementations of those algorithms have been coded in fixed-point math at any time over the last twenty years?
Never mind ML applications, which often use low-precision floats to maximize both dynamic range and memory efficiency. If there's a single trend that defines modern computing, it's the drive to turn everything into one big linear algebra problem and throw parallel FP execution units at it.
It's grossly ignorant to say that floating point performance only matters to astronomers or physicists or engineers, and it's a genuine revelation to me -- and a disturbing one -- to realize that people still think this way.
No, this isn't an apology for the debacle that is AVX-512, but... get real, no pun intended. It's not 1992 anymore.
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…
Jim Keller had an interesting talk recently [1] about ways of doing parallel processing to better us the billions of transistors we have - assuming the task is parallelizable. There's the scalar core (i.e the basic CPU) which is easy to program realtively. Then a scalar core with vector instructions - difficult to program efficiently. Then there are arrays of scalar cores, i.e. GPUs, so relatively easy to program aga…
It's not all that different conceptually to AVX-512 with mask registers, except the vector size is even larger and of course the programming model differs.
Earlier quoted context omitted.
GPU programming is easy enough, the complexity comes from the seperate memory system and the tedious(and not portable) API you need to use to access the GPU. I prefer intrinsics as they give more control than shader languages and they can be written in C++ instead of fiddling with some garbage GPU API that runs async.
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.
CUDA seems nice, but being Nvidia only makes it a total dead end.
“One challenge with AVX-512 is that it can actually _slow down_ your code. It's so power hungry that if you're using it on more than one core it almost immediately incurs significant throttling. Now, if everything you're doing is 512 bits at a time, you're still winning. But if you're interleaving scalar and vector arithmetic, the drop in clock speeds could slow down the scalar code quite substantially.“ - 3JPLW and https://blog.cloudflare.com/on-the-dangers-of-intels-frequen...
The processor does not immediately downclock when encountering heavy AVX512 instructions: it will first execute these instructions with reduced performance (say 4x slower) and only when there are many of them will the processor change its frequency. Light 512-bit instructions will move the core to a slightly lower clock.
* Downclocking is per core and for a short time after you have used particular instructions (e.g., ~2ms).
* The downclocking of a core is based on: the current license level of that core, and also the total number of active cores on the same CPU socket (irrespective of the license level of the other cores).
As per https://lemire.me/blog/2018/09/07/avx-512-when-and-how-to-us...
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.
The AVX512 instructions can cause strange global performance downgrades. “One challenge with AVX-512 is that it can actually _slow down_ your code. It's so power hungry that if you're using it on more than one core it almost immediately incurs significant throttling. Now, if everything you're doing is 512 bits at a time, you're still winning. But if you're interleaving scalar and vector arithmetic, the drop in clock…
Can other SIMD instructions (AVX2, say) do the same?
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
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 integrated SoCs vs versatile and flexible component-based hardware.
It's The One Ring ([ARM-based] SoCs) vs freedom of choice and modularity (PC). If I don't do simulations or 3d-modelling/rendering, I am free to choose a cheap display adapter without powerful 3D-acceleration and choose a better audio interface instead (e.g. for music production).
The SoC approach forces me to buy that fancy AI/ML-accelerator, various video codecs, and powerful graphics hardware with my CPU regardless of my needs, because the benevolent system provider (e.g. Apple) deems it fit for all...
Torvalds is just old-school in that he prefers freedom of choice and the "traditional" PC over highly integrated SoCs.