[Vector API] Question about SPECIES_64 for DoubleVector and LongVector(Internet mail)

[jiefu(傅杰)]

Hi Paul,
 
Thanks for your reply.
Okay, let's try to optimize them.

After more investigation, I found Double64Vector can be benefitial for some cases.
For example, I used it to implement a fast_acos(x) like this:
------------------------------------
    static double fast_acos(double i) {
        double[] t = new double[1];
        t[0] = i;
        DoubleVector av = DoubleVector.fromArray(SPECIES64, t, 0);
        av.lanewise(VectorOperators.ACOS).intoArray(t, 0);
        return t[0];
    }
------------------------------------

It seems much faster than Math.acos if svml is enabled for double64 [1].

Thanks.
Best regards,
Jie


[1] https://github.com/openjdk/panama-vector/pull/39


On 2021/2/23, 4:14 AM, "Paul Sandoz" <paul.sandoz at oracle.com> wrote:

    Hi Jie,
    
    I think they are there in part for uniformity, and in part because it was marginally easier to include them rather than exclude them. Algorithmically they might prove useful if operating generically over species. IMHO it's too early to decide that we don’t need ‘em. Since we are incubating we have flexibility to decide later on.
    
    Ideally they should just map to the appropriate non-vector hardware register with scalar instructions. An argument for removal could be that there is a higher cost to optimally support them.
    
    Paul.
    
    > On Feb 19, 2021, at 12:35 AM, jiefu(傅杰) <jiefu at tencent.com> wrote:
    > 
    > Hi all,
    > 
    > According to the JVM specification, both double and long are 64-bit.
    > So Double64Vector and Long64Vector are vectors which contain just 1 lane only.
    > 
    > But none of the 1-lane vectors would be get vectorized in HotSpot.
    > People who use Double64Vector and Long64Vector may encounter performance drop of their programs.
    > 
    > I didn't see any benefit of SPECIES_64 for DoubleVector and LongVector.
    > So why we provide them for programmers?
    > 
    > Thanks.
    > Best regards,
    > Jie