Author: Vincent Diepeveen
Date: 09:08:07 08/06/03
Go up one level in this thread
On August 05, 2003 at 13:02:50, Albert Silver wrote: >On August 05, 2003 at 11:15:41, Robert Hyatt wrote: > >>On August 05, 2003 at 10:45:41, Ricardo Gibert wrote: >> >>>On August 05, 2003 at 09:53:26, Robert Hyatt wrote: >>> >>>>On August 05, 2003 at 09:24:07, ERIQ wrote: >>>> >>>>>. >>>> >>>> >>>>No. >>> >>>I have to disagree. I have performed a number of experiments and found msvc >>>faster some of the time and gcc faster some of the time. It all depends on a >>>number of factors that are not completely predictable. >>> >>>The experiments consisted of simulataneously dropping CD copies of each compiler >>>from the roof of my home and observing which CD impacted the ground first. They >>>never seemed to impact the ground at exactly the same time, but there was no >>>clear favorite either. >> >> >>:) > >Joking aside, how much slower on average is gcc compared to msvc, and more >importantly what are the final results like between the two? > > Albert K7 2.127Ghz PLEASE NOTE THAT MY EXPERIMENTS ARE DETERMINISTIC. Crafty is NOT deterministic, though i bet for bitboards at 32 bits cpu's you better can chose for buggy intel c++. GCC is faster nearly 1% than msvc6 sp5 procpack Note that the procpak for msvc is really 7% faster at K7 for DIEP. this is gcc with PGO of course. so it takes a long period of time to compile it when compared to msvc. the default compile i therefore do with msvc. intel c++ is not deterministically giving same result. So i have not tested latest 7.1 version extensively. I do know that it is superior at itanium processors compared to gcc. And a lot. We talk about 88k nps versus 72k nps difference. that's like 22% or so. However there is problems with icc. I do not trust it because of the many bugs in the past. So it has to proof itself deterministically. It is not giving deterministically same search. Please note that crafty does not have such debug features. Bob can say what he wants, but he does not have same testbeds i have. I can create extensive logfiles which include all evaluations all nodes searched and all alfa and beta values and so on. Huge logfiles. If that gives a 1 to 1 file compare then it is deterministically the same of course. However a problem is that bugs in intel c++ especially happen when you have optimizations turned on. If you have 'printf' only as debug option then you will not find the bug, because the printf avoids the register problems. what i do is i put the stuff into shared memory. only after the run i verbose print the stuff to a logfile. Even that is already risky with intel c++ to proof that it is bugfree. Currently it isn't showing the 100% same thing simply. there is issues with it always going for stupid instructions that involve the mmx/sse2 part. i do not want to use them. i want to use 32 bits registers! the difference is that floating point is 80 bits. when put in MMX that is just 64 bits. So you lose 16 bits. That's what icc is continuesly doing. So i go strip out that code and then again retest it deterministically. Till then all i know is that in nodes a second it is a bit slower. not much than the above 2 compilers. Best regards, Vincent
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.