Author: Vincent Diepeveen
Date: 13:17:35 10/02/02
Go up one level in this thread
On October 02, 2002 at 15:53:52, Robert Hyatt wrote: your statement was: gcc 2.95.2 is way faster than any other gcc version. you get back to your claim? >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.