By: Gabriele Svelto (gabriele.svelto.delete@this.gmail.com), November 8, 2019 7:03 am
Room: Moderated Discussions
Montaray Jack (none.delete@this.none.org) on November 8, 2019 1:38 am wrote:
> I think they want to have all the SIMD functionality encapsulated in the Vector extension. Seems a reasonable
> argument, why have multiple ops for different bit widths, when you can just send it all to the vector unit.
> Although, I don't know if they've nailed down the vector extension yet, I haven't checked since this last
> spring. Hwacha seemed like it could make a beast of a machine, provided they could keep it fed.
One significant change that has been added to the vector extension proposal recently is being able to query the number of lanes in the physical implementation. The rationale behind it is being able to generically implement algorithms using cross-lane operations like permutations.
However besides the V (Vector) extension there's also the P (packed-SIMD) one. You can find details about it in this recent presentation. It's more geared towards DSP-type application and embedded use-cases.
> I think they want to have all the SIMD functionality encapsulated in the Vector extension. Seems a reasonable
> argument, why have multiple ops for different bit widths, when you can just send it all to the vector unit.
> Although, I don't know if they've nailed down the vector extension yet, I haven't checked since this last
> spring. Hwacha seemed like it could make a beast of a machine, provided they could keep it fed.
One significant change that has been added to the vector extension proposal recently is being able to query the number of lanes in the physical implementation. The rationale behind it is being able to generically implement algorithms using cross-lane operations like permutations.
However besides the V (Vector) extension there's also the P (packed-SIMD) one. You can find details about it in this recent presentation. It's more geared towards DSP-type application and embedded use-cases.