TalkChess.com

My question is a little out of subject as it concerns an Othello program I am writing and not a chess program. However my program shares many similarities with modern chess programs: bitboard (kindergarten approach) for move generation, search using the negascout algorithm, hash tables, parallel search using YBWC, etc.
My program is written in a portable way and compiles under various compilers and OSes, preferably as a 64 bit executable. As expected the performance of my program varies according to the compiler I use. But I also find MS-Windows 64 bits (Vista and 7) significantly behind Linux or Mac-OS-X. A simple perft (without hashing, just to test the move generator performance) show a 10% loss in performance. On a 2.4Ghz CPU, I get, doing a "perft 12" from the initial position:
- Linux (fedora 12, gcc 4.4.2): 16.17s.
- Mac OS X (10.6.2, gcc 4.2.1): 16.27s.
- Windows 7 (64bits, gcc 4.5.0cvs or Visual C++ 10 beta 2): 17.64s.
During a normal play, the lost in performance is even worst, about 25 or 30%.

So, I am wondering whether your chess programs show a similar behaviour, with a relatively poor behaviour under MS-windows 64bits, or if I missed something in my compilation under MS-Windows.

PS: My program is named Edax and a beta version is available here (with source code under GPLv3):

http://abulmo.perso.neuf.fr/edax/4.0.beta/index.htm

Sounds compiler related to me...

In a test done some year ago, i've found this strange behavior: my chess program, compiled for Windows, runs faster in a virtual box (XP) in Linux than in its original OS, Windows XP. That was very strange... because i've used the same executable in both Windows XP and virtual box with Windows XP. I was expecting than it would be run slower in virtual box but it happened the opposite.

abulmo wrote:My question is a little out of subject as it concerns an Othello program I am writing and not a chess program. However my program shares many similarities with modern chess programs: bitboard (kindergarten approach) for move generation, search using the negascout algorithm, hash tables, parallel search using YBWC, etc.
My program is written in a portable way and compiles under various compilers and OSes, preferably as a 64 bit executable. As expected the performance of my program varies according to the compiler I use. But I also find MS-Windows 64 bits (Vista and 7) significantly behind Linux or Mac-OS-X. A simple perft (without hashing, just to test the move generator performance) show a 10% loss in performance. On a 2.4Ghz CPU, I get, doing a "perft 12" from the initial position:
- Linux (fedora 12, gcc 4.4.2): 16.17s.
- Mac OS X (10.6.2, gcc 4.2.1): 16.27s.
- Windows 7 (64bits, gcc 4.5.0cvs or Visual C++ 10 beta 2): 17.64s.
During a normal play, the lost in performance is even worst, about 25 or 30%.

So, I am wondering whether your chess programs show a similar behaviour, with a relatively poor behaviour under MS-windows 64bits, or if I missed something in my compilation under MS-Windows.

PS: My program is named Edax and a beta version is available here (with source code under GPLv3):

http://abulmo.perso.neuf.fr/edax/4.0.beta/index.htm

Should never happen unless you are doing too much input/output in your program. The O/S should generally not be involved while you are actually searching, which means the only speed difference you should see is due to the compilers you use.

MattieShoes wrote:Sounds compiler related to me...

Thank you for your answer. I will investigate in this direction.

bob wrote:Should never happen unless you are doing too much input/output in your program. The O/S should generally not be involved while you are actually searching, which means the only speed difference you should see is due to the compilers you use.

Thank you for your answer. I will tune further the compiler options under Windows to see if I can get better results, which includes waiting for stable releases of gcc 4.5 & Visual C++ 2010.

abulmo wrote:

bob wrote:Should never happen unless you are doing too much input/output in your program. The O/S should generally not be involved while you are actually searching, which means the only speed difference you should see is due to the compilers you use.

Thank you for your answer. I will tune further the compiler options under Windows to see if I can get better results, which includes waiting for stable releases of gcc 4.5 & Visual C++ 2010.

If you are really curious, it might be worthwhile to look at the assembly output of the executable under Linux (and maybe Mac) and Windows. If the assembly output of the critical (performance intensive) sections are different, that could point to a compiler difference. I recall some gcc versions aggressively schedule no-op instructions.

I would be quite surprised if the assembly output is identical and your performance numbers still show that Vista is behind.

Using PGO can give a substantial performance boost (15-20% is fairly common). It is a little tricky to set up because you have to compile twice, once with profiling on, then run the program, then compile/link with PGO. Are you doing this? This works well for me with Visual C++. I have not been able to get it to work with my sources and g++: it crashes in the link phase. But you may have better luck.

--Jon

jdart wrote:Using PGO can give a substantial performance boost (15-20% is fairly common). It is a little tricky to set up because you have to compile twice, once with profiling on, then run the program, then compile/link with PGO. Are you doing this? This works well for me with Visual C++. I have not been able to get it to work with my sources and g++: it crashes in the link phase. But you may have better luck.

I tried it, but without much success. Under linux, with both icc 11.0 (intel compiler) & gcc 4.4 the PGO optimized program was slower than the non optimized program by 10-15%. Under Windows, with visual C++ 10, the result is neutral.

--
Richard

For PGO optimization to work, the profiling run should be typical of normal program execution (in terms of the branching decisions made). If the program is not branch intensive or if the profiling run is not typical of the actual run, PGO probably will not help. Wonder if this holds for your program.

I apologize for stating the obvious, but the fact that PGO makes performance worse does appear somewhat odd.