swarm-support
[Top][All Lists]
Advanced

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

Re: Anywone write anything about efficiency and space?


From: Theodore C. Belding
Subject: Re: Anywone write anything about efficiency and space?
Date: Tue, 6 Jan 1998 18:11:30 -0500

Hi-
Just a few general comments:

It generally isn't worth while worrying about efficiency in a program until
the last stages of development: "make it compile, make it run, make it
correct, make it fast, make it small", in that order.  In most cases you
should profile the program to see exactly where it is spending the most
time.  If you just go ahead and optimize a part of the program that you
think looks suspicious, you will very likely spend all your time optimizing
code that uses little run time, while missing the actual bottlenecks.  A
good rule of thumb is that 20% of the code takes up 80% of the run time; if
you optimize that 20% you can usually ignore the remaining 80% of the
program.  Also, compilers such as gcc are very good at optimizing low level
code (such as the order of assembly language instructions), especially on
RISC chips --- they're often better at that sort of thing than human
programmers.  gprof is a Unix profiler that works with gcc.  Nelson Minar
mentioned a while ago that he'd been able to profile Swarm programs; I
haven't tried it myself.  I think that documenting how to profile Swarm
code would be very valuable.

There is at least one important exception to the above, though: you should
try to use the most appropriate algorithms and data structures for your
program, beginning at the design stage.  If you use a bad algorithm or data
structure, you may get an exponential increase in run time.  (See
Sedgewick's Algorithms in C for a good introduction to this topic).  I
haven't looked at the innards of any of the Swarm data structures or memory
management, but I'd assume most of it's reasonably efficient.

Regarding the question of whether to use monolithic or composite objects, I
personally favor object composition.  The advantage is that you can swap a
component out even at run time, which lets you radically change the
composite's characteristics (see Gamma et al.'s Design Patterns).  Again,
if you profile the code and see that one of the composites is a bottleneck,
you can write an optimized, monolithic object.  Otherwise you shouldn't
waste your time on it.  As Jan said, your time is valuable too.

Although I'd agree with Jan that you should remember that disks and RAM are
cheap, and CPU's are doubling in speed, I'd also keep in mind that that
doesn't mean that you should use a bad algorithm or data structure that
prevents you from running your simulation right now.

Hope that helps.
-Ted

--
Ted Belding                               address@hidden
University of Michigan Program for the Study of Complex Systems
http://www-personal.umich.edu/~streak/



                  ==================================
   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]