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.8 required=5.0 tests=BAYES_00,INVALID_MSGID, 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: 103376,dab7d920e4340f12 X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,dab7d920e4340f12 X-Google-Attributes: gid1014db,public From: "Tim Behrendsen" Subject: Re: C is 'better' than Ada because... Date: 1996/08/03 Message-ID: <01bb80f9$5df267c0$9cee6fce@timhome2>#1/1 X-Deja-AN: 171889691 references: 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-03T00:00:00+00:00 List-Id: William Clodius wrote in article ... > In article <01bb7fd4$6a0f4300$87ee6fce@timpent.airshields.com> "Tim > Behrendsen" writes: > > > > 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. > > > [paraphrase: Anecdote about bad code with very complex array] > [manipulations being 3-4x slower than code rewritten with pointers] > > This anecdote by itself says nothing. It says that you had an employee > wrote slow code and that he used arrays. Unfortunately, because you > never determined the specific sources of the inefficiencies, it does > not say that the slow code was due to the use of arrays. It could very > well be due to the misuse of arrays, in particular if he used column > major order instead of C's preferred row major order, or due to > entirely different reasons. It is possible for a knowledgeable person > to write very efficient code using arrays. Well, you say my anecdote says nothing, then turn around and say that it requires a "knowledgeable person" to do arrays correctly. If modern compilers are so good that programmers shouldn't have to worry about using arrays, then it should have been smart to optimize "misuse of arrays". The point is, pointers are native to machine architectures, so it's going to be easier for the optimizer to produce straightforward optimizations if the programmer doesn't do anything dumb by creating unsafe side effects. -- Tim Behrendsen (tim@airshields.com)