Geert (boschg.delete@this.mac.com) on July 11, 2020 9:36 pm wrote:
> Linus Torvalds (torvalds.delete@this.linux-foundation.org) on July 11, 2020 8:34 pm wrote:
> > Geoff Langdale (geoff.langdale.delete@this.gmail.com) on July 11, 2020 7:49 pm wrote:
> > >
> > > But we have some SIMD-based table lookup
> > > stuff that's way faster than the integer equivalent both
> > > because you're doing a lot of stuff at once, but you're
> > > also doing stuff where there's no integer equivalent (there's no PSHUFB for a GPR register).
> >
> > Yeah, and we might even use some of it. We have places where
> > we do "vectorization" by hand and use integer registers
> > to hold as many bytes as possible, and look for '/' or
> > the terminating NUL byte (obviously I'm talking about
> > filename copies) and create a hash of the result at the same time, one (integer) word at a time.
> >
> > We could possibly even have an AVX512 version.
> >
> > If it was available, and if it didn't tank performance due to frequency issues.
> >
> > But it isn't, and it does.
> >
> > Fragmentation kills your market. The fact is, AVX512 isn't
> > worth it, because it's not reliably enough there.
> > And I don't think it's reasonably ever going to be, because it was never designed to work on low end.
> >
> > With a new not-even-released-yet CPU's not supporting it being a case in point.
> >
> > And that makes AVX512 actively bad. It was literally designed not to be used
> > in any generic code, and is basically only useful for "hey, we have this kernel
> > of code that is so hot that we'll just create five different versions of it.
> >
> > What part of that is hard to understand? It sure seems to be something Intel cannot
> > get its head around, since Intel keeps making that mistake over and over again.
>
> This seems to be the common theme of FP improvements: yes there are some workloads that are very
> (statically) predictable and possible to schedule/vectorize ahead of time: the entire lie that Explicit
> Parallel Instruction Computing (Itanium) was based on. Most interesting real life workloads (say running
> database queries, compiling code) are far more data-driven and are not helped at all. Sure, some SPEC
> benchmarks (but, notably, not gcc) might improve, yet few actual workloads do.
>
> AMD seems to once again be focused on what matters (single thread integer performance,
> total integer throughput with passable FP), while Intel's goofing off on fanciful side-projects
> like iAPX 432, i860, IA64 and now AVX512. Once in a while they go back to basics and
> do great work, but they sure seem to need competition to focus.
>
> -Geert

Intel and AMD have similar focus on general single threaded performance.

But with FP, I think AMD focuses more on general FP perf. They have wider FP dispatch (2x256b FADD + 2x256b FMUL/FMA), with lower fadd/fmul latency than Intel. AMD's gonna do better on any FP workload that's not dominated by FMA or AVX512, which is most things.

So AMD has way more than "passable" FP. It's actually better than Skylake FP in many cases.