Puzzling performance difference between ifort and gfortran

Question

Recently, I read a post on Stack Overflow about finding integers that are perfect squares. As I wanted to play with this, I wrote the following small program:

PROGRAM PERFECT_SQUARE
IMPLICIT NONE
INTEGER*8 :: N, M, NTOT
LOGICAL :: IS_SQUARE

N=Z'D0B03602181'
WRITE(*,*) IS_SQUARE(N)

NTOT=0
DO N=1,1000000000
  IF (IS_SQUARE(N)) THEN
    NTOT=NTOT+1
  END IF
END DO
WRITE(*,*) NTOT ! should find 31622 squares
END PROGRAM

LOGICAL FUNCTION IS_SQUARE(N)
IMPLICIT NONE
INTEGER*8 :: N, M

! check if negative
IF (N.LT.0) THEN
  IS_SQUARE=.FALSE.
  RETURN
END IF

! check if ending 4 bits belong to (0,1,4,9)
M=IAND(N,15)
IF (.NOT.(M.EQ.0 .OR. M.EQ.1 .OR. M.EQ.4 .OR. M.EQ.9)) THEN
  IS_SQUARE=.FALSE.
  RETURN
END IF

! try to find the nearest integer to sqrt(n)
M=DINT(SQRT(DBLE(N)))
IF (M**2.NE.N) THEN
  IS_SQUARE=.FALSE.
  RETURN
END IF

IS_SQUARE=.TRUE.
RETURN
END FUNCTION

When compiling with gfortran -O2, running time is 4.437 seconds, with -O3 it is 2.657 seconds. Then I thought that compiling with ifort -O2 could be faster since it might have a faster SQRT function, but it turned out running time was now 9.026 seconds, and with ifort -O3 the same. I tried to analyze it using Valgrind, and the Intel compiled program indeed uses many more instructions.

My question is why? Is there a way to find out where exactly the difference comes from?

EDITS:

gfortran version 4.6.2 and ifort version 12.0.2
times are obtained from running time ./a.out and is the real/user time (sys was always almost 0)
this is on Linux x86_64, both gfortran and ifort are 64-bit builds
ifort inlines everything, gfortran only at -O3, but the latter assembly code is simpler than that of ifort, which uses xmm registers a lot
fixed line of code, added NTOT=0 before loop, should fix issue with other gfortran versions

When the complex IF statement is removed, gfortran takes about 4 times as much time (10-11 seconds). This is to be expected since the statement approximately throws out about 75% of the numbers, avoiding to do the SQRT on them. On the other hand, ifort only uses slightly more time. My guess is that something goes wrong when ifort tries to optimize the IF statement.

EDIT2:

I tried with ifort version 12.1.2.273 it's much faster, so looks like they fixed that.

Are those wall times or CPU times? Can you paste the output of `time ` for each one? And were these 32-bit builds or 64-bit builds? — David Schwartz, Jan 17 '12 at 10:49
Have you tried disassembling the object files emitted by each compiler and comparing them? — talonmies, Jan 17 '12 at 11:02
@talonmies: no I didn't, since I don't really understand assembly. Although running through `valgrind --tool=callgrind --dump-instr=yes` also gives the assembly code, but that's really complex (many differences) and depends on the level of optimization. — steabert, Jan 17 '12 at 11:08
Did you try more aggressive optimization levels? They might be worth it. — Vladimir F Героям слава, Jan 17 '12 at 13:03
Are you sure your program is correct? With more recent versions of gfortran than 4.5 i get different answers. — Vladimir F Героям слава, Jan 17 '12 at 13:10
@Vladimir: which optimizations would you suggest beyond `-O3`? That gfortran 4.5 gives different answers is strange, what do you get? — steabert, Jan 17 '12 at 13:34
A similar question last month had this interesting answer: http://stackoverflow.com/a/8346126/189050 — Deditos, Jan 17 '12 at 15:53
@Vladimir: I fixed the program, `NTOT` wasn't initialized. @Deditos: yes, I read that post and indeed this can have an effect. Only in this case ifort seems to completely choke on that complex IF-statement — steabert, Jan 17 '12 at 15:58
@steabert Now the results are correct. Just fyi I get 14.6s for gfortran 4.5, 10.7s for gfortran 4.6 and 4.7 and 14.2s for Solaris Studio 12.3. — Vladimir F Героям слава, Jan 17 '12 at 16:38
@Vladimir: nice, thnx. Do you by chance have ifort to try? :) This seems rather an ifort problem (see edit). — steabert, Jan 17 '12 at 16:42

laxxy · Accepted Answer · 2012-01-25T00:09:03.313

5

What compiler versions are you using? Interestingly, it looks like a case where there is a performance regression from 11.1 to 12.0 -- e.g. for me, 11.1 (ifort -fast square.f90) takes 3.96s, and 12.0 (same options) took 13.3s. gfortran (4.6.1) (-O3) is still faster (3.35s). I have seen this kind of a regression before, although not quite as dramatic. BTW, replacing the if statement with

is_square = any(m == [0, 1, 4, 9])
if(.not. is_square) return

makes it run twice as fast with ifort 12.0, but slower in gfortran and ifort 11.1.

It looks like part of the problem is that 12.0 is overly aggressive in trying to vectorize things: adding

!DEC$ NOVECTOR

right before the DO loop (without changing anything else in the code) cuts the run time down to 4.0 sec.

Also, as a side benefit: if you have a multi-core CPU, try adding -parallel to the ifort command line :)

edited Jan 25 '12 at 00:09

answered Jan 24 '12 at 23:03

laxxy

1,148
8
17

See edit: with ifort version 12.1.2.273 it worked. Also, there is a difference when compiling and linking seperately or on one line, strange. Now I have: gfortran 3.1 s with or without your `any` statement, and ifort 3.3 s original and 5.0 s with the `any` statement. – steabert Jan 25 '12 at 07:37
yes, I think the reason `any` made things faster in 12.0 was by preventing vectorization. Difference between compiling separately and on one line I think suggests something like that instruction cache issue might be going on. Also, the whole thing would speed up a lot if you use single instead of double precision, and I think also if you modify the function to return 1 or 0 and add results up instead of having an `if` statement (conditional statements in loops are often bad for performance). – laxxy Jan 25 '12 at 17:12
thnx for the comments especially the addition hint, I'll try that. As for double precision: I need it to get the correct square root for very large integers. This was just an exploration of integer square root, to see if it can be done faster with other methods, but it turned out that the sqrt instruction can't be beaten... – steabert Jan 25 '12 at 17:39
well, turns out that with the integer is_square function and simple addition in the loop, the code runs slower, i.e. 3.9s instead of 3.1s :) – steabert Jan 25 '12 at 17:45
I see. Just tried -- for me this also happened, but only with gfortran (not ifort), and only when if function was declared as integer(8) -- with machine default integer the speed is the same. No improvement though -- I guess there are quite a few jumps there already, so one more does not really matter :) – laxxy Jan 26 '12 at 19:44
The conspiracy theorist will point out that Intel did this so they can claim v12 is faster than v11. – John Alexiou Mar 23 '12 at 14:17

Puzzling performance difference between ifort and gfortran

1 Answers1

Linked