MASON-INTEREST-L Archives

October 2006

MASON-INTEREST-L@LISTSERV.GMU.EDU

Options: Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Date:
Tue, 10 Oct 2006 12:30:47 -0400
MIME-version:
1.0
Reply-To:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Content-type:
text/plain; charset=us-ascii
Subject:
From:
"Maciej M. Latek" <[log in to unmask]>
In-Reply-To:
Content-transfer-encoding:
7bit
Comments:
To: MASON Multiagent Simulation Toolkit <[log in to unmask]>
Parts/Attachments:
text/plain (34 lines)
Hi all,

I've got a question concerning parallelization of visualization inspired by
parallel version of Heatbugs (which works very nicely on a Core Duo by the
way, one can really see the difference) and Mr. Ong's problem.

My understanding is that, as the GUI thread repaints displays, the SimState
thread is put on hold. When we consider really computationally expensive GUI
tasks as laying out a graphs, this seems to be suboptimal solution. I was
wondering if it would be possible to put the two thread on separate
processors, have the GUI thread probe the other one for information and
afterwards to detach and free the SimState thread to go ahead while GUI is
doing its job. After GUI is done, the process would repeat.

I realize that in general I would loose synchronization, but if I'm laying
something out let's say each 50 time-steps and still have to wait few second
for the simulation to resume, this path would provide me with much smoother
and faster performance. 

The questions are:

1) Is it doable?
2) Would it violate some important MASON design principle?
3) How much modification to MASON core would one have to introduce to arrive
at such a solution?

Regards

Maciek Latek

    

  

ATOM RSS1 RSS2