Re: High Level Language vs Assembly (Anton Ertl)
22 Mar 2001 01:16:06 -0500

          From comp.compilers

Related articles
[24 earlier articles]
Re: High Level Language vs Assembly (Joachim Durchholz) (2001-03-10)
Re: High Level Language vs Assembly (Joachim Durchholz) (2001-03-10)
Re: High Level Language vs Assembly (Toon Moene) (2001-03-12)
Re: High Level Language vs Assembly (Tom Shackell) (2001-03-14)
Re: High Level Language vs Assembly (2001-03-14)
Re: High Level Language vs Assembly (Tom Fjellstrom) (2001-03-22)
Re: High Level Language vs Assembly (2001-03-22)
| List of all articles for this month |

From: (Anton Ertl)
Newsgroups: comp.compilers
Date: 22 Mar 2001 01:16:06 -0500
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
References: 01-02-094 01-02-101 01-03-074 01-03-081 01-03-087
Keywords: assembler, optimize
Posted-Date: 22 Mar 2001 01:16:06 EST (Jonathan Thornburg) writes:
>Matt asked
>> how much improvement
>> is there between non-optimized and highly optimized code?

That depends on the source code, and on the compiler.

If the compiler tries to generate good code even with optimization
off, and the programmer writes the code to fit the compiler and
architecture, there won't be much difference.

If, OTOH, the programmer writes the code in a way that relies on
certain optimizations, and the compiler performs this optimization
only when optimization is on, the difference can be huge. E.g., I
have written and designed program generators that rely heavily on
register allocation and copy propagation; I measured a factor of 5-9
between "gcc-2.6.3 -O3 -fomit-frame-pointer" and plain "gcc-2.6.3" for
programs generated by one of the generators.

So, the benefit of optimization is not necessarily faster programs,

- less speed tuning effort necessary (my generators would have been
significantly more complex if they would try to produce the same code
quality without copy propagation).

- programs can be tuned for maintenability, readability, and other
goals instead of speed on non-optimizing compilers.

- programmer training can concentrate on other issues than
compiler/architecture-specific micro-optimizations (some people I know
still maximize the use of constructs like "*x++" as if they were still
programming a 68k with a non-optimizing compiler);

- program performance becomes less compiler/architecture-specific.

>I have a C++ application (number-crunching, big arrays) which makes
>heavy use of inline functions. Using gcc 2.95.2 on an alpha-ev6 system,
>-O9 runs about a factor of 10 faster than -g. And gcc is _far_ from
>the world's most-optimizing "optimizing compiler".

However, gcc is one of the world's most-non-optimizing non-optimizing
compilers when run without -O, so the slowdown is larger than you
might see with other compilers. E.g., I just compiled

int foo(int a,int b, int c)
    return a+b+c;

and compiled it with two compilers without optimization on an Alpha:
"cc -O0" (DEC C V5.6-084) produces 9 instructions, gcc-2.95.1 produces
21 instructions.

Now, about the often-sneered-at optimization capabilities of gcc
compared to others: "gcc-2.95.1 -O" produces 3 instructions for this
function, whereas "cc -O5" produces 6. As long as you don't expect
things like cache blocking or software pipelining that gcc does not do
(yet?), gcc's code quality is pretty good.

- anton
M. Anton Ertl Some things have to be seen to be believed Most things have to be believed to be seen

Post a followup to this message

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