1 / 6

The Most Needed Feature(s) for OpenMP 3.0

Bronis R. de Supinski Center for Applied Scientific Computing Lawrence Livermore National Laboratory June 2, 2005. The Most Needed Feature(s) for OpenMP 3.0. What makes new features worthwhile?. Support for underlying OpenMP philosophy High-level constructs Easy-to-understand semantics

donkor
Download Presentation

The Most Needed Feature(s) for OpenMP 3.0

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Bronis R. de SupinskiCenter for Applied Scientific ComputingLawrence Livermore National LaboratoryJune 2, 2005 The Most Needed Feature(s)for OpenMP 3.0

  2. What makes new features worthwhile? • Support for underlying OpenMP philosophy • High-level constructs • Easy-to-understand semantics • Low cost extension/modification of serial code • Programmer needs • Variety of parallelism models • Control when appropriate • Clarity of specification (incontrovertible definitions) • Portability • Not just “quality of implementation”

  3. Features for Clarity of Specification • Little details that 2.5 deferred to 3.0 • Over a dozen “small” outstanding issues • Many concern clarity of specification(e.g., directive grammar) • Orthogonality of constructs and base language • Reduction operators: min and max • Array reductions • Allow unsigned integers as LCVs • (More) formalized memory model • Avoids natural language interpretations • Stated strictly in terms of operation orderings • Won’t happen in 3.0…

  4. Several Worthy Candidates • Data distribution • Associate data to threads • Is this implementation- or architecture-specific? • Task queues • Supports a very common form of parallelism • Long-standing, well-understood proposals • Informational interface for tool support • Variable name mangling • Outline routines (or indicate that they aren’t used) • Run-time library names • Others…

  5. Personal Favorites • Contexts or subteams • Allow (subsets of) team to be reordered and named • Provides greater user control • Synchronization • Sections with varying parallelism • Supports portable libraries • Work distribution • User knows which thread should execute which work • Let them specify it! • Schedule rules help but not always natural • Often what users mean by “data distribution”

  6. UCRL-PRES-212612 Work performed under the auspices of the U. S. Department of Energy by University of California Lawrence Livermore National Laboratory under Contract W-7405-Eng-48

More Related