swarm-support
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Optimization: why don't I get no speedup?


From: glen e. p. ropella
Subject: Re: Optimization: why don't I get no speedup?
Date: Mon, 07 Jan 2002 17:28:11 -0800

At 12:58 PM 1/7/2002 -0600, you wrote:
I'm going to show the code snip below, but I'm just bringing this up to say that optimization is a drag when you get no speedup out of it!

And to ask the musical question: How long do you stare at a method like this before you conclude that it is as fast as you can possibly make it?

I won't suggest other optimizations to make; but, I'll talk to the
main purpose of the email.  There are two fundamentals
you need when you profile to enlighten refactoring:
o Know exactly what you're optimizing (and what you're optimizing
for), and
o Chunk up your software so that you can know exactly what you're
optimizing.

The reason I say this is it strikes me from you're email that
you don't actually know how many (and of what type) operations
this method is performing.  *If* I had time to do it right now,
the first thing I'd do is go through each version of the method
and count the number of logical, mult., and div. operations and
the number of function calls.

After doing that, if the number of operations are on the same
order of magnitude, then that explains why you're not seeing
a performance improvement.

The second thing I'd do would be to try to abstract up a little
and see if I'm doing only the necessary things multiple times.
(For example, why put the if WRAPAROUND test inside any for loop
at all.... unless it might change during iteration?  Why not just
have switched for loops?)  What this abstraction exercise usually
will tell you is whether or not you have the right data structures
(foremost) and logic for convolving those data structures to do
what you want to do most efficiently.  (For example, if all you're
doing is modifying the level of a value in a patch of area, why
not create a separate method that takes, as input, the delta matrix:
     *D2D(popChange[i],gridOffsets,xx,yy); for each i
the reference data:
     xx, yy, patchShape, patchSize
and the operator between the two:
     +
..... If you had that as a separate method, you would be
calculating the contents of the delta matrix separately from
applying the delta matrix to the grid.  Then when you profiled,
you would have a finer granularity on your profiling data.  *And*
you just might be able to come up with a more efficient algorithm
using matrix operations instead of doing things cell-by-cell.)

[grin]  But all that *is*, quite honestly, a big fat "maybe".

So, I can't treat your irritation about doing a bunch of work
without seeing a benefit, except to say that you have to be
careful about where you apply your efforts... a.k.a.  Know
what, exactly, you're optimizing.


glen e. p. ropella  =><=          Hail Eris!
Home: 831.335.4950  =><=  Cell: 831.247.7901
http://sru51-1.servers-r-us.com/~gepr


                 ==================================
  Swarm-Support is for discussion of the technical details of the day
  to day usage of Swarm.  For list administration needs (esp.
  [un]subscribing), please send a message to <address@hidden>
  with "help" in the body of the message.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]