RE: Multithreading question

[Darold Higa]

I know I need to rewrite my code in order to improve performance.  I feel
however that I should stick to Objective-C for replication/methodological
reasons.

My simulation works fine with a low agent count, but I get much more
interesting results as my population densities rise, hence my desire to
improve performance.  Even with more efficient code, once I hit the magic
number of around 1200 agents, things really slow down.

As a result I was hoping that I could throw more hardware at the issue, so
as I refine and add more stages to my model, I can maintain reasonable
performance.  The goal of this model is to add layers of social complexity
and increase the simulation area.  My fear is that as I add social
complexity, multi-day runs turn into multi-week runs.

Darold Higa

-----Original Message-----
From: address@hidden
[mailto:address@hidden Behalf Of
address@hidden
Sent: Wednesday, January 29, 2003 1:39 AM
To: address@hidden
Subject: Re: Multithreading question


Darold Higa writes:
 >
 > I have done very little research on this topic, but I do know my
simulation
 > has serious performance issues.  I am looking into a new development
 > platform.

If you've mentioned this already, I apologize; but, have you done
any profiling and optimization of your simulation?  One can often
see tremendous speedup by carving off the big time-wasters.  Some
of those options even include short-circuiting objc features.

 >  I was told by someone that if I wanted to look into
 > multithreading, the libraries that I'm building from have to be
 > multithreading compliant.  Do the Swarm libraries meet this criteria?  I
 > vaguely recall parallel processing as one possible direction for swarm.

Well [grin], I'm not sure what that advice is intending by "multithreading
compliant"; but, any piece of code can be made "multi-threaded", including
a swarm app.  But, there are various different types of threads.  The
only example of a parallel swarm that I've seen is one that used MPI
explicitly to launch swarms on other machines and pass agents back and
forth.

There are no "in principle" barriers to a multi-threaded swarm; but,
I don't think any of our code is thread-safe.

 > It seems that the two leading contenders hardware wise are Apple desktops
 > and a P4 system with Hyper Threading, both are multiprocessor setups
(albeit
 > virtual in the P4 case).  Either system would benefit from multithreaded
 > applications, if I understand correctly.
 >
 > Is it going to kill me to convert my ObjC Swarm app into a multithreaded
 > application?  Will I see any real benefits even without making the
 > application multithreaded?

I suspect, that if you've done the above mentioned profiling and
optimization, and you're still having a performance problem, then the
time has come to rewrite your simulation with some new objectives in
mind, namely parallelism and speed.

I presume you wrote this swarm app as a prototype.  Swarm, RePast,
AScape, and their ilk are excellent for prototyping.  But, if you've
settled on your model, it is often best to rewrite it in C++ or
Fortran, or whatever.

That goes for other "platforms", as well.  I'm sure there are platforms
out there that do their best to make their applications efficient.
But, nothing will ever be as efficient as using a basic language...
especially if that language has features that exploit parallelism.

However, if you are still in your prototyping phase, *and* you've done
the profiling/optimization, then your best bet would be to parallelize
your swarm app.  But, I wouldn't suggest using threads.  Use multiple
processes.  It's a sledge hammer, that's true.  But, overall, it will
help you think clearly about your problem.

--
glen e. p. ropella              =><=                           Hail Eris!
H: 831.335.4950                              http://www.ropella.net/~gepr
M: 831.247.7901                               http://www.tempusdictum.com


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



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