RE: Multithreading question

[Darold Higa]

Thanks for the information.  I think I can parcel out tasks in parallel by
geography, since agents only interact with agents in the same geogrpahic
space.  One of my programming friends has offered to look over my simulation
structure to suggest how to parcel out tasks.

It sounds like as long as I don't expect agents to interact while "in
transit" between geographic spaces I can use geography to divide the
schedule into discrete units.

Wow, this would allow for extremely distributed processing...it would be
possible to create simulations of enormous size.

OK, I will have to digest all of this.

Thanks for the help everyone!

Darold Higa


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


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.



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