Re: code quality, was Good practical language and OS agnostic text?

Hans-Peter Diettrich <>
Sun, 22 Apr 2012 12:41:55 +0200

          From comp.compilers

Related articles
Good practical language and OS agnostic text? (2012-04-17)
Re: Good practical language and OS agnostic text? (Alain Ketterlin) (2012-04-18)
Re: Good practical language and OS agnostic text? (Hans-Peter Diettrich) (2012-04-19)
Re: Good practical language and OS agnostic text? (BartC) (2012-04-21)
Re: code quality, was Good practical language and OS agnostic text? (Hans-Peter Diettrich) (2012-04-22)
| List of all articles for this month |

From: Hans-Peter Diettrich <>
Newsgroups: comp.compilers
Date: Sun, 22 Apr 2012 12:41:55 +0200
Organization: Compilers Central
References: 12-04-019 12-04-023 12-04-033 12-04-058
Keywords: optimize, benchmarks
Posted-Date: 22 Apr 2012 10:23:34 EDT

BartC schrieb:
> "Hans-Peter Diettrich" <> wrote in message
>> Life is too short for writing an full-blown heavily-optimizing
>> production compiler from scratch, including its whole RTL.
> Especially when there might only be difference of 2 or 3 times between
> performance of the best and worst code.
> My own compiler for x86-32 generates pretty awful code, and on a small
> handful of mostly numeric benchmarks, it averages out about 2.5 x as
> slow as gcc on it's highest optimisation setting. But, gcc often
> recognises these benchmarks as doing nothing useful, so removes whole
> sections of code!

I never trust benchmarks, in detail when supplied by compiler vendors :-]

When we had several workstations for evaluation, the AIX workstation
came with a benchmark program executing in about 3 seconds on that
machine. On other machines the time ranged from 8 minutes to more than
an hour.

When I added a printf after the loop in the benchmark code, it also took
about 8 minutes! The benchmark turned out to test the compiler *default*
optimization settings, where the HP station was so incredibly slow
because it had turned off *any* optimization by default.

  From that experience I also learned what optimization means in
practice. A dumb compiler, or with all optimizations disabled, may fetch
every expression operand from memory, and write back every intermediate
result (SSA?), which is nice when debugging some code. Thus *register
allocation* turned out to be a basic optimization of high value - I
wonder how somebody could ever design a CPU (with more than 8 bit
registers) with as few registers as available on most Intel processors.
Dead code elimination and moving loop-invariant computations out of
loops are the next optimizations to consider. And CSE...

Another compiler, for an M68000, turned out to be a very quick&dirty
port of an M6800 compiler. According to "an int is a pointer, a pointer
is an int" it kept all operands in the M68K *address* registers, so that
every logical or arithmetic operation had to be done in a subroutine,
which moved the operands from A0 and A1 into *data* registers, evaluated
and stored back the result into A0. The caller had to move the operands
into A0 and A1 before, of course. In my test programs every single C
statement resulted in about 3 pages of assembler code! [1]

But despite that horrible code generation, this compiler came with a
very powerful graphics and window software, with amazing runtime
behaviour. This observation again relativates the need for optimization,
at least in GUI applications.

[1] This compiler, and my rudimentary knowledge of C and compilers and
runtime libraries, made me write my first C decompiler in the late 80's.
Of course in Basic, which was the language I had used on all my
homecomputers before. Hereby I learned more and more about bad and good
practices in compiler writing, encountering any number of workarounds
for adopting old 8-bit compilers to 16/32 bit code and memory layouts.


Post a followup to this message

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