Has gcc closed the gap to the Intel compiler?

Programming Topics (Computer Chess) and technical aspects as test techniques, book building, program tuning etc

Moderator: Andres Valverde

Has gcc closed the gap to the Intel compiler?

Postby Volker Pittlik » 19 Nov 2009, 15:25

I just made some compilations of Crafty 23.1 with different compilers and I'm a bit astonished when I compare the results of bench.
I use an 64-bit Linux and the versions of gcc and the intel compiler are:

Code: Select all
volker@vpittlik:~$ icc -V
Intel(R) C Compiler for applications running on Intel(R) 64, Version 10.1    Build 20080312 Package ID: l_cc_p_10.1.015
Copyright (C) 1985-2008 Intel Corporation.  All rights reserved.
FOR NON-COMMERCIAL USE ONLY

volker@vpittlik:~$ gcc --version
gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4)


With identical settings for both versions I got for the gcc executabel:

Total nodes: 102663816
Raw nodes per second: 2325341
Total elapsed time: 44.15

And for the intel compilation:

Total nodes: 102663816
Raw nodes per second: 2301879
Total elapsed time: 44.60

In the past there was always a huge difference. Does someone else observe something similar? Or am I just doing someting wrong?


vp
User avatar
Volker Pittlik
 
Posts: 1031
Joined: 24 Sep 2004, 10:14
Location: Murten / Morat, Switzerland

Re: Has gcc closed the gap to the Intel compiler?

Postby Dann Corbit » 19 Nov 2009, 22:38

What is your build process?

Are you using pgo for both?

What are the compiler flags that you are using?

If you really do get the same performance for GCC, that is amazing and good news.
Dann Corbit
 

Re: Has gcc closed the gap to the Intel compiler?

Postby Volker Pittlik » 20 Nov 2009, 10:43

Dann Corbit wrote:What is your build process?
...


I use the Makefile coming with Crafty almost unchanged. My changes are:

in the section "linux":
I changed "-mpreferred-stack-boundary=2" to "-mpreferred-stack-boundary=4" because 2 gave me a compiler error and I found out in previous test 4 is resulting in the fastest binary (although the difference is very small and may be caused by random). I deleted "-march=i686" what is causing an error here too. I also changed "-DINLINE32" to "-DINLINE64".

In all sections which I used:
I added "-DSKILL" because I like this feature very much. Whereever necessary I set "-DCPUS" to 2 because that is what I'm using here.

In the linux-icc and linux-icc-profile section:
I deleted "-xN" because it is causing an error here.

I copied the "profile:" section and called the copy "profile-icc:". I changed "csh" to "bash" cause csh gives me an error and I use bash here. I also changed "$(MAKE) linux-profile" and "$(MAKE) linux" to "$(MAKE) linux-icc-profile" and "$(MAKE) linux-icc".

So I can make the different binaries by typing "make linux" and "make profile-icc". I can see clearly that the different compilers are involved by watching the console. After the profile run the profdir contains "4b054484_07225.dyn 4b05448f_07314.dyn pgopti.dpi pgopti.spi and pgopti.spl" therefore I think the profile run really has happened.

After I noticed that there is no difference in the bench result I made another compilation doing the profile steps manually. After step 1 the executable was very slow as expected. I just ran a bench command with it. After the second compilation I got the same surprising bench result as if typing "make profile-icc".

I possibly have done something wrong, but everything looks as usual to me. In the past I did such compilations very often and got the expected speed difference. That's why I'm so surprised.

vp
User avatar
Volker Pittlik
 
Posts: 1031
Joined: 24 Sep 2004, 10:14
Location: Murten / Morat, Switzerland

Re: Has gcc closed the gap to the Intel compiler?

Postby Jim Ablett » 21 Nov 2009, 11:51

Hi Volker,

I took a look at Crafty's makefile.
My comments below are based on Windows version of Intel compiler, but should also apply to Linux.

The Linux-ICC profiles really should be using '-ipo' (interprocedural optimization) instead of '-Ob2 '
Also '-Oi' '-unroll' and try '-unroll-aggressive' , maybe '-Ot' instead of '-O2'

Jim.
___________________________
http://jimablett.net63.net/
Jim Ablett
 
Posts: 721
Joined: 27 Sep 2004, 10:39
Location: Essex, England

Re: Has gcc closed the gap to the Intel compiler?

Postby Volker Pittlik » 21 Nov 2009, 12:28

Jim Ablett wrote:...
The Linux-ICC profiles really should be using '-ipo' (interprocedural optimization) instead of '-Ob2 '
Also '-Oi' '-unroll' and try '-unroll-aggressive' , maybe '-Ot' instead of '-O2'


I'll try that also because the compiler itself sends out a warning about the -Ob2 option.

However, I just tested a gcc- an icpc-build of Stockfish. The Stockfish Makefile can used nearly unchanged.
just type "icc-profile:".

The result is similar:

setoption name Threads value 1
go nodes 10000000

gcc: info nodes 10020180 nps 755157 time 13269 hashfull 805
intel: info nodes 10020180 nps 773520 time 12954 hashfull 805


Volker, somehow not believing what is going on here...
User avatar
Volker Pittlik
 
Posts: 1031
Joined: 24 Sep 2004, 10:14
Location: Murten / Morat, Switzerland

Re: Has gcc closed the gap to the Intel compiler?

Postby Volker Pittlik » 22 Nov 2009, 12:52

I made some more tests now with Crafty and Stockfish.
Using -ipo for Crafty results in a bit faster bench results (40.35 instead of 43.95 seconds).
Oi and Ot are not available at Linux. -funroll-all-loops makes it slower again. I got a bit faster executable
using -O3 instead of -O2 (39.12 secs).

I was not able to generate an executable using gcc with -fprofile-generate and -fprofile-use. Some
counters I have no idea of show an illegal value.

Using icpc with Stockfish is resulting in a binary which uses 6864 ms to execute "go nodes 10000000".
Using -ipo makes no difference here cause its already default for c++ compilation
The gcc binary needs 7231 ms for the same command.

So it seems to me that there is still a small difference which has become significant smaller than some time ago.
I guess I will stay with gcc cause to measure the differences in rating points may need thousands of games to test.
And that a faster executable is stronger doesn't really need a verification by test.


vp
User avatar
Volker Pittlik
 
Posts: 1031
Joined: 24 Sep 2004, 10:14
Location: Murten / Morat, Switzerland

Re: Has gcc closed the gap to the Intel compiler?

Postby Miguel A. Ballicora » 22 Nov 2009, 18:23

Volker Pittlik wrote:I just made some compilations of Crafty 23.1 with different compilers and I'm a bit astonished when I compare the results of bench.
I use an 64-bit Linux and the versions of gcc and the intel compiler are:

Code: Select all
volker@vpittlik:~$ icc -V
Intel(R) C Compiler for applications running on Intel(R) 64, Version 10.1    Build 20080312 Package ID: l_cc_p_10.1.015
Copyright (C) 1985-2008 Intel Corporation.  All rights reserved.
FOR NON-COMMERCIAL USE ONLY

volker@vpittlik:~$ gcc --version
gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4)


With identical settings for both versions I got for the gcc executabel:

Total nodes: 102663816
Raw nodes per second: 2325341
Total elapsed time: 44.15

And for the intel compilation:

Total nodes: 102663816
Raw nodes per second: 2301879
Total elapsed time: 44.60

In the past there was always a huge difference. Does someone else observe something similar? Or am I just doing someting wrong?


vp


One thing I noticed is that there is a very significant difference between Intel and GCC in 32 bits. In 64 bits, not much (but I have not exhausted all possibilities, just -O2 for both). PGO and -ipo gave me an extra 10% speed up for intel, but I did not try GCC's PGO. I read somewhere that GC Pascutto observed a similar thing. Maybe the guys who develop the optimizations with GCC are focusing on 64 bits mainly.
The good thing about Intel is that it gives much better warnings. I am currently using both, but for internal testing I will keep using GCC to be consistent.

Miguel
User avatar
Miguel A. Ballicora
 
Posts: 160
Joined: 03 Aug 2005, 02:24
Location: Chicago, IL, USA


Return to Programming and Technical Discussions

Who is online

Users browsing this forum: No registered users and 3 guests