The Mu的lticore Programming Challenge.pptVIP

* * * * Manage expectations: If I double the core count, how come I don’t double the performance But this is much like uniprocessors – 2*frequency != 2*performance * * * * * Fortress: Data model: shared global address space Control model: multithreaded Basic primitive is “spawn” Transactional access to shared variables Atomic blocks Explicit testing and signaling of failure/retry Lock-free (no blocking, no deadlock) Locality Description of machine structure Objects (including threads) reside in regions Data distribution in library, so extensible Loops are parallel by default X10 Based on Java With an array sublanguage Dynamic asynchronous “activities” lightweight threads Places A collection of data objects and activities Async(P) S: where P is a place, and S is a statement Data is local to activity or place, or is global Synchronization on groups of threads via clocks Clocks are dynamic, thread can register on multiple clocks * * * * * * * * * * * * * * More multilevel codes, easiest way to get more scalability but today this doesn’t work: no thread pinning, no data locality * * Here is roughly how BT-MZ works: - BT-MZ is a multi-zone code. In each time step, each zone is solved independently before the boundary data are communicated to the neighboring zones. The coarse grain parallelization is applied to zone solving stage. - Because these zones have different sizes, a load balancing scheme is applied by grouping the zones into groups that have roughly the same size. Each group of zones is assigned to a SUBTEAM. Number of zone groups = number of subteams (defined by OMP_NUM_THREADS). - For threads within a subteam, they will work on loop-level parallelism with each zone. There is no overlapping of thread ids among different subteams. So, the following piece of code * * * More multilevel codes, easiest way to get more scalability but today this doesn’t work: no thread pinning, no data locality Loop unrolling raises mem usage, a