[Vector] RFR: reshape, resize, rebracket, cast

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Thu Jan 24 02:47:32 UTC 2019


Kishor,

> I have new webrev which modifies the tests to use the new methods - http://cr.openjdk.java.net/~kkharbas/vector-api/webrev-reshape_etc.01
> Incremental webrev - http://cr.openjdk.java.net/~kkharbas/vector-api/webrev-reshape_etc.01_to_base

It looks good to me and aligned with what was discussed previously.

Please, also update users:

$ egrep -r -e resize -e reshape -e rebracket -I -l 
test/jdk/jdk/incubator/vector
test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/jdk/incubator/vector/AbstractVectorBenchmark.java
test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/jdk/incubator/vector/PopulationCount.java
test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/jdk/incubator/vector/Rearrange.java
test/jdk/jdk/incubator/vector/benchmark/src/main/java/benchmark/jdk/incubator/vector/SumOfUnsignedBytes.java
test/jdk/jdk/incubator/vector/VectorHash.java
test/jdk/jdk/incubator/vector/VectorReshapeTests.java
test/jdk/jdk/incubator/vector/CovarOverrideTest.java

> New methods:
>      class Vector<E> {
> 
>          /* E x S  ->  E' x S' */
>          /* was reshape() and rebracket() before */
>          Vector<F> reinterpret(Species<F> s)
> 
>          /* E x S  ->  E x S' */
>          /* was resize() before */
>          Vector<E> reshape(Species<E> s)
>      
>          /* E x S  ->  E' x S' */
>          Vector<F> cast(Species<F> s)
>      }

As a next step, I'd like to question the presence of `reshape`.

It seemed reasonable to keep it at the time discussion happened, but 
based on my recent experience with the API, `reinterpret`/`cast` look 
more than enough unless truncation/padding is forbidden on 
`reinterpret`/`cast` and exposed through a dedicated API point (`reshape`).

There's one nice thing about `reshape`: it preserves element type, so 
there's no need to cast result back to specialized vector type (e.g., 
Vector<Integer> => IntVector). But `reinterpret`/`cast` suffer from that 
and it would be nice to provide a workaround/solution.

For example, how about introducing Vector.toIntVector() et al which 
serve as assertions about vector shapes backed by runtime checks?

   IntVector   v = ... ; // Int128Vector
   LongSpecies s = ... ; // Long256Species
   LongVector vl1 = (LongVector)v.cast(s);
   LongVector = v.cast(s).toLongVector();

Should work rather well for fluent-style code.

Best regards,
Vladimir Ivanov

>> -----Original Message-----
>> From: Viswanathan, Sandhya
>> Sent: Wednesday, January 16, 2019 12:33 PM
>> To: Kharbas, Kishor <kishor.kharbas at intel.com>; panama-
>> dev at openjdk.java.net; Brian Goetz <brian.goetz at oracle.com>; John Rose
>> <john.r.rose at oracle.com>; Vladimir Ivanov
>> <vladimir.x.ivanov at oracle.com>
>> Cc: joe.darcy at oracle.com
>> Subject: RE: [Vector] RFR: reshape, resize, rebracket, cast
>>
>>
>> Adding Brian, John, Joe and Vladimir to the thread. Please do give your
>> feedback on the patch from Kishor
>> (http://cr.openjdk.java.net/~kkharbas/vector-api/webrev-reshape_etc)
>> implementing the reinterpret API as suggested by Brian and Vladimir in
>> thread https://mail.openjdk.java.net/pipermail/panama-dev/2018-
>> December/003365.html.
>>
>> Best Regards,
>> Sandhya
>>
>>
>> -----Original Message-----
>> From: panama-dev [mailto:panama-dev-bounces at openjdk.java.net] On
>> Behalf Of Kharbas, Kishor
>> Sent: Wednesday, January 16, 2019 12:20 AM
>> To: panama-dev at openjdk.java.net
>> Subject: [Vector] RFR: reshape, resize, rebracket, cast
>>
>> Hi,
>> I have a patch which refactors the above methods as discussed in this thread
>> - https://mail.openjdk.java.net/pipermail/panama-dev/2018-
>> December/003365.html.
>>
>> Please review the changes at - http://cr.openjdk.java.net/~kkharbas/vector-
>> api/webrev-reshape_etc
>> Generation of intrinsics and correct vector boxing elimination have been
>> verified. In the next patch I will add changes to jtreg tests.
>>
>> I wanted to bring forth one small issue(possibly) which programmers might
>> face with this change -
>>
>> We provide specialized types like IntVector, FloatVector, etc for users to
>> define their vectors and they would be able to write code like this with
>> previous methods,
>>      FloatVector float256 = SPECIES_FLOAT256.cast(int256); Here FloatSpecies
>> would always return FloatVector.
>>
>> However with this change, since cast() is defined on a vector and takes
>> species of a generic type, it cannot return a specialized Vector like IntVector
>> or FloatVector. User has to explicitly cast the return vector from Vector<T>
>> to specialized Vector or use a generic vector of corresponding element type.
>> For example,
>>      FloatVector float256 = (FloatVector)int256.cast(SPECIES_FLOAT256);
>>    or
>>      Vector<Float> float256 = int256.cast(SPECIES_FLOAT256);
>>
>> I am not sure if this is even a problem, but I thought its worth mentioning.
>>
>> Thanks
>> Kishor


More information about the panama-dev mailing list