Re: Justifying Optimization

Lex Spoon <lex@cc.gatech.edu>
5 Feb 2003 23:55:28 -0500

          From comp.compilers

Related articles
[9 earlier articles]
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)
Re: Justifying Optimization bobduff@shell01.TheWorld.com (Robert A Duff) (2003-02-05)
Re: Justifying Optimization vbdis@aol.com (2003-02-06)
Re: Justifying Optimization vbdis@aol.com (2003-02-06)
Re: Justifying Optimization joachim_d@gmx.de (Joachim Durchholz) (2003-02-11)
Re: Justifying Optimization joachim_d@gmx.de (Joachim Durchholz) (2003-02-11)
Re: Justifying Optimization joachim_d@gmx.de (Joachim Durchholz) (2003-02-11)
[4 later articles]
| List of all articles for this month |

From: Lex Spoon <lex@cc.gatech.edu>
Newsgroups: comp.compilers
Date: 5 Feb 2003 23:55:28 -0500
Organization: Georgia Institute of Technology
References: 03-01-158 03-01-178
Keywords: optimize, practice
Posted-Date: 05 Feb 2003 23:55:28 EST

cgweav@aol.com (Clayton Weaver) writes:


>> Most programmer time is invested into commercial applications
>>targetted for Windows and nothing else (sad as this state of affairs
>>is). In that area, it makes sense to run the debug-mode code, simply
>>to cut down on the effort for testing.
>
>>Additional testing with the optimizer turned on will just find a lot
>>of bugs that were never relevant in debug code - why fix them?
>>Customers don't care about them, fixing them just runs the risk of
>>introducing other errors, and customers want that the software vendor
>>invests his time into new features (or in fixing the more obvious
>>bugs and misfeatures), not in making the software beautiful.
>
> I recently upgraded a Windows ISP client (after the old one crashed
> and ate an email filing cabinet).
>
> The newer version is quite a bit slower than the one that I upgraded
> from. I do not view it as "the price of more stable code", because I
> do not know that the new version is any more stable than the one I
> upgraded from (software upgrades on Windows go the other way more
> often than not in my experience).
>
> Instead, I am thinking "time to get a different ISP".
>
> Is that really the response that you want from customers?


To be fair, it's not clear that the optimizer would help here. A huge
reason for really slow programs nowadays seems to be loading all of
their bulk from disk, including DLL's. Once most of the "slow"
desktop programs of today finally get loaded, they are pretty zippy.
Moore's law grants forgiveness, except for on hard drive speeds.


There is another technology that might help, besides writing smaller
programs...


Consider the situation from another perspective: everyone seems to be
manually implementing reloads of memory snapshots, and the
implementations are complicated and kludgy as they load multiple
layers of different kinds of files (DLL's, ini files, bitmaps, etc).
It should be much faster to have real memory snapshots, so that you
can load all the data from the hard drive as one long, contiguous
read, and then immediately start running.


That is, if everyone would just use Lisp instead of reinventing it, if
they would just accept the fate of every language to eventually be
Lisp, then everything would be so much simpler and faster. :)


-Lex



Post a followup to this message

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