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/08/01 Message-ID: <01bb7fd4$6a0f4300$87ee6fce@timpent.airshields.com> X-Deja-AN: 171565101 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><01bb7e2f$aeef4660$87ee6fce@timpent.airshields.com> content-type: text/plain; charset=ISO-8859-1 organization: A-SIS mime-version: 1.0 newsgroups: comp.lang.ada,comp.lang.c Date: 1996-08-01T00:00:00+00:00 List-Id: William Clodius wrote in article > There is no reason why a good compiler should generate worse code for > an array access than for a pointer access. An array can be constructed > by the compiler as a single block of memory whose access via indices > is the same as through a pointer. Au contraire, because a pointer can > be associated with any object of compatible type the analysis for a > highly optimizing compiler is more difficult with pointers than with > arrays. The problem with arrays in C is their lack of flexibility in > term of dynamic memory allocation, that if they are associated with a > pointer at any point in the scope alias analysis becomes more > compicated for the compiler, and that when pased as an argument > to a user defined function they are not distinguished from pointers. I normally use IBM's C compiler under AIX. I'm not sure where it fits in the scheme of things, but it seems to do a pretty decent job optimizing. I had an [ex-]employee who wrote the slowest code on the face of the earth. Because of performance problems in our application, I went through and analyzed his code. The man almost never used pointers, and almost always used array accesses. These algorithms were much more complex that the trivial examples we've been talking about. I rewrote the subroutines to use pointers, and with an eye toward easy optimization by the compiler. The algorithms used were exactly the same; I just reworked the stylistic expression of them. I didn't view the assembly language output, or anything processor specific like that. I simply coded things in a straightforward data-flow sort of way, keeping the amount of context information that the compiler needed at any one point in the subroutine to a minimum. I was easily able to get 3-4x performance improvements. My point is that, yes, optimizers can do a good job in certain circumstances, but out in the real world with very complex subroutines, there is only so much that is possible. Perhaps I've only used compilers with bad optimizers, but isn't it better to code programs for straightforward optimization and not depend on what goes on behind the scenes? Who goes back and checks what the compiler produced? At least until you begin profiling the program to figure out why the darn thing is so slow ... > 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. > > But if your test conditions are wrong you have typically not > appropriately tested all aspects of the code, including the > correctness of its output, its robustness, and its general > efficiency. I disagree; I can test all the code paths without them necessarily being executed the relative number of times that a real world test would bring. Take a relational DBMS; I can test all of the SQL constructs that may be supported, but that doesn't mean that I have real-world databases at my disposal in order to general code optimization statistics. > Actually C has relatively little in the way of data flow concepts as > data flow is commonly understood. A true data flow language would > avoid side effects in almost every context except I/O. Your example is > full of side effects, some of which, particularly GetValue(arg), are > difficult to optimize. Depending on the context a data flow language > might have the syntax > > array[1:n] = GetValye(arg(1:n)); > where (array /= 0) { ... } > > in the above GetValue is required to not have side effects so that the > definition > > array[1:n] = GetValye(arg(1:n)); > > can be understood as occuring in parallel. In C for full optimization > the compiler has to determine that arg is not aliased with elements of > array, and that GetValue has no side effects. Note that a highly > pipelined architecture is comparable to a truly parallel architecture > in many optimization issues. I would imagine that C would rather stink when it comes to automated parallization (but then, what doesn't?). Ordering a pipeline is much less complex of a problem that parallelizing an algorithm, though! If I'm not mistaken, however, it used to be the case the parallelizing compilers were primarily for FORTRAN, because of it's very primitive (read: lack of side effects) nature. This is somewhat dated knowledge on my part, though. There may be more sophisticated solutions out there nowadays. I guess my point is not that any construct in C is automatically able to be optimized to the limit; it's that it's possible to code things in such a way that it gets optimized very well. -- Tim Behrendsen (tim@airshields.com)