Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!uflorida!novavax!proxftl!bill From: bill@proxftl.UUCP (T. William Wells) Newsgroups: comp.lang.c Subject: Re: Array indexing vs. pointers... Summary: A mild flame: context determines goodness Message-ID: <836@proxftl.UUCP> Date: 30 Sep 88 06:22:32 GMT References: <8809191521.AA17824@ucbvax.Berkeley.EDU> <68995@sun.uucp> <23025@amdcad.AMD.COM> <607@ardent.UUCP> Reply-To: bill@proxftl.UUCP (T. William Wells) Organization: Proximity Technology, Ft. Lauderdale Lines: 120 Expires: Sender: Followup-To: Distribution: Keywords: In article <607@ardent.UUCP> mec@ardent.UUCP (Michael Chastain) writes: : Good grief. Say NO to low-level performance tweaking. Good grief. Say NO to understanding the language well enough that "low-level performance tweaking" is natural to the programmer. Grrr. Note that the quotes here are because I disagree that the programming practices being condemned constitute "low-level performance tweaking". : I prefer to use the most natural data representation I can think of. : If something's an array, I don't dink around inside it with pointers. This completely irrelevant: one man's "natural" is another's perversion. The claim that such is "natural" is only a statement of a personal preference. My own preference is to think in terms of pointers exclusively; and I tend not to use array indexing. Note that I do not advocate using pointers for this reason, I do so for a completely different one, which I will state shortly. : If you had to debug this code with a typical sdb-like debugger, which : would you rather look at? "iArg" or "argv"? I find wild array : references easier to deal with than wild pointer references: less : likely to occur, easier to debug/find when they do. I find all of : these properties more useful than the small and doubtful performance But *I* don't. Personal preferences aren't natural law. : gain that I can get by *increasing the entropy* of my code and data. This asserts that the use of pointers increases the disorder (that is what entropy is about, after all) in one's code and data; this is entirely a subjective judgement. --- At one time, I spent a lot of my spare time improving other people's code. One of the things I discovered is that almost all the code I was dealing with had better than 25% execution time fat. What I mean is that when I merely changed all of the code to follow my coding practices (which are not anything special, just obvious things that every coder ought to know), it got that much better; I am not talking about mere tweaks, nor am I talking about optimizing particular sections of code. I am talking about reading each line of code and making obvious changes (things like using temporaries when needed, adding appropriate register declarations, eliminating obviously unnecessary function calls, etc.) Supposing that the 90-10 rule actually applies (which experience shows to be something of an exaggeration, and utterly irrelevant to a lot of well written code), and I were to take the same code and optimize that 10% as much as possible. I might expect that to double the speed of the 10%. Now, how much faster would this unrealistic example get? 45%. Now, let us compare these: if the programmer had trained himself to code my way, he could have written the program to be 25% faster *with no additional effort*. Or, he could have it 45% better doing it the original way, after all the additional effort to optimize that 10% (if we are being optimistic, that is). If he were to spend that extra effort on the code that follows my practices, the resultant code would be 59% faster. The point of all this is that learning coding practices that result in writing reasonably fast code, and applying them, can result in code that is as good or better (when measured by execution time) as code written to standards that ignore execution speed which is then optimized as necessary. And having learned to do this, one does not have to spend extra effort to make faster code, it comes "naturally". What I am calling for is an understanding of what kind of coding practices make for good code, and the inclusion of execution speed in the definition of "good code". --- Now, as I said, I will justify why *I* use pointers almost to the exclusion of arrays. Most of the code I write in which efficiency is a concern falls into one of two categories: code that takes a long time to run, but will be run on a particular kind of machine, and code that takes a fairly short time to run, but will get run on damn near every kind of machine that is capable of running it at all. For the code that takes a long time to run, it happens that it will be run on a more-or-less conventional architecture: this means that pointer references are generally going to be faster than indexing. For the others, what happens is that the unconventional architectures also run the programs very quickly: the execution time does not matter for these. However, for a certain class of conventional processors, the execution time is of great performance: if the code is not fast enough on an 8086 (or equivalent), it just isn't useful. For most of these slower processors, indexing is much slower than using pointers. Now, for the last case, the reason is compelling: I *must* use pointers instead of indexing as the code will not be fast enough. And, at least for my code, the 90-10 rule is pure BS: rarely does *any* subsystem (never mind particular functions) get more than 20% of the execution time. --- The long and short of the above is that neither indexes or pointers are intrinsically better than the other; programming being a utilitarian art, "better" depends on what you want to use it for. And in C, given the equivalence between indexing and pointer arithmetic, there can be no abstract reason for preferring one above the other. --- Bill You can still reach me at proxftl!bill But I'd rather you send to proxftl!twwells!bill