From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: *** X-Spam-Status: No, score=3.2 required=5.0 tests=BAYES_00,RATWARE_MS_HASH, RATWARE_OUTLOOK_NONAME autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1014db,dab7d920e4340f12 X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,dab7d920e4340f12 X-Google-Attributes: gid103376,public From: "Tim Behrendsen" Subject: Re: C is 'better' than Ada because... Date: 1996/07/30 Message-ID: <01bb7e2f$aeef4660$87ee6fce@timpent.airshields.com> X-Deja-AN: 171101275 references: <31e02c32.342948604@netline-fddi.jpl.nasa.gov> <4rr961$hdk@btmpjg.god.bel.alcatel.be> <31e180c5.430136383@netline-fddi.jpl.nasa.gov> <4s4adc$l4a@ecuador.it.earthlink.net> <31EA0B65.3EF8@wgs.estec.esa.nl> <31EF7E48.5ABE@lmtas.lmco.com> <01bb7bfc$3c5ca460$96ee6fcf@timhome2> <4tkeuk$cu2@goanna.cs.rmit.edu.au> content-type: text/plain; charset=ISO-8859-1 organization: A-SIS mime-version: 1.0 newsgroups: comp.lang.ada,comp.lang.c Date: 1996-07-30T00:00:00+00:00 List-Id: Richard A. O'Keefe wrote in article <4tkeuk$cu2@goanna.cs.rmit.edu.au>... > In article <01bb7bfc$3c5ca460$96ee6fcf@timhome2> "Tim Behrendsen" > writes: > > Behrendsen's Law: "All optimizers are crap." > > [paraphrase: Modern compilers *awesome*, global optimizations, run time > [profiles for next compilation cycle. Humans too busy to/can't do this] I'm not going to claim to have used every compiler, obviously, but I base this opinion on often viewing the assembly language output when I get a core dump or during debugging sessions. Now, I've used a lot of assembly language, so I usually write my C code to be easy on the optimizer (use pointers when needed rather indexes, for example), and I admit that sometimes optimizers are very good. The problem is, the compiler often doesn't have enough contextual information to know what to do compared to the human writing the program, which bring us to ... Global optimization: The compiler can often make decisions better than the human can because of the large scope of global optimizations, but again, the information needed to know when certain areas are going to be used a lot versus other areas is not known at compile time, which moves us to ... Run time profiling/compiler feedback: This can certainly provide good information back to the compiler, but it seems a little dangerous. I have not used this type of optimization, so my opinion means little in this case, except for just my general impression. Anything other than a trivial program is going to be very difficult to simulate real-world conditions in order to get an optimal result. The downside is if your test conditions are wrong, you may end up with a "most pessimum" optimization. It just seems to me that there is no substitute for a well thought-out design. Depending on the compiler to save bad design is just a bad idea. > > We will never have an optimizer that can do as good a job > > as human optimization until we get "strong AI", but that would > > take an actual science of AI to exist (let's not get started on > > *that*!). C is one of few languages that recognizes this. > > You just haven't a clue about the things modern compilers can do, and do do. > Loop unrolling, strip-mining, vectorising, analysing the class hierarchy so > as to replace dynamic dispatch by inlined code, branch prediction based on > profiles, AND IT ALL HAPPENS EVERY TIME I RUN THE COMPILER. What we get > right now is better than almost every programmer there is, and we get it > far cheaper. The above are all worthwhile opimizations; I'm not claiming that optimizers do nothing. All I'm saying is that too often programmers fall back on the lazy line, "Oh well, the compiler should take care of that." For example, if I have ... for (i = 0; i < 10000000; ++i) array[i] *= abs(values[i]); Should I be *sure* this is going to be done efficiently, and use pointers, or should I just let the compiler handle it? I say that a competent programmer should use pointers out of habit, because its just good design and practice. And when the problem becomes less trivial than the one above, the programmer will already be using the proper techniques *the first time*, rather than having to go back and fix the inevitable performance bottlenecks. I think you are being too optimistic that optimizers produce better code than "almost every programmer there is". If that were true, then projects would *never* be written in assembly language. As it stands, we know that often times things are written in assembly for performance reasons, such as device drivers. The perfect example of this are computer games. If your theory were true, then they would all be written in high-level languages to gain the best performance. We know that this isn't the case, however. A bright human can always outdo the optimizer. > And you know what? C is one of the *harder* languages to optimise! You are probably right, if you let the optimizer handle everything. But C also gives the capability to do things such as ... if ((array[++n] = GetValue(arg)) != 0) { .... v.s. a typical non-C language ... n = n + 1; array[n] = GetValue(arg); if (array[n] != 0) { ... } Now, which is easier to optimize? For this trivial case, a modern compiler would probably do exactly the same thing, but what about when it starts getting non-trivial? If I code my expressions to take advantage of the "data flow" nature of C's syntax, I can make it very easy for the optimizer to do a great job. And it's not any more work, it's just a matter of experience and living in reality, and not pretending that the compiler is smarter than it really is. -- Tim Behrendsen (tim@airshields.com)