Abstract

The OpenMP standard defines an Application Programming Interface (API) for shared memory computers. Since its introduction in 1997, it has grown to become one of the most commonly used API's for parallel programming. But success in the market doesn't necessarily imply successful computer science. Is OpenMP a "good" programming environment? What does it even mean to call a programming environment good? And finally, once we understand how good or bad OpenMP is; what can we do to make it even better? In this paper, we will address these questions.

Highlights

  • OpenMP [1] is an Application Programming Interface for writing multithreaded programs

  • We map from the problem domain into the algorithm domain using the specification model. This high level, problem-dependent and usually informal model is used as we translate the mathematics of the problem into high-level data structures, an overall algorithm structure, and collections of software components. As we translate those components into code, we need an abstraction of the parallel computation as supported by the target Application Programming Interface (API)

  • The Architecture Review Board (ARB) works on future enhancements to the language through its futures committee

Read more

Summary

Introduction

OpenMP [1] is an Application Programming Interface for writing multithreaded programs It is not a replacement for low-level thread libraries. The overwhelming majority of applications programmers, don’t need to control the low level details of how threads execute. They need portability and maintainability coupled with convenience so they can hit tight delivery schedules. Since its introduction in 1997, OpenMP has grown to become one of the top four API’s for expressing concurrency in programs (the others are MPI, POSIX threads, and the threads API used with Microsoft Operating systems) This is a major improvement over the early to mid 90’s when there were dozens of programming environments to choose between. We will provide an answer to the question “how good is OpenMP”

The historical roots of OpenMP
What is a “good” programming environment
Levels of abstraction in OpenMP
How good is OpenMP?
Making OpenMP more convenient
Making OpenMP even better
Automatic scooping
Expanding the range of specification models
Work queues
Exposing cost models
Thread affinity
Reusable loop schedules
Conclusion
Full Text
Published version (Free)

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call