[Vector API] Missing a way to know which operators are preferred

[Eric Liu]

Hi Michaël,

Thanks for you feedback.

> it's currently possible to know for a given type which VectorSpecies is preferred
> on the current platform.

I think the preferred species is usually the largest available species.

> an application developer would want to know which Operator will be preferred (i.e.
> backed by an appropriate SIMD instruction) on a targeted platform. Similarly, a
> library developer would want to be able to pick at runtime between different
> implementations of an algorithm.

Usually, the larger species would have better performance since more data could be
handled in just one time. That’s true that it’s architecture dependent. Even though
some instructions have low throughput in a larger size, a well implemented backend
should choose the optimal instructions and should not trouble the Java developers.

Have you ever found a case that has better performance but with a smaller species on
any platform? If there is, perhaps some micro-architecture optimizations should be done.


- Eric

From: panama-dev <panama-dev-retn at openjdk.org> On Behalf Of Michaël Figuière
Sent: Saturday, October 15, 2022 1:56 AM
To: panama-dev at openjdk.org
Subject: [Vector API] Missing a way to know which operators are preferred

Hello,

A suggestion based on my small experience with the Vector API: it's currently possible to know for
a given type which VectorSpecies is preferred on the current platform, but it's not the case for
Operator. As the Vector API is all about improved performance, an application developer would
want to know which Operator will be preferred (i.e. backed by an appropriate SIMD instruction) on
a targeted platform. Similarly, a library developer would want to be able to pick at runtime between
different implementations of an algorithm.

That could look like:

boolean VectorOperators.Operator#isPreferredWith(VectorSpecies)

I haven't looked at the implementation details but I assume that it would be doable as the Operator
actual implementation is already picked based on CPU instructions availability.

Thanks,
Michaël
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20221017/8c115daf/attachment-0001.htm>