Re: kickass optimizing compilers?

glen herrmannsfeldt <>
8 Feb 2004 22:04:55 -0500

          From comp.compilers

Related articles
[7 earlier articles]
Re: kickass optimizing compilers? (Christopher Brian Colohan) (2004-01-16)
Re: kickass optimizing compilers? (Jeff Kenton) (2004-01-16)
Re: kickass optimizing compilers? (Robert Knighten) (2004-01-17)
Re: kickass optimizing compilers? (Walter Banks) (2004-01-18)
Re: kickass optimizing compilers? (dablick) (2004-02-01)
Re: kickass optimizing compilers? (2004-02-04)
Re: kickass optimizing compilers? (glen herrmannsfeldt) (2004-02-08)
Re: kickass optimizing compilers? (2004-02-08)
Re: kickass optimizing compilers? (2004-02-12)
| List of all articles for this month |

From: glen herrmannsfeldt <>
Newsgroups: comp.compilers
Date: 8 Feb 2004 22:04:55 -0500
Organization: Comcast Online
References: 04-01-044 04-01-082 04-02-010 04-02-068 04-02-068
Keywords: assembler, optimize
Posted-Date: 08 Feb 2004 22:04:55 EST

Blitz wrote:


(most of the discussion comparing optimizing compilers to
    assembler programmers has been previously snipped.)

> What a load of croc. A program can never be smarter then a human at
> all times. It might do an overall better job, but there are a lot
> places it couldn't even come close to taking smart enough decisions.
> And your compiler which was compared to the home assigment of students
> isn't quite fair is it?

Well, the answers were in the six or seven instruction range,
and comparing instruction counts isn't usually the right answer.
People usually want the fastest executing code, not the least
number of instructions.

> They are students who are just trying to learn
> not experts of assembly coding or that certain cpu. Even today, in
> 2004 no compiler comes close to an experienced asm coder. But the
> difference is that compilers generate good enough code to be used. But
> the innerloops of power demanding apps should always be written by
> hand. There is no way a compiler can come close a good asm coder until
> the day computers are able to think for themselfs the way humans do.

In the days when instruction sets were simple, especially in the
single accumulator days, there weren't many choices. Optimizing
probably depends on minimizing load/store of intermediate values, and
in some cases people might see usage patterns that a compiler wouldn't

If you have a variety of different instructions that can generate the
desired result, and you want to minimize time instead of instructions,
it is much easier for a compiler using dynamic programming algorithms
to find the best set of available instructions for a given problem
than for a human to do it.

Humans, though, are better at noticing that there is a completely
different way to do the problem. Also, the best algorithm may depend
on the scale of the problem, such as the number of times a loop is
executed, which the compiler may not know about.

-- glen

Post a followup to this message

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