THE PARALLEL PROGRAMMING LANGUAGE: i. ?· Second, monitors and ... Monica Lam served on my orals committee…

  • Published on
    19-Aug-2018

  • View
    212

  • Download
    0

Transcript

  • THE Cool PARALLEL PROGRAMMING LANGUAGE:DESIGN, IMPLEMENTATION, AND PERFORMANCE

    a dissertation

    submitted to the department of computer sci ence

    and the committee on graduate studi es

    of stanforduniversi ty

    in partial fulfi llment of the requirements

    for the degree of

    doctor of phi losophy

    Rohit ChandraApril 1995

  • c Copyright 1995by

    Rohit ChandraAll Rights Reserved

    ii

  • I certify that I have read this dissertation and that in my opinionit is fully adequate, in scope and in quality, as a dissertationfor the degree of Doctor of Philosophy.

    John L. Hennessy(Principal Advisor)

    I certify that I have read this dissertation and that in my opinionit is fully adequate, in scope and in quality, as a dissertationfor the degree of Doctor of Philosophy.

    Anoop Gupta(Co-advisor)

    I certify that I have read this dissertation and that in my opinionit is fully adequate, in scope and in quality, as a dissertationfor the degree of Doctor of Philosophy.

    Monica S. Lam

    Approved for the University Committee on Graduate Studies:

    iii

  • Abstract

    Effective utilization of multiprocessors requires that a program be partitioned for parallelexecution, and that it execute with good data locality and load balance. Although auto-matic compiler-based techniques to address these concerns are attractive, they are oftenlimited by insufficient information about the application. Explicit programmer participa-tion is therefore necessary for programs that exploit unstructured task-level parallelism.However, support for such intervention must address the tradeoff between ease of useand providing a sufficient degree of control to the programmer.

    In this thesis we present the programming language Cool, that extends C++ withsimple and efficient constructs for writing parallel programs. Cool is targeted towardsprogramming shared-memory multiprocessors. Our approach emphasizes the integra-tion of concurrency and synchronization with data abstraction. Concurrent execution isexpressed through parallel functions that execute asynchronously when invoked. Syn-chronization for shared objects is expressed through monitors, and event synchronizationis expressed through condition variables. This approach provides several benefits. First,integrating concurrency with data abstraction allows construction of concurrent data struc-tures that have most of the complex details suitably encapsulated. Second, monitors andcondition variables integrated with objects offer a flexible set of building blocks that canbe used to build more complex synchronization abstractions. Synchronization operationsare clearly identified through attributes and can be optimized by the compiler to reducesynchronization overhead. Finally, the object framework supports abstractions to improvethe load distribution and data locality of the program.

    Besides these mechanisms for exploiting parallelism, Cool also provides supportfor the programmer to address the performance issues, in the form of abstractions thatcan be used to supply hints about the objects referenced by parallel tasks. These hintsare used by the runtime system to schedule tasks close to the objects they reference,and thereby improve data locality. The hints are easily supplied by the programmer interms of the objects in the program, while the details of task creation and scheduling aremanaged transparently within the runtime system. Furthermore, the hints do not affect thesemantics of the program and allow the programmer to easily experiment with differentoptimizations.

    iv

  • Coolhas been implemented on several shared-memory machines, including the Stan-ford DASH multiprocessor. We have programmed a variety of applications in Cool,including many from the SPLASH parallel benchmark suite. Our experience has beenpromising: the applications are easily expressed in Cool, and perform as well as hand-tuned codes using lower-level primitives. Furthermore, supplying hints has proven tobe an easy and effective way of improving program performance. This thesis thereforedemonstrates that (a) the simple but powerful constructs in Cool can effectively ex-ploit task-level parallelism across a variety of application programs, (b) an object-basedapproach improves both the expressiveness and the performance of parallel programs,and (c) improving data locality can be simple through a combination of programmerabstractions and smart scheduling mechanisms.

    v

  • Acknowledgements

    It is a pleasure to acknowledge the people who have contributed in different ways tothis dissertation. Foremost amongst them is my advisor, John Hennessy, who providedconstant encouragement and enthusiasm, and never hesitated to remind me that thisdissertation was about designing a programming language. I was very fortunate to haveAnoop Gupta as my co-advisor, who was there to remind me that the language had tosolve the problems of real parallel programmers. I am grateful to him for his criticismsand his total hands-on involvement (how many advisors will sit and hack with you fortwo days?). Monica Lam served on my orals committee and read this dissertation, andhelped balance my perspective on the thesis. Mendel Rosenblum served on my oralscommittee, and Krishna Saraswat chaired the oral examination.

    Many students worked with me on Cool during various stages as the languageevolved. The primary co-conspirators were Arul Menezes and Shigeru Urushibara, whoparticipated in the initial language design and implementation. Several students subse-quently used Cool for various application projects, including Avneesh Agrawal, Ma-neesh Agrawala, Denis Bohm, Michael Lin, Greg Lindhorst, Steve Speer, Robert Wilson,and Kaoru Uchida. I am grateful to them for developing many of the Cool applicationspresented here, for their patience with the prototype implementation, and for providingvaluable feedback on the language design.

    Members of the DASH group provided the incredibly broad environment essential forsystems research; through them I learnt about other aspects of parallel computer systems.J. P. Singh and Ed Rothberg developed many of the parallel applications used in thisdissertation, and cheerfully helped in porting them to Cool. Jonathan Chew and DaveNakahira kept DASH alive and well, and Charlie Orgish kept the maze of machines inCIS working.

    Several friends offered relief when I was too deeply buried in the thesis. KouroshGharachorloo, Ravi Soundararajan, Ben Verghese, Scott Devine, and Mendel Rosenblumprovided refreshing diversions from Cool into other research areas. Avneesh Agrawalrescued me from tennis deprivation at all hours, David Cyrluk introduced me to theintramural table-tennis competition, and Hanna Djajapranata humored my pizza and ice-cream excursions. Kourosh, my office-mate for all these years, inflicted me with reluctant

    vi

  • learning of memory consistency models. Ashok Subramanian, my house-mate for someyears, coined the name of the language (Cool). JP, my house-mate for the other years,contributed to my stamina through house-hunting tests of endurance.

    Jumping through the bureaucratic hoops involved would not be possible without theadministrative support provided by Margaret Rowland, Darlene Hadding, and the amazingCSD staff. They have kept the bureaucracy off my back, and kept my student life runningsmoothly in spite of all my efforts to the contrary (how else could I file a study list twoquarters late?). I am grateful to Silicon Graphics for graciously providing me with timeoff to finish this dissertation, and to DARPA for patiently providing several years offunding for this research.

    My final thanks are to my parents, my family, and my wife, for their constant loveand support.

    vii

  • This dissertation is dedicated

    to the memory of my father.

    viii

  • Contents

    Abstract iv

    Acknowledgements vi

    1 Introduction 1

    1.1 The Problem : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 2

    1.2 Our Approach : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 4

    1.2.1 Expressing Parallelism : : : : : : : : : : : : : : : : : : : : : : : 5

    1.2.2 Improving Data Locality and Load Balancing : : : : : : : : : : : 6

    1.2.3 Potential Drawbacks : : : : : : : : : : : : : : : : : : : : : : : : 6

    1.3 Evaluation : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 7

    1.4 Contributions of the Thesis : : : : : : : : : : : : : : : : : : : : : : : : 7

    1.5 Organization of the Thesis : : : : : : : : : : : : : : : : : : : : : : : : : 8

    2 Language Design and Programming Experience 10

    2.1 Runtime Execution Model : : : : : : : : : : : : : : : : : : : : : : : : : 10

    2.2 Language Constructs : : : : : : : : : : : : : : : : : : : : : : : : : : : : 11

    2.2.1 Expressing Concurrency : : : : : : : : : : : : : : : : : : : : : : 11

    2.2.2 Mutual Exclusion : : : : : : : : : : : : : : : : : : : : : : : : : 13

    2.2.3 Event Synchronization : : : : : : : : : : : : : : : : : : : : : : : 14

    2.2.4 Task-Level Synchronization : : : : : : : : : : : : : : : : : : : : 16

    2.2.5 Summary : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 17

    2.3 Examples : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 17

    ix

  • 2.3.1 Illustrating the Constructs : : : : : : : : : : : : : : : : : : : : : 18

    2.3.2 Object-Level Synchronization : : : : : : : : : : : : : : : : : : : 20

    2.3.3 Exclusive Access to Multiple Objects : : : : : : : : : : : : : : : 22

    2.4 Experience with Applications : : : : : : : : : : : : : : : : : : : : : : : 23

    2.4.1 Water : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 24

    2.4.1.1 Exploiting Concurrency : : : : : : : : : : : : : : : : : 26

    2.4.1.2 Expressing Synchronization : : : : : : : : : : : : : : : 26

    2.4.1.3 Performance and Summary : : : : : : : : : : : : : : : 27

    2.4.2 Ocean : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 28

    2.4.2.1 Exploiting Concurrency : : : : : : : : : : : : : : : : : 28

    2.4.2.2 Expressing Synchronization : : : : : : : : : : : : : : : 30

    2.4.2.3 Performance and Summary : : : : : : : : : : : : : : : 30

    2.4.3 LocusRoute : : : : : : : : : : : : : : : : : : : : : : : : : : : : 31

    2.4.3.1 Exploiting Concurrency : : : : : : : : : : : : : : : : : 32

    2.4.3.2 Expressing Synchronization : : : : : : : : : : : : : : : 32

    2.4.3.3 Obtaining Private Per-Task Storage : : : : : : : : : : : 32

    2.4.3.4 Performance and Summary : : : : : : : : : : : : : : : 35

    2.4.4 Panel Cholesky : : : : : : : : : : : : : : : : : : : : : : : : : : 35

    2.4.4.1 Exploiting Concurrency : : : : : : : : : : : : : : : : : 37

    2.4.4.2 Expressing Synchronization : : : : : : : : : : : : : : : 37

    2.4.4.3 Other Performance Issues : : : : : : : : : : : : : : : : 38

    2.4.4.4 Summary : : : : : : : : : : : : : : : : : : : : : : : : 39

    2.4.5 Block Cholesky : : : : : : : : : : : : : : : : : : : : : : : : : : 39

    2.4.5.1 Exploiting Concurrency : : : : : : : : : : : : : : : : : 40

    2.4.5.2 Expressing Synchronization : : : : : : : : : : : : : : : 40

    2.4.5.3 Performance and Summary : : : : : : : : : : : : : : : 42

    2.4.6 Barnes-Hut : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 43

    2.4.6.1 Expressing Concurrency and Synchronization : : : : : 45

    2.4.6.2 Summary : : : : : : : : : : : : : : : : : : : : : : : : 46

    2.4.7 Discussion : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 47

    2.4.7.1 Exploiting Concurrency : : : : : : : : : : : : : : : : : 47

    2.4.7.2 Expressing Synchronization : : : : : : : : : : : : : : : 47

    x

  • 2.4.7.3 The Object-Based Approach : : : : : : : : : : : : : : 48

    2.5 Alternate Design Choices : : : : : : : : : : : : : : : : : : : : : : : : : 49

    2.5.1 Return Value of Parallel Functions : : : : : : : : : : : : : : : : 49

    2.5.1.1 A Variation of the Current Design : : : : : : : : : : : 50

    2.5.1.2 Future Types in oldCool : : : : : : : : : : : : : : : : 52

    2.5.2 Waitfor : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 55

    2.6 Summary : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 55

    3 Data Locality and Load Balancing 57

    3.1 Exploiting the Memory Hierarchy : : : : : : : : : : : : : : : : : : : : : 59

    3.2 Our Approach : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 60

    3.3 The Abstractions : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 60

    3.3.1 Defaults : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 62

    3.3.2 Simple Affinity : : : : : : : : : : : : : : : : : : : : : : : : : : 62

    3.3.3 Task and Object Affinity : : : : : : : : : : : : : : : : : : : : : 63

    3.3.4 Processor Affinity : : : : : : : : : : : : : : : : : : : : : : : : : 63

    3.3.5 Multiple Affinity Hints : : : : : : : : : : : : : : : : : : : : : : 64

    3.3.6 Task Stealing : : : : : : : : : : : : : : : : : : : : : : : : : : : 64

    3.3.7 Summary of Affinity Hints : : : : : : : : : : : : : : : : : : : : 65

    3.4 Object Distribution : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 65

    3.5 Summary : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 69

    4 Implementation and Optimizations 70

    4.1 Implementing the Constructs : : : : : : : : : : : : : : : : : : : : : : : 70

    4.1.1 Concurrency: Parallel Functions : : : : : : : : : : : : : : : : : : 71

    4.1.2 Synchronization: Monitors : : : : : : : : : : : : : : : : : : : : 75

    4.1.2.1 Translation of a Monitor : : : : : : : : : : : : : : : : 76

    4.1.2.2 The Synchronization Algorithm : : : : : : : : : : : : : 77

    4.1.3 Synchronization: Condition Variables : : : : : : : : : : : : : : : 82

    4.1.4 Synchronization: waitfor : : : : : : : : : : : : : : : : : : : : : 83

    4.2 Overheads and Optimizations : : : : : : : : : : : : : : : : : : : : : : : 85

    4.2.1 Overheads : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 85

    4.2.2 Optimizations : : : : : : : : : : : : : : : : : : : : : : : : : : : 86

    xi

  • 4.2.2.1 Monitors with only Mutex Functions : : : : : : : : : : 88

    4.2.2.2 Spin Monitors : : : : : : : : : : : : : : : : : : : : : : 88

    4.2.2.3 Private Condition Variables : : : : : : : : : : : : : : : 89

    4.2.2.4 Directly Recursive Calls : : : : : : : : : : : : : : : : 90

    4.2.2.5 Tail Release Optimization : : : : : : : : : : : : : : : : 90

    4.2.2.6 Parallel Monitor Functions : : : : : : : : : : : : : : : 90

    4.2.3 Evaluating the Optimizations in Applications : : : : : : : : : : : 91

    4.3 Runtime Scheduling Support for Locality Optimizations : : : : : : : : : 94

    4.4 Summary : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 96

    5 Case Studies 97

    5.1 Ocean : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 98

    5.2 Water : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 101

    5.3 LocusRoute : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 105

    5.4 Barnes-Hut : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 109

    5.5 Panel Cholesky : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 112

    5.6 Block Cholesky : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 117

    5.7 Summary : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 122

    6 Related Work 123

    6.1 Other Parallel Languages : : : : : : : : : : : : : : : : : : : : : : :...

Recommended

View more >