[vector] reshape/cast using species

[Paul Sandoz]

> On Feb 27, 2018, at 8:47 PM, John Rose <john.r.rose at oracle.com> wrote:
> 
> On Feb 27, 2018, at 5:03 PM, Paul Sandoz <paul.sandoz at oracle.com <mailto:paul.sandoz at oracle.com>> wrote:
>> 
>> Hi,
>> 
>> I think it makes more sense to move the reshape and cast functionality from Vector to species, and then to preserve the fluent nature of the API add methods to Vector that accept a species and defer to the species method. Same applies to Mask and Shuffle.
>> 
>>  http://cr.openjdk.java.net/~psandoz/panama/species-reshape-cast/webrev/index.html <http://cr.openjdk.java.net/~psandoz/panama/species-reshape-cast/webrev/index.html>
> 
> This looks good.  You are removing dynamic calls to the factory/registry method
> Vector.speciesInstance, and rooting the computation in constant species.
> 
> Eventually we might have a way to express constant expressions sort of like
> C++ constexpr, and that might make us add more places where species
> constants can be written, and even dynamically derived.  But putting them
> on static finals is a known-good way to make them available to the user
> and scrutable to the JIT.
> 

Yes.


> A couple more observations:
> 
> The newly placed Species.cast operation has a decision chain on the
> target lane type (byte, long, float, etc.).  Maybe this can be refactored
> at some point to a dispatch on a species subtype, which "knows"
> which loop to execute?
> 

This pair-wise conversion is awkward. I sense some MethodHandle mechanism might help. I think the effort we put in this will depend on what can be made intrinsic.

Also, I am unsure what is possible via AVX, which may also influence if we provide a Mask or Shuffle variant for the case of element bit size expansion and lane-wise reduction (e.g. going from 64 packed bytes -> 16 packed ints).


> I see there are ByteBuffer.allocate calls floating around.  I guess these
> get intrinsified away, so it's not an issue, but I have to ask

Eventually i expect that to be the case, these will be intrinsic for hardware supported shapes hence why i did not put much effort into this method right now. We could go deeper into the concrete implementations and use Unsafe copying of the bytes from the source to destination array. We could reliably operate on Java arrays if the represent was always byte[] rather than the corresponding primitive array for the element type. For the reshape operation we need to preserve the bits.

Paul.

> :  Is there
> a more direct way to do it, of working with plain Java arrays?  (Had
> to ask.)
> 
> Good work!
> 
> — John
> 
>> 
>> 
>> I left some commented out methods that are intrinsic as a reminder this needs to be looked at:
>> 
>> 139 //    //Costless vector cast.  Bit-wise contents preserved
>> 140 //    @HotSpotIntrinsicCandidate
>> 141 //    default <F> Vector<F, S> rebracket(Class<F> type) { return reshape(type, shape());}
>> 142 
>> 
>> 468 //#if[float]
>> 469 //    @HotSpotIntrinsicCandidate
>> 470 //#end[float]
>> 471 //    @Override
>> 472 //    public <F> Vector<F,S> cast(Class<F> type) {
>> 473 //        return cast(type, shape());
>> 474 //    }
>> 
>> I’ll need some guidance with respect preserving hotspot intrinsic behavior for the newly added methods on species.
>> 
>> I’ll add some combo test later.
>> 
>> Thanks,
>> Paul.
>