By: anon1 (anon.delete@this.gmail.com), May 18, 2022 1:15 am
Room: Moderated Discussions
Michael S (already5chosen.delete@this.yahoo.com) on May 17, 2022 6:28 am wrote:
> anon1 (anon.delete@this.anon.com) on May 17, 2022 4:47 am wrote:
>
> > AVX512 is not vector-agnostic
>
> Which, from point of view of compiler developers, is rather big simplification.
What would make you say that? SVE has instructions that directly support looping over arbitrary vector sizes with easily customisable strides and automatic scaling. Seems like a more straightforward thing to support from a compiler writer perspective than something like AVX512. You can even vectorise data-dependent code thanks to fault-tolerant loads (which I don't exist all on AVX512).
And sure, knowing the register size can make it easier to generate optimal code, but that's not what we are after here. We are talking about versatility. And I'd say if a vector-agnostic approach costs you, say, 5% of potential performance, but simplifies deployment and allows vectorisation in more places, it's well worth the tradeoff.
> anon1 (anon.delete@this.anon.com) on May 17, 2022 4:47 am wrote:
>
> > AVX512 is not vector-agnostic
>
> Which, from point of view of compiler developers, is rather big simplification.
What would make you say that? SVE has instructions that directly support looping over arbitrary vector sizes with easily customisable strides and automatic scaling. Seems like a more straightforward thing to support from a compiler writer perspective than something like AVX512. You can even vectorise data-dependent code thanks to fault-tolerant loads (which I don't exist all on AVX512).
And sure, knowing the register size can make it easier to generate optimal code, but that's not what we are after here. We are talking about versatility. And I'd say if a vector-agnostic approach costs you, say, 5% of potential performance, but simplifies deployment and allows vectorisation in more places, it's well worth the tradeoff.
