[vector] ARM SVE

[Paul Sandoz]

Hi,

Adam pointed me to this paper that gives a good overview of the ARM Scalable Vector Extension:

  https://alastairreid.github.io/papers/IEEE_Micro/

This nudged me to think about how this might affect the Vector API.

In general it need not have much impact. With SVE there is one shape, but it’s type need not be exposed nor need it express size explicitly. We already have on Vector:

  static <E> Vector.Species<E, ?> preferredSpeciesInstance(Class<E> c) {

The JVM is well positioned to take advantage for both x86 and ARM SVE in this respect given it’s dynamic nature.

For SVE It makes less sense to refer to explicit shapes we currently have now, the implementations are far less useful for any cross x86/ARM CPU platform code, and in general the guidance is where possible to code algorithms in a shape agnostic manner.

Might it be useful to expose such a shape explicitly as a type, such as Shapes.SPreferred? does this imply in the long run that shape is not required as the sweet spot is shape agnostic code?

I suspect for the latter question it might be too early to answer properly. For the former question it seems quite possible to expose such a shape if more preferable to using the wild card.

For shape agnostic code i think we will require some helper methods to manage the tail of elements that do full up to the preferred vector size. SVE has some interesting instructions for managing this aspect and masks (termed predicates) are fundamental to this rather than optional as in AVX. This might affect the efficiency of code produced on a SVE platform. We might need to explore functional loopy code if we can side-step the profile polution (i.e. version the generated loop methods per the vector kernels). SVE also has interesting support for data dependent loops where a vector can be loaded where some lanes silently fault until accessed (speculative access [*]).

Paul.

[*] Although this makes me nervous given the recent exploits.