psrc@poseidon.ATT.COM (Paul S. R. Chisholm) (10/15/88)
<"He seemed like such a nice man . . . and then he turned out to be a writer!"> In article <8595@smoke.ARPA>, gwyn@smoke.ARPA (Doug Gwyn ) writes: > In article <517@poseidon.UUCP> psrc@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@poseidon.att.com (formerly psc@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.