Re: Interesting article by Randall Hyde


Scott Moore wrote:
> >
>
> I would never imply that VC++ or GCC produce infailable machine code.
> In my opinion, based on looking at the output in assembly, and the
> results on benchmarks, that VC is not good at all, and GCC, while
better,
> is hardly ideal.

Well, as you are the compiler optimization "expert". Why don't you post
some code from a compiler that you feel does a better job? I, for one,
would like to see some additional data points.

>
> Well, you picked two compilers, one that is free, and another that
> might as well be free (VC++) since it is fairly well tied up to
microsoft
> offerings.
>
> I *imagine* Intels own compiler is better,

And this is *exactly* the point I'm making.
For a couple of decades, now, people have been suckered by the
statement "compiler optimizations are so good that they produce better
machine code than human assembly programmers."

Granted, it is *very* easy to find a few examples where compilers do a
spectactular job (and I'm talking about compilers like MSVC and GCC,
which you seem to think do a horrid job). But when you start looking at
large sets of compiler inputs and outputs, you begin to find that
examples where the compilers are absolutely brilliant tend to be
matched by examples where the compilers do some of the stupidest
things.

Whenever this fact is pointed out to the "let the compiler optimize for
you" proponents, the response is almost universally "well, you should
be using a better compiler." I've been hearing this line for over 15
years now. When pressed, though, the "proponent" will say something
like "I *imagine* Intels own compiler is better". IOW, their statements
are based on assumptions, heresay, or someone else's opinion rather
than personal experience.

Now I have no doubt that there is some compiler out there that will do
a *much* better job on this particular example that I'm griping about
right now. Indeed, I had *hoped* someone would post code I could use.
Or, at least, someone could point out a good reason why the code can't
be moved out of the loop (because I sure can't see a reason why).

> but I'm not about to buy
> the compiler, for the simple reason that I don't program in C.

So, then, why are you making comments about the quality of compilers
when you don't have the experience to back those statements up? Sure,
you're repeating stories you've heard elsewhere (OH! Microsoft is bad.
They write bad code. Their compilers *must* generate horrible code).
You're on shaky ground here.

> In fact, I am not particularly impressed with the optimizability of
> C in general.

We certainly agree that the C language is not particularly optimizable.
Pascal, for example, is much easier to optimize. OTOH, more research
has gone into optimizing C than any other language I'm aware of, and
other than FORTRAN it's leaps and bounds above everything else in terms
of the work that has gone into creating optimizing compilers. FORTRAN's
up there too, but a lot more work has gone into C (/C++) for obvious
reasons.

> The idea of C was originally that it was supposed to be
> a simple compiler that left most optimization up to the programmer
> (for example, the i++ operator performs what most optimizing
compilers
> already did with i = i+1).

Ritchie denies that this was the reason for the ++ operator (and other
so-called "optimized" operators such as "+="). He claims they were
stuck in the language for convenience. Maybe he was lying, I don't
know. But I tend to believe the language designer in these matters.
What would he have to gain by lying about it?

> We both agree that C is no longer a
> low optimization language, but what that says is that people will put
> optimization effort into whatever language is in demand, regardless
of
> the merits of the idea.

Exactly.
And given all the research that has gone into creating optimizing C
compilers, I would have expected this one example to have produced
better machine code via the application of these well-known techniques.



> Compilers generate better code than *most* programmers all of the
time,

Quite frankly, because *most* programmers aren't very good :-(.

> and better code than expert programmers *most* of the time.

Depends. Is the "expert" programmer *trying* to create good code, or
are they just hacking stuff out? Based on the code I've been looking at
lately, I would not say "most of the time." "Some of the time",
definitely, but not "most of the time."

The other issue, and this is the crucial point I want to make, is that
the quality of a compiler's output is *highly* dependent upon the input
you feed it. An expert C programmer, who understands how compilers
operate and optimize code, can write their C source code in a manner
that will produce *very good* machine code *most* of the time (the
strlen example at hand is a good example of a failure; in my case I
guess I knew a little too much about compiler optimization and I
expected the compiler to deal with that issue). Very carefully written
C code *can* produce code that is almost as good as hand-written
assembly language. Indeed, that's the premise of a book I'm currently
working on. However, it *takes* an expert programmer to help the
compiler produce code that is better than expert programmers most of
the time :-)


> Average
> programmers don't know as much about optimizing the assembly code as
> the compiler does,

Which is while I feel there is a market for a book that explains this
kind of stuff; so those average programmers can become expert
programmers.

> for the simple reason that average programmers
> today don't know assembly, or have only a passing familarity with it.

One doesn't really need to be an expert assembly programmer to do this.
The programmer certainly needs to know machine organization well and
they *do* need a "passing familiarity" with assembly language to be
able to understand what the compiler is doing with their code, but
learning things like "compilers don't handle code motion real well when
you put a strlen function call in a for loop..." are easy enough to
learn without needing to know anything about assembly language.


> Of course expert assembly programmers can beat a compiler on a
section
> of code. But that takes time and effort, and most experts reasonably
> conclude that the compiler is better for most code, with only a few
> sections hand optimized.

My experience is a bit different. I find that if I just write large
sections of assembly language code, the result is often faster and
shorter than the comparable optimized HLL code. This is without me even
thinking about writing the best possible code (certainly no cycle
counting or other draconian measures). Writing code in this manner
almost always yields sub-optimal assembly code and the compiler
certainly beats me for some small sequences. Overall, the hand-written
code wins, though.

I stopped counting cycles when the Pentiums first came out and it was
obvious that counting cycles was a complete waste of time because the
cycles counts for a given instruction were going to vary widely
depending on the processor executing the instructions. In theory, this
should have been a big advantage for compilers (after all, with a
compiler option you can recompile for a specific CPU). In reality,
though, developers don't produce a large number of different builds for
different CPUs, so compiler generated code suffers from the same
problem.

>
> We have been around this before. The real problem here is that you
> were an expert in assembly in the 1980s, when everyone still used
> assembly.

Actually, I still consider myself an expert today :-) Whether or not a
majority of people still use assembly is irrelevant. BTW, I also
consider myself an expert C programmer. I written just about as many
lines of C as I have assembly over the years, and about 1/3 to 1/2 that
number of lines of Pascal.

> Now the train left, everyone uses high level languages, and
> assembly language knowledge, unsuprisingly, is dwindling.

And your point is?

>
> You and I actually have the same background, and agree on most
things.
> However, at the end of the 1980's I embraced high level languages,
> and you became a critic of them.

Hmmmm...
I guess you don't know me very well. I use C/C++ all the time. The vast
majority of the programming I've done in the past decade has been in C
(and Flex and Bison :-)). In the decade before that, most of the work I
did was in Pascal. The difference between you and I is that I refuse
to become an apologist for HLLs. People still need to know assembly.
The code written by new programmers over the past decade is terrible.
Largely because they've been taught that performance doesn't matter and
there is no need to worry about optimizing their code. Why bother, when
the side-effects of Moore's law (actually, observeration) suggest that
CPUs will be twice as fast in two years anyway? Go back and read the
article that this thread is based upon. Here's the link:

<http://www.onlamp.com/pub/a/on­lamp/2004/05/06/writegreatcode­.html>


You'll notice that this article is *not* suggesting a return to
programming applications in assembly language. Rather, it is suggesting
that programmers should study assembly language in order to learn how
to write better HLL code. The conclusion sums it up best:

>>>>
To write great code requires one to write efficient code. Writing
efficient code requires good algorithm choices and a good
implementation of those algorithms. The best implementations are going
to be written by those who've mastered assembly language or fully
understand the low-level implementation of the high-level language
statements they're choosing. This doesn't mean that we'll return to the
days when major commercial applications were written entirely in
assembly language. However, to reverse the trend of software running
slower and slower even though CPUs are running faster and faster is
going to require programmers to begin considering the low-level
implications of the code that they write.
<<<<<

You've had the benefit of working on computers in the days when
everything was programmed in assembly. Therefore, *you* understand
what's going to happen when you place certain statements into a HLL
program (with respect to the code the compiler will generate). Most
newer programmers are ignorant of this process and, therefore, will
often choose really bad HLL statements to solve a given problem,
causing the compiler to generate really bad machine code. No matter how
great compiler technology becomes, optimizers aren't going to be able
to over come bad input. And that's why programmers should still learn
assembly language; so they have an idea of what the compiler is going
to do to their HLL code. That simple fact is what I've been pushing for
the better part of a decade now.



> The good 'ole days are gone, Randall, and all the pining that things
> have got worse is not going to sway programmers who turn out
applications
> far larger than could ever have been produced with assembly
languages.

Well, there is one issue. The crazy acceleration of CPU speeds in the
1990s has come to a grinding halt. No longer can programmers count on
(a misinterpretation of) Moore's Law to bail them out. In the past,
people have complained that although CPUs have gotten faster, software
has not gotten faster. Well, guess what? If programmers keep writing
code the way they have in the past decade, software is going to start
running *slower* because CPUs speed aren't increasing as rapidly as
they have in the past (indeed, I have an article coming out in EDN
magazine in a few months discussing this very phenomenon). While this
doesn't imply that people are going to have to start writing their
applications in assembly language, it does imply that people are going
to have to start watching how they write their code in the future. And
*knowing* assembly language is going to be one of the most important
pieces of knowledge programmers can possess when they need to start
worring about how to write great code, even in a HLL.

I guess I could say that "the good old days of getting away with
sloppiness are now coming to an end."
Cheers,
Randy Hyde

.

Relevant Pages

  • Re: the quality of assembly language code
    ... what people considered "optimization" when Tony Hoare wrote this paper ... > this potential of assembly language code "beating" the compiler is ... programmers are too lazy to write the code efficiently. ...
    (comp.lang.asm.x86)
  • Re: the quality of assembly language code
    ... > code than human beings writing raw assembly language. ... Having spent a fair amount of time analyzing compiler output recently, ... assembly programmers and compilers. ... the compiler is doing with their HLL code) don't have a clue what HLL ...
    (comp.lang.asm.x86)
  • Re: the quality of assembly language code
    ... Intel's compiler is supposed to ... I have found that I prefer 'C' and assembler roughly in inverse ... >> code than human beings writing raw assembly language. ... > assembly programmers and compilers. ...
    (comp.lang.asm.x86)
  • Re: Brian Kernighan, maybe Im not worthy, maybe Im scum
    ... what experienced programmers do, ... optimization, ... Thugs" ad nauseum fits that a lot more closely than discussing compiler ... be modified outside a loop, and guessing ...
    (comp.programming)
  • Re: problem in creating Services
    ... I do not consider most MSDN samples as examples of good coding. ... In an optimizing compiler, both forms will ... generate the same code (debug compiler code efficiency is irrelevant). ... Sadly, although the compiler technology matured, the programmers didn't. ...
    (microsoft.public.vc.mfc)