Difference between revisions of "Main Page/hybrid prog"
From Nekcem
Jump to navigationJump to search| Line 1: | Line 1: | ||
| − | This is the document page for hybrid programming plan for [http://www.mcs.anl.gov/~mmin/nekcem.html NekCEM]. | + | This is the document page for hybrid programming plan for [http://www.mcs.anl.gov/~mmin/nekcem.html NekCEM] (some notes taken from DOE Exascale workshop). |
| − | ==Approaches | + | ==Approaches == |
* hybrid/evolutionary: MPI+ ___ ? | * hybrid/evolutionary: MPI+ ___ ? | ||
** MPI for inter-node prog, since # notes and inter-node concerns not expected to change dramatically | ** MPI for inter-node prog, since # notes and inter-node concerns not expected to change dramatically | ||
| Line 20: | Line 20: | ||
* unified/holistic: __ ? | * unified/holistic: __ ? | ||
** a single notation for inter- and intra-node programming? | ** a single notation for inter- and intra-node programming? | ||
| + | ** traditional PGAS languages: UPC, CAF, Titanium | ||
| + | *** require extension to handle nested parallelism, vertical locality | ||
| + | ** HPCS languages: Chapel, X10, Fortress(?) | ||
| + | *** designed with locality and post-SPMD parallelism in mind | ||
| + | ** other candidates: Charm++, Global Arrays, Parallel X, ... | ||
| + | |||
| + | * others | ||
| + | ** mainstream multi-core/GPU language: (sufficient promise to fund?) | ||
| + | **domain-specific language | ||
| + | *** fit your problem? | ||
| + | *** should focus on more general solutions | ||
| + | **functional languages | ||
| + | *** never heavily adopted in mainstream or HPC | ||
| + | *** copy-on-write optimization and alias analysis? | ||
| + | ** parallel scripting languages? | ||
| + | |||
| + | |||
| + | ==Expectation== | ||
| + | *parallelism: nested, dynamic, loosely-coupled, data-driven (i.e. ''post-SPMD'' programming/execution models) | ||
| + | ** to take advantage of architecture | ||
| + | ** to better support load balancing and resilience | ||
| + | |||
| + | * locality: concepts for vertical control as well as horizontal (i.e. locality within a node rather than simply between nodes) | ||
| + | |||
| + | == Tools: Debuggers, perf. analysis== | ||
| + | * challenges | ||
| + | ** need aggregation to hide details | ||
| + | ** need to report info in user's terms | ||
| + | *good area for innovation (e.g. execution visualization to understand mapping of code to hardware) | ||
Revision as of 11:56, 31 January 2011
This is the document page for hybrid programming plan for NekCEM (some notes taken from DOE Exascale workshop).
Approaches
- hybrid/evolutionary: MPI+ ___ ?
- MPI for inter-node prog, since # notes and inter-node concerns not expected to change dramatically
- support for hybrid programming/interoperability
- purer one-sided communications; active messages
- asynchronous collectives
- something else for intra-node
- OpenMP
- introduction of locality-oriented concepts?
- efforts in OpenMP 3.0 ?
- PGAS languages
- already support a notation of locality in a shared namespace
- UPC/CAF need to relax strictly SPMD execution model
- Sequoia
- support a strong notation of vertical locality
- OpenMP
- MPI for inter-node prog, since # notes and inter-node concerns not expected to change dramatically
- unified/holistic: __ ?
- a single notation for inter- and intra-node programming?
- traditional PGAS languages: UPC, CAF, Titanium
- require extension to handle nested parallelism, vertical locality
- HPCS languages: Chapel, X10, Fortress(?)
- designed with locality and post-SPMD parallelism in mind
- other candidates: Charm++, Global Arrays, Parallel X, ...
- others
- mainstream multi-core/GPU language: (sufficient promise to fund?)
- domain-specific language
- fit your problem?
- should focus on more general solutions
- functional languages
- never heavily adopted in mainstream or HPC
- copy-on-write optimization and alias analysis?
- parallel scripting languages?
Expectation
- parallelism: nested, dynamic, loosely-coupled, data-driven (i.e. post-SPMD programming/execution models)
- to take advantage of architecture
- to better support load balancing and resilience
- locality: concepts for vertical control as well as horizontal (i.e. locality within a node rather than simply between nodes)
Tools: Debuggers, perf. analysis
- challenges
- need aggregation to hide details
- need to report info in user's terms
- good area for innovation (e.g. execution visualization to understand mapping of code to hardware)
