Re: Multithreading question

[Matteo Morini]

Dear Darold,

together with some of my colleagues we're investigating the possibility 
of running multithreaded Swarm applications on multiple processors. Our 
idea would be to exploit a Mosix cluster; if I understand correctly you 
are thinking about multiprocessor machines, but in the end we're 
tackling the same issue.

With Javaswarm we're stuck (the problem being with mosix anyway, not 
with multiprocessor pc's). I personally have an Objective-C application 
which would benefit a lot from going multithreaded (either on Mosix or 
on a multiprocessor single machine), being inherently parallel. It's 
about a genetic algorithm-based production planner: if you're into GAs 
you've probably seen the point already. The fact is many computationally 
heavy independent tasks (computing every candidate solution's fitness) 
can be run simultaneously on different CPUs. The idea of going 
multithread has been in my mind for a long time, and I expect to start 
working on it seriously as soon as I get some spare time. By now I've 
just got a really simple Obj-C Swarm multithreaded application 
performing dummy tasks in parallel. I can send it to you if you feel 
like giving it a look.
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)]

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.