Romain Dolbeau (romain.delete@this.dolbeau.org) on July 14, 2020 11:27 am wrote:
> anon (anon.delete@this.anontech.anon) on July 14, 2020 10:53 am wrote:
> > But, the AVX512 design is by definition much more tied to
> > implementation than SVE(2). So it's not entirely unfair.
>
> I don't see why. The two current implementations of AVX512F+some extensions, KNL and SKX, have
> vastly different behavior. AVX512 only says registers are 512 bits wide. SVE doesn't, it just
> says a multiple of 128 (up to 2048). Beyond that, the implementation details are open for both
> (latency, throughput, etc.). Including the width of the actual functional units.
>
> > I think it's perfectly reasonable to expect processors to be more tailored for their end markets.
>
> Indeed. But I think most people underestimate how many Xeons end up doing FP work. I agree with you
> only a small fraction of users care, but they buy a lot of systems. And clearly, all current high-performance
> silicon designers thought it mattered (at least until quite recently): Intel added AVX-512 to mainstream
> Xeon a while ago, and AMD doubled flops/cycle between Naples and Rome. The ThunderX2 isn't king of
> that particular hill, but it's not completely terrible, either. A64FX is matching KNL and SKX on a
> per-cycle basis, and was designed specifically for that market - and with just 32 GiB of HBM memory
> on-board and the built-in TOFU, is probably only suitable for that market.
>
> I suspect the cost of adding that level of performance (even if it goes unused) to an otherwise
> general-purpose design is not high enough to forgo the business of FP-heavy workloads for
> the sake of other markets. Or so it would appear from the designers' behavior...
>
> Situation might change, though. The Arm-based designers may target narrower
> markets at first, so may have different trade-offs, one way or the other.
>
> > Right, but the difference being that you might expect it to be reasonable for SVE2 to (eventually)
> > end up everywhere, whereas a fixed 512-bit vector ISA may just probably not be optimal everywhere.
>
> Forcing 512-bits is clearly an issue for the smaller designs, but that's for storage/datapath. Nothing forces
> an implementer to use 512-bits wide FPUs. You could implement AVX-512 with a single DP FMA, with each instruction
> taking 8 cycles to fully issue. It probably fit the bill of many non-FP workload (and perhaps even a non-trivial
> fraction of FP workload would get decent performance as they will be latency/bandwidth bound on memory or caches
> rather than on the FP units anyway, that's why Naples/Rome sold quite well: more bandwidth!).
>
> Obviously SVE doesn't have that particular issue, that's true. Whether this will translate into
> a market advantage is less obvious; why would anyone rewrite 128-bits NEON code to SVE scalable
> code if most SVE implementations are 128-bits and offers next to no benefits performance-wise?

You still get some SVE win even from 128b implementation. Smaller code because no epilog stuff. Use of mask registers.
Like all these things it's VERY dependent on what benchmarks you use and how you choose to aggregate the numbers, but an overall win of 20% from the SVE ISA compared to NEON using essentially the same underlying hardware is the number I have seen.