Author: Robert Hyatt
Date: 14:17:11 10/02/02
Go up one level in this thread
On October 02, 2002 at 16:27:07, Vincent Diepeveen wrote: >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... I posted some numbers. How about your doing something besides waving your hands and chanting??? For Crafty, 2.95.2 is _faster_. Period. And for Crafty, Intel's compiler is faster still. Period. That's all I have said about Crafty. We have run other big codes on my quad cluster. namd was the latest. Intel was significantly faster than either gcc 2.95.2, gcc 3.2 or the Portland Compiler Group's commercial C compiler. All verified by multiple people, who not only watched the speed but ran production runs of > 48 hours to compare actual answers as well... > >>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.