Author: Vincent Diepeveen
Date: 13:27:07 10/02/02
Go up one level in this thread
On October 02, 2002 at 16:22:13, Robert Hyatt wrote: >On October 02, 2002 at 16:17:35, Vincent Diepeveen wrote: > >>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? > >No I do not. And that was not my claim. My claim was > >"for crafty, gcc 2.95.2 has _always_ produced the fastest executables, for >every snapshot, every major version, all the way thru the current gcc 3.2 that >is on redhat 8.0" > >Nothing more, nothing less, and it is _still_ true. Intel's compiler is simply >faster >still... Even a pig which knows that 3 is more than 1 can see 3.2 being faster than 2.95.2 though... >Have trouble understanding or comprehending that??? > > >> >>>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.