Author: Robert Hyatt
Date: 11:53:16 09/30/02
Go up one level in this thread
On September 30, 2002 at 10:19:53, Tom Likens wrote: > >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 Eugene will probably shoot me for this, but don't forget he is in the compiler group up there, and he is _always_ using pre-release compilers to fiddle with Crafty (among other things no doubt). I've yet to get ICC to produce executables as fast as (or faster than) his executables of Crafty he posts on my ftp site... icc is faster than any gcc I have tried, and I have tried so many versions and snapshots it isn't funny. To date, 2.95.2 is the fastest gcc for Crafty, and it lags at _least_ 10% behind intel's compiler.
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.