Re: Anywone write anything about efficiency and space?

[Jan Kreft]

Hi Paul,

talking about efficiency more or less efficiently, there are two very
different efficiencies at stake: your's and the computer's. The latter
irrelevant as long as you don't have to wait for results from simulation
runs. (It's a different story if you write programs millions will use,
then, an inefficient program would waste the time of millions. Like in the
case of Swarm itself ;-). 

I was happy with running about a dozen simulations overnight in most
cases, sometimes it took longer than that, well into the next day. Then
Sven or someone posted a comparision of RNG times with different CPU's and
compiler options that prompted me to try myself letting gcc optimize the
code, the gain was 20% (100% with -g and 80% with -O3). Cheaper than
upgrading the CPU. Faster (my time - not the computer's) than optimizing
myself. 

If you spend half a year to tune your code and the simulations are, say,
twice as fast and this saves a few weeks with the runs, where's the point?
In half a year you can buy a faster CPU anyway.

On Sun, 4 Jan 1998, Paul Johnson wrote:

> 
> I keep wondering about RAM and efficiency in designing Swarm projects, 
> and wondered if anyone had written about it.  Here's part of the reason
> I am concerned.
> 
> Several years ago, I wrote a simulation in the SAS macro language that
> ran on a mainframe, I think it was an Amdahl.  That took hours, so a 
> consultant said I should just write it in Pascal and run it on a 486
> and it would be much faster.  So I spent a few months learning Pascal
> and finally got a simulation running, but then CLUNK, there were inherent
> limits that stopped me from scaling up the size of the project. I was
> using Borland Pascal 7.0, not exactly a piece of crap. As I recall, there
> were two major problems. One was that there was a strict upper limit on
> the number of variables that could be introduced.  Second, there was a limit
> on the size of an array, or the number of items pointed to by an array.
> No matter how much RAM you have, you can't have an array with more than
> a certain size (was it 64k?). 
> There were some work-arounds for the array problem, but as I recall
> they did not scale with the parameters easily, and I was stuck with
> a middle sized model.
> 
> Working with Swarm, I've learned a bit about C and ObjC and haven't heard
> any talk about limits on array size or such. What a relief!  But I still
> keep wondering if I am going to hit such things.  
> 
> If somebody does think about writing something, here are some of the
> specific questions I would like to ask:
> 
> 1.  Suppose I create an object, and it has several int and float variables.
> Suppose I then create 3 lists, and add that object to each one. That doesn't
> create 3 copies of the object, does it? How much RAM is used? 

Depends, of course. Just to give an example, my agents use about 750
bytes.

> 2. In the docs on Arrays and lists, there are some comments about
> speed, but, since I'm not a programmer, I don't understand them very well.
> Care to elaborate?
> 3. Maybe this is too vague, but I keep wondering whether it is better/faster 
> to
> design an object that has many methods that it can perform sequentially or
> several objects, each of which performs one method, each of which is called
> sequentially?   Know what I mean?  It seems like the one big object might
> have less message passing, since the object has command of all instance 
> variables inside it.  However, such code is not so elegant and useful
> in other projects.
> 4. I remember reading several months ago about a way to run a program
> and then measure the amount of time the CPU spent on each task.  One could
> look to see where gains in program speed might be had.  But I
> cant even remember if that was in Linux, or on an Alpha system, or what!
> Anyone remember it?
> 
> Paul E. Johnson                           address@hidden

Hope that helps,

Jan.


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