Re: Justifying Optimization

"Conor O'Neill" <ONeillCJ@logica.com> wrote in message news:03-01-137...
>
> However, I'm also coming more to the view that it is not necessary to
> optimise _everything_. Typically, your numerical sections would
> benefit greatly from optimisations, but much of your program logic has
> such random access patterns that a compiler can't do much with it.


If it were simply the question of optimization vr.s no optimization,
I'd agree with you. But I think it's a question of optimization vs
obfuscation. More programming sins are committed in the name of
performance than any other reason, including stupity. Optimization is
the first line of defense against this, it allows us to go "Write
clean, simple code! The optimizer will make it run fast!"


If performance is really not important, fine. Don't compile with
optimization. But the *millisecond* you think "I should speed this
up", stop and turn optimization back on. Or don't speed the code up.


It always start so innocent- the first hit is free. Just change this
%2 to &1. Eliminate this common subexpression. Use pre/post
increment/decrement a little more often. Do a little more in this
expression. Next thing you know, you're hand unrolling loops and hand
inlining functions. Code- and bugs- are replicated all over the
place, maintainance has been shot to hell, and the flow and structure
of the code is completely obscured by the optimizations.


Here's the punchline: every one of those optimizations I mentioned is
doable by most compilers. By turning optimization on, you could have
the best of both worlds- high performance code, and *maintainable*
code. Instead, you're likely to end up with neither.


Many compilers allow you to debug with at least some optimization
turned on. I know gcc does- I don't remember for the compilers
specifically named in the original post. Debugging with optimization
turned on is a little more tricky, you need to have some understanding
of how the optimizer works so the bouncing around isn't surprising.
But this is a good idea anyways, if for no other reason so that you
know what optimization the compiler can do automatically and what
optimization you might need to do yourself.


As a side comment, I think a lot of programmers prefer to
hand-optimize, even if the computer can do it faster and better for
them. To be a programmer (and survive) you have to like complexity.
Some code is just inately boring. I mean, consider:
        for (i = 0; i < len; ++i) {
                a[i] = f(b[i]);
        }
how much pride can you have in writting that? Good lord, it's a
simple for loop. On the other hand, if you see:


        switch (len % 8) {
                do {
                        case 0: *a++ = f(*b++); len--;
                        case 7: *a++ = f(*b++); len--;
                        case 6: *a++ = f(*b++); len--;
                        case 5: *a++ = f(*b++); len--;
                        case 4: *a++ = f(*b++); len--;
                        case 3: *a++ = f(*b++); len--;
                        case 2: *a++ = f(*b++); len--;
                        case 1: *a++ = f(*b++);
              } while (--len > 0);
        }


you know a 31337 hax0r wrote the code. Saracasm intended- especially
once you recognize that the second piece of code a) is probably slower
(even unoptimized) on modern hardware, b) is harder to maintain, and
c) introduces a bug (hint: what happens when len == 0?). But it takes
a simple peice of code, and makes it complex. And helps to hide
exactly how simple their code really is.


The only other reason I can think of for programmers to both contort
their code and resist optimization (and I've seen this all too often)
is rampant stupidity.


Brian

Return to the comp.compilers page.
Search the comp.compilers archives again.