Polyhedron 2005 Benchmarks

[Paul Thomas]

Dominique,

>
>It seems that your AMD is slower than mine and have a smaller L2 cache.
>If so, it confirms that some of the Polyhedron tests are sensitive to the 
>L2 cache size (I have proof of that for tfft).
>
Yes, I would agree with that.  This is apparent from the Wiki posting, 
where a PIV, even under Cygwin, is doing much better for the tests that 
are sensitive to cache size.

>
>I also confirm that mod() is slow in g95 and gfc (g77 as well), that there
>is a large benefit to inline dot_product (at least for small vectors).
>
I have put in a lot of work to fashion an inline MOD that both improves 
the range for which a result is given and the speed.  I know what to do 
now (Thanks, Uros and Tobi) and will implement it it in the next week.

>
>In addition replacing 3 dot_products by a matmul of a 3x3 matrix times a
>length 3 vector gives catastrophic results (with all compilers) and
>g95 and gfc are unable to reorder loops such as
>
>do i = 1, ni
>  do j = 1, nj
>     a(i,j) = b(i,j)
>   end do
>end do
>
>
I was just going to try Stephen's suggestion of -ftree-loop-linear.

>limit stacksize unlimited       (csh)
>ulimit -s unlimited             (sh)
>
I have been using the gfortran option.

The present status of the three lines that I have been persuing to 
improve gfortran's performance is:
(i)  I think that the inline dot_product is ready to resubmit.  It 
improves the performance for small arrays and, as far as I know, does no 
harm anywhere.
(ii) MOD requires some work but there is light at the end of the tunnel.
(iii) There is a typo in dependency.c(gfc_is_same_range)

00157   /* Use the bound of the array if no bound is specified.  */
00158   if (ar1->as && !e1)
00159     e1 = ar1->as->lower[n];
00160 
00161   if (ar2->as && !e2)
00162     e2 = ar2->as->upper[n];  <==== this should be lower

which when corrected, allows it to be used in gfc_check_section_vs_section to return immediately with GFC_DEP_EQUAL.

The one reference to this function is to a commented out section in trans-array that is meant to do scalarizer loop reordering.

This section of code is broken; the more obvious corrections result in a reordering but the strides get mixed up.

I have put this on a longer term TODO list.

In the mean time, the simplest fix of dependency.c will ready for submission in a few days.

Best regards

Paul