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: Giuliano Carlini Subject: Re: What's the best language to start with? [was: Re: Should I learn C or Pascal?] Date: 1996/08/13 Message-ID: <32114FEF.17DC@ix.netcom.com>#1/1 X-Deja-AN: 174061467 references: <31FBC584.4188@ivic.qc.ca> <01bb8342$88cc6f40$32ee6fcf@timhome2> <4u7grn$eb0@news1.mnsinc.com> <01bb83ad$29c3cfa0$87ee6fce@timpent.airshields.com> <4u89c4$p7p@solutions.solon.com> <01bb83f5$923391e0$87ee6fce@timpent.airshields.com> <01bb8534$b2718bc0$87ee6fce@timpent.airshields.com> <01bb87cf$97ae8e80$87ee6fce@timpent.airshields.com> <01bb88d4$022bf4a0$32ee6fce@timhome2> content-type: text/plain; charset=us-ascii organization: Netcom x-netcom-date: Tue Aug 13 11:03:11 PM CDT 1996 mime-version: 1.0 reply-to: giuliano@ix.netcom.com newsgroups: comp.lang.c,comp.lang.c++,comp.unix.programmer,comp.lang.ada x-mailer: Mozilla 3.0b6Gold (Win95; I) Date: 1996-08-13T23:03:11-05:00 List-Id: Tim Behrendsen wrote: > > Dan Pop wrote in article > ... > > In <01bb87cf$97ae8e80$87ee6fce@timpent.airshields.com> "Tim Behrendsen" > writes: > > > > >Dan Pop wrote in article > > >... > > >> In <01bb8534$b2718bc0$87ee6fce@timpent.airshields.com> "Tim > Behrendsen" > > > writes: > > >> > > >> >Here's an example: > > >> > > > >> >int a[50000],b[50000],c[50000],d[50000],e[50000]; > > >> > > > >> >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). The > > >> >reason I knew the second would be faster is because I know > > >> >to limit the amount of context information the optimizer has > > >> >to deal with in the inner loops, and I know to keep memory > > >> >localized. > > >> > > >> 1. For a marginal speed increase (~25%), you compromised the > readability > > >> of the code. > > > > > >You call 25% a "marginal" increase? Actually, I would too. Typically, attacking slow spots by changing algorithms, small changes to interface that permit massive performance speedups, etc will often result in 50 to 90% speedups. And these optimizations are portable, whereas depending on the optimizer is not. > > > > Yes, I do call 25% a marginal increase. Would you be considerably > happier > > if everything would run 25% faster, at the expense of everything being > > harder to develop and maintain by a factor of 2? > > No, I wouldn't be happier with "a factor of 2", but that's a > very large presumption. Who's doing anything strange and > arcane? I just made it easier on the compiler / computer. As another data point, It did take me a lot longer to understand code snippet 2 than one. Maybe 50%, maybe 200%, I can't say for sure; my internal clock doesn't act like a stopwatch ;-> Depending on where in the code we're talking about, either of you could be "right". The only 90/10 rule (90% of the execution time is taken by 10% of the code) would dictate using this optimization in frequently executed paths. The original is superior everyplace else due to comprehension. > Well, the compiler didn't do a very good job, does it? > And that's the whole point. It is ivory tower naivete to > think that compilers optimize everything perfectly every > time. Generally programmers shouldn't be optimizing code by hand unless they are sure it affects the "bottom line". So, if a performance analysis shows that you need to contort your code to get a major speed-up, I'm all for it. Otherwise, avoid them like the plague. g