loop unroll and alignment

[TimP]

I've been trying to use the Advisor screen to assist in summarizing differences in performance with Intel compiler target architecture.  There are surprising differences apparently associated with loop unrolling and alignment. 

I have a case where I specified -Qunroll:4 but, according to the assembly code view, the actual unrolling with outer loop parallelization and vectorization is 2 for AVX and none for AVX2, while the Advisor summary leaves it blank. The actual performance, measured by QueryPerformance ABI, shows the AVX code performing 1.8x of AVX2.  Intel compilers are not emitting any ALIGN directive in the code shown by -S compile option.

There is another non-vectorizable loop (with outer omp parallel loop) where gfortran is out-performing the Intel compilers by 30%, even though all compilers are unrolling by 2. no-fma appears to make no difference. gfortran emits a conditional code alignment 4,,10 in standard configuration, which I modify to 4,,12 when I have the opportunity, while Intel compilers don't align.  4,,10 should mean that up to 10 bytes of padding are inserted if that will produce 16-byte alignment, and the addresses shown by Advisor appear to agree with those directives.  4,,15 would match the ALIGN 16 sometimes emitted by Intel compilers. gfortran and ifort issue apparently the same instructions for this one loop (presumably insignificant changes in instruction order); ICL uses additional lea instructions which seem to slow it down.

The Advisor quoted VL will change sometimes between 4 and 8 from AVX to AVX2 for the same loop using REAL64, both using ymm registers.  This apparently means that the quoted % vector effectiveness is useless when comparing target architectures.

In case anyone has missed other discussions, among the reasons for making such comparisons are to avoid losing performance with AVX2, or to support both AVX and AVX2 targets efficiently.  In the case of real complex, one would like to know from Advisor whether SSE3 is more efficient than AVX or AVX2.

I'm still guessing at what may be favorable or unfavorable loop alignments.  It seems possible for a loop to begin 2 or 3 bytes before a 16-byte boundary without slowing it down, but starting 5 bytes or more after a 16-byte boundary seems bad.

[James_T_Intel]

Can you file this in Intel® Premier Support and include the result directory?

[TimP]

I noticed that the misleading vector lengths are picked up from the opt-report, so that can't be blamed on Advisor.  Still, it means to me that the screen space spent on VL and vector efficiency would be better used other ways.  When looking at SSE code, the leading designator of float32 ahead of float64 in REAL64 loops (which use SSE moves correctly) adds to the confusion.

I checked with other tools, including VTune, and found agreement with the loop alignments shown by Advisor.  On the Fortran forum, I got the expert opinion that there is no way to use the Windows .asm files generated by Intel compilers with an assembler such as ml64 (without serious editing, possibly by a script).

I'll work on an IPS submission.  I'll have to thank James in advance in case he takes on this case which touches multiple tools.  I have been a little surprised that 2 IPS submissions which I made have been fixed during the beta test, although it must have been as a result of someone else pointing out the same issues. 

I'll have to wait to see if the current problem with the IPS site may be resolved.  It has regressed to requiring a SAP NetWeaver login, a problem I haven't seen since I retired.  It did come up shortly, project file attached to IPS issue 6000161287