Multithreading

[Dave Murray-Rust-2]

Hi all,

I'm trying to understand what level of multithreading repast provides.  
Does it simply run the scheduler in a separate thread, or is there the  
possibility of running multiple threads for updates.

Currently, I'm running on a dual-core machine, and it's only using one  
core - is this normal, and is there any (relatively easy) way to  
distribute agents across multiple cores? (I'm on OSX in case that  
makes a difference)

Cheers,
dave

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Repast-interest mailing list
Repast-interest@...
https://lists.sourceforge.net/lists/listinfo/repast-interest

[Tom Howe]

The Repast scheduler does run in a separate thread, and the default
mode of operation is that the actions are essentially single threaded.
 However, if you use the "duration" parameter which is included in
most of the scheduler methods, the action will be executed in a
separate thread.  Of course, all normal warnings about multithreaded
coding apply (synchronize your data, etc).

-Tom

On Mon, Jun 16, 2008 at 5:38 AM, Dave Murray-Rust
<d.murray-rust@...> wrote:

> Hi all,
>
> I'm trying to understand what level of multithreading repast provides.
> Does it simply run the scheduler in a separate thread, or is there the
> possibility of running multiple threads for updates.
>
> Currently, I'm running on a dual-core machine, and it's only using one
> core - is this normal, and is there any (relatively easy) way to
> distribute agents across multiple cores? (I'm on OSX in case that
> makes a difference)
>
> Cheers,
> dave
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Repast-interest mailing list
> Repast-interest@...
> https://lists.sourceforge.net/lists/listinfo/repast-interest
>

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Repast-interest mailing list
Repast-interest@...
https://lists.sourceforge.net/lists/listinfo/repast-interest

[Dave Murray-Rust-2]

OK, thanks that helps a lot.

So, each action can be run in a thread, but the same action cannot  
(easily) have multiple threads to parallellize processing the  
different agents it applies to? For instance, if I have a lot of the  
same type of agents, and I want to make use of multiple cores, I must  
find a way to split the action into several parts which will then  
independently run in their own threads?

Is there any support for taking a set of agents running the same  
complex action and having some agents run their action in one thread  
and some in another (I can imagine some workarounds, but it seems like  
a useful piece of functionality in this increasingly multicore world...)

Cheers,
dave

On 16 Jun 2008, at 13:17, Tom Howe wrote:

> The Repast scheduler does run in a separate thread, and the default
> mode of operation is that the actions are essentially single threaded.
> However, if you use the "duration" parameter which is included in
> most of the scheduler methods, the action will be executed in a
> separate thread.  Of course, all normal warnings about multithreaded
> coding apply (synchronize your data, etc).
>
> -Tom
>
> On Mon, Jun 16, 2008 at 5:38 AM, Dave Murray-Rust
> <d.murray-rust@...> wrote:
>> Hi all,
>>
>> I'm trying to understand what level of multithreading repast  
>> provides.
>> Does it simply run the scheduler in a separate thread, or is there  
>> the
>> possibility of running multiple threads for updates.
>>
>> Currently, I'm running on a dual-core machine, and it's only using  
>> one
>> core - is this normal, and is there any (relatively easy) way to
>> distribute agents across multiple cores? (I'm on OSX in case that
>> makes a difference)
>>
>> Cheers,
>> dave
>>
>> --
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>>
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> _______________________________________________
>> Repast-interest mailing list
>> Repast-interest@...
>> https://lists.sourceforge.net/lists/listinfo/repast-interest
>>
>

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Repast-interest mailing list
Repast-interest@...
https://lists.sourceforge.net/lists/listinfo/repast-interest

[Tom Howe]

If I understand you correctly, then no, there is no explicit support
for that.  I realize that this isn't a great answer but there are
tools in the java.util.concurrent package that should help you handle
these tasks.  Specifically, I'm thinking of Barrier, Semaphore and
Lock classes.

-Tom

On Mon, Jun 16, 2008 at 1:19 PM, Dave Murray-Rust
<d.murray-rust@...> wrote:

> OK, thanks that helps a lot.
>
> So, each action can be run in a thread, but the same action cannot (easily)
> have multiple threads to parallellize processing the different agents it
> applies to? For instance, if I have a lot of the same type of agents, and I
> want to make use of multiple cores, I must find a way to split the action
> into several parts which will then independently run in their own threads?
>
> Is there any support for taking a set of agents running the same complex
> action and having some agents run their action in one thread and some in
> another (I can imagine some workarounds, but it seems like a useful piece of
> functionality in this increasingly multicore world...)
>
> Cheers,
> dave
>
> On 16 Jun 2008, at 13:17, Tom Howe wrote:
>
>> The Repast scheduler does run in a separate thread, and the default
>> mode of operation is that the actions are essentially single threaded.
>> However, if you use the "duration" parameter which is included in
>> most of the scheduler methods, the action will be executed in a
>> separate thread.  Of course, all normal warnings about multithreaded
>> coding apply (synchronize your data, etc).
>>
>> -Tom
>>
>> On Mon, Jun 16, 2008 at 5:38 AM, Dave Murray-Rust
>> <d.murray-rust@...> wrote:
>>>
>>> Hi all,
>>>
>>> I'm trying to understand what level of multithreading repast provides.
>>> Does it simply run the scheduler in a separate thread, or is there the
>>> possibility of running multiple threads for updates.
>>>
>>> Currently, I'm running on a dual-core machine, and it's only using one
>>> core - is this normal, and is there any (relatively easy) way to
>>> distribute agents across multiple cores? (I'm on OSX in case that
>>> makes a difference)
>>>
>>> Cheers,
>>> dave
>>>
>>> --
>>> The University of Edinburgh is a charitable body, registered in
>>> Scotland, with registration number SC005336.
>>>
>>>
>>> -------------------------------------------------------------------------
>>> Check out the new SourceForge.net Marketplace.
>>> It's the best place to buy or sell services for
>>> just about anything Open Source.
>>> http://sourceforge.net/services/buy/index.php
>>> _______________________________________________
>>> Repast-interest mailing list
>>> Repast-interest@...
>>> https://lists.sourceforge.net/lists/listinfo/repast-interest
>>>
>>
>
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Repast-interest mailing list
Repast-interest@...
https://lists.sourceforge.net/lists/listinfo/repast-interest

[Nick Collier-2]

You might also want to look at Doug Lea's Fork Join framework.

http://gee.cs.oswego.edu/dl/papers/fj.pdf

This can be useful in that the schedule itself introduces another  
thing to synchronize against. For example, if you schedule agent A to  
do B at time T, the normal assumption is that when B returns the  
schedule can move on to the next event. The fork / join stuff should  
allow you to work within this paradigm but parallelize those bits of  
agent behavior (B, for example) that can be decomposed.

Nick

On Jun 16, 2008, at 2:19 PM, Dave Murray-Rust wrote:

> OK, thanks that helps a lot.
>
> So, each action can be run in a thread, but the same action cannot
> (easily) have multiple threads to parallellize processing the
> different agents it applies to? For instance, if I have a lot of the
> same type of agents, and I want to make use of multiple cores, I must
> find a way to split the action into several parts which will then
> independently run in their own threads?
>
> Is there any support for taking a set of agents running the same
> complex action and having some agents run their action in one thread
> and some in another (I can imagine some workarounds, but it seems like
> a useful piece of functionality in this increasingly multicore  
> world...)
>
> Cheers,
> dave
>
> On 16 Jun 2008, at 13:17, Tom Howe wrote:
>
>> The Repast scheduler does run in a separate thread, and the default
>> mode of operation is that the actions are essentially single  
>> threaded.
>> However, if you use the "duration" parameter which is included in
>> most of the scheduler methods, the action will be executed in a
>> separate thread.  Of course, all normal warnings about multithreaded
>> coding apply (synchronize your data, etc).
>>
>> -Tom
>>
>> On Mon, Jun 16, 2008 at 5:38 AM, Dave Murray-Rust
>> <d.murray-rust@...> wrote:
>>> Hi all,
>>>
>>> I'm trying to understand what level of multithreading repast
>>> provides.
>>> Does it simply run the scheduler in a separate thread, or is there
>>> the
>>> possibility of running multiple threads for updates.
>>>
>>> Currently, I'm running on a dual-core machine, and it's only using
>>> one
>>> core - is this normal, and is there any (relatively easy) way to
>>> distribute agents across multiple cores? (I'm on OSX in case that
>>> makes a difference)
>>>
>>> Cheers,
>>> dave
>>>
>>> --
>>> The University of Edinburgh is a charitable body, registered in
>>> Scotland, with registration number SC005336.
>>>
>>>
>>> -------------------------------------------------------------------------
>>> Check out the new SourceForge.net Marketplace.
>>> It's the best place to buy or sell services for
>>> just about anything Open Source.
>>> http://sourceforge.net/services/buy/index.php
>>> _______________________________________________
>>> Repast-interest mailing list
>>> Repast-interest@...
>>> https://lists.sourceforge.net/lists/listinfo/repast-interest
>>>
>>
>
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Repast-interest mailing list
> Repast-interest@...
> https://lists.sourceforge.net/lists/listinfo/repast-interest

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Repast-interest mailing list
Repast-interest@...
https://lists.sourceforge.net/lists/listinfo/repast-interest

[Miles Parker]

You'd also want to think carefully about repeatability, i.e. w/  
synchronization issues if you are updating values for agents based on  
values that exist in other agents, and one processor gets a few extra  
cycles you could very easily have different results from the same  
seed. Parallel stuff works very well with simultaneous updates, e.g.  
CA type models where the state for the _entire_ model is based on the  
state from the previous iteration only. I experimented quite a bit  
with supporting parallel operation transparently in Ascape. I used  
barriers to ensure that the above situation didn't occur, but after  
all of that extra work -- and in effect taking the LCD of processor  
performance -- I only was able to achieve a 20% improvement in speed  
on a dual processor Opteron system. Now, my implementation might have  
been sucky, and with the multi-core stuff this is only going to become  
much more important, so I wouldn't say that this one result should  
keep people from trying. This was actually a significant motivator for  
the meta modeling approaches as having the semantic model information  
at code generation time is really the only way that I can think of  
(excluding processor optimization tricks and perhaps dynamic code  
morphing) to know reliably wether certain parallel operations can be  
safely made, or if they can't be made safely, what you might give up  
by doing it anyway. And typically, that's repeatability..

On Jun 16, 2008, at 12:14 PM, Tom Howe wrote:

> If I understand you correctly, then no, there is no explicit support
> for that.  I realize that this isn't a great answer but there are
> tools in the java.util.concurrent package that should help you handle
> these tasks.  Specifically, I'm thinking of Barrier, Semaphore and
> Lock classes.
>
> -Tom
>
> On Mon, Jun 16, 2008 at 1:19 PM, Dave Murray-Rust
> <d.murray-rust@...> wrote:
>> OK, thanks that helps a lot.
>>
>> So, each action can be run in a thread, but the same action cannot  
>> (easily)
>> have multiple threads to parallellize processing the different  
>> agents it
>> applies to? For instance, if I have a lot of the same type of  
>> agents, and I
>> want to make use of multiple cores, I must find a way to split the  
>> action
>> into several parts which will then independently run in their own  
>> threads?
>>
>> Is there any support for taking a set of agents running the same  
>> complex
>> action and having some agents run their action in one thread and  
>> some in
>> another (I can imagine some workarounds, but it seems like a useful  
>> piece of
>> functionality in this increasingly multicore world...)
>>
>> Cheers,
>> dave
>>
>> On 16 Jun 2008, at 13:17, Tom Howe wrote:
>>
>>> The Repast scheduler does run in a separate thread, and the default
>>> mode of operation is that the actions are essentially single  
>>> threaded.
>>> However, if you use the "duration" parameter which is included in
>>> most of the scheduler methods, the action will be executed in a
>>> separate thread.  Of course, all normal warnings about multithreaded
>>> coding apply (synchronize your data, etc).
>>>
>>> -Tom
>>>
>>> On Mon, Jun 16, 2008 at 5:38 AM, Dave Murray-Rust
>>> <d.murray-rust@...> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> I'm trying to understand what level of multithreading repast  
>>>> provides.
>>>> Does it simply run the scheduler in a separate thread, or is  
>>>> there the
>>>> possibility of running multiple threads for updates.
>>>>
>>>> Currently, I'm running on a dual-core machine, and it's only  
>>>> using one
>>>> core - is this normal, and is there any (relatively easy) way to
>>>> distribute agents across multiple cores? (I'm on OSX in case that
>>>> makes a difference)
>>>>
>>>> Cheers,
>>>> dave
>>>>
>>>> --
>>>> The University of Edinburgh is a charitable body, registered in
>>>> Scotland, with registration number SC005336.
>>>>
>>>>
>>>> -------------------------------------------------------------------------
>>>> Check out the new SourceForge.net Marketplace.
>>>> It's the best place to buy or sell services for
>>>> just about anything Open Source.
>>>> http://sourceforge.net/services/buy/index.php
>>>> _______________________________________________
>>>> Repast-interest mailing list
>>>> Repast-interest@...
>>>> https://lists.sourceforge.net/lists/listinfo/repast-interest
>>>>
>>>
>>
>>
>> --
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>>
>>
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Repast-interest mailing list
> Repast-interest@...
> https://lists.sourceforge.net/lists/listinfo/repast-interest

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Repast-interest mailing list
Repast-interest@...
https://lists.sourceforge.net/lists/listinfo/repast-interest

[Dave Murray-Rust-2]

Thanks all for the discussion on multithreading. It's been quite  
interesting for me, coming from a JADE background, where each agent  
runs in its own thread, and there's a very 'hands-off' approach to how  
you're allowed (as a programmer) to interact with agents. In that  
world, repeatability tended to come more from the increased  
formalisation of agent behaviours - protocols tended to be designed so  
that they were relatively time independent.

I've quite enjoyed the stuff in java.util.concurrent, so I guess I'll  
have a look into using that for appropriate parts of my model.

 From personal experience, it seems that I run models either as part  
of my development cycle, to see if they're behaving about right, or I  
run them to get results. In development, I want it to run as quickly  
as possible, so I can fix the latest round of bugs, where as when  
collecting results, time is less of a factor (until the model gets  
gigantic!).
Thinking out loud, would it make sense to add a parameter to the  
SynchronizedMethod annotation, e.g. Paralellizable=true, at which  
point the scheduler packages the agents into Ncores blocks and  
schedules each one in a different thread? If this could be easily  
switched on and off, it would mean that model development could be  
done with quick, non-repeatable runs on a multicore desktop, and it  
could all be switched into serial mode when the time came to do  
ensemble runs or regression tests.

Cheers,
dave


On 17 Jun 2008, at 19:05, Miles Parker wrote:

>
> You'd also want to think carefully about repeatability, i.e. w/  
> synchronization issues if you are updating values for agents based  
> on values that exist in other agents, and one processor gets a few  
> extra cycles you could very easily have different results from the  
> same seed. Parallel stuff works very well with simultaneous updates,  
> e.g. CA type models where the state for the _entire_ model is based  
> on the state from the previous iteration only. I experimented quite  
> a bit with supporting parallel operation transparently in Ascape. I  
> used barriers to ensure that the above situation didn't occur, but  
> after all of that extra work -- and in effect taking the LCD of  
> processor performance -- I only was able to achieve a 20%  
> improvement in speed on a dual processor Opteron system. Now, my  
> implementation might have been sucky, and with the multi-core stuff  
> this is only going to become much more important, so I wouldn't say  
> that this one result should keep people from trying. This was  
> actually a significant motivator for the meta modeling approaches as  
> having the semantic model information at code generation time is  
> really the only way that I can think of (excluding processor  
> optimization tricks and perhaps dynamic code morphing) to know  
> reliably wether certain parallel operations can be safely made, or  
> if they can't be made safely, what you might give up by doing it  
> anyway. And typically, that's repeatability..
>
> On Jun 16, 2008, at 12:14 PM, Tom Howe wrote:
>
>> If I understand you correctly, then no, there is no explicit support
>> for that.  I realize that this isn't a great answer but there are
>> tools in the java.util.concurrent package that should help you handle
>> these tasks.  Specifically, I'm thinking of Barrier, Semaphore and
>> Lock classes.
>>
>> -Tom
>>
>> On Mon, Jun 16, 2008 at 1:19 PM, Dave Murray-Rust
>> <d.murray-rust@...> wrote:
>>> OK, thanks that helps a lot.
>>>
>>> So, each action can be run in a thread, but the same action cannot  
>>> (easily)
>>> have multiple threads to parallellize processing the different  
>>> agents it
>>> applies to? For instance, if I have a lot of the same type of  
>>> agents, and I
>>> want to make use of multiple cores, I must find a way to split the  
>>> action
>>> into several parts which will then independently run in their own  
>>> threads?
>>>
>>> Is there any support for taking a set of agents running the same  
>>> complex
>>> action and having some agents run their action in one thread and  
>>> some in
>>> another (I can imagine some workarounds, but it seems like a  
>>> useful piece of
>>> functionality in this increasingly multicore world...)
>>>
>>> Cheers,
>>> dave
>>>
>>> On 16 Jun 2008, at 13:17, Tom Howe wrote:
>>>
>>>> The Repast scheduler does run in a separate thread, and the default
>>>> mode of operation is that the actions are essentially single  
>>>> threaded.
>>>> However, if you use the "duration" parameter which is included in
>>>> most of the scheduler methods, the action will be executed in a
>>>> separate thread.  Of course, all normal warnings about  
>>>> multithreaded
>>>> coding apply (synchronize your data, etc).
>>>>
>>>> -Tom
>>>>
>>>> On Mon, Jun 16, 2008 at 5:38 AM, Dave Murray-Rust
>>>> <d.murray-rust@...> wrote:
>>>>>
>>>>> Hi all,
>>>>>
>>>>> I'm trying to understand what level of multithreading repast  
>>>>> provides.
>>>>> Does it simply run the scheduler in a separate thread, or is  
>>>>> there the
>>>>> possibility of running multiple threads for updates.
>>>>>
>>>>> Currently, I'm running on a dual-core machine, and it's only  
>>>>> using one
>>>>> core - is this normal, and is there any (relatively easy) way to
>>>>> distribute agents across multiple cores? (I'm on OSX in case that
>>>>> makes a difference)
>>>>>
>>>>> Cheers,
>>>>> dave
>>>>>
>>>>> --
>>>>> The University of Edinburgh is a charitable body, registered in
>>>>> Scotland, with registration number SC005336.
>>>>>
>>>>>
>>>>> -------------------------------------------------------------------------
>>>>> Check out the new SourceForge.net Marketplace.
>>>>> It's the best place to buy or sell services for
>>>>> just about anything Open Source.
>>>>> http://sourceforge.net/services/buy/index.php
>>>>> _______________________________________________
>>>>> Repast-interest mailing list
>>>>> Repast-interest@...
>>>>> https://lists.sourceforge.net/lists/listinfo/repast-interest
>>>>>
>>>>
>>>
>>>
>>> --
>>> The University of Edinburgh is a charitable body, registered in
>>> Scotland, with registration number SC005336.
>>>
>>>
>>
>> -------------------------------------------------------------------------
>> Check out the new SourceForge.net Marketplace.
>> It's the best place to buy or sell services for
>> just about anything Open Source.
>> http://sourceforge.net/services/buy/index.php
>> _______________________________________________
>> Repast-interest mailing list
>> Repast-interest@...
>> https://lists.sourceforge.net/lists/listinfo/repast-interest
>
>

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Repast-interest mailing list
Repast-interest@...
https://lists.sourceforge.net/lists/listinfo/repast-interest

[Miles Parker]

On Jun 20, 2008, at 2:07 AM, Dave Murray-Rust wrote:

> Thanks all for the discussion on multithreading. It's been quite  
> interesting for me, coming from a JADE background, where each agent  
> runs in its own thread, and there's a very 'hands-off' approach to  
> how you're allowed (as a programmer) to interact with agents. In  
> that world, repeatability tended to come more from the increased  
> formalisation of agent behaviours - protocols tended to be designed  
> so that they were relatively time independent.

Gotcha..I think there is a lack of clarity in the terminology or my  
use of it. Repeatability for me in this sense == the ability to obtain  
*exactly* the same result in terms of every agent's micro behaviors  
from a known seed, whereas "reproducible" == the ability to produce  
the same general results given the same set of specifications. IOTW, a  
fully determined model. Or are the more loosely coupled models  
actually precise (perhaps a better word would be rigid) enough in  
their formalisms to produce entirely repeatable results?

>
>
> I've quite enjoyed the stuff in java.util.concurrent, so I guess  
> I'll have a look into using that for appropriate parts of my model.
>
> From personal experience, it seems that I run models either as part  
> of my development cycle, to see if they're behaving about right, or  
> I run them to get results. In development, I want it to run as  
> quickly as possible, so I can fix the latest round of bugs, where as  
> when collecting results, time is less of a factor (until the model  
> gets gigantic!).

The way that some of talk about this is "interactive" v. "batch"  
modes. But yes, its a very good idea to do things this way. Though I'd  
argue that you also want speed on the batch side as that is where you  
will be doing the most runs. But there are a bunch of other things you  
can do there, starting w/ pulling out all UI, unnecessary stats calls,  
etc.. and the fact that batch runs are very amenable to simple  
embarrassingly parallel implementations. Speaking of, we need good  
tools to give an interactive flavor to batch runs, through sending  
multiple jobs off to cluster nodes transparently and feeding back  
results to the user in real time.

I'm just  getting ready to upload the GIS stuff, btw.

>
> Thinking out loud, would it make sense to add a parameter to the  
> SynchronizedMethod annotation, e.g. Paralellizable=true, at which  
> point the scheduler packages the agents into Ncores blocks and  
> schedules each one in a different thread? If this could be easily  
> switched on and off, it would mean that model development could be  
> done with quick, non-repeatable runs on a multicore desktop, and it  
> could all be switched into serial mode when the time came to do  
> ensemble runs or regression tests.
>
> Cheers,
> dave
>
>
> On 17 Jun 2008, at 19:05, Miles Parker wrote:
>
>>
>> You'd also want to think carefully about repeatability, i.e. w/  
>> synchronization issues if you are updating values for agents based  
>> on values that exist in other agents, and one processor gets a few  
>> extra cycles you could very easily have different results from the  
>> same seed. Parallel stuff works very well with simultaneous  
>> updates, e.g. CA type models where the state for the _entire_ model  
>> is based on the state from the previous iteration only. I  
>> experimented quite a bit with supporting parallel operation  
>> transparently in Ascape. I used barriers to ensure that the above  
>> situation didn't occur, but after all of that extra work -- and in  
>> effect taking the LCD of processor performance -- I only was able  
>> to achieve a 20% improvement in speed on a dual processor Opteron  
>> system. Now, my implementation might have been sucky, and with the  
>> multi-core stuff this is only going to become much more important,  
>> so I wouldn't say that this one result should keep people from  
>> trying. This was actually a significant motivator for the meta  
>> modeling approaches as having the semantic model information at  
>> code generation time is really the only way that I can think of  
>> (excluding processor optimization tricks and perhaps dynamic code  
>> morphing) to know reliably wether certain parallel operations can  
>> be safely made, or if they can't be made safely, what you might  
>> give up by doing it anyway. And typically, that's repeatability..
>>
>> On Jun 16, 2008, at 12:14 PM, Tom Howe wrote:
>>
>>> If I understand you correctly, then no, there is no explicit support
>>> for that.  I realize that this isn't a great answer but there are
>>> tools in the java.util.concurrent package that should help you  
>>> handle
>>> these tasks.  Specifically, I'm thinking of Barrier, Semaphore and
>>> Lock classes.
>>>
>>> -Tom
>>>
>>> On Mon, Jun 16, 2008 at 1:19 PM, Dave Murray-Rust
>>> <d.murray-rust@...> wrote:
>>>> OK, thanks that helps a lot.
>>>>
>>>> So, each action can be run in a thread, but the same action  
>>>> cannot (easily)
>>>> have multiple threads to parallellize processing the different  
>>>> agents it
>>>> applies to? For instance, if I have a lot of the same type of  
>>>> agents, and I
>>>> want to make use of multiple cores, I must find a way to split  
>>>> the action
>>>> into several parts which will then independently run in their own  
>>>> threads?
>>>>
>>>> Is there any support for taking a set of agents running the same  
>>>> complex
>>>> action and having some agents run their action in one thread and  
>>>> some in
>>>> another (I can imagine some workarounds, but it seems like a  
>>>> useful piece of
>>>> functionality in this increasingly multicore world...)
>>>>
>>>> Cheers,
>>>> dave
>>>>
>>>> On 16 Jun 2008, at 13:17, Tom Howe wrote:
>>>>
>>>>> The Repast scheduler does run in a separate thread, and the  
>>>>> default
>>>>> mode of operation is that the actions are essentially single  
>>>>> threaded.
>>>>> However, if you use the "duration" parameter which is included in
>>>>> most of the scheduler methods, the action will be executed in a
>>>>> separate thread.  Of course, all normal warnings about  
>>>>> multithreaded
>>>>> coding apply (synchronize your data, etc).
>>>>>
>>>>> -Tom
>>>>>
>>>>> On Mon, Jun 16, 2008 at 5:38 AM, Dave Murray-Rust
>>>>> <d.murray-rust@...> wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> I'm trying to understand what level of multithreading repast  
>>>>>> provides.
>>>>>> Does it simply run the scheduler in a separate thread, or is  
>>>>>> there the
>>>>>> possibility of running multiple threads for updates.
>>>>>>
>>>>>> Currently, I'm running on a dual-core machine, and it's only  
>>>>>> using one
>>>>>> core - is this normal, and is there any (relatively easy) way to
>>>>>> distribute agents across multiple cores? (I'm on OSX in case that
>>>>>> makes a difference)
>>>>>>
>>>>>> Cheers,
>>>>>> dave
>>>>>>
>>>>>> --
>>>>>> The University of Edinburgh is a charitable body, registered in
>>>>>> Scotland, with registration number SC005336.
>>>>>>
>>>>>>
>>>>>> -------------------------------------------------------------------------
>>>>>> Check out the new SourceForge.net Marketplace.
>>>>>> It's the best place to buy or sell services for
>>>>>> just about anything Open Source.
>>>>>> http://sourceforge.net/services/buy/index.php
>>>>>> _______________________________________________
>>>>>> Repast-interest mailing list
>>>>>> Repast-interest@...
>>>>>> https://lists.sourceforge.net/lists/listinfo/repast-interest
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> The University of Edinburgh is a charitable body, registered in
>>>> Scotland, with registration number SC005336.
>>>>
>>>>
>>>
>>> -------------------------------------------------------------------------
>>> Check out the new SourceForge.net Marketplace.
>>> It's the best place to buy or sell services for
>>> just about anything Open Source.
>>> http://sourceforge.net/services/buy/index.php
>>> _______________________________________________
>>> Repast-interest mailing list
>>> Repast-interest@...
>>> https://lists.sourceforge.net/lists/listinfo/repast-interest
>>
>>
>
>
> --
> The University of Edinburgh is a charitable body, registered in
> Scotland, with registration number SC005336.
>

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Repast-interest mailing list
Repast-interest@...
https://lists.sourceforge.net/lists/listinfo/repast-interest