Re: What's the best language to start with? [was: Re: Should I learn C or Pascal?]

[seebs@solutions.solon.com (Peter Seebach)]

In article <01bb8534$b2718bc0$87ee6fce@timpent.airshields.com>,
Tim Behrendsen <tim@airshields.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.

>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.

Abstraction itself is an intentional inefficiency in most cases.  A
function which writes to files on disks *or* to terminal devices is
*guaranteed* to take at least one more test than a simpler function
which handles only one.

>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.

No, a programmer who uses Motif at all is likely to generate slow programs,
because there are too many layers involved, and I'm not sure either X *or*
Motif is a good model.

>Now, we know that this does not reflect the real world.  The
>question is, how does a programmer learn the efficient
>implementations that the optimizer can deal with effectively
>from the boneheaded ones?

A programmer does this, *IF IT BECOMES NECESSARY*, by experimenting.

>Here's an example:

>int a[50000],b[50000],c[50000],d[50000],e[50000];

This is not a strictly conforming C program.

>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.

>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 that is where abstraction,
>ignorance, and niavete begin to hurt.

I am unconvinced that this example is remotely relevant to the general case.

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.

Abstraction is a trade-off of maintainability and readability vs. code
speed.

I would not expect test1 to be faster.  I would write it anyway, because
I would not expect it to be much slower.  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.

The cool thing is, I can unroll the loop in test1 much faster than you can
unroll all the loops in test2.  Further, it is obvious in test1 that the
intent is to do the same thing to each array.

The problem with most slow code is not microoptimizations like this; it's vast
inefficiencies at the basic design level.

If I could arrange to need only one of those five arrays, I bet my code would
be faster than yours, no matter *how* much you optimized it.

-s
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 - http://www.solon.com/~seebs
Unix/C Wizard - send mail for help, or send money for consulting!
The *other* C FAQ, the hacker FAQ, et al.  See web page above.
Unsolicited email (junk mail and ads) is unwelcome, and will be billed for.