Author: Vincent Diepeveen
Date: 12:05:38 10/02/02
Go up one level in this thread
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. 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. gives a speed boost of around 20% for me. even if it's 10% for you... >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.