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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fc89c,97188312486d4578 X-Google-Attributes: gidfc89c,public X-Google-Thread: 109fba,baaf5f793d03d420 X-Google-Attributes: gid109fba,public X-Google-Thread: 1014db,6154de2e240de72a X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,97188312486d4578 X-Google-Attributes: gid103376,public From: cjsonnack@mmm.com (Chris Sonnack) Subject: Re: What's the best language to start with? [was: Re: Should I learn C or Pascal?] Date: 1996/08/09 Message-ID: <4ug5u5$kha@dawn.mmm.com>#1/1 X-Deja-AN: 173193767 references: <31FBC584.4188@ivic.qc.ca> <01bb83f5$923391e0$87ee6fce@timpent.airshields.com> <01bb8534$b2718bc0$87ee6fce@timpent.airshields.com> <4ud81d$5ii@solutions.solon.com> followup-to: comp.lang.c,comp.lang.c++,comp.unix.programmer,comp.lang.ada organization: 3M/IT/EIS (St.Paul,MN 55144) reply-to: cjsonnack@mmm.com (Chris Sonnack) newsgroups: comp.lang.c,comp.lang.c++,comp.unix.programmer,comp.lang.ada Date: 1996-08-09T00:00:00+00:00 List-Id: Peter Seebach (seebs@solutions.solon.com) wrote: >> Look at the code-bloated and slow-software world we live in, >> particularly on desktop platforms. I think this is caused by >> people not truly understanding what's *really* going on. > > I believe it's caused by people who have a poor understanding of what > they're trying to do. Or more likely, both. >> void test1() { >> int i, j; >> for (j = 0; j < 10; ++j) { >> for (i = 0; i < 50000; ++i) { >> ++a[i]; ++b[i]; ++c[i]; ++d[i]; ++e[i]; >> } >> } >> } >>void test2() { >> int i, j; >> for (j = 0; j < 10; ++j) { >> for (i = 0; i < 50000; ++i) ++a[i]; >> for (i = 0; i < 50000; ++i) ++b[i]; >> for (i = 0; i < 50000; ++i) ++c[i]; >> for (i = 0; i < 50000; ++i) ++d[i]; >> for (i = 0; i < 50000; ++i) ++e[i]; >> } >> } >> On my AIX system, test1 runs in 2.47 seconds, and test2 >> runs in 1.95 seconds using maximum optimization (-O3). > > I am unconvinced that this example is remotely relevant to the general > case. Probably not, but the real world does contain specific cases like this. I really don't understand the resistance to the idea that programmers should understand AS MUCH AS POSSIBLE about their craft. I really don't. It's like an auto mechanic who doesn't want to know as much as possible about how car engines work. Which mechanic would you rather hire; one who knows the high-level stuff and can do MOST types of work, or one who can build an engine from scrap metal? If you (generic you) don't want to learn about the metal, fine. That means I can get hired over you when the job entails embedded programming or device drivers or a lot of other tasks fully rounded programmers may face. Do I like assembly? Hell, no. Am I fully capable of being hired for a job that requires its use? Hell, yes. > In particular, in the real world, would you rather maintain code more like > the first or the second? I'd prefer to maintain the first; it would be > easier to change all occurances of 50000, if this needed to be done. They're both pretty clear. And any real programmer knows rule #27: "There should be no constants in your code except the numbers 1 and 0, and you should view those with suspicion." A real programmer would use a #define for the 50000, so changing it would be easy in either event. > Abstraction is a trade-off of maintainability and readability vs. code > speed. The above example has little to do with abstraction either way. The more general case would be, how does one code large loop constructs. This is one case where understanding the underlying concepts does help. > If, *and only if*, there turned out to be a performance problem, I'd > probably start by unrolling the loop in test1, possibly getting a > much greater performance increase. I'm not sure unfolding a ten-fold iteration would do much. Ten times a really tiny bit is still a pretty tiny bit. The key here is that a programmer who already understands BOTH the high- and the low-level would naturally write it the "right" way first. In the real world, doing it right the first time counts for a lot. > Further, it is obvious in test1 that the intent is to do the same thing > to each array. As written, it's obvious in both cases. > The problem with most slow code is not microoptimizations like this; it's > vast inefficiencies at the basic design level. Absolutely. -- Chris Sonnack http://eishcq.mmm.com Engineering Information Services/Information Technology/3M, St.Paul, Minn ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It takes a long time to understand nothing. Opinions expressed herein are my own and may not represent those of my employer.