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=3.2 required=5.0 tests=BAYES_00,RATWARE_MS_HASH, RATWARE_OUTLOOK_NONAME autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,baaf5f793d03d420 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,97188312486d4578 X-Google-Attributes: gid103376,public X-Google-Thread: fc89c,97188312486d4578 X-Google-Attributes: gidfc89c,public X-Google-Thread: 1014db,6154de2e240de72a X-Google-Attributes: gid1014db,public From: "Tim Behrendsen" Subject: Re: What's the best language to start with? [was: Re: Should I learn C or Pascal?] Date: 1996/08/11 Message-ID: <01bb87cf$97ae8e80$87ee6fce@timpent.airshields.com> X-Deja-AN: 173574483 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> content-type: text/plain; charset=ISO-8859-1 organization: A-SIS mime-version: 1.0 newsgroups: comp.lang.c,comp.lang.c++,comp.unix.programmer,comp.lang.ada Date: 1996-08-11T00:00:00+00:00 List-Id: Dan Pop wrote in article ... > In <01bb8534$b2718bc0$87ee6fce@timpent.airshields.com> "Tim Behrendsen" writes: > > >Dan Pop wrote in article > >... > > > >I've spoken to enough people that have had C++ disasters to > >convince me that the more abstraction there is, the more > >danger there is of inefficient code. This shouldn't be that > >hard to believe; any time you abstract away details you are > >giving up knowledge of what is going to be efficient. > > Nonsense. The efficiency of an implementation can be also thought in > abstract terms, you don't need to know how the compiler works or > assembly language in order to implement your application in an efficient > way. Or you may know all these irrelevant details and still write > inefficient code, because it's so much easier in many OOPLs. Certainly the most influential factor to the speed of an application is the algorithms that are chosen. No question. That having been said, why are application written in OOPLs often very inefficient? I think it's because they are built up with so many abstract black boxes that it's difficult to keep track of the interactions between the pieces. Same with HLLs. They are nothing more than "objects" on top of the assembly language. Any time you have generalization you introduce inefficiency, and knowing the general principles behind how things are going to compile can only help. An example from another post is recursion; show me the computer where recursion is not slower than a non-recursive implementation of an algorithm > >I alluded to this in another post, but a good example is Motif > >and X11. A programmer who only understands Motif, but does not > >understand X11 is going to write slow crap, period. > > More nonsense. Unless your applications spend the bulk of their CPU > time in the user interface, that should be a non-issue. You obviously haven't done much Motif programming. Example: If you are not careful, you can introduce a round trip every time you specify a color. > >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? It's attitudes like this that give us the slow code world we have right now. And how is one less readable than the other? > 2. Another compiler, on another system, might generate faster code > out of the test1. This is especially true for supercomputers, > which have no cache memory (and where the micro-optimizations are done > based on a completely different set of criteria) and where the cpu time > is really expensive. Show me the computer where test1 comes out faster. Or shouldn't we depend on the compiler to optimize this? > 3. You used exclusively abstract concepts to justify why test2 is > faster on your particular platform/compiler combination. No references > to the length of a cache line or to the compiler being able to use > a more efficient instruction or instruction combination in one case > than in the other. > > Let's see what happens on my 486DX33 box: > > So, it's 1.10 + 0.23 = 1.33 seconds of cpu time for test1 versus > 1.17 + 0.18 = 1.35 seconds for test2. Conclusions: > > 1. My 486DX33 is faster than your AIX system (or maybe gcc is faster than > xlc) :-) Oops! I just realized my AIX program had 100 for the outer loop, not 10 (had me worried for a minute there ...) > 2. Your results are not reproducible. Your extra "insight" simply "helped" > you to generate less readable code. Actually, try again with 500 or 5000 in the inner loops; 50000 probably flushed the cache. In any case, the code is identically readable either way IMO, and costs you nothing to implement the efficient way. So it wasn't on one architecture, big deal. On the average, it will be, and costs nothing to do it that way/ > >Now I submit that if I showed the average C programmer > >both programs, they would guess that test1 is faster because > >it has "less code", > > And he might be right, both on a CP/M-80 micro and a Cray supercomputer. > Or on most systems with a compiler that can do loop unrolling. Not gonna find this mythical bizarre beast, except for trivial differences because of the extra loop overhead. > >and that is where abstraction, > >ignorance, and niavete begin to hurt. > > The key to proper optimization is profiling. Additional knowledge about > a certain platform is a lot less important. Agreed; optimization shouldn't be to a certain platform, but optimizations can be made on general basis. Again, is it the case that I can order my code into any algorithmically valid sequence and get identical running times? > And if the wrong algorithm has been chosen in the first place, no > amount of micro-optimization will save the code performance. The guy > who can do a decent algorithm analysis (an entirely abstract operation) > will always beat the one who is an expert assembly programmer but > prefers to spend his time coding instead of dealing with abstractions. Agreed. -- Tim Behrendsen (tim@airshields.com)