RFR: 8255959: Timeouts in VectorConversion tests

[Martin Doerr]

On Fri, 6 Nov 2020 00:59:56 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> At the moment, neither PPC nor s390 support any conversion intrinsics. Modern s390 (or 
>> z/Architecture to be more precise) machines have vector instructions, but nobody implemented them in hotspot. So s390 uses the regular 8 Byte registers for vectors. PPC only uses 16 Byte vectors on modern hardware (8 Byte on older hardware).
>> 
>> Default timeout is 1200 and I found out that 50% more makes the tests happy on all our machines.
>> 
>> We could do an experiment, but I'm not familiar with the test.
>
> Perhaps the following patch might help.
> 
> Still for say 512 conversion test on my mac that has no AVX512 support the test runs (including compilation) in about 60s. With the patch it reduces to about 40s.
> 
> If you run jtreg in verbose mode, `-va` it should output individual test times. Perhaps some are taking longer than others?
> 
> diff --git a/test/jdk/jdk/incubator/vector/AbstractVectorConversionTest.java b/test/jdk/jdk/incubator/vector/AbstractVectorConversionTest.java
> index d1303bfd295..1754af2110a 100644
> --- a/test/jdk/jdk/incubator/vector/AbstractVectorConversionTest.java
> +++ b/test/jdk/jdk/incubator/vector/AbstractVectorConversionTest.java
> @@ -551,7 +551,8 @@ abstract class AbstractVectorConversionTest {
>        int m = Math.max(dst_species_len,src_species_len) / Math.min(src_species_len,dst_species_len);
>  
>        int [] parts = getPartsArray(m, is_contracting_conv);
> -      for (int ic = 0; ic < INVOC_COUNT; ic++) {
> +      int count = invocationCount(INVOC_COUNT, SPECIES, OSPECIES);
> +      for (int ic = 0; ic < count; ic++) {
>           for (int i=0, j=0; i < in_len; i += src_species_len, j+= dst_species_len) {
>              int part = parts[i % parts.length];
>              var av = Vector64ConversionTests.<I>vectorFactory(unboxed_a, i, SPECIES);
> @@ -592,7 +593,8 @@ abstract class AbstractVectorConversionTest {
>        int m = Math.max(dst_vector_size,src_vector_size) / Math.min(dst_vector_size, src_vector_size);
>  
>        int [] parts = getPartsArray(m, is_contracting_conv);
> -      for (int ic = 0; ic < INVOC_COUNT; ic++) {
> +      int count = invocationCount(INVOC_COUNT, SPECIES, OSPECIES);
> +      for (int ic = 0; ic < count; ic++) {
>          for (int i = 0, j=0; i < in_len; i += src_vector_lane_cnt, j+= dst_vector_lane_cnt) {
>            int part = parts[i % parts.length];
>            var av = Vector64ConversionTests.<I>vectorFactory(unboxed_a, i, SPECIES);
> @@ -609,4 +611,15 @@ abstract class AbstractVectorConversionTest {
>        }
>        assertResultsEquals(boxed_res, boxed_ref, dst_vector_lane_cnt);
>      }
> +
> +    static int invocationCount(int c, VectorSpecies<?>... species) {
> +        return Arrays.asList(species).stream().allMatch(AbstractVectorConversionTest::leqPreferred)
> +                ? c
> +                : Math.min(c, c / 100);
> +    }
> +
> +    static boolean leqPreferred(VectorSpecies<?> species) {
> +        VectorSpecies<?> preferred = VectorSpecies.ofPreferred(species.elementType());
> +        return species.length() <= preferred.length();
> +    }
>  }

Hi Paul,
your proposal helps a bit. Test has passed on some machines, but not on all ones.
"contracting_conversion_scalar" is still very prominent on PPC. Do we need to implement intrinsics to get this fast?

In addition, there's another timeout in AddTest.java on x86:
https://bugs.openjdk.java.net/browse/JDK-8255915

So it seems like there's more work to do.
Suggestions?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1079