Re: Justifying Optimization

Jan C.=?iso-8859-1?Q?Vorbr=FCggen?= <jvorbrueggen@mediasec.de>
25 Jan 2003 01:04:29 -0500

          From comp.compilers

Related articles
[3 earlier articles]
Re: Justifying Optimization christian.bau@cbau.freeserve.co.uk (Christian Bau) (2003-01-21)
Re: Justifying Optimization vbdis@aol.com (2003-01-21)
Re: Justifying Optimization jgd@cix.co.uk (2003-01-21)
Re: Justifying Optimization touati@prism.uvsq.fr (Sid TOUATI) (2003-01-25)
Re: Justifying Optimization ONeillCJ@logica.com (Conor O'Neill) (2003-01-25)
Re: Justifying Optimization jvorbrueggen@mediasec.de (Jan C. =?iso-8859-1?Q?Vorbr=FCggen?=) (2003-01-25)
Re: Justifying Optimization jvorbrueggen@mediasec.de (Jan C.=?iso-8859-1?Q?Vorbr=FCggen?=) (2003-01-25)
Re: Justifying Optimization jvorbrueggen@mediasec.de (Jan C.=?iso-8859-1?Q?Vorbr=FCggen?=) (2003-01-25)
Re: Justifying Optimization joachim_d@gmx.de (Joachim Durchholz) (2003-01-26)
Re: Justifying Optimization lars@bearnip.com (2003-01-26)
Re: Justifying Optimization cgweav@aol.com (2003-01-29)
Re: Justifying Optimization tmk@netvision.net.il (2003-01-30)
Re: Justifying Optimization lex@cc.gatech.edu (Lex Spoon) (2003-02-05)
[10 later articles]
| List of all articles for this month |

From: Jan C.=?iso-8859-1?Q?Vorbr=FCggen?= <jvorbrueggen@mediasec.de>
Newsgroups: comp.compilers
Date: 25 Jan 2003 01:04:29 -0500
Organization: MediaSec Technologies GmbH
References: 03-01-088 03-01-098
Keywords: optimize, practice
Posted-Date: 25 Jan 2003 01:04:29 EST

Joachim Durchholz schrieb:


> The point is: I spent an entire week debugging at assembly level to
> fix a bug that was entirely irrelevant to the logic of the
> application. From this perspective, it was a total waste of time;
> the decision to run the application with optimizations turned on
> didn't do the project any good (since the final application turned
> out to be fast enough even with debug code inside) but wasted a
> man-week of time (and added a lot of grey hairs to my project
> leader's head).


Yeah sure. The more likely case, however, is that those arguments were
used, but the effect was indetectable in the results for the test
cases. When deployed in the wild, the first thing would have been a
lot of complaints from your customers that your product failed in
certain unpredictable ways.


Of course, you should complain loudly and bitterly that such a
"stooopid" bug wasn't diagnosed by the compiler. Hey, if Fortran can
do it, why can't the "modern" language you are using?


One of the few reasons to re-start Netscape (still at 4.7) is that
after some days of use it gets some internal pointers confused, so
that the default file name presented for "save this link as..." is
taken from the wrong place. Just a nuisance, to be sure, and it has a
work-around that can be used most of the time, but it's an example of
what's wrong with modern software.


> I agree with Michael's colleagues that performance is rarely a
> reason to turn optimization on.


Tell that to the people buying the largest computers and using
petacycles for their work. At the other end of the scale, in an
embedded system some optimization can make the difference between what
chip to use, saving a few cents per item, and making the difference
between bliss and misery (cf. Dickens).


I even disagree that one can debug without optimization. There are
enough cases were you have to leave your program running for
substantial time until you get to the point where debugging can start
(watchpoints, conditional breakpoints, and all that). If that time
increases from a few minutes to an hour, you've just lost a lot of
productivity. You _should_ insist on a development system that allows
you to mix optimized and non-optimized code.


Jan


Post a followup to this message

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