VectorAPI Testing Infrastructure custom loop trip count

[Paul Sandoz]

> On Apr 3, 2018, at 7:35 AM, Halimi, Jean-Philippe <jean-philippe.halimi at intel.com> wrote:
> 
> I agree that we might want to focalize the stress on the compute kernel itself. Doing so involves re-assigning values tested in the assert method.

   9         $type$[] a = null;
  10         $type$[] b = null;
  11         $type$[] r = null;
  12         boolean[] mask = null;
  13         for (int ic = 0; ic < INVOC_COUNT; ic++) {
  14             a = fa.apply(SPECIES.length());
  15             b = fb.apply(SPECIES.length());
  16             r = new $type$[a.length];
  17             mask = fm.apply(SPECIES.length());

Why don’t you move the allocations out of the invocation loop as well? 

The inputs are never modified and the result will just get overwritten, it should not matter what its prior contents were. 

We are assuming that storing into the array works correctly (e.g. no weird bug eliding stores) and we should have separate tests focused on loads/stores to increase our trust.

--

Separately, maybe we should revisit the compare tests later on to try and pull out the assert from the kernel loop.

Paul.

> I do see advantages especially if we want to use jmh to add performance analysis capabilities in the future.
> 
> I have done a quick rework of the patch to keeps the assert out-of-loop. Let me know which one looks best for you.
> 
> http://cr.openjdk.java.net/~jphalimi/webrev_testing_trip_count_v1.1/webrev/ 
> 
> Thanks,
> 
> Jp
> 
> -----Original Message-----
> From: Paul Sandoz [mailto:paul.sandoz at oracle.com] 
> Sent: Monday, April 2, 2018 11:37 AM
> To: Halimi, Jean-Philippe <jean-philippe.halimi at intel.com>
> Cc: panama-dev at openjdk.java.net
> Subject: Re: VectorAPI Testing Infrastructure custom loop trip count
> 
> 
> 
>> On Apr 2, 2018, at 8:13 AM, Halimi, Jean-Philippe <jean-philippe.halimi at intel.com> wrote:
>> 
>> Dear all,
>> 
>> The following link is a patch adding support for a custom trip count for each test in the testing infrastructure.
>> 
>> http://cr.openjdk.java.net/~jphalimi/webrev_testing_trip_count_v1.0/webrev/
>> 
>> Please take a look and let me know your thoughts.
>> 
> 
> Do you have any views on whether the outer loop should cover just the kernel loop, or also include the allocation and assertion as in your patch?
> 
> I am unsure, but my suspicion it may be more more beneficial if it covers just the kernel loop so C2 is focused on the kernel, then allocation/assert code has less influence on the code shape.
> 
> Assuming the operations are deterministic, my suspicion is we are more interested in the correctness of a C2 produced code and less so on the intermediate results, which i think we can get coverage on with intrinsics off and/or with tiered compilation/C1 only.
> 
> Maybe later we configure what is in and outside the loop?
> 
> Paul.