Author: Vincent Diepeveen
Date: 05:57:46 10/01/02
Go up one level in this thread
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. 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. 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. 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.