LISTSERV mailing list manager LISTSERV 16.0

Help for MASON-INTEREST-L Archives


MASON-INTEREST-L Archives

MASON-INTEREST-L Archives


MASON-INTEREST-L@LISTSERV.GMU.EDU


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Monospaced Font

LISTSERV Archives

LISTSERV Archives

MASON-INTEREST-L Home

MASON-INTEREST-L Home

MASON-INTEREST-L  January 2016

MASON-INTEREST-L January 2016

Subject:

Re: ParallelSequence bug

From:

Sean Luke <[log in to unmask]>

Reply-To:

MASON Multiagent Simulation Toolkit <[log in to unmask]>

Date:

Tue, 12 Jan 2016 13:21:52 -0500

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (37 lines)

On Jan 12, 2016, at 8:54 AM, Axel Kowald <[log in to unmask]> wrote:

> It runs, but the single threaded version is twice as fast as the version
> with four threads ! :-(
> Maybe that's because I have many removals and insertions of agents. I
> don't now.
> I used setUsesSets(true), which makes things faster, but not as fast as
> the single threaded version.

:-( Did you try profiling it? It is my experience that ABM models benefit from parallelization only when the threads in question are highly non-memory-bound and long enough running. I can give you some heatbugs examples there.

> While doing this I also discovered a bug in loadStepsSet() of Sequence.
> At the end of the method the line
> steps = (Steppable[]) (stepsHash.toArray(steps));
> has to be changed to something like
> steps = (Steppable[]) (stepsHash.toArray(Arrays.copyOfRange(steps, 0, 1)));
> because we must make sure that the size of the passed Steppable[] is
> smaller than the number of elements in stepsHash, otherwise the length
> of the new steps is wrong. What a mad behaviour of toArray() !!

A bug, but I think the fix is different. AFAIK the behavior of toArray(foo) is follows:

- If foo is exactly the right size, it will be used. Here we're fine.

- If foo is too small, a new array will be used and returned. Here we're also fine.

- If foo is too big, it will be used but only filled up as needed. Here, we just need to update the size variable internally.

So we could just do this, right?

size = stepsHash.size();
if (steps == null)
steps = new Steppable[size];
steps = (Steppable[]) (stepsHash.toArray(steps));

Sean

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In