By: Romain Dolbeau (romain.delete@this.dolbeau.org), July 14, 2020 10:09 am
Room: Moderated Discussions
Linus Torvalds (torvalds.delete@this.linux-foundation.org) on July 12, 2020 11:35 am wrote:
> Because this forum is about architecture design and implementation, isn't it?
It is. And I think one of the reasons for your issues with AVX-512 is that you're mixing the two - design and implementation. The AVX-512 design is not what the Skylake-X implementation did with it.
> So I think it's very fair to put down that gauntlet: AVX512 vs SVE2.
TL;DR: If FP is your thing, AVX-512 & SVE are both good and both better than the stuff before. If it isn't, they're both mostly a waste of silicon, like the stuff before.
First, context: I'm a HPC guy, and old school at that. Double-precision FP is my lifeblood. I couldn't care less about virtualization, web workloads, interpreted languages, or pure pointer-chasing stuff like compilers (though I rely on them heavily, and worked in a compiler company for a long time). Basically, I'm only interested in enough sequential performance to support parallelism (calling an MPI function is essentially sequential...), and in SIMD FP real-life performance (i.e. on useful codes, not on Linpack). In other words, I'm the kind of guy for whom AVX-512 or SVE were designed... so I like them :-)
For implementations:
AVX-512: KNL wasn't quite it (high latencies, missing DQ/VL, abysmal sequential performance, ...) and Skylake-X XCC has a major power/thermal issue, well documented. Lower-end Skylake-X are less catastrophic, though somewhat because they are slower to begin with (they don't have the 2nd FMA on port 5).
SVE2: There isn't any. SVE (without the 2, so missing some DSP-oriented stuff, as SVE2 doesn't bring much to the table for the FP crowd) only has one currently available. That is the (currently unobtainium outside of Fugaku itself) Fujitsu A64FX, which seems good from early reports. Time will tell.
As far as design goes, they're both very good, although they work on different assumptions. You certainly can build a case for or against either of them based on details, but broadly, they both do the job well, and better than previous solutions (MMX, SSE, AVX, NEON, VIS, MSA, AltiVec, ...).
AVX-512 is good, full stop. Sure, it assumes you know how much data is in a register and the kind of code you work with, so you can use any of the available width (128, 256 and 512 are all available if you have VL support, which only KNL is lacking) optimally. But it has all you need to generate code from a compiler on a wide range of cases: masking, scatter/gather, reasonable orthogonality, good feature coverage (they added back rotation, complex arithmetic support is still somewhat lacking). Compared to AVX2, there's no comparison, it's much easier/nicer to deal with, and you get an extra 16 registers as well. AVX2 doesn't have scatter, can't mask properly, etc. Semantically, it's just SSE on wider registers (and three operands, granted, the one redeeming feature of AVX).
SVE is basically the same as AVX-512 (though rotation is only in SVE2 and complex support is better), just with no fixed width. The idea is that binary code will be 'portable' between implementations of different width, a nice goal. Unfortunately, that doesn't play as nice with algorithms (or optimizations) with a fixed amount of work. You can't fully unroll your vectorized/cache-blocked loop if you don't know how many vector fit in the cache to begin with. And there's the weight of legacy, e.g. math libraries that assume they will know the width of the vector at compile time... So while the idea is attractive, it simply causes a different set of trade-offs than fixed-width ISA like AVX-512.
Which is better? For my job, hopefully SVE :-) But it's the quality of implementation that is going to make the difference. Codes don't magically run on the SIMD ISA. They go through a compiler first, and then they need to run on the whole core alongside an operating system, with only some successfully vectorized bits relying on the SIMD part of the design. Ultimately, as long as all the required features are there, the ISA really doesn't matter that much (heresy, I know).
As for general availability... Sure, AVX-512 is missing from most processors. But SVE* is currently missing from *all* of them. Sure, using 512-bits wide registers on Skylake is seldom a good idea. But that doesn't mean that AVX-512 sucks - just that 512 bits on Skylake sucks. That's why ICC or GCC default to 256 bits vector on Skylake: you can have all the goodies of AVX-512 without the frequency penalty.
Also - the whole set of extensions to AVX-512 is a mess, yes. For _that_ part, SVE is currently better, but the SVE2 specifications were released before any SVE implementation, so it may not stay that way :-(
Narrower SIMD ISA could get away without the advanced features from AVX-512/SVE, but that was because the cost of not vectorizing was low - cost being evaluated by comparing achieved performance vs. theoretical peak. So only vectorizing the 'easiest' case was OK. AVX-512 and SVE can vectorize a lot more cases; but that means a lot more is expected of them performance-wise. AMD took some HPC market share because they had a lot more memory bandwidth, and it could run with all the AVX/AVX2 experience accumulated in codes during the Sandy Bridge/Ivy Bridge/Haswell/Broadwell era. Whereas Skylake-X needs at least recompiling for AVX-512 (256 bits or otherwise), and sometimes a whole new retuning of the codes. SVE will have/already has the same issue, and for it the tools are less mature (a lot of AMD Naples/Rome sold in the HPC market run codes compiled with ICC/IFORT...).
As for RISC-V V - the design is not frozen yet, and there's no high-performance implementations (at least not public), so it's not fair to compare. Hopefully, the final design will be feature-rich enough to be generally usable, yet will still allow for high-performance implementations. The academic implementations (ETH-Zurich ARA, BSC VPU, maybe others) will give an idea of the starting point for high-performance designs. When it comes to extensions, given that it seems to be a selling point for RISC-V to have a lot of them, it's likely not going to be any better than for AVX-512. If the baseline is good enough, it shouldn't matter too much though.
For the HPC market, this are interesting times; for a long time the choice was only "will you take NVidia GPU with those Intel CPU?", now IBM has taken back some (thanks to NVlink, to a large extent), AMD has taken back some (mostly the bandwidth crowd), and Arm is stepping up as an alternative (some ThunderX2 deployment, the A64FX taking the #1 spot on the Top500, and maybe some future stuff).
> Because this forum is about architecture design and implementation, isn't it?
It is. And I think one of the reasons for your issues with AVX-512 is that you're mixing the two - design and implementation. The AVX-512 design is not what the Skylake-X implementation did with it.
> So I think it's very fair to put down that gauntlet: AVX512 vs SVE2.
TL;DR: If FP is your thing, AVX-512 & SVE are both good and both better than the stuff before. If it isn't, they're both mostly a waste of silicon, like the stuff before.
First, context: I'm a HPC guy, and old school at that. Double-precision FP is my lifeblood. I couldn't care less about virtualization, web workloads, interpreted languages, or pure pointer-chasing stuff like compilers (though I rely on them heavily, and worked in a compiler company for a long time). Basically, I'm only interested in enough sequential performance to support parallelism (calling an MPI function is essentially sequential...), and in SIMD FP real-life performance (i.e. on useful codes, not on Linpack). In other words, I'm the kind of guy for whom AVX-512 or SVE were designed... so I like them :-)
For implementations:
AVX-512: KNL wasn't quite it (high latencies, missing DQ/VL, abysmal sequential performance, ...) and Skylake-X XCC has a major power/thermal issue, well documented. Lower-end Skylake-X are less catastrophic, though somewhat because they are slower to begin with (they don't have the 2nd FMA on port 5).
SVE2: There isn't any. SVE (without the 2, so missing some DSP-oriented stuff, as SVE2 doesn't bring much to the table for the FP crowd) only has one currently available. That is the (currently unobtainium outside of Fugaku itself) Fujitsu A64FX, which seems good from early reports. Time will tell.
As far as design goes, they're both very good, although they work on different assumptions. You certainly can build a case for or against either of them based on details, but broadly, they both do the job well, and better than previous solutions (MMX, SSE, AVX, NEON, VIS, MSA, AltiVec, ...).
AVX-512 is good, full stop. Sure, it assumes you know how much data is in a register and the kind of code you work with, so you can use any of the available width (128, 256 and 512 are all available if you have VL support, which only KNL is lacking) optimally. But it has all you need to generate code from a compiler on a wide range of cases: masking, scatter/gather, reasonable orthogonality, good feature coverage (they added back rotation, complex arithmetic support is still somewhat lacking). Compared to AVX2, there's no comparison, it's much easier/nicer to deal with, and you get an extra 16 registers as well. AVX2 doesn't have scatter, can't mask properly, etc. Semantically, it's just SSE on wider registers (and three operands, granted, the one redeeming feature of AVX).
SVE is basically the same as AVX-512 (though rotation is only in SVE2 and complex support is better), just with no fixed width. The idea is that binary code will be 'portable' between implementations of different width, a nice goal. Unfortunately, that doesn't play as nice with algorithms (or optimizations) with a fixed amount of work. You can't fully unroll your vectorized/cache-blocked loop if you don't know how many vector fit in the cache to begin with. And there's the weight of legacy, e.g. math libraries that assume they will know the width of the vector at compile time... So while the idea is attractive, it simply causes a different set of trade-offs than fixed-width ISA like AVX-512.
Which is better? For my job, hopefully SVE :-) But it's the quality of implementation that is going to make the difference. Codes don't magically run on the SIMD ISA. They go through a compiler first, and then they need to run on the whole core alongside an operating system, with only some successfully vectorized bits relying on the SIMD part of the design. Ultimately, as long as all the required features are there, the ISA really doesn't matter that much (heresy, I know).
As for general availability... Sure, AVX-512 is missing from most processors. But SVE* is currently missing from *all* of them. Sure, using 512-bits wide registers on Skylake is seldom a good idea. But that doesn't mean that AVX-512 sucks - just that 512 bits on Skylake sucks. That's why ICC or GCC default to 256 bits vector on Skylake: you can have all the goodies of AVX-512 without the frequency penalty.
Also - the whole set of extensions to AVX-512 is a mess, yes. For _that_ part, SVE is currently better, but the SVE2 specifications were released before any SVE implementation, so it may not stay that way :-(
Narrower SIMD ISA could get away without the advanced features from AVX-512/SVE, but that was because the cost of not vectorizing was low - cost being evaluated by comparing achieved performance vs. theoretical peak. So only vectorizing the 'easiest' case was OK. AVX-512 and SVE can vectorize a lot more cases; but that means a lot more is expected of them performance-wise. AMD took some HPC market share because they had a lot more memory bandwidth, and it could run with all the AVX/AVX2 experience accumulated in codes during the Sandy Bridge/Ivy Bridge/Haswell/Broadwell era. Whereas Skylake-X needs at least recompiling for AVX-512 (256 bits or otherwise), and sometimes a whole new retuning of the codes. SVE will have/already has the same issue, and for it the tools are less mature (a lot of AMD Naples/Rome sold in the HPC market run codes compiled with ICC/IFORT...).
As for RISC-V V - the design is not frozen yet, and there's no high-performance implementations (at least not public), so it's not fair to compare. Hopefully, the final design will be feature-rich enough to be generally usable, yet will still allow for high-performance implementations. The academic implementations (ETH-Zurich ARA, BSC VPU, maybe others) will give an idea of the starting point for high-performance designs. When it comes to extensions, given that it seems to be a selling point for RISC-V to have a lot of them, it's likely not going to be any better than for AVX-512. If the baseline is good enough, it shouldn't matter too much though.
For the HPC market, this are interesting times; for a long time the choice was only "will you take NVidia GPU with those Intel CPU?", now IBM has taken back some (thanks to NVlink, to a large extent), AMD has taken back some (mostly the bandwidth crowd), and Arm is stepping up as an alternative (some ThunderX2 deployment, the A64FX taking the #1 spot on the Top500, and maybe some future stuff).
Topic | Posted By | Date |
---|---|---|
Alder Lake and AVX-512 | me | 2020/07/11 07:02 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/11 11:41 AM |
informative (NT) | blue | 2020/07/11 12:40 PM |
grumpy | Michael S | 2020/07/11 12:51 PM |
grumpy | me | 2020/07/11 01:27 PM |
area and power cost of AVX-512 | Michael S | 2020/07/11 12:58 PM |
area and power cost of AVX-512 | Anon | 2020/07/11 04:35 PM |
area and power cost of AVX-512 | Michael S | 2020/07/12 04:16 AM |
area and power cost of AVX-512 | Travis Downs | 2020/07/12 09:13 AM |
area and power cost of AVX-512 | Travis Downs | 2020/07/11 07:19 PM |
Alder Lake and AVX-512 | Maynard Handley | 2020/07/11 02:02 PM |
Alder Lake and AVX-512 | Ungo | 2020/07/11 05:28 PM |
Alder Lake and AVX-512 | Maynard Handley | 2020/07/11 10:16 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/11 06:51 PM |
Alder Lake and AVX-512 | ⚛ | 2020/07/12 01:48 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 03:07 PM |
HDR | Anon3 | 2020/07/12 03:42 PM |
HDR10 in Kaby Lake? | David Kanter | 2020/07/12 05:09 PM |
HDR10 in Kaby Lake? | Maynard Handley | 2020/07/12 06:13 PM |
Thanks for the link (NT) | David Kanter | 2020/07/12 06:43 PM |
HDR10 in Kaby Lake? | Anon3 | 2020/07/13 01:36 AM |
Alder Lake and AVX-512 | Dummond D. Slow | 2020/07/12 03:00 PM |
AVX-512 with narrow ex units? | m | 2020/07/23 12:10 PM |
AVX-512 with narrow ex units? | Anon | 2020/07/23 12:53 PM |
AVX-512 with narrow ex units? | Paul A. Clayton | 2020/07/23 06:32 PM |
AVX-512 with narrow ex units? | Anon | 2020/07/23 06:50 PM |
AVX-512 with narrow ex units? | Paul A. Clayton | 2020/07/23 07:45 PM |
AVX-512 with narrow ex units? | Anon | 2020/07/23 08:15 PM |
AVX-512 with narrow ex units? | Jukka Larja | 2020/07/24 04:44 AM |
AVX-512 with narrow ex units? | Gabriele Svelto | 2020/07/24 02:56 PM |
AVX-512 with narrow ex units? | Jouni Osmala | 2020/07/24 09:22 PM |
AVX-512 with narrow ex units? | Jukka Larja | 2020/07/25 01:32 AM |
AVX-512 with narrow ex units? | Eugene Nalimov | 2020/07/25 05:56 PM |
AVX-512 with narrow ex units? | Jukka Larja | 2020/07/26 01:28 AM |
AVX-512 with narrow ex units? | Gabriele Svelto | 2020/07/26 02:22 PM |
AVX-512 with narrow ex units? | Jukka Larja | 2020/07/27 07:00 AM |
AVX-512 with narrow ex units? | -.- | 2020/07/23 06:32 PM |
AVX-512 with narrow ex units? | Travis Downs | 2020/07/24 05:01 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/11 04:45 PM |
Alder Lake and AVX-512 | Chester | 2020/07/11 05:26 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/11 06:22 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 02:02 AM |
Alder Lake and AVX-512 | Travis Downs | 2020/07/13 09:01 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/11 06:54 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/11 08:01 PM |
Alder Lake and AVX-512 | N Owen | 2020/07/12 12:37 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 01:48 AM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 07:13 PM |
Alder Lake and AVX-512 | Travis Downs | 2020/07/13 09:09 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/13 11:42 PM |
Alder Lake and AVX-512 | Doug S | 2020/07/11 11:49 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 01:53 AM |
Alder Lake and AVX-512 | Travis Downs | 2020/07/11 07:03 PM |
Alder Lake and AVX-512 | Veedrac | 2020/07/11 07:43 PM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 01:31 AM |
Alder Lake and AVX-512 | Veedrac | 2020/07/12 04:01 AM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 03:26 PM |
Alder Lake and AVX-512 | Anon3 | 2020/07/12 04:07 PM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 05:39 PM |
Alder Lake and AVX-512 | Veedrac | 2020/07/12 04:21 PM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 05:33 PM |
Alder Lake and AVX-512 | Veedrac | 2020/07/12 05:54 PM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 06:20 PM |
Alder Lake and AVX-512 | David Hess | 2020/07/12 07:32 PM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 08:41 PM |
Alder Lake and AVX-512 | ⚛ | 2020/07/13 04:02 AM |
Alder Lake and AVX-512 | anon2 | 2020/07/13 07:25 PM |
PentiumMMX vs Transmeta's VLIW in hindsight | ⚛ | 2020/07/19 06:16 AM |
PentiumMMX vs Transmeta's VLIW in hindsight | Maynard Handley | 2020/07/19 10:47 AM |
PentiumMMX vs Transmeta's VLIW in hindsight | anon2 | 2020/07/19 03:24 PM |
VLIW, OOO, Pairing, and Fusion | Chester | 2020/07/19 10:16 PM |
Poulson was in-order (NT) | anon2 | 2020/07/20 12:20 AM |
VLIW, OOO, Pairing, and Fusion | Michael S | 2020/07/20 12:48 AM |
Itanium is NOT VLIW | Heikki Kultala | 2020/07/20 02:27 PM |
Itanium is NOT VLIW | Adrian | 2020/07/20 11:03 PM |
Itanium crappiness and EPIC - and could EPIC still have something good in it? | Heikki Kultala | 2020/07/21 03:38 AM |
Itanium crappiness and EPIC - and could EPIC still have something good in it? | anon2 | 2020/07/21 05:03 AM |
Itanium crappiness and EPIC - and could EPIC still have something good in it? | dmcq | 2020/07/21 03:27 PM |
Itanium crappiness and EPIC - and could EPIC still have something good in it? | j | 2020/07/21 08:54 AM |
Itanium crappiness and EPIC - and could EPIC still have something good in it? | Tim McCaffrey | 2020/07/21 10:30 AM |
Itanium crappiness and EPIC - and could EPIC still have something good in it? | Linus Torvalds | 2020/07/21 09:13 AM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | Heikki Kultala | 2020/07/22 12:31 PM |
Turn that on its head? | Ray | 2020/07/22 12:49 PM |
Turn that on its head? | Anon | 2020/07/22 01:53 PM |
Turn that on its head? | Maynard Handley | 2020/07/22 02:37 PM |
Turn that on its head? | anon2 | 2020/07/22 03:32 PM |
Turn that on its head? | anon3 | 2020/07/22 04:45 PM |
Turn that on its head? | Heikki Kultala | 2020/07/23 02:53 AM |
Turn that on its head? | Anon | 2020/07/23 10:20 AM |
Turn that on its head? | Heikki Kultala | 2020/07/23 11:21 AM |
Turn that on its head? | Brett | 2020/07/23 03:26 PM |
Turn that on its head? | Brett | 2020/07/24 04:22 AM |
Bundling OOO entries does this implicitly | David Kanter | 2020/07/23 10:56 AM |
Turn that on its head? | anon | 2020/07/23 11:49 AM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | Maynard Handley | 2020/07/22 02:29 PM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | wumpus | 2020/07/22 03:16 PM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | Doug S | 2020/07/22 10:37 PM |
what Intel would have done | Michael S | 2020/07/23 12:46 AM |
what Intel would have done | Doug S | 2020/07/23 09:52 AM |
what Intel would have done | Anon | 2020/07/23 10:25 AM |
what Intel would have done | Michael S | 2020/07/23 11:23 AM |
what Intel would have done | Montaray Jack | 2020/07/23 06:08 PM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | Heikki Kultala | 2020/07/22 11:47 PM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | wumpus | 2020/07/23 01:46 PM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | Michael S | 2020/07/23 12:56 AM |
Itanium is not synomym of EPIC. Itanium is just the most common EPIC-style architecture | Heikki Kultala | 2020/07/23 02:44 AM |
thanks | Chester | 2020/07/24 03:50 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/11 07:46 PM |
Alder Lake and AVX-512 | never_released | 2020/07/11 08:54 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 02:25 AM |
Alder Lake and AVX-512 | anon2 | 2020/07/12 01:36 AM |
Alder Lake and AVX-512 | Doug S | 2020/07/12 12:01 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 02:41 AM |
Alder Lake and AVX-512 | rwessel | 2020/07/12 10:17 AM |
Alder Lake and AVX-512 | -.- | 2020/08/18 03:24 AM |
Alder Lake and AVX-512 | Travis Downs | 2020/08/18 11:04 PM |
Alder Lake and AVX-512 | Geoff Langdale | 2020/07/11 07:49 PM |
Alder Lake and AVX-512 | anon | 2020/07/11 08:12 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/11 08:33 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 03:00 AM |
Alder Lake and AVX-512 | Jukka Larja | 2020/07/12 08:51 AM |
Alder Lake and AVX-512 | Maynard Handley | 2020/07/12 10:30 AM |
Alder Lake and AVX-512 | Jukka Larja | 2020/07/13 07:43 AM |
Alder Lake and AVX-512 | Montaray Jack | 2020/07/23 07:20 PM |
Alder Lake and AVX-512 | Jukka Larja | 2020/07/24 04:57 AM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/12 11:35 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 12:01 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 12:15 PM |
Alder Lake and AVX-512 | anonymou5 | 2020/07/12 01:50 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 02:31 PM |
Alder Lake and AVX-512 | anonymou5 | 2020/07/12 03:09 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 04:25 PM |
Alder Lake and AVX-512 | anonymou5 | 2020/07/12 08:34 PM |
Alder Lake and AVX-512 | Jose | 2020/07/13 01:35 AM |
Alder Lake and AVX-512 | gallier2 | 2020/07/13 02:11 AM |
Alder Lake and AVX-512 | gallier2 | 2020/07/13 02:01 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/13 11:06 AM |
Alder Lake and AVX-512 | Doug S | 2020/07/13 12:11 PM |
Alder Lake and AVX-512 | Brett | 2020/07/14 02:34 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/14 09:02 AM |
Alder Lake and AVX-512 | Maynard Handley | 2020/07/14 12:40 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/14 12:48 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/15 01:37 AM |
OS X file names normalization | Michael S | 2020/07/15 02:26 AM |
OS X file names normalization | Simon Farnsworth | 2020/07/15 04:16 AM |
OS X file names normalization | Michael S | 2020/07/15 10:51 AM |
OS X file names normalization | Simon Farnsworth | 2020/07/15 12:27 PM |
OS X file names normalization | Doug S | 2020/07/15 10:46 AM |
OS X file names normalization | Michael S | 2020/07/15 11:05 AM |
OS X file names normalization | Linus Torvalds | 2020/07/15 12:58 PM |
OS X file names normalization | Linus Torvalds | 2020/07/15 02:21 PM |
OS X file names normalization | gallier2 | 2020/07/15 11:57 PM |
OS X file names normalization | gallier2 | 2020/07/15 11:44 PM |
OS X file names normalization | Rob Thorpe | 2020/07/15 11:23 AM |
OS X file names normalization | Doug S | 2020/07/15 01:32 PM |
OS X file names normalization | Maynard Handley | 2020/07/15 05:20 PM |
OS X file names normalization | Linus Torvalds | 2020/07/15 08:37 PM |
OS X file names normalization | Anon3 | 2020/07/16 01:43 PM |
OS X file names normalization | Doug S | 2020/07/16 03:38 PM |
OS X file names normalization | Linus Torvalds | 2020/07/17 12:21 AM |
OS X file names normalization | Anon3 | 2020/07/17 02:15 AM |
OS X file names normalization | Jukka Larja | 2020/07/17 06:40 AM |
OS X file names normalization | gallier2 | 2020/07/17 03:19 AM |
OS X file names normalization | Linus Torvalds | 2020/07/17 09:41 AM |
OS X file names normalization | Dummond D. Slow | 2020/07/17 09:54 AM |
OS X file names normalization | Linus Torvalds | 2020/07/17 10:16 AM |
OS X file names normalization | Simon Farnsworth | 2020/07/18 06:12 AM |
OS X file names normalization | Anon3 | 2020/07/17 02:04 AM |
OS X file names normalization | Doug S | 2020/07/17 10:15 AM |
Alder Lake and AVX-512 | Maynard Handley | 2020/07/15 10:32 AM |
File Systems and VC Problems | Rob Thorpe | 2020/07/15 07:24 AM |
vectorization of utf8 | Robert David Graham | 2020/07/13 02:36 PM |
vectorization of utf8 | anon2 | 2020/07/13 05:07 PM |
vectorization of utf8 | Robert David Graham | 2020/07/13 08:36 PM |
vectorization of utf8 | anon2 | 2020/07/13 11:23 PM |
vectorization of utf8 | Maynard Handley | 2020/07/13 10:46 PM |
vectorization of utf8 | Gabriele Svelto | 2020/07/15 03:27 AM |
Alder Lake and AVX-512 | gallier2 | 2020/07/14 01:13 AM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/12 01:29 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 02:08 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/12 06:26 PM |
Alder Lake and AVX-512 | -.- | 2020/07/12 07:11 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/12 07:43 PM |
Alder Lake and AVX-512 | Jukka Larja | 2020/07/13 08:38 AM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/13 10:10 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/13 11:02 AM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/13 11:22 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/13 12:10 PM |
Alder Lake and AVX-512 | Jörn Engel | 2020/07/13 04:03 PM |
Alder Lake and AVX-512 | Jukka Larja | 2020/07/14 06:53 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/11 08:34 PM |
Alder Lake and AVX-512 | Brett | 2020/07/11 09:02 PM |
Alder Lake and AVX-512 | David Hess | 2020/07/13 12:36 PM |
Alder Lake and AVX-512 | anonymou5 | 2020/07/13 01:01 PM |
Alder Lake and AVX-512 | Brett | 2020/07/13 04:19 PM |
Alder Lake and AVX-512 | Geert | 2020/07/11 09:36 PM |
AMD's FPU | Chester | 2020/07/12 02:28 AM |
Is 3|5 lower than 4? | Michael S | 2020/07/12 03:59 AM |
Is 3|5 lower than 4? | Chester | 2020/07/12 05:54 AM |
Alder Lake and AVX-512 | Geoff Langdale | 2020/07/11 11:45 PM |
Alder Lake and AVX-512 | me | 2020/07/12 03:44 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 04:09 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 11:35 AM |
~80% of details are wrong. So what one can expect from conclusions? :( (NT) | Michael S | 2020/07/12 11:57 AM |
~80% of details are wrong. So what one can expect from conclusions? :( | anonymous2 | 2020/07/12 12:50 PM |
Alder Lake and AVX-512 | nobody in particular | 2020/07/12 12:25 PM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 12:37 PM |
Alder Lake and AVX-512 | nobody in particular | 2020/07/12 12:43 PM |
Alder Lake and AVX-512 | me | 2020/07/12 01:32 PM |
Alder Lake and AVX-512 | Maynard Handley | 2020/07/12 08:51 PM |
Alder Lake and AVX-512 | UnmaskedUnderflow | 2020/07/12 12:33 PM |
AVX-512 vs SVE2 | -.- | 2020/07/12 06:22 PM |
AVX-512 vs SVE2 | noko | 2020/07/13 12:12 AM |
AVX-512 vs SVE2 | -.- | 2020/07/13 04:00 AM |
Alder Lake and AVX-512 | Geoff Langdale | 2020/07/12 08:18 PM |
Could you please stop top-posting (NT) | Jukka Larja | 2020/07/13 08:45 AM |
Alder Lake and AVX-512 | Romain Dolbeau | 2020/07/15 01:00 AM |
Alder Lake and AVX-512 | Spiteful Sprites | 2020/07/13 04:59 AM |
Alder Lake and AVX-512 | nobody in particular | 2020/07/13 09:12 AM |
Alder Lake and AVX-512 | Spiteful Sprites | 2020/07/13 04:21 PM |
Alder Lake and AVX-512 | Jouni Osmala | 2020/07/14 02:55 AM |
RISC-V & commercial support (was: Alder Lake and AVX-512) | Romain Dolbeau | 2020/07/15 01:11 AM |
RISC-V & commercial support (was: Alder Lake and AVX-512) | Romain Dolbeau | 2020/07/15 01:13 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/13 11:10 AM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | Romain Dolbeau | 2020/07/14 10:09 AM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | anon | 2020/07/14 10:53 AM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | Romain Dolbeau | 2020/07/14 11:27 AM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | Maynard Handley | 2020/07/14 12:52 PM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | Doug S | 2020/07/14 01:43 PM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | anon | 2020/07/14 03:01 PM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | Linus Torvalds | 2020/07/14 12:00 PM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | Romain Dolbeau | 2020/07/14 11:42 PM |
Configurable cache line size? | Doug S | 2020/07/15 10:56 AM |
Configurable cache line size? | dmcq | 2020/07/15 03:43 PM |
Configurable cache line size? | Romain Dolbeau | 2020/07/15 11:37 PM |
Configurable cache line size? | NoSpammer | 2020/07/16 01:27 AM |
Configurable cache line size? | Pixie | 2020/07/16 10:55 AM |
Configurable cache line size? | Etienne | 2020/07/17 01:03 AM |
Configurable cache line size? | Hugo Décharnes | 2020/07/18 02:11 AM |
Cache line size | Mark Roulo | 2020/07/15 06:10 PM |
Cache line size | anon | 2020/07/15 06:46 PM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | Gabriele Svelto | 2020/07/17 02:30 AM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | dmcq | 2020/07/17 03:34 AM |
AVX-512/SVE & HPC (was: Alder Lake and AVX-512) | zArchJon | 2020/07/17 01:16 PM |
Macro-instructions to the rescue | ⚛ | 2020/07/24 12:56 PM |
Some fundamentals haven't changed | Chester | 2020/07/24 03:59 PM |
Some fundamentals haven't changed | ⚛ | 2020/07/24 04:24 PM |
Some fundamentals haven't changed | dmcq | 2020/07/25 07:58 AM |
Some fundamentals haven't changed | ⚛ | 2020/07/25 11:05 AM |
Some fundamentals haven't changed | Brett | 2020/07/25 02:16 PM |
Some fundamentals haven't changed | Brett | 2020/07/25 02:27 PM |
What belt is. | Heikki Kultala | 2020/07/26 07:49 AM |
What belt is. | Michael S | 2020/07/26 10:00 AM |
What belt is. | Brett | 2020/07/26 11:46 PM |
What belt is. | Michael S | 2020/07/27 12:52 AM |
What belt is. | Brett | 2020/07/27 07:25 AM |
What belt is. | Doug S | 2020/07/27 01:31 PM |
What belt is. | Andrew Clough | 2020/07/28 06:11 AM |
What belt is. | dmcq | 2020/07/28 08:17 AM |
Mill Compiler still MIA? | Geoff Langdale | 2020/07/28 05:04 PM |
If they release the compiler, how they will blame the still-in-development compiler for the lacklust (NT) | Anon | 2020/07/28 05:20 PM |
If they release the compiler, how they will blame the still-in-development compiler for the lacklust | Anon | 2020/07/28 05:20 PM |
Apparently they're busy writing a kernel... | Anon | 2020/07/29 03:03 AM |
Apparently they're busy writing a kernel... | dmcq | 2020/07/29 03:39 AM |
What belt is. | ⚛ | 2020/07/26 11:44 AM |
What belt is. | anonymous2 | 2020/07/26 12:02 PM |
What belt is. | Doug S | 2020/07/26 03:26 PM |
What belt is. | ⚛ | 2020/07/26 04:02 PM |
good | useruser | 2020/07/12 10:06 AM |
Alder Lake and AVX-512 | -.- | 2020/07/11 09:03 PM |
Alder Lake and AVX-512 | -.- | 2020/07/11 09:07 PM |
Alder Lake and AVX-512 | j | 2020/07/13 12:29 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/13 01:12 AM |
Alder Lake and AVX-512 | j | 2020/07/13 02:58 AM |
Alder Lake and AVX-512 | dmcq | 2020/07/13 04:53 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/14 12:57 AM |
Alder Lake and AVX-512 | Maynard Handley | 2020/07/14 10:26 AM |
Alder Lake and AVX-512 | dmcq | 2020/07/14 12:33 PM |
Alder Lake and AVX-512 | dmcq | 2020/07/14 03:43 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/15 12:55 AM |
Alder Lake and AVX-512 | dmcq | 2020/07/15 02:19 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/15 02:34 AM |
Alder Lake and AVX-512 | dmcq | 2020/07/15 03:03 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/15 09:43 AM |
Alder Lake and AVX-512 | dmcq | 2020/07/15 09:54 AM |
Alder Lake and AVX-512 | Michael S | 2020/07/15 11:35 AM |
Alder Lake and AVX-512 | dmcq | 2020/07/15 03:18 PM |
GV100 + POWER9 | Michael S | 2020/07/16 01:17 AM |
GV100 + POWER9 | dmcq | 2020/07/16 08:58 AM |
GV100 + POWER9 | dmcq | 2020/07/16 09:10 AM |
Alder Lake and AVX-512 | dmcq | 2020/07/15 02:48 AM |
Alder Lake and AVX-512 | o | 2020/07/12 03:08 AM |
Alder Lake and AVX-512 | ⚛ | 2020/07/12 11:07 AM |
Alder Lake and AVX-512 | ⚛ | 2020/07/12 11:32 AM |
Alder Lake and AVX-512 | Linus Torvalds | 2020/07/12 11:39 AM |
Alder Lake and AVX-512 | ⚛ | 2020/07/12 12:47 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 01:18 PM |
x87 crap | Heikki Kultala | 2020/07/12 01:30 PM |
x87 crap | Michael S | 2020/07/12 01:37 PM |
x87 crap | Heikki kultala | 2020/07/12 02:11 PM |
x87 crap | Michael S | 2020/07/12 02:50 PM |
Sparc and PA-RISC vs pentium FP performance | Heikki Kultala | 2020/07/13 01:14 AM |
Sparc and PA-RISC vs pentium FP performance | anonymous2 | 2020/07/13 10:48 AM |
Alder Lake and AVX-512 | Doug S | 2020/07/12 03:33 PM |
Alder Lake and AVX-512 | Michael S | 2020/07/12 04:10 PM |
Alder Lake and AVX-512 | David Kanter | 2020/07/12 05:01 PM |
Alder Lake and AVX-512 | anon | 2020/07/12 05:40 PM |
~0% of users do much FP outside of GPUs for games (NT) | anonymous2 | 2020/07/12 05:47 PM |
~0% of users do much FP outside of GPUs for games | Maynard Handley | 2020/07/13 12:26 AM |
not true | Chester | 2020/07/13 12:37 AM |
not true | Michael S | 2020/07/13 01:29 AM |
not true | Chester | 2020/07/13 01:59 AM |
not true | anonymous2 | 2020/07/13 10:32 AM |
not true | Maynard Handley | 2020/07/13 02:30 PM |
not true | Chester | 2020/07/14 05:47 AM |
not true | Doug S | 2020/07/13 12:30 PM |
not true | Anon | 2020/07/13 01:16 PM |
not true | Maynard Handley | 2020/07/13 02:39 PM |
not true | Maynard Handley | 2020/07/13 02:38 PM |
not true | Linus Torvalds | 2020/07/13 11:27 AM |
not true | Dummond D. Slow | 2020/07/13 02:10 PM |
not true | Maynard Handley | 2020/07/13 02:49 PM |
not true | Dummond D. Slow | 2020/07/13 03:38 PM |
not true (about FP, not avx-512) | Chester | 2020/07/17 10:37 AM |
Alder Lake and AVX-512 | Travis Downs | 2020/07/11 06:45 PM |
Alder Lake and AVX-512 | -.- | 2020/07/11 06:57 PM |
Alder Lake and AVX-512 | -.- | 2020/07/12 04:26 PM |