swarm-support
[Top][All Lists]
Advanced

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

Re: Multithreading question


From: Jason Alexander
Subject: Re: Multithreading question
Date: Wed, 29 Jan 2003 15:43:57 +0000

I did go multithread by scheduling the independent steps like this (untested pseudocode follows :-)
I'm going by memory... sorry for errors)

[modelActions createActionForEach: agentsList message(step1)]
[modelActions createActionForEach: agentsList message(step2)]

You might want to check if making the following change speeds things up at all. Instead of writing

[modelActions createActionForEach: agentsList message(step1)]
[modelActions createActionForEach: agentsList message(step2)]

put

[modelActions createAction: self message(fooBar)]

(the right message might not be createAction... it's been a long time since I've used Swarm)

and then in the class file define fooBar as follows:

- (void) fooBar() {
// loop over agentsList using standard iterator techniques, calling step1 for each // loop over agentsList using standard iterator techniques, calling step2 for each
}

Introducing the above change into my code sped up one model by a factor of 10. Of course, in my case the slowdown was due to Swarm's message-passing methods in createActionForEach when the list contains heterogeneous agents. In your case, I would guess the forks(), etc. are much more of a bottleneck than Swarm's message-passing methods.

Cheers,

Jason



where each anAgent in agentsList performs:

*at step 1:

{...

   mypid=fork();
   if mypid=0 {
       //pid=0 tells you this is a child
       //perform task
       //store result somewhere (*)
       return self; //(or was it exit 0?)
   }    else
return self; //this is the parent process, return immediately and spawn next child
}

*at step 2;

{...
   waitpid(mypid,NULL,0);
//in order to keep things in sync we wait for all the agents in list to perform before starting a new cycle
   return self;
}

(*) managing to catch 'child' processes results is not so easy: I'm trying shared memory (but this would not go on Mosix) or writing to file.

Answering your questions: converting your application to multithread would definitely not kill you *if* it has a parallel architecture, that is there is something that can be done without waiting for the previous step to complete. In other words (and keeping it as simple as it can): if your problem is to solve (a+b) * (c+d) you can split the problem into (a+b) and (c+d) and run the two sub-problems on different processors, then multiply the results. If you need to recursively solve an equation like x(t+1)=f(x(t)) you see you can't do the trick, and are bound to serially perform each step, since you have to wait for the last iteration to complete before moving on. This would not kill you either but would waste a lot of your time. Without making your application mulithread you'd have a monolithic process running on a single processor; I bet that's not you expect from a 4-way hyperthreaded P4 :-)

---Matteo

Darold Higa wrote:

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

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?

So many hardware related questions, I apologize.

Darold Higa


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


--
J. McKenzie Alexander
Department of Philosophy, Logic and Scientific Method
London School of Economics and Political Science
Houghton Street, London WC2A 2AE


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