Author: Robert Hyatt
Date: 12:53:52 10/02/02
Go up one level in this thread
On October 02, 2002 at 15:05:38, Vincent Diepeveen wrote: >On October 02, 2002 at 11:26:51, Robert Hyatt wrote: > >actually i have 20 lines of code which produces clear bugs in it. >but i can't cut'n paste them because they are property of a big >project. i actually *did* forward them. Why can you cut/paste 20 lines of code? If it is part of a "big project" it won't be revealing very much. > >your statement that crafty's fastest gcc is version 2.95.2 is nonsense. >every idiot can see that 3.2 is way faster using the profile info. See the times I posted. Not made up. No hand waving... > >gives a speed boost of around 20% for me. even if it's 10% for you... Can't help that. Every "idiot" can see the times I posted. The gcc 3.2 executable is far slower than the intel 6.0 executable. I'm still playing with 3.2 but have not closed the gap yet... > >>On October 01, 2002 at 08:57:46, Vincent Diepeveen wrote: >> >>>On September 30, 2002 at 10:19:53, Tom Likens wrote: >>> >>>I'm really not interested in the intel c++ compiler to >>>waste time to clearly find bugs without getting paid for it. >>> >>\ >>Based on the bugs you have "found" and reported, they would/n't consider >>paying you anyway. Because what you are reporting are imaginary bugs. >>Too much testing here has confirmed that for _significant_ programs, the >>compiler produces perfect results, and the results are produced faster than >>any version of gcc, thru the current 3.2 gcc as released in redhat 8.0... In >>fact, >>intel's compiler is producing numbers at least 10% faster than gcc 3.2. Here >>is one sample: >> >>Intel's compiler: time=18.99 >>gcc 3.2 time: time=23.16 >> >>Both run on a single 700mhz xeon, one processor, with the best optimization >>flags >>I have found so far... that is significant. >> >>>However if you want my makefile which i use for intel c++ >>>you can email me. >>> >>>I need to add that i am multiprocessor. The bug i talked >>>about for the intelc++ with regards to diep, it was appearing >>>in the game diep - xinix, round 1 icsvn2. diep gave away a pawn >>>there without clear reasons. >>> >>>I could never reproduce the move except with intel c++ 6.0 >>>using optimizations. Of course i just went to msvc compiled >>>diep versions then and didn't give the intel c++ any thought >>>anymore. >> >>That is some kind of scientific reasoning. A bug shows up rarely, and >>when it shows up with a specific compiler, it _must_ be the compiler. >> >>:) >> >>look forward to playing your program in the future with that kind of >>debugging... >> >> >>> >>>if something loses half a point for me (Rae1 would have won >>>the game simply, which is the move any other executable played >>>whatever i tried) then i am capable of killing every intel guy >>>who worked on the compiler. >> >>Or perhaps you should just spend more time debugging your code? >>It works well for too many programs here, including some _huge_ programs >>that run for weeks at a time, for the compiler to have that kind of bugs. More >>likely it is the _program_ that has the bugs, rather than the compiler. >> >>> >>>half a point there and half a point in SOS game would've meant >>>i would have been first, what happened now is that i played someone >>>in round 2 who scored zero points. Bad for my sum of opponents... >>> >>> >>> >>>>Vincent, >>>>I've got some time over the next couple of days (we just taped out a chip, and >>>>I'm >>>>taking some time off), so I think I'll run an experiment or two using the code >>>>you >>>>supplied as a starting point. I have access to a P-III, a P4 and an Athlon >>>>processor >>>>so I can run some realistic tests on the Intel compiler (and the new gcc >>>>compiler >>>>as well). >>>> >>>>It might be helpful if you gave me your compiler settings. As a data point, >>>>for Intel profiling I've been using: >>>> >>>>-O3 -axK -xK -prof_genx >>>> >>>>and for profile-guided executables: >>>> >>>>-O3 -axK -xK -wp_ipo -ipo_obj -prof_use >>>> >>>>These settings *should* work on everything from a P-III onward. >>>>I interspersed a few other comments below. >>>> >>>>On September 30, 2002 at 04:50:31, Vincent Diepeveen wrote: >>>> >>>>>There is zillions of bugs in the intel c++ compiler where it >>>>>generates code that is buggy both at my P3 as well as the K7s. >>>>> >>>>>Of course the majority of bugs in the intel 6.0 compiler i didn't >>>>>checkout, i just file compared the logs. >>>>> >>>>>All compilers produced the same log except the intel c++ 6.0 compiler. >>>>> >>>>>One bug i HAD to investigate and it was in a program doing floating point >>>>>for a database conversion tool where i casted things to int. >>>>> >>>>>something like >>>>> >>>>>int coefficient(int bla,int blabla) >>>>> double a,b,c,d,e,f,g; >>>>> >>>>> .. (all kind of stuff) >>>>> >>>>> return( (int)((a*b)+c)); >>>>>} >>>>> >>>>>It took me very long to find this bug. I was very sick when >>>>>i learned that sometimes it returned a random value. >>>> >>>>Yeah, this sounds like one of those lovely, 2:00 AM in the morning debug >>>>sessions- >>>>been there, done that. One quick question here, did you ever get an assembly >>>>language dump of the code to see what was being produced? If you isolate the >>>>module and compile it using: >>>> >>>>-S <your compiler settings> etc. >>>> >>>>it will give you Intel assembly. Another idea would be to enable/disable the >>>>various >>>>optimization switches to try and isolate the switch causing the problem. >>>> >>>>>Obviously it didn't happen when i compiled without optimizations. >>>>>Just debug code with intel c++ it worked fine. Yet i'm not having >>>>>a good feeling running always with debug code turned on :) >>>>> >>>>>Do you? >>>> >>>>No, having the debug code always turned on is a good way to sink to the bottom >>>>of the ratings list, although you'll probably catch a lot of bugs :) >>>> >>>>>Further the intel c++ 6.0 compiler is hell slower for DIEP >>>>>at AMD than even a default msvc 6.0 sp4 procpack compile. >>>>>Not to mention the gcc 3.1 which has branch >>>>>reorder optimizations using profile info >>>>>just like the intel c++ thing has. >>>>> >>>>>to my amazement gcc 3.1 with branch reordering also was a bit faster >>>>>at my P3 than the intel c++ 6.0 thing. >>>> >>>>Gcc 3.2 is a nice improvement over the previous versions. The additional C++ >>>>compIiance alone, makes it worth the cost of admission. I saw a speed increase >>>>moving to 3.2, but the biggest increase was moving to the Intel compiler (for >>>>me). >>>>Of course, if it produces buggy code it's a moot point, since I can make >>>>anything >>>>arbitrarily fast if it doesn't have to be correct. >>>> >>>>>I do not know what the 6.0 compiler is doing, but it seems they only >>>>>did effort to get it slower at the K7, thereby also sacraficing speed >>>>>at their own P3 hardware. >>>>> >>>>>Another weird thing for me is the realisation that the optimizing with >>>>>profile information in a open source compiler is doing way better than >>>>>the intel c++ is. Isn't it allowed in the specint or so? :) >>>>> >>>>>If i see the specbench.org testresults, i do not see them use the >>>>>profile info to reorder branches. >>>> >>>>I'm guessing they are either too lazy or they don't understand the full >>>>capabilities of the compiler (maybe a little of both). >>>> >>>>>msvc doesn't have all this cool features regrettably, otherwise it would >>>>>be by far fastest compiler as a default compile from it is way faster >>>>>than a default gcc compile is for k7. Yet the 20% speed the k7 executable >>>>>of DIEP wins by that extra optimization pass using profile info, that's the >>>>>big win. >>>>> >>>>>Best regards, >>>>>Vincent >>>> >>>>I'm not a huge fan of Microsoft, but I give credit where credit is due. For a >>>>*long* time (years) their compiler produced the fastest code by a large >>>>margin. That doesn't seem to be the case any more for just the reason you >>>>mention. Without the extra info the profile pass provides (say that five times >>>>fast ;) >>>>they are starting to lag behind. >>>> >>>>regards, >>>>--tom
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.