(resend) Re: optimization and C arrays (was Re: Return pointer to array: notpossible?)

[Theodore C. Belding]

On Thu, 1 Apr 1999, Paul E. Johnson wrote:

> Yes, profiling does work, but after you take care of the easy problems,
> you are left with a huge category objc_mesg_lookup, which consumes 85%
> of the calls, and there's no way to differentiate among which messages
> are using all the calls. 

You should at least be able to find what routines in your program are
calling objc_mesg_lookup. You'll need to look at the call graph for that,
along with the cumulative seconds of each routine, not just the self
seconds in the flat profile. You might have to divide one big routine into
a couple small ones, if you can't narrow it down as is.

> I got the idea that a C-array was going to save objc_mesg_lookups,
> instead of the Swarm array, that is constantly looking up messages to
> pass array items in and out. But, given your advice, I guess my study is
> best spent on other aspects of the problem.

Well, the Swarm array's objc_mesg_lookups *might* be the bottleneck, as
you say. The problem is that human intuition is notoriously bad for
figuring out where the hot spots in a program are going to be.  And in my
own experience, there are often spots where I am creating new objects or
copying objects where I don't have to (and didn't know about), which turns
out to be the bottleneck, not something else. That is, there are often
things going on in your program that you overlook if you don't profile.

Amdahl's Law implies that if you speed up a part of the program that only
takes 1% of the run time, you will get at the very most only a 1% total
speedup in your program. So if you spend all your time optimizing by using
C arrays, and that isn't the real bottleneck, you're wasting your time and
losing the advantages of Swarm containers, to boot.

> If an action has to be carried out for each of 10 objects for each of 1
> million agents, it was just my guess that I could save 10 lookups for
> each of 1 million agents by going to a C array rather than swarm array. 
> Is it not correct that when you have a C array, and you grab item 5 with
> array[4], it uses less steps than [SomeArray atOffset:4] to retrieve the
> same thing?

Probably. But again the question is, is there something else in your
program that is calling objc_mesg_lookup even more often? And how does the
cost of using the Swarm array compare to the benefits that you get from
using the Swarm array?

In my C++ programs, I use a rather expensive random number generator
object that has a very long period (adapted from NR's ran2).  I've
optimized my program to the point where that generator is now the single
biggest bottleneck.  I could use some one-line random number generator
function or macro and avoid both the C++ object overhead and the overhead
from using ran2.  But the benefit of having a very long period is worth
the cost, to me, and 500 runs still take only about half an hour.

> My main objective was not to use pointers, but to use a C array instead
> of a Swarm Array.  But, if you all say so, I'm willing to chalk that up
> to a learning experience.

Sorry, I equated C arrays and pointers in my email.  They're *almost*
equivalent. If you just use the name of a C array, it *usually* transforms
into a pointer to the first element in the array. There's a few gotchas,
though --- see the comp.lang.c FAQ if you want more info, or a good C
book.

> Can you give me an idea of how I can write periodic output into memory
> and then save it at the end of the run, rather using fprintf at every
> timestep?  

Well, what I do in C++ is write to a stream that happens to store
everything in memory (in an STL container), not on disk. After n writes to
the stream, the stream knows that it should write to disk.  I'm not sure
how I would do it in straight C or Obj C, though. Maybe simply put all the
information in a Swarm container.  When the Swarm container reaches a
certain size, or at the end of the run, write the Swarm container to disk
and empty it. If it won't work with a Swarm container for some reason, you
could write everything in a C array and write to disk when the C array
fills up, or use dynamic memory allocation.  
-Ted



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