Re: Seg fault after 2 days of simulation

[Jan Kreft]

Marcus,

On 17 Oct 1999, Marcus G. Daniels wrote:

> >>>>> "JK" == Jan Kreft <address@hidden> writes:
> 
> JK> In other words, soon I'll have to
> JK> use some sort of supercomputer to run my models, and that will
> JK> mean going to pure C rather than Java from Objective C.
> 
> This is one reason we developed an extensible language layer rather
> than rewriting Swarm in Java.  With or without a parallel version of
> Swarm, some users may actually need to look at the assembly code that
> GCC generates or even do manual assembly coding to get sufficient
> performance for high dimensional spaces of models (e.g. future
> versions of BacSim).  They may need to use a massively-optimizing,
> highly-tuned proprietary supercomputer FORTRAN compiler and tie those
> features in to Swarm.
> 
> JK> Preemptively, I have made this years additions to BacSim as close
> JK> to C as I could within the limits imposed by the existing
> JK> code. 
> 
> What I think you mean (not using ObjC messages just for the heck of it,
> planned use of memory, using non-OO coding when there won't be
> hetergenous agents), is sensible programming anyway.
> 
> Do you know in a precise way the distribution of the ways cycles get
> spent, i.e. have you profiled BacSim?  Do you know for a fact there
> aren't fixable bottlenecks?  Supposing there were a parallel version
> of Swarm where all logically concurrent events ran on different
> processors, would you still think using low-level code was a solution?

Yes, I have profiled. Result was as it should be, e.g. that the simulation
of diffusion takes the bulk of the time, about 95%. I simulate diffusion
of substrate and growth of bacteria, where diffusion is a fast process and
growth is slow (ms versus min timescale). Hence, many diffusion steps are
needed per growth step. My old BacSim was maybe 10000 fold slower because
I didn't separate the simulation into processes at different timescales. 
So the huge speed-up was due to better design of the model and better
algorithms. Not profiling. I could try to use even better ones, but they
would be very difficult to understand and implement properly, which is why
I would like to stick to the current one, called alternate direction
implicit method in Numerical Recipes. 

If there were a paralled version of Swarm, I hope I could simply divide
the space into chunks and have one processor for each chunk.

To summarize, I think the most important issue for speed-up is choosing a
good algorithm, then using ||lism, then optimizing/profiling. 

Cheers, 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.