The Landscape of Seven Questions and Seven Dwarfs for Parallel Computing Research: a view from Berkeley



Download 232.56 Kb.
Page8/13
Date28.01.2017
Size232.56 Kb.
#8845
1   ...   5   6   7   8   9   10   11   12   13

5.0 Programming Models


Figure 1 shows that a programming model is a bridge between a system developer’s natural model of an application and an implementation of that application on available hardware. A programming model must allow the programmer to balance the competing goals of productivity and implementation efficiency. We believe that the keys to achieving this balance are:

  • Opacity abstracts the underlying architecture. Doing so obviates the need for the programmer to learn the architecture’s intricate details and enables programmer productivity.

  • Visibility makes the key elements of the underlying hardware visible to the programmer. It allows the programmer to realize performance constraints of the application by exploring design parameters such as thread boundaries, data locality, and the implementations of elements of the application.

Experiences with both high-performance computing applications [Pancake and Bergmark 1990] and embedded applications [Shah et al 2004a] have shown some common elements that must be accessible from a programming model. For exposed architectures, programs must be balanced computationally with consideration for memory and communication resources. Arbitration schemes for architectures with shared resources can also influence performance. A good programming model should do these things well automatically or provide control, with varying levels of visibility, to the programmer.


Programming models for parallel computation must provide visibility to the features of the architecture to the user or abstract it away. Programming approaches do this by implicitly or explicitly dealing with following:

  • Identification of computational tasks – How is the application divided into parallel tasks?

  • Mapping computational tasks to processing elements – The balance of computation determines how well utilized the processing elements are.

  • Distribution of data to memory elements – Locating data to smaller, closer memories increases the performance of the implementation.

  • The mapping of communication to the inter-connection network – You may avoid interconnect bottlenecks by changing the communication of the application.

  • Inter-task synchronization – The style and mechanisms of synchronizations can influence not only performance, but also functionality.

Figure 8 summarizes the choices on these topics with eight current parallel models for embedded and high performance computing.
While maximizing the raw performance of future multiprocessor devices is important, the real key to their success is the programmer's ability to harvest that performance. In this section, we touch on some of the issues relating to programming highly concurrent machines. Of chief concern to us are how to specify––that is, what abstractions to use––and optimize programs on future architectures. In the following sections we present some “points to ponder” for designers of programming systems for parallel machines. We mostly focus on the visibility/opacity tradeoff when considering:

  • The role of compilation (5.1)

  • The level of abstraction in the programming language (5.2, 5.3, 5.4)

  • Operating sytem support (5.5)




Model

Domain

Computa-tional Tasks

Task Mapping

Data distribution

Communi-cation Mapping

Synchro-nization

Real-Time Workshop [Mathworks 2004]

DSP

Explicit

Explicit

Explicit

Explicit

Explicit

TejaNP [Teja 2003]

Network

Explicit

Explicit

Explicit

Explicit

Explicit

YAPI [Brunel et al 2000]

DSP

Explicit

Explicit

Explicit

Explicit

Implicit

MPI [Snir et al 1998]

HPC

Explicit

Explicit

Explicit

Implicit

Implicit

Pthreads

General

Explicit

Implicit

Implicit

Implicit

Explicit

MapReduce [Dean 2004]

Data sets

Explicit

Implicit

Implicit

Implicit

Explicit

Click to network processors [Plishker et al 2003]

Network

Implicit

Implicit

Implicit

Implicit

Explicit

OpenMP [OpenMP 2006]

HPC

Implicit (directives)

Implicit

Implicit

Implicit

Implicit (directives)

HPF [Koelbel et al 1993]

HPC

Implicit

Implicit

Implicit (directives)

Implicit

Implicit

StreamIt [Gordon et al 2002]to RAW

Video

Implicit

Implicit

Implicit

Implicit

Implicit

Figure 8 Comparison of eightten current parallel programming models, sorted from most explicit to most implicit. [Snir et al 1998] [Plishker et al 2003] [OpenMP 2006] [Koelbel et al 1993]


Download 232.56 Kb.

Share with your friends:
1   ...   5   6   7   8   9   10   11   12   13




The database is protected by copyright ©ininet.org 2024
send message

    Main page