Performance of pgi openaccfor a matrix-matrix multiplication

[gongjing]

Hi,

The question is related to the two older questions.

better performance on Kepler k20 than Fermi NVIDIA Tesla ?

Hi, Can we always get better performance on Kepler k20 than that on Fermi Tesla GPU? I used pgi 12.10.0 with OpenACC to compile a code and found that the performance on K20 becomes worse. Is it related to the rather old version of PGI or there are any specific parameters available for the Kepler k20 GPU ? Thanks you very much for your help.

should use to "acc reduction" in an inner loop

Hi All, I am a new user of pgi acelerator. I try to use openacc for a matirx multiplication, such as … !$ACC DATA COPYIN(D,u,v,w) !$ACC& COPYOUT(m) !$ACC PARALLEL LOOP do k=1,n do j=1,n do i=1,n m(i,j,k) = 0. do l=1,n m(i,j,k) = m(i,j,k) + D(l,i)*u(l,j,k) $ + D(l,j)*v(i,l,k) $ + D(l,k)*w(i,j,l) enddo enddo enddo enddo !$ACC END PARALLEL LOOP !$ACC END DATA when compile the code, I obtain the following messa…

The matrix-matrix multiplication likes

do e=1,nel
   do k=1,n
   do j=1,n
   do i=1,n
       tmp = 0.
       do l=1,n
          tmp = tmp + D(i,l)*u(l,j,k,e)+D(j,l)*v(i,l,k,e)+D(k,l)*w(i,j,l,e)
       enddo
       m(i,j,k,e) = tmp
   enddo
   enddo
   enddo
enddo

where typically n=4-16 and nel=10-1000. We can only obtain around maximum 20G FLOPS using pgi compilers on Tesla k20x for n=16 and nel=400.

!$acc kernels
!$acc loop gang
671: do e=1,nel
!$acc loop gang vector
673:   do k=1,n
!$acc loop vector
675:  do j=1,n
677: do i=1,n
       tmp = 0.
679:   do l=1,n
              tmp = tmp + D(i,l)*u(l,j,k,e)+D(j,l)*v(i,l,k,e)+D(k,l)*w(i,j,l,e)
          enddo
       m(i,j,k,e) = tmp
   enddo
   enddo
   enddo
enddo
!$acc end kernels

1. In that case, should “reduction” be added on the inner-loop ?

 !$ACC LOOP REDUCTION(+:tmp)                                                              
            do l=1,n  ! serial loop, no reductio

Even the reduction is added, the loop “do l=1,n” still is parallelized
…
671, Loop is parallelizable
673, Loop is parallelizable
675, Loop is parallelizable
677, Loop is parallelizable

679, Loop is parallelizable
…
(but performance reduced from 20G to 13G FLOGS)


2) The performance for the kernels on a Fermi GPU was obtained around 23G. Is there any way to improve the performance on K20x ? I have used the compiler flag (-ta=nvidia,5.0) and other openacc implementation have been tested, such as

 !$acc kernels
    do ;
      do; do;
...
  !$acc parallel loop collapse(4) 
     do;
       do, do

but cannot obtain better performance.

Thanks for your assistance.

/Jing

[MatColgrove]

Hi Jing,

For #1, don’t confuse the message “Loop is parallelizable” with what’s actually scheduled. This message is from the analysis stage and just means that it could be parallelized. Look for the loops schedule messages for what actually was parallelized.

Given the values of “n” are so small, I would collapse the k, j, and I loops together, and just perform the reduction loop sequentially in the kernel. In the just released PGI 14.4, we’ve made considerable improvements with loop collapsing so please consider using this new release.

!$acc kernels 
!$acc loop gang 
671: do e=1,nel 
!$acc loop vector(512) collapse(3) 
673:   do k=1,n 
675:  do j=1,n 
677: do i=1,n 
       tmp = 0. 
679:   do l=1,n 
              tmp = tmp + D(i,l)*u(l,j,k,e)+D(j,l)*v(i,l,k,e)+D(k,l)*w(i,j,l,e) 
          enddo 
       m(i,j,k,e) = tmp 
   enddo 
   enddo 
   enddo 
enddo 
!$acc end kernels

For #2, try targeting compute capability 3.5 (i.e. -ta=tesla:cc35) and use the “INTENT(IN)” attribute on your read-only arrays. In these cases, we attempt to utilize texture memory can help considerably for random-access memory patterns such as how you’re using the “D” array.

Some other general performance ideas:

Given the schedule above, you could also help your memory access a bit by using “j” or “k” as the leading dimension of the “u” array instead of “l”.

Other things to are to disable RDC (-ta=tesla:nordc) assuming you don’t use the “routine” directive. In 14.4, we’ve added an “unroll” option (enabled by default with -O3) which helps a few codes but can slow down others. Worth a try though.

Finally, look at the PTX information for the register usage (-ta=tesla:ptxinfo) and use this information to determine the occupancy. You can then adjust the vector width higher or lower or use “-ta=tesla:maxregcount:xx” to adjust the total register usage per gang to see how it effects occupancy and performance.

• Mat

[gongjing]

Hi Mat,

Thank for your valuable input.

Now the code is changed to

!$acc kernels
!$acc loop gang
671: do e=1,nel
!$acc loop vector(16) collapse(3)
do ...

With pgi 14.2 (13.10 used previously) and flag -ta=tesla:cc35, 40G flops can be obtained for nel=400 and n=16. that indeed improves much performance.

I will try other suggestions, but it seems “-ta=tesla:nordc” does not work for the code, there is a compiler error

Accelerator Fatal Error: No CUDA device code available
File: math.f
Function: zero:1388

But the “zero” function is

subroutine zero(a,n)
      DIMENSION  A(n)
!$ACC DATA PRESENT(A(1:n))                                                                  
!$ACC PARALLEL LOOP                                                                                  
      DO I = 1, N
         A(I) = 0.0

Thanks again.

/Jing