In that case, you will positively *hate* Charm++:
Charm++, is a fairly sophisticated parallel programming language and runtime
system that facilitates load balancing, latency hiding, and fault tolerance
through processor virtualization. Applications built upon Charm++ create
parallel objects (""chares"") which then communicate through the runtime
system. Through virtualization and asynchronous communication, portably
scalable applications can be developed, with interconnect- and
communications layer-specific optimizations efficiently and transparently
handled in the Charm++ runtime system. The runtime system can also be tuned
for virtually any architecture to manage object creation for data locality
and to schedule execution of virtual processes to overlap communication with
computation. Charm++ features most relevant to performance on many-core
petascale architectures include data object prioritizing and dynamic load
balancing.
Each parallel task is implemented in Charm++ as an object, which is
scheduled for execution by the runtime engine. Through categorization of the
parallel task objects, the runtime system can selectively prioritize
communications to exploit data locality and to maximize bandwidth. On
many-core architectures, we will apply dynamic object prioritizing to
differentiate objects having data dependencies with only within their
respective nodes from objects that have off-node dependencies. Such
differentiation will reduce traffic on the network interconnect and increase
the overlap of communication and computation.
Dynamic load balancing greatly increases the scalability of Charm++
applications. The runtime system tracks statistics for communication and
computation of each object. The execution statistics are periodically
compared, and because Charm++ parallel objects are not
processornode-centric, objects that are taking excessive amounts of time are
migrated to processors nodes that are less heavily loaded. Load balancing
can be performed across the whole machine or a subset of the machine. For
example, in molecular dynamics simulations, the movement of large- scale
molecular systems is relatively small in relation to the small time steps,
so load balancing after several 100s to 1000s of time steps achieves optimal
layouts that apply with little modification for the remainder of the
simulation. These types of algorithms are among the most difficult of to
load balance, ing cases and Charm++ has unique capabilities include for
local load- balancing and topology awareness which will be absolutely
essential for providing maximum performance on many-core petascale
architectures.
On 6/4/07, Marcus G. Daniels <[EMAIL PROTECTED]> wrote:
Douglas Roberts wrote:
> You could write an ABM in any language, including assembly, but why in
> the world would you want to do that?
Some reasons:
1) because the use of OO methodologies used in many ABMs are often very
basic and require very little software support, e.g. just containers and
messaging
2) simple code is easier to explain to non-programmers
3) simple things can be optimized effectively, and computer performance
is often a rate limiting factor in ABM
============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
lectures, archives, unsubscribe, maps at http://www.friam.org
--
Doug Roberts, RTI International
[EMAIL PROTECTED]
[EMAIL PROTECTED]
505-455-7333 - Office
505-670-8195 - Cell
============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
lectures, archives, unsubscribe, maps at http://www.friam.org
