Author: Robert Hyatt
Date: 18:08:47 08/06/03
Go up one level in this thread
On August 06, 2003 at 12:08:07, Vincent Diepeveen wrote: >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++. (1) I have absolutely no idea what you are talking about. If you don't use the parallel search, crafty is _perfectly_ deterministic. Time after time. Please post an example to support your claim it is not. (2) Intel c++ is _not_ "buggy". It works just fine. > >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. It certainly does. At least for those of us that know what we are doing. > >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. Hint: That is a _good_ thing. _not_ a bad thing. "MY" testbed didn't show me a consistent speedup >2.0 for two processors. For just one example. > >I can create extensive logfiles which include all evaluations all nodes searched >and all alfa and beta values and so on. Huge logfiles. SO can I. See the "tr" command. > >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.