More on efficiency (was: Array indexing vs. pointers)

Paul S. R. Chisholm psrc at poseidon.ATT.COM
Sat Oct 15 03:11:45 AEST 1988


<"He seemed like such a nice man . . . and then he turned out to be a writer!">

In article <8595 at smoke.ARPA>, gwyn at smoke.ARPA (Doug Gwyn ) writes:
> In article <517 at poseidon.UUCP> psrc at poseidon (Paul S. R. Chisholm) writes:
> >Moral:  A really good C programmer should know assembler language and
> >compiler technology to write ordinary applications efficiently.

> I have to disagree with this.  What is "efficient" for one implementation
> may not be efficient for another, and most real C applications end up being
> used with several different C implementations.

I agree.  That's why you need to know, not your specific processor's
strengths, but also what different compilers can and can't do on
different processors.  That's what I meant by "compiler technology".

The real gains in speed will come from the design, not the coding.  But
code should be written as if it's important.  Someone in another
discussion has suggested you can get a ten percent speed up that way.
I'd believe that.  You can also probably save ten percent of your space
that way, and space doesn't follow a 90%-10% rule.

>                                                 Low-level tweaking should
> only be done when a specific implementation has unacceptable overhead in
> some "bottleneck" code, and only after the algorithmic aspects of the
> application have been made as good as possible.  Jon Bentley's book on
> "Writing Efficient Programs" is recommended reading.

Let me second both of these statements.

Paul S. R. Chisholm, psrc at poseidon.att.com (formerly psc at lznv.att.com)
AT&T Bell Laboratories, att!poseidon!psrc, AT&T Mail !psrchisholm
I'm not speaking for the company, I'm just speaking my mind.



More information about the Comp.lang.c mailing list