Re: Speedy compilers

Rudi.Ziegaus@bingo.baynet.de (Rudi Ziegaus)
18 Dec 1998 12:16:58 -0500

          From comp.compilers

Related articles
[8 earlier articles]
Re: Speedy compilers icedancer@ibm.net (1998-11-30)
Re: Speedy compilers janusz.szpilewski@alcatel.pl (Janusz Szpilewski) (1998-11-30)
Re: Speedy compilers amitp@theory.stanford.edu (Amit Patel) (1998-12-10)
Re: Speedy compilers mfinney@lynchburg.net (1998-12-13)
Re: Speedy compilers eclectictech@usa.net (1998-12-18)
Re: Speedy compilers zalman@netcom.com (1998-12-18)
Re: Speedy compilers Rudi.Ziegaus@bingo.baynet.de (1998-12-18)
Re: Speedy compilers Rudi.Ziegaus@bingo.baynet.de (1998-12-18)
Re: Speedy compilers jeff-news@jeff-jackson.com (Jeff Jackson) (1998-12-18)
Re: Speedy compilers albaugh@agames.com (1998-12-19)
Re: Speedy compilers terryg@uswest.net (1998-12-19)
Re: Speedy compilers genew@vip.net (1998-12-19)
Re: Speedy compilers fjh@cs.mu.OZ.AU (1998-12-19)
[2 later articles]
| List of all articles for this month |

From: Rudi.Ziegaus@bingo.baynet.de (Rudi Ziegaus)
Newsgroups: comp.compilers
Date: 18 Dec 1998 12:16:58 -0500
Organization: Bingo (Buergernetz Ingolstadt eV)
References: 98-11-047 98-11-086 98-11-089
Keywords: performance, comment

[ re how much people care about compile speed vs. runtime speed ]


There is a golden rule to code optimization, that I like to cite :
"Never use it". I was working with MSC 5 several years ago when I ran
into a problem with a so-called safe optimization. There were three
optimizations built into the compiler that were regarded so safe that
you didn't have to turn them on, but they were on by default and your
only choice was to turn them off alltogether.


Well, this safe optimation overwrote my stack in some special
situations. Of course you could not recreate the same problem in a
somewhat simpler test case. However the bug was reproducable in our
code.


I work for a bank and I believe that in our environment optimization
is not so important, since we are doing APPC programming (Advanced
program to program communication) with the mainframe with slow telecom
lines in between.


I believe a clever algorithm can do much better than any optimation.
Of course there are some cases (e. g. graphics programming, CAD, etc.)
where performance counts.


BUT : functionality before speed.


I remember a book I read during my studies where the author cited a
case, to which he was called. A program that had to be fast, did not
work. He provided a program that was running correctly, but was way
slower than the original one.


The original program's author pointed to this speed difference. The
author of the book replied, that he could write a program that would
be done in less than a second, if the result was not importent ...


I believe, many speed improvements can be gained by


a) clever parameter passing (registers)
b) optimized libraries


I once compared a sort program written for OS/2 in C (one version
compiled with CSet 2 compared to the other version compiled with
Borland C++ 2.0).


To my dismay, Borland's result were much slower : The program had to
read about 7000 lines of code into an array, sort it and write it to a
different file.


                                            CSet Borland
-------------------------------------------------------------
results 3 s 15 s


Borland's compiler already took 3 seconds just to read the file into
the memory. This speed advantage does not come from clever code
optimization, but from highly optimized libraries.
[I can believe that MSC 5 had optimizer bugs, Microsoft's compilers are
famous for optimizer bugs. But there really are optimizers that make
your program run faster without breaking it, and there's no reason not
to use them along with good algorithms. -John]


Post a followup to this message

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