🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #11835

Re: FFT for SPARC

#11835
From: Ed Nather
Date: Tue, 28 May 1991 18:08
39 lines
2450 bytes
In article <12392@uwm.edu>, ballen@convex.csd.uwm.edu (Bruce Allen) writes:
> 
> I am looking for
> something that was initially coded high-level, for instance, and
> then recoded by hand to wring out every last iota of performance.

Then you are looking for a procedure that is probably far less efficient
than it could be.

When a programmer codes a known algorithm, he thinks in terms of the
operations available to him -- for example, in Fortran or C there are
a set of operations to choose from, and he chooses from them.  They are
then translated into machine code by a compiler/assembler/linker.  But
when he codes directly in machine code (or in assembler) he thinks in
terms of the basic machine operations available, and chooses from them.
He can often find quicker ways to get the same result using this richer
set of operations, than when he is limited by those available at a higher
level.  This effect was probably minimal in C when the target was a PDP-11,
but can by much greater for other target machines.  Wringing out the last
iota of performance, when the whole coding approach is not optimal, can
give the illusion of economy, but there may be greater economies to be
found by starting with a different set of available operations.

As an example, several years ago I ran a published version of the Sieve of
Eratosthenes written in Fortran and timed it on a machine not noted for its
Fortran compiler efficiency, then recoded the same algorithm in assembler
and ran it.  The assembler version ran 22 times faster.  It made use of an
obscure operation in the inner loop, where the combination "i + i + 1" was
accomplished in a single instruction -- not something a compiler would be
likely to generate.

I believe in compilers, use them most of the time, but can still write
faster code in assembler when performance is otherwise unacceptable.  I
keep waiting for the day when CPU speed is so fast I don't have to do this,
but the day hasn't arrived yet -- at least not for computers I can afford.

-- 
Ed Nather
Astronomy Dept, U of Texas @ Austin
Technical Details
Message-ID: <49576@ut-emx.uucp>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!ut-emx!nather
References: <12392@uwm.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!ut-emx!nather
From: nather@ut-emx.uucp (Ed Nather)
Newsgroups: comp.arch
Subject: Re: FFT for SPARC
Message-ID: <49576@ut-emx.uucp>
Date: 28 May 91 18:08:44 GMT
References: <12392@uwm.edu>
Organization: The University of Texas at Austin; Austin, Texas
Lines: 39