Vector API Latest Draft Spec

[Paul Sandoz]

> On 14 Jul 2017, at 13:20, John Rose <john.r.rose at oracle.com> wrote:
> 
> On Jul 14, 2017, at 12:51 PM, Graves, Ian L <ian.l.graves at intel.com <mailto:ian.l.graves at intel.com>> wrote:
>> 
>>> 2) I was pondering about masks and wondering whether Vector etc should
>>> be parameterised by lane rather than bits. API-wise this is more appealing
>>> when pushing/pulling from element sources as its more obvious what the
>>> quantities are. Masks are more easily usable across vector types. However
>>> optimisation-wise this may become more tricky since a mask consisting of 8
>>> lanes could be 8 bytes packed into 128 bits, or 8 ints packed into 512 bits (this
>>> might work on AVX512 but there are likely other examples on AVX2 where
>>> the register sizes don’t correspond). An alternative is to support a cast, which
>>> would be optimal for cases where the lane and element bit size are the same
>>> (namely transforming between Float/Int and Double/Long).
>>> My inclination would be to explore the lane declaring route, as long as we are
>>> confident the JIT can optimize. Note that generics help here but HotSpot still
>>> presumably has to do checks when compiling since raw types can be used.
>>> 
>> 
>> … When I experiemented with Lane vs Bit-size, I ran into the most pain
>> around casting.  Casting with a lane count parameter puts you into an
>> undefined space.  When recasting to a Vector of a specific shape, you
>> have the knowledge that the shape is unchanged by the cast.  This
>> isn't the case with lane counts. Some casts will shorten or lengthen
>> your vector's element count.  If you're parameterizing by lane number,
>> you would have to loosen the constraint on the lane parameter in these
>> operations or strengthen the assumptions about lane counts in the
>> casting operations.
> 
> 
> From the user point of view, bit-count is almost always uninteresting,
> so it would seem to be a slam-dunk to reformulate the API to emphasize
> lane count instead.  I went back and forth on this in my mind the first
> time around, and realized that when I was coding with vectors (using
> gcc and immintrin.h) I had to keep bit-size (aka register type) foremost
> in mind, even when I wanted to deal only with lane count.

Thanks, very enlightening, at this level of the API shape makes a lot of sense, and resolving API issues with Mask using lanes seems a bit like the tail wagging the dog.

Paul.