Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!daver!dlb!netcom!mcmahan
From: mcmahan@netcom.COM (Dave Mc Mahan)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: On the subject of optimization
Message-ID: <1991Apr10.060055.2829@netcom.COM>
Date: 10 Apr 91 06:00:55 GMT
References: <2243@pdxgate.UUCP>
Organization: Dave McMahan @ NetCom Services
Lines: 63


 In a previous article, bairds@eecs.cs.pdx.edu (Shawn L. Baird) writes:
>I think jumping into assembly code where not needed can be a treacherous
>mistake.

Yes, it can be.  Once you have taken the leap you usually can't go back and
future modifications are difficult, especially when they have to be performed
by others.

> One method of avoiding wasting time on unnecesaary optimizations is to
>profile your code.  Write some timer routines and throw it in with
>Forbid()/Disable() or whatever works for your project.  Then go look at
>the slower code and see what you can do to speed it up.

This is an excellent technique and should always be tried first.  However,
it is not the be-all/end-all when some types of optimizations are needed.
There are certain operations that are just plain math or compute intensive
and just plain require at least some feedback from the assembly language
output of a compiler to get right.  I try to use a profiling method as
much as possible and stop when I get it good enough, but there are times
when I KNOW due to the operation being performed that code just can't go
any faster without some kind of examination of compiler output and possibly
jumping in to assembly language to save a few critical cycles of time.  I
am currently implmenting a low pass smoothing filter for ECG's at work on
a 68000.  The operation is going to consume at least 25% of the total CPU
cycles on the processor and other things need to be done in addition to that
one operation.  I did manage to write the code in 'C', but I was seriously
concerned about having enough CPU time left over.  There just aren't that
many ways to do intensive integer multiplication besides the use of the
muls instruction.  I had to cut down overhead in other portions of the code
to allow enough time.  Examining the assembler output from my compiler was
of great help in selecting the methods I used.

I guess the bottom line is:  Keep it simple, but know what is going on.  If
you need the cycles, avoid writing actual assembler code before you have
exhausted all other approaches.  Profiling is a big help, but just directs
you in where to start thinking about different algorithms.  Sometimes you
just have to do what you've got to do.

> If you're
>lucky, you get to the point where you don't need more speed because the
>hardware or the user is slowing you down.

Luck has little to do with it.  If you have a task that can be done and you
are smart enough, the result is deterministic: it will work.  If the task
is just impossible or you aren't smart enough, again the result is
deterministic: it won't work. 


>Seriously though, profile, profile,
>profile.  Don't assume which part of your code is slowing you down. It's
>easy to get it wrong.

Quite correct!!!  It's amazing how wasteful some simple little line can be
if it is in the wrong loop!

> Shawn L. Baird, bairds@eecs.ee.pdx.edu, Wraith on DikuMUD

    -dave

-- 
Dave McMahan                            mcmahan@netcom.com
					{apple,amdahl,claris}!netcom!mcmahan