|LDD/STD Optimizations firstname.lastname@example.org (1992-03-03)|
|Re: LDD/STD Optimizations idacrd!desj@uunet.UU.NET (1992-03-09)|
|Re: LDD/STD Optimizations email@example.com (1992-03-10)|
|Re: LDD/STD Optimizations firstname.lastname@example.org (1992-03-10)|
|Re: LDD/STD Optimizations idacrd!desj@uunet.UU.NET (1992-03-11)|
|From:||email@example.com (David Keppel)|
|Organization:||Computer Science & Engineering, U. of Washington, Seattle|
|Date:||Tue, 10 Mar 1992 17:38:19 GMT|
Hey, what do you know. I'm going to start another religous war.
>>Preston is paraphrased by firstname.lastname@example.org as saying:
>> Maybe I'm just overly used to FORTRAN, but I see a lot of code
>> where unaligned array slices or odd-size columns get passed.
idacrd!desj@uunet.UU.NET (David desJardins) writes:
>[If you care about performance, write your code on the basis of what
> performs well. Serious users can avoid unaligned slices.]
One of the goals of an optimizer is to let the programmer write code
that runs well on a variety of machines. Writing around the machine
architecture should be avoided where possible because (a) it is extra
work for the programmer during creation, debugging, tuning and
maintainance and (b) because code that is hand-optimized for one
machine is often hand-pessimized for another.
Except for assembly, it's also the case that some optimizations cannot
be expressed in the source language.
How much work is worth how much potential gain? For me to try
optimizations by hand requires substantial effort. It may have zero
payoff. Some optimizations may even conflict with each other. The
optimizer just goes ahead and tries.
There's also the issue of dusty decks; I'll ignore that for this
;-D oN ( Superarg: Finding the shortest rebuttal ) Pardo
Return to the
Search the comp.compilers archives again.