Adrian (a.delete@this.acm.org) on August 2, 2018 11:46 pm wrote:
> AM (myname4rwt.delete@this.jee-male.com) on August 2, 2018 11:46 am wrote:
> >
> > Right, it's time for obituary to whole LRB lineage. Rumours were circulating back at last year's SC that
> > whole family got the knife, and this recently leaked roadmap I saw at AT just proved them true.
> >
> > That being said, I have some doubts that although shown on the roadmap, Knights Mill will become a
> > product in a usual sense of the word -- Intel ark-launched a few SKUs last year, but they neither
> > made it to the price list, nor became listed on its site of Xeon Phi family to this day, so I think
> > Intel might have pending shipping commitments to customer[s] who placed preorders, and that's it.
>
>
> While the kind of implementation originally envisioned for the Larrabee instruction
> set is very dead at this point, the Larrabee instructions are quite good, so I hope
> to see them in more processors and especially in some future AMD processors.
>
>
> I dislike very much the fact that the Larrabee New Instructions are named now AVX-512,
> because this looks like a rewriting of the history to show Intel in a better light.
>
> In my opinion, AVX is the ugly instruction set given by Intel to us at a time
> when they could have given us the much better Larrabee instructions. AVX should
> have never existed, so I do not like to see that name applied to Larrabee.
>
>
> The Larrabee instructions preceded Sandy Bridge by a few years. Sandy Bridge could have implemented
> them easily (of course, not with 2 * 512 bit FMA per cycle, but with 2 * 128 or 1 * 256 and maybe with
> slow implementations for scatter & gather and maybe omitting a few graphics oriented instructions,
> like the transcendental function approximations that have also been omitted in Skylake Server).
>
>
> Instead of doing that, Intel, like always in its history, introduced
> the good features only one-by-one, every few years.
>
>
> Yes, of course I agree that this was the best way for increasing Intel's profits,
> but that does not mean that I despise this kind of strategy any less.
>
>

Since LRBNI encoding was incompatible with existing ISA and compatibility was a major goal of KNL. they had to change an encoding.
As long as they changed the encoding, they had to change the name, preferably to something radically different, in order to minimize confusion.
Any different name would do, but name AVX512 carries a little of additional information like "compatible with AVX", "Intel official wider version of mainstream SIMD".
And in fact it does share four important characteristics with AVX:
1. Arithmetic instructions have one destination which is always register. That applies to all Intel FP/SIMD since x87.
2. Majority of arithmetic instruction have two sources neither of which has to be the same as destination. That does not apply to the previous Intel FP/SIMD.
3. Up to one source operand can come from memory. Again, that applies to all Intel FP/SIMD since x87, but differ from majority of non-Intel SIMD world.
4. Lower 128-bit of registers are mapped into XMM registers.

Of course, there are major differences as well (32 registers, FMA4, masks), but IMHO similarities are sufficient to justify the name.

As to merits, my opinion is opposite, too. I like AVX/AVX2. Yes, tools for 128-bit lane crossing are painfully weak, but it was possible to improve them in evolutionary manner (of course, calling improvements AVX3 and then AVX3.1, etc :-) ). But it's quite natural expansion, improvement, sanitizing of SSE.
And encoding is as dense as possible under circumstances of backward compatibility.

I don't like AVX512. At all. And I blame LRB/KNC, mostly weak instruction decoders of LRB and original 3D grahics orientation for most of shortcomings.

My main complaints:
1. Too many software-visible vector registers (=encode density suffers)
2. They are too narrow. 1024 bits is a sane minimum width for vector registers. 4096-bit is a sane (and traditional) maximum.
3. Vector load-op is a misfeature. Itt may be (if compiler did it right, which happens rarely) helps unbalance uArchs that should have never been created. It never not help good uArchs, but unnecessary complicates both HW and compilers.
4. "Throughput engine" (and everything above 256-bit is definitely throughput) should be separated from "latency engine" (scalar FP) in software-visible manner. I.e. no overlap of register files. Overlap is a new mistake of AVX512, LRBNI did it correctly.

I started this tune here, or may be even earlier, in this very thread, and repeated myself so many times that it became boring.