Author: Bernhard Bauer
Date: 00:49:03 08/09/99
Go up one level in this thread
On August 07, 1999 at 16:44:40, Robert Hyatt wrote: >On August 07, 1999 at 15:14:03, Vincent Diepeveen wrote: > >>On August 07, 1999 at 12:56:44, Robert Hyatt wrote: >> >>>On August 07, 1999 at 08:13:33, Vincent Diepeveen wrote: >>> >>>>installed gcc 2.95 a few days ago. >>>>didn't speedup diep at all, whatever option i tried >>>>or used. >>>> >>>>HOWEVER, >>>>where i recently reported about all problems diep had >>>>with linux, now a different story. >>>> >>>>All those problems DIEP had with linux have dissappeared. >>>>DIEP runs stable under linux, no forfeits at a dual machine >>>>sincethen at the icc server. >>>> >>>>Seems gcc 2.95 is a big step forward for my program! >>>> >>>>Greetings, >>>>Vincent >>> >>> >>>I would be concerned, if that fixed (or hid) your bugs. I am using this >>>same compiler, and find that it is almost identical to my favorite version >>>of pgcc. Very little difference in execution speed. >>> >>>And there have been no serious parallel programming bugs exposed in the older >>>gcc/egcs compilers. We have all sorts of parallel programming going on here >>>using gcc under linux, and in over 2 years, we have _never_ found a bug in the >>>code produced by the compiler. >>> >>>However, if you have uninitialized variables and the like, the non-determinism >>>will certainly cause a program to behave differently with multiple threads >>>active. But if it has bugs in a non-parallel mode, just because they suddenly >>>become visible in parallel search doesn't mean the compiler is broken. It means >>>that the program is very suspect. >> >>It's very hard to call a big program buggy if it's >>running stable under NT for years >>without any problems having major bugs, which only show up under linux, >>but dissappear when a bugfixed gcc compiler comes out. >> > > >I see this _all_ the time. Just because a program runs correctly, doesn't >mean it is a correct program. Bad memory references can luckily land on >variables that don't mind getting overwritten, or which have a value of 0. >Uninitialized variables (local) can be fortunate that they luck into a zero >on the stack, until some new optimization changes this. Etc... > >Blaming the compiler is wrong, 99.99999999% of the time... > > > > >>a big program with difficult pointer datastructures and very well >>hand optimized is no compare with a bunch of quick&cheap&slow students >>programs. > > >Sorry to tell you this, but we have students here that have written programs >over 200,000 lines long working on MS/PhD projects. Those are as complex as >anything I have written... > > > > >> >>>In your case, the way you are sharing things, the compiler really doesn't even >>>care that you are doing things in parallel because you aren't using the 'light- >>>weight thread' approach to parallel search, which means the compiler has no >>>influence at all over your program... the only danger is in whatever you are >>>sharing among the processes... because you _must_ get the 'volatile' things >>>properly identified or the optimizer will zap you. But once they are right, >>>I don't see any problems at all, even in hundreds of different student programs >>>that are being worked on/tested... >> >>i'm not claiming my parallellism is bugfree. i never will. I'm talking >>about the single processor version. Of course i never tried to find the >>bug in the compiler. I only looked for bugs in DIEP all that time. >> >>If i compile kernels or the gcc compiler i see weird warnings which i would >>never want to have in my program. And then compile the new gcc compiler, >>also seeing all kind of weird warnings, then >>that gives people stuff to think about. > > >warnings really are 'warnings'. 99 % of them are type mismatches in procedure >calls, but since it knows this, it does the conversions just fine. I compile >linux with my old pgcc for years... and it has worked _flawlessly_. And I >don't think either your program nor mine are _anything_ like as complex as >Linux is... > > > > > > >> >>There were definitely bugs in gcc, that's the only sure thing. >>I'm happy DIEP runs very good now. Next >>step is of course bugfree parallel. > > > >There were no documented bugs that I am aware of... If you believe that the >compiler was the problem, I'm not going to try to convince you otherwise. But >you are going to be sadly disappointed when the bugs finally show up and get >fixed... and they turn out to be 'hidden' bugs in your code... Here just some observations using gcc2.95. On a Sun Ultra Sparc (2 proc) I tried to compile Crafty 16.15. For the following compiler flags I got: -O worked. -O2 core dumped. -O3 core dumped. So I'm able to produce a working crafty, but no higher optimization than -O. Kind regards Bernhard
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.