By: Andrey (andrey.semashev.delete@this.gmail.com), September 21, 2021 5:25 pm
Room: Moderated Discussions
-.- (blarg.delete@this.mailinator.com) on September 21, 2021 4:35 pm wrote:
> Michael S (already5chosen.delete@this.yahoo.com) on September 21, 2021 10:23 am wrote:
> > Those that want 70-80% utilization would have to target actual width anyway.
> > Or use higher-level frameworks and let their code generators to target actual width.
>
> That's definitely not how ARM is promoting SVE be used, but assuming your suggestions are true,
> how would you approach alignment on a machine with 384-bit vectors? Or one with 640-bit vectors?
I would think, such an implementation is unrealistic, unless the underlying memory transfer unit (e.g. a cache line) is a multiple of 48 (for 384-bit vectors) or 80 (for 640-bit), or alignment is entirely irrelevant (which is unrealistic in its own right). There is no sense in designing an actual hardware where the vector size does not work well with other subsystems, memory subsystem in particular.
> Michael S (already5chosen.delete@this.yahoo.com) on September 21, 2021 10:23 am wrote:
> > Those that want 70-80% utilization would have to target actual width anyway.
> > Or use higher-level frameworks and let their code generators to target actual width.
>
> That's definitely not how ARM is promoting SVE be used, but assuming your suggestions are true,
> how would you approach alignment on a machine with 384-bit vectors? Or one with 640-bit vectors?
I would think, such an implementation is unrealistic, unless the underlying memory transfer unit (e.g. a cache line) is a multiple of 48 (for 384-bit vectors) or 80 (for 640-bit), or alignment is entirely irrelevant (which is unrealistic in its own right). There is no sense in designing an actual hardware where the vector size does not work well with other subsystems, memory subsystem in particular.