Problem vectorizing FORTRAN code

[Alberto_R_1]

Hi all,

My original code had some probems to get good vectorizations. Following siggestions in different places (including several INTEL articles), I decided that re-structuring the data layout seems the more promising approach.

 Instead of defining an array of complex matrices:

 type su3
     complex (kind=8) :: comp(3,3)
  end type

  type field
    type (su3), allocatable :: v(:)
  end type

  that makes vectorization complicated (how to vectorize the multiplication of a single 3x3 matrix?), I have decided to invert the orderof the layout.

 type grid_complex
    complex (kind=8), allocatable :: v(:)
  end type
 
  type field
    type (grid_complex) :: comp(3,3)
  end type

   (i.e. AoS versus SoA data structures). This approach works for me because I *always* have to multiply O(1000) matrices at the same time. The idea was that the this typical operation can now be coded in a routine like the following:

 module procedure su3xsu3(g,a,b)
    type (field), intent (in) :: a,b
    type (field), intent (inout) :: g
    integer :: i, j
    
    do concurrent (i=1:3,j=1:3)
       g%comp(i,j)%v = &
            a%comp(i,1)%v*b%comp(1,j)%v + &
            a%comp(i,2)%v*b%comp(2,j)%v + &
            a%comp(i,3)%v*b%comp(3,j)%v
    end do

     return
  end procedure su3xsu3

  I was assuming that now the data layout is perfectly aligned, and
therefore vectorization straightforward. The surprise is that Intel Fortran
v16 optimization report claims (ifort -opt-report5 -O3 -xavx  -align array128byte -opt-assume-safe-padding):

LOOP BEGIN at src/group_su3.f90(56,5)
   remark #25101: Loop Interchange not done due to: Original Order seems proper
   remark #25452: Original Order found to be proper, but by a close margin
   remark #15542: loop was not vectorized: inner loop was already vectorized

   LOOP BEGIN at src/group_su3.f90(56,5)
      remark #15542: loop was not vectorized: inner loop was already vectorized

      LOOP BEGIN at src/group_su3.f90(57,8)
         remark #15389: vectorization support: reference g has unaligned access
         remark #15389: vectorization support: reference a has unaligned access
         remark #15389: vectorization support: reference b has unaligned access
         remark #15389: vectorization support: reference a has unaligned access
         remark #15389: vectorization support: reference b has unaligned access
         remark #15389: vectorization support: reference a has unaligned access
         remark #15389: vectorization support: reference b has unaligned access
         remark #15381: vectorization support: unaligned access used inside loop body
         remark #15305: vectorization support: vector length 2
         remark #15399: vectorization support: unroll factor set to 2
         remark #15309: vectorization support: normalized vectorization overhead 0.239
         remark #15300: LOOP WAS VECTORIZED
         remark #15450: unmasked unaligned unit stride loads: 6 
         remark #15451: unmasked unaligned unit stride stores: 1 
         remark #15475: --- begin vector loop cost summary ---
         remark #15476: scalar loop cost: 33 
         remark #15477: vector loop cost: 22.000 
         remark #15478: estimated potential speedup: 1.490 
         remark #15488: --- end vector loop cost summary ---
         remark #25015: Estimate of max trip count of loop=128
      LOOP END
   LOOP END
LOOP END

  This means, that for some reason beyond my understanding, he claims that variables a and b have the incorrect alignement in memory, and therefore although he vectorizes the loop, he does not expect much improvement.

  Since I am asking to use avx instructions (SDIM size of 256 bits), that
can process at the time 2 double precision complex numbers, I would expect a
naive speedup of 2x.

Now if I use the -ipo command, I get (ifort -ipo -opt-report5 -O3 -xavx  -align array128byte -opt-assume-safe-padding):

LOOP BEGIN at src/group_su3.f90(56,5) inlined into src/main.f90(10,8)
   remark #25101: Loop Interchange not done due to: Original Order seems proper
   remark #25452: Original Order found to be proper, but by a close margin
   remark #15542: loop was not vectorized: inner loop was already vectorized

   LOOP BEGIN at src/group_su3.f90(56,5) inlined into src/main.f90(10,8)
      remark #15542: loop was not vectorized: inner loop was already vectorized

      LOOP BEGIN at src/group_su3.f90(57,8) inlined into src/main.f90(10,8)
         remark #15388: vectorization support: reference a.COMP.V has aligned access
         remark #15388: vectorization support: reference c.COMP.V has aligned access
         remark #15388: vectorization support: reference b.COMP.V has aligned access
         remark #15388: vectorization support: reference c.COMP.V has aligned access
         remark #15388: vectorization support: reference b.COMP.V has aligned access
         remark #15388: vectorization support: reference c.COMP.V has aligned access
         remark #15388: vectorization support: reference b.COMP.V has aligned access
         remark #15305: vectorization support: vector length 2
         remark #15399: vectorization support: unroll factor set to 2
         remark #15300: LOOP WAS VECTORIZED
         remark #15448: unmasked aligned unit stride loads: 6 
         remark #15449: unmasked aligned unit stride stores: 1 
         remark #15475: --- begin vector loop cost summary ---
         remark #15476: scalar loop cost: 33 
         remark #15477: vector loop cost: 14.000 
         remark #15478: estimated potential speedup: 2.350 
         remark #15488: --- end vector loop cost summary ---
         remark #25015: Estimate of max trip count of loop=128
      LOOP END
   LOOP END
LOOP END

The compiler correctly identifies the components v(:) to be aligned and vectorizes the loop.

Now the questions:

  1) What am I missing? Why the original loop, without in-linning the function does not vectorize correctly.

  2) A more general question: Does all this shufling of data layout makes
sense for you? Could I expect an improvement by using a SoA layout if my
codes uses most the time in small matrix multiplications? Any other hints
for writing efficient code for modern architectures while being standard
conforming?

  Many thanks!

A.