on scalable shared memory multiprocessors...automatic computation and data partitioning on scalable...
TRANSCRIPT
Automatic Computation and Data Partitioning
on Scalable Shared Memory Multiprocessors
Sudarsan Tandri
.I thesis submitted i n conformity nith the requirements
for the degree of Doctor of Philosophy.
Graduate Department of Computer Science.
in the L'niversity of Toronto
@ Copyright by Sudxsan Tandri 1997
National Library 1+1 of Canada Bibliothkque nationale du Canada
Acquisitions and Acquisitions et Bibliographic Services services bibliographiques 395 Wellington Street 395. me Wellington OttawaON KIAON4 OttawaON K1AON4 Canada Canada
Your Me vorre defence
Our rk~ Norre relrKenC8
The author has granted a non L'auteur a accorde une Licence non exclusive licence allowing the exclusive pennettant a la National Library of Canada to Bibliotheque nationale did Canada de reproduce, loan, distribute or sell reproduire, preter, distribuer ou copies of th~s thesis in microform, vendre des copies de cette these sous paper or electronic formats. la forme de microfiche/fh3 de
reproduction sur papier ou su. format Bectronique.
The author retains ownership of the L'auteur conserve la propriete du copyright in thls thesis. Neither the droit d7auteur qui protege cette these. thesis nor substantial extracts fiom it Ni la these ni des extraits substantiels may be printed or otherwise de celleci ne doivent Btre imprimes reproduced without the author's ou autrement reproduits sans son permission. autorisation.
Automatic Computation and Data Partitioning
o n Scalable Shared Memory Multiprocessors
S d a rsa n Tit ndM
Doctor of Philosophy. 1997
Department of Compu ter Science
I:niversit_v of Toronto
Abstract
Scalable shared memory multiprocessors are becoming increasingly popular platforms
for highperformance scientific compu tin% because they both scale to large numbers of pro
cessors and support the familiar shared memory abstraction. In order to improve application
performance on these machines. it is essential to divide computation among processors and
to piace data carefully in the distributed shared memory. I n particular. relying on only
the native operating system page placement policies to manage data often results in poor
performance of applications.
Computation and data partitioning is necessary for the management of corn pu tation and
data on shared memory multiprocessors. The primary focus of this dissertation is the au
tomatic derivation of computation and data partitions For regular scientific applications on
scalable shared memory multiprocessors. Ideally. such partitions masimize parallelism and
cache locality and minirriize remote memory accesses. memory contention. synchronization
overhead. and fake sharing. In general. the problem of deriving optimal computation and
data partitions is XPhard. The conl plesity results from the combinatorics of possible corn
putation and data partitions and the interdependence of the above optimization objectives.
The degree to tvtiich these optimization objectives affect rhe performance of an application
also varies, according to the characteristics of the application and the architecture of the
scalable shared nienlory multiprocessor.
This dissertation presents a heuristic algorithm called the Computa t ion a n d Data Par
t i i ioning (CDP} algorithm for deriving cornputation and data partitions on scalable shared
rnemory n~ultiprocessors. The C'DP algorithm establishes affinity relationships between
~vtlere data is located. based on array accesses in the program. and where computations
are performed. These datacomputation affinity relationships are used as a basis to deter
mine the computation partitions for all the parallel loops. and to determine static and/or
dynamic d a t a partit ions for all the arrays in the input program. The CDP algorithm takes
into account shared mernor. effects i n selecting the appropriate computat ion and d a t a par
titions. Esperirnental results from the implementation of the CDP algorithm in a prototype
compiler demonst rate that t he algorithm is romputationally efficient and t h a t i t improves
t.he performarice of a s ~ ~ i t e of benchmark applications. compared to the native operating
..;?stern page placement policies for d a t a management.
Acknowledgements
First and foremost. I would like to thank my supervisor Tarek 1bdelrahman for guid
ing me throughout my Pt1.D. I deeply respect his ability to translate ideas into technical
documents. l t y special thanks to SIichael Stumrn for channelizing my ideas onto a right
track. and tor his ir~valuable suggestions which has transformed the structure of this thesis.
I thank Ken Sevcik. Songnian Zhou. and Charles Clarke for beins my committee members
and for providing valuable suggestions ~vhich improved the quality of this thesis. ll_v thanks
to Rudolf Eigenmann for being my esternal examiner. and for providing valuable comments
for estending this research.
l l y greatest thanks to m y friend. Dattatraya Kufkarni for h is ~a luable suggestions.
his never give up" attitude. and for helping rne endure the turbulent times during the
culmination of this thesis. l [ y thanks to Stian kar and Ravindran. who were always there for
me as good friends. I also thank H u i . tiarim. and Danny for all the interesting discussions.
I thank the Hector team and the Hurricane team for providing the Hector multipro
cessor. I a m grateful to the Center for Parallel Computing at the Cniversity of Ilichigan
for providing time o n the Conyes Exemplar multiprocessor. I a m especiall> thankful to
Andretv C'aird of the C'PC for his invaluable help with the system.
.\I! heartfelt t l ~ a n ks to i'ijaya. PSX. Papooz. and Jaoa for sharing my sorrons and
jubilant times during the PI1.D. roller cocaster which seemed to have many more troughs
than peaks. I thank rn> brothers Shyam. Giri. Hari. and Balaji for encouragirig me and for
taking pride in all my endeavors. Finally and importantl!.. t wish to thank my wife. Radha.
for her undaunted belief i n my abilities and her patience.
S[y parents t1ai.e been very supportive and it is to them that I dedicate this thesis.
To my parents
Contents
1 Introduction 1
...................................... 1.1 Computation and Data Partitioning 2
....................................................... 1.2 Research Overview 4
...................................................... 1.3 Thesis Organization 5
2 Background and Related Work 6
............................................................ 1 The Problerrl 6
............................ 2.2 Notation for C'orripntation and Data Partitions 8
................................................... '2.2.1 Data Partitions 9
........................................... 2.2.2 C'omputation Partitions 11
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Related \Vork 11
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Gupta and Banerjee 12
...................................... 2 . 3 . Bisby . Iiremer . and iicnnedy 13
............................................. 2 . 3 Palermo and Banerjee 13
2 . 4 Ciarciactal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
................................................ 2.3 ..5 .\ nderson and Lam 1.5
............................................................... 2.4 Discussion 16
3 New Computation and Data Partitions 17
.............................................. 1 Ncw Distribution Attributes 17
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 . Rcvcrse Distribution Attributes 17
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.2 C'orrlpourtd Distribution Attributes 'LO
..................................................... 3.2 New Data Partitions 21
............................................ 3.2.1 ilanytoOne Mapping 22
6 Cost Model for Performance Estimation 79
...................................... 6.1 Performance Estimation Parameters 79
.................................... 6.1.1 MachineDependent Parameters $0
................................... 6 . 1 ProgramDependent Parameters 81
...................................................... 2 .I lode1 Formulation $1
............................... 6.3 Estimating LlachineDependent Parameters $ 3
............................... 6.4 Estimating ProgramDependent Parameters 35
................................... 6.4.1 Estimating Array Access Ranges d.5
............................. 6.4.2 Estimating Local and Remote .kcesses 86
6 . 3 Including Temporal Reuse .A cross Loops i n the Estimation of the
................................................... Cache =\ccesses 37
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 ..i Putting It All Toogether 91
................................................. 6.6 Cache Utilization Factor 92
............................................................... 6.7 Summary 92
7 Experimental Results 94 . ................................................. I . I Benchmark Applications 94
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 . 2 Experimental Platforms 96  ....... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 . 2 . Hector 97
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.2 Con\.es Esemplar 97  1.2.:) KSR1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98  ............................. 2  C'orriments on llachine Characteristics SP
 ................................................. 1.3 T h e Compiler Prototype 99  ..................................................... 4 Overall Performance 100  " ................................................... I . Compiler Performance LO6
 .................................. 1 ..i .L DataComputation Affinity Phase 106   .................................... t 3 . 2 Dynamic Array Partition Phase 10s  ............................... 1 .5 .:I Processor Geomet r~ ltapping Phase 109   ................... I 3 . 4 Corn ments on the Characteristics of Applications 110
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6 Comparison wit11 Other Approaches 111   ............................................................... I . ( Summary 114
8 Conclusion 115
8.1 Contributions ........................................................... 116
............................................ 2 Directions for Future Research 116
.......................................... 8.2.1 Interprocedural Analysis 116
.................................... Y .2.2 Dynamic Processor Geometries 117
........................................... S.2.3 Performance Estimation 117
.................................... 8.2.4 Hybrid .\ lultiprocessor Systems 117
Bibliography 118
A Implementing Data Partitions on SSMMs 122
B Training Set Kernels 125
.......................................... B.1 The l l emory Contention Factor 12.5
............................................. B.2 The Cost of Synchronization 126
......................................................... 8.3 The OCP Factor 128
List of Tables
.................................... 4.1 Requirements for the psinv subroutine 33
1.2 Performance bot tienecks i n various data and computation partitionings for
..................................................................... .AD[ 39
.................................... fj.1 Parameters for performance estimation 80
............... 6.2 .\fachin edependent parameters for modelling multiprocessors $4
. ................................................ 4 . L Application characteristics 9.5  ............................................. 2 .\ lultiprocessor characteristics 07
7.3 Execlition time of sequential application on 1 processor of the indicated ma
. . . . . . . . . . . . . . . chine i n rnilli Seconds (Problem Size is shown i n parenthesis) LO0  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . , .I Data partitions derii:ed by the CDP algoritlm 101  . 4.3 blain machine characteristics that affect the choice of coniputation and data
............................... partitions on the chosen suite of benchmarks 101
7.6 Impact of cache on data partiti011 selection: performance o l p s inv application . 104   ... . . . . . . . . . . . . . . . . . . . . . 1 . I 1 Ieasurements from datacomputation affinity phase 107
......................... 7.S hleasurements from dynamic array partition phase 109
. . . . . . . . . . . . . . . . . . . . . 7.9 .L leasurernents from processor geometry mapping phase 109  .... . . . . . . . . . . . . . . . . . . . . . . . . . 1.10 Features of the algorithm applications exercise L LO
................................... 7.11 Bisby . Iiremer . and Kennedy's approach 111
............................................ 712 Anderson and Lam's approach 113
7.13 Quality of solutions obtained by Anderson and Lam's algebraic solution on
................................................ the Hector multiprocessor 113
List of Figures
*I . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Scalable sharedmemory multiprocessor architecture
. . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 An example of computation and data partitioning 13
. ...... 2.1 Choices for partitioning data and computation for an example program 1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Esamples of data partitions 10
Examples of data partitions usin5 reverse distribution attributes P=4) . . . . . . I$
. . . . . . . . . . . . . . . . . . . . llapping functions for traditional distribution attributes 19
. . . . . . . . . . . . . . . . . . . . . . . Ilapping functions for reverse distribution attributes 19
. . . . . . . . . Esamples of data partitions using compound distribution attributes 20
. . . . . . . . . . . . . . . . . . . . Stappinq ft~nctions for compound distribution attributes 21
TLVO array dimensions are mapped onto the same dimension of processor
*) 1 geonletry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  . ).) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functions for manytoone mapping 
A n array dimension mapped onto multiple processor geometry dimensions . . . '14
Itanyternany mapping of array dimensions to processor geonlet ry dimensions . 2.5
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The psinv subroutine 31
. . . . . . . . . . . . . . . . . . . . . . . . Sorrnalized execution time of Mult i g r i d on KSR 1 32
. . . . . . . . . . . . . . . . . . . . . . . . . . . Observations from the P l t O S hard~vare monitor 33
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Outline of the AD[ program 34
. . . . . . . . . . . . . . . . . . . . . . . . . . . Partitioning requirements of the different phases 35
. . . . . . . . . . . . . . . . . . . . ( * . Block{l}) data partition with pipelined computation 36
. . . . . . . . . . . . . . . . . ( * . Block{l)) data partition tvith relased computation rule 37
. . . . . . . . . ( B l o c k { l ) . ~lock{l}j data partition with relaxed computation rule 38
6.1 T h e Mock diagram of tohe performance es t imator ........................... $2
2 .An example t o i l lustrate t he C'DFG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . $8
................................................... 6.3 C'DFG for t h e example $8
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.4 Algori thm: 6uild.C'DFC; .. d9
........................................ 6 ..5 AFG for t he a r r ays in the example 90
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.6 Aigorithrn: .4mzy..lcc~.5sCb.s t . 91
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Jasmine compiler block diagram 99
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performance o n a [tiprocessor Hector 102
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Per formance on a 30processor C'onves 103
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performance o n a 16processor KSR 1 !0:3
Compar ing t h e performance of different d a t a parti t ions with the parti t ions
derived by the C'DP alqorit hm: . lpplication s vpenta . m s m . tomcatv . a n d
..ID[ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Comparing the performance of different d a t a par t i t ions with the partit ions
derived by he CDP alqorichm: Applications Ft2d . svd . psinv . and Rt3d . . . . I06
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..I . f Data management in SSlISI 123
CHAPTE,R 1
Introduction
ScalabIe shared memory nl~~ltiprocessors (SSLIhIs) are becoming increasingly popular plat
forms for highperformance scientific computing both because they scale to large numbers
of processors and because they support the familiar shared memory abstraction. 4 SShClI
is typically built by connecting clusters of processors with a scalable interconnection net
~vork. as shown in Figure 1.1. The shared niernory is ph_vsicall_v distributed into memory
nlodtiles. one in each cluster. h[eniory access latency within a cluster is usually uniform.
but is nonuniform across clusters. The estent to which memory access latency is non
uniform depends on the interconnection nettvork. Remote memory access latency can range
anywhere from one to t ~ v o orders of magnitude higher than local niernory access latencv.
Esamples of SS.\IIIs include the Stanford D*h [l] and Flash ['I. the Lniversiry of Toronto
Hector j3] and XI*.\I.\chine [I]. the IiSRL j.7. the HP/Conves Eseniplar [R]. and the SGI
Origin '1000 [T I .
.\ conirnon approach to irnprovinq the performance of applications on SSSIlls has been
to paritlleIize the applications manually. tvhich is conlpies and tedious. Hence. conipi1ers
that t ransforni sequential prozrarrls into efficient parallel programs are required. to red trce
programming effort arid to promote portability. These compilers are termed purullelizing
cornpikrs. and have been the focus of research for man?; years. Parallelization tech nology
h,as advanced considerably i n the past decade. Polaris
S L Fort ran C'onipiler [ L ij are some of the research and
that exist toda~..
[$I. SCIF [s]. KAP [LO]. and IBlI's
conlrr~ercial parallelizing corn pilers
The primary focus of pnrallelizing corrlpilers has been the detection of parallelism in
11t.stt.d loops. because loops are the main source of paraIleiisrn. I'nfortunately. the identifi
cation of parallelism is not sufficient to result in good parallel performance on SSl I l l s . I t is
Cluster 1  Cluster n Re . r .
Figure I . 1: Scalable sharedmemory mrt Itiprocessor architect11 re.
also essential to place data carefully in shared memory. so as to mitigate the effects of t h e
nonuniformity of memory access latencies. to improve cache locality. to reduce contention.
anti to minimize false sharing. Compilers for SS.Lt.LIs have largely ignored issues related to
data pIacement and have left them to the operating system. Operating systems distribute
and manage da ta usin: page placement policies such as firsthit" and ..roundrobin" [X 1'21.
rvhich locate pages in the physicaily distributed shared memory as the pages are initially
accessed. C'nt'ortunately. these policies often lead to poor performance. because they are
oblivioris to the data access patterns of an application and manage data at too coarse a
r a n u l a r i t ~ : the\.. often fail to enhance memory iocality and. i n addition. may result i n
menlory contention and hotspots [I?. 13. 141.
In this thesis. rve s h o ~ that compilers can be used to manage both computation and
data i n regular (ie.. densematrix) scientific applications on SShILIs using the framework
of computation and data partitioning. .LIore specifically. we propose and evaluate compiler
techiiiques that automatically derive computation and data partitioning for such applica
t ions to enhance parallelisni and locality. and t h u s improve performance.
1.1 Computation and Data Partitioning
Cornputation partitioning maps the iterations of nested loops onto processors of a multi
processor. Similarly. data partitioning maps array data onto the memory modules of the
multiprocessor. Figure L  2 illustrates a possible computation and data partitioning for the
Processor Z   j
Memory 1 % Memory 2 Ta Data Pnrt~tronmg I 2 5 26.50 51..75 76.. 100
4
Figure 1.2: .In example of computation and da ta partitioning.
follnning loop on a 4processor SSl[h[:
f o r a l l i = 1.100
A ( i ) = i
end for
The 100 iterations of the loop are divided among t h e four processors such that each
processor executes 2.3 consecutive iterations. The 100 elements i n arra) A are mapped onto
t he two memorv modules such that each module contains 2 consecutive segments of 2.5 array
elements. as shown i n Figure 1.2.
It is crucial that the compiler choose appropriate computation and da ta partitions. The
partitioning shown in Figure 1.2 has good memory locality. since each iteration of the loop
accesses array elements that are mapped onto the memory niodule closest to the processor
executing the iteration. In other words. the esecution of the loop does not result in any
remote rnemorv accesses. Consider a scenario wherein the conipu ta t ion partitioning remains
the same. b u t array ekments 1..X are mapped onto memory module 2. and array elements
.i1..100 are mapped onto memory niodule L. \Vith this computation and data partitioning.
each iteration of the loop must access array elements remotely.
It is also important to cIloose a computation partitioning that balances the workload on
the processors. For esarnple. the computation partitioning shown i n Figure 1.2 maps the
iterations so that the workload on the processors is balanced. Consider a scenario wherein
the data partitioning remains the same as shown. but the iterations are mapped (rather
artificially) such that processor 1 esecutes iterations 1..10. processor 2 esecutes iterations
11 ..Ti 0. processor 3 esecutes iterations 5 l . . G O . and processor 4 executes the remaining 40
iterations. This partitioning of t h e iterations would result in poor performance, since the
norkload on the processors is unbalanced. In general. computation and data partitionings
that arc compatible with respect to data access patterns and workload distribution should
be chosen in order to achieve good locality of data accesses and balance of workload.
[ n addition to improving memory locality and balancing the workload. the chosen com
putation and data partitions must also enhance cache locality. reduce contention. minimize
synchronizatiort overhead. and reduce false sharing.
Data partitioning is used on distributed memory niultiprocessors to map array da ta onto
the separate address spaces. The computation partitioning on these machines is implicit.
because it is indirectly specified using a computation rule such as the ownercorrtput~s
rule [L5. 161. I n the past decade. many researchers have focused on compiler techniques
that automatic all^ dcrive data partitionings for distributed memory multiprocessors. This
thesis cstends their work in three ways: ( i ) we use data partitioning to enhance memory
locality on SSlIlls. ( i i ) we do not use a computation rule. but map computations explicitly
onto processors. and ( i i i ) ive autorrlatically derive both computation and data partitions
that take into account shared memory effects. In contrast. data partitions on distributed
memory nlultiprocessors are derived ivitli the main objective of minimizing interprocessor
con) mu nicatiori.
1.2 Research Overview
The primary research focus of this thesis is to develop a compiler framework targeted to
inlprovc the performance of dense rnatris scientific applications (i.c.. applications in which
the array subscript expressions arc affine functions of the loop index variables. and the
array and Ioop bounds are known) o n SSMbIs. An outcome of this thesis is a heuristic
Framework impleniented i n the Jasmine compiler [ I T ] prototype, which automatically derives
cornputation and data partitions. Thc main contributions of this thesis are as follows.
I . \C7e show that shared memory effects, such as cache affinity. memory contention, syn
chronization overhead. and false sharing. must be considered while deriving compu
tation and data partitionings. Indeed. we show that the data partitions selected by
existing techniques on distributed memory multiprocessors may not always be the
best choice for a SShllI. although both architectures have a physically distributed
memory.
2. CVe present a heuristic algorithm called the Computation and Data Partitioning (CDP)
algorit ttm. which derives computation and data partitions for S S M l k CVe show that
the CDP algorithm is computationally efficient. while taking into account shared
memory effects that affect the performance of applications. Experimental evaluation
of the CDP algorithm on three SSMSls demonstrates the effectiveness of the algorithm
in improving the performance of a suite of benchmark applications. compared to the
native operating system for data nianagement.
1.3 Thesis Organization
The definition of the conlputation and data partitioning problem and an overview of existing
techniques to automaticalIy derive data partitions on distributed memory multiprocessors
are presented in Chapter 2. Sew computation and data partitions that we have introduced
are presented in Chapter 3. These new partitions facilitate the establishment of data
corn putation affirlit~.. which is the basis or the C'DP algorithm. The perforn~ancc factors
that affect tlic selectiou of con~putation and data partitions on SSXIlIs arc identified in
Chapter 4. The C'DP algorithm for heuristicall! deriving cornpu tation and data partitions
for SSAIlls is presented in Chapter Ti. The cost model used in the CDP algorithm to stat
ically evaluate the effectiveness of candidate computation and data partitions is presented
in Chapter 6. The experimental evaluation of the CDP algorithm is presented in Chapter 7.
Concluding rerliarks and directions for future research are presented in Chapter 8.
Background and Related Work
In this chapter. n7e describe the background and related work w i t h respect to the problem
of automatically deriving computation and data partitions. This chapter is organized as
follo~vs. First. we define tlie problem of deri\.ing optimal computation and d a t a partitions.
and i l l ustratc tlie conlplltational complesity involved wit 11 an esarnple. Second. we describe
the notation used to specif!. computation and data partitions. Finally. we review esisting
techniques for deriving computation arid data partitions. principally on distributed memory
niultiprocessors.
2.1 The Problem
h t r r partitiorzirig of an array divides the array into subarrays and maps t liese subarrays
onto Siniilarly. corrrputatiorl partitioning of a loop nest divides tlie iteration
space of the loop arid assigns the iterations to the processors.
C'ornputation and dnta pcrrtition.~ must be dericed so as to minimize the frecution time
o/ thc application on n g i w n ntrltiproce.wor. The problem of selecting optimal computation
and data partitions (i.e.. computation and data partitions that minimize iriterproccssor
communication. minimize load inibalance. rnasiniize cache locality. minimize contention.
mini rnize syncii ronizatiorl over head. and minimize false sharing) is corn pu tationally hard due
to the combinatorics of possible coniputation and da ta partitions, given the dimensionality
and the number of arrays. arid the number of loops in each loop nest [18. 19). The complesity
of the problem can be illustrated using the program shown in Figure 2.1. It contains two loop
'Although subarrays are assigned to memory modules. in this thesis we use the phrase *.assigning sub arrays to a proccssor" to mc,u "assigning subarrays to the memory module which is close to the proccssor." This phrasing implicitly associates a proccssor with the memory module close to the proccssor .and simplifies the presentation.
Input Program
Data Partitioning Choices (Drmrnslons of arrays that x e pan~nonrd)
.A I B I C
dimrns~on I dirnensron 2 dimension 3 dirnrnslon 1 & 2 dimrns~on 1 & 3 dimens~on 1 & 3 dimstwon 1.2 9r 3
dlrnrnsron 1 dimension 2 dimension 3 dimrnsron I Sr 2 dimrnslon I & 3 dimrnslan 2 lllr 3 dimrns~on 1.1 9 3
d~mension 1 dirnrnslon 2 dimenston 3 dimmslon 1 & 2 dimrns~on l & 3 ciirnms~on 2 & 3 ciimrnslon I . 2 & 3
Cornpubtion Partitioning Choices (Loops that are partitioned and executed by diiferent processon)
Processor Geometry Choices r Msppmg of the pm~tionrd loops and pmitionrd dimensions 1
Figure 2.1: Choices for partitioning d a t a and computation for a n example program.
nests accessing three 3dimensional arrays. A. B. and C. The set of possible combinat ions of
loops tha t can be partitioned in each loop nest is indicated to t h e right of each nest. T h e
indcs of each loop tha t ma1 be partitioned is s h o ~ v n to indicate t h a t t he corresponding loop
is partitioned. For esample. i k j in the table indicates a computat ion partition t h a t divides
loops n i t h i terators i and 1. The number of possible choices for computa t ion partitioning is
2"  1. where d is the depth of the loop nest. Thus. there a re seven choices for partitioning
each of the two loop nests.
Possible d a t a partitions for each array in the example are shown belotv the loop nests.
T h e number of possible partitions for one array are 2"'  1. where d' is the dimensionality
of the array. In this case. each array has seven possible partitioning choices.
T h e computat ion and d a t a partitions must also be mapped o n t o processors. Th i s is
typically done by choosing a processor geometry. which is a ndimensional Cartesian grid of
processors. ( p L . p a r . . . pn). I n this notation for processor geometry. p, denotes the number
of processors in the i t h dimension. and pl x p2 x    x p, = P is t h e to ta l number of
processors. The dimensionality of the processor geometry. n. is usually limited by the
highest array dimensionality. In our example. the processors can be organized as a L
dimensional. 2dimensional. or 3dimensional processor geometries. Clearly. there is only
one possible 1dimensional processor geometry for a given number of processors. fVit h
P = 16. there are 5 possible 2dimensional processor geometries ( p l . pz) : ( 16. 1 ). (3. 2) . (4 .
I ) . (2. 8) and ( 1. 16). Similarly. I6 processors can be organized in 1.3 different 3dimensional
processor geometries.
The number of possible partitions for a n array can be computed using the number
of dimensions of the array. d. and the number of processors. .\ssuming tha t the number
of processors is a power of some prime number p. i.e.. P = pk. the number of possible
partitions. n. for a ddimensional array is ("!;i;' ) 0 Note that this formula can also be
used to obtain the number of partitions for loops in a loop nest xith a depth of d.
The nun1 ber of choices for partitioning arrays and iteration spaces increases esponen
tially as the number of arr;is and the number of loop nests in the program increases. The
search space that must be considered ~vhen there are a arrays accessed i n each of 1 loop nests k+d 1 ( % + I ) m i in the program is ( n Z t n)' = n('")='   ( , i  l 1 . In our esample. with 16 processors.
one must consider over 2.5 billion ( 1.5.'') possibie computation and data partitions to derive
a n optimal solution by an exhaustive search. The number of choices grows to nearly 400
billion j2S4=') nhen ne have 61 processors."
The problem of selecting optimal conlpu tation and data partitions is further complicated
by the replication of arra>.s. the freql~ency of esecution of loop nests. and the presence of
selection statements. such as ifthenelse. that alter the execution frequency of loop nests.
Hence. techniques for selecting computation and data partitions are heuristic. because of
the esponential complesity of the problem. These techniques reduce the conlplesity by
making simplifying assumptions and/or by en1plol;ing efficient search techniques.
2.2 Notation for Computation and Data Partitions
Coniputation and data partitions are specified using textual notations for con\vnience.
Languages such as HPF include such a notation as a part of language specification [L6]. in
t h i s section. tve describe these testual notations. The computation and data partitioning
'Sote that we have onl!: considered the choice of loops and m a y dimensions for partitioning and not the manner in which they are divided. Considering the manner in which the loops and array dimensions are divided further increases the number of choices for computation and data partitioning.
is specified as a mappin5 from a grid of iterations and a grid of da ta elements onto the
Cartesian grid of processors.
2.2.1 Data Partitions
The notation for the data partitioning of an array has two components for each array
dimension: a distribution attribute. and a processor dim~ns ion assignment . A distribution
attribute is assigned to each array dimension. and it specifies hotv an array dimension should
be divided. There are three (list ribution attributes typically used on distributed memorq.
multiprocessors: Block. Cyclic. and BlockCyclic. In this dissertation. we refer to these
three a t tributes as the tmciitional distribution attributes. The Block attribute slices an
array dimension into blocks of contiguous elements and assigns each block to one processor.
The Cyclic attribute partitions an array dimension by distributing the array elements to
processors i n a roundrobin fashion. The BlockCyclic attribute specifies that 6 contiguous
array elements in a dimension must be mapped onto the same processor. followed by the next.
6 elements to the nest processor. i n a roundrobin fashion: b is called the block . s ix . Thus.
the BlockCyclic distrib~ltion attribute with a block size of 1 and the C y c l i c distribution
attribute are equivalent. .I special distribution attribute. denoted by *. is used to indicate
that an array dimension is not partitioned a t aI1.
The processor dimension assignment maps array dimensions onto the dimensions of the
processor geometry. This assignment is specified by using a onctoone mapping between the
dinlensions of arrajs assigned distribution attributes and the dimensions of the processor
geometry. Thus. in conjunction with the distribution attribute. the processor dimension
czssign ment determines t he nun1 ber of subdivisions in to which an array dimension must be
divided.
I n this dissertation. ne denote the processor dimension assignment by appending a di
mension of the processor geometry to the distribution attribute. For example. ~(~lock{l))
indicates that the single dimension of array A is mapped onto dimension 1 of the processor
geometry. and the array dimension is divided into pl blocks. where pl is the number of
processors in the first dimension of the processor geometry. [ t is important to note t h a t the
distribution attribute not onb specifies the manner in which the array dimension should
be diiided but also imposes an implicit ordering for rriapping the subarrays: the first sub
array is mapped onto the first processor. the second s u barray is mapped onto the second
AcBlock(0l. Block(1 I, hr Block{l 1, Block(0)) ArBlock{ 1). BIock(2J)
(a] (5 ) (ct
Figure 2.2: Esamples of data partitions.
processor. and so on.
LYhen an array dimension is mapped onto a nonesistent dimension of the processor
geometry. ie.. dimension 0. then the notation indicates that the array dimension is not par
* attribute. For example. ~(Block(0)) titioned. Hence, such a mapping is equivalent to the
is equivalent to A ( * ) .
Figure 2.2 illustrates some common data part itions of a 2diniensional array. Fig
ure 2.2(a) illustrates the case in ~shich a 2dimensional array. A. is partitioned onto a
1dimensional processor geometry containing 4 processors. Both dimensions of A have the
Block distribution attribute. However. the first dimension is associated with dimension
0 of the processor geometry. and the second dimension is associated with dimension 1 of
the processor geometry. Hence. the first dimension is not partitioned. and the second di
mension is divided into 1 blocks of columns. Figure 2.2(b) illustrates the case where array
A is divided into ! Mocks of rans and mapped onto a 1dimensional processor geometry.
A partitiorli~ig of array A onto a 2dimensional processor gometry of 16 processors. ~vith
4 processors along each dimension. is shown in Figure L'.2(c). The 2dimensional array is
partitioned along both the dimensions into 4 blocks for a total of 16 blocks. Each of the 16
processors is assigned one block of the array.
.in important localit optimization used i n practice is to replicate arrays and subarrays
on processors. Replication of arrays and subarraxs can be specified using the above nota
tion for data partitions. For example. the ~(~lock(1)) partitioning of a n array A onto a
2dimensional processor geometry will result in the array being divided and mapped onto
the first dimension, and the array being replicated along the second dimension of the pro
cessor geometry. \frhen the number of array dimensions iv i th a mapping is less than the
dimensionality of the processor geometry. then an array is replicated along the dimensions
of the processor geometry that are not associated with any array dimension.
The partitioning of a n array is static if it is fixed throughout the execution of the pro
gram. Howcver. in some programs it is beneficial to have a n array partitioned differentiy
in different parts of the program. I n these cases. the partitioning is referred to as dynamic.
Dynamic partitioning requires the repartitioning of arrays. and hence incurs runtime over
head.
2.2.2 Computation Partitions
Computation partitions can be esplicitly specified using a notation similar t o the notation
for da t a partitions. A distribution attr ibute associated with a loop specifies the division
of loop iterations into subsets of iterations. and a processor dimension assignment specifies
how these subsets are assigned to processors.
On distributed memory multiprocessors. computation partitioning is implicit and is
specified indirectly. using a computation rule such as the ownercomputes rule [l5. 161. The
processor that has a da t a partition assigned to its memory is said to own the da ta in the
partition. \Vith the ownercomputes rule. t h e processor that owns a data item is mapped
with all tlre computations that update/write the da ta item. Ising a computation rule
simplifies the compiler's task of generating the messages required on a distributed memory
n~ultiprocessor [15]. In contrast. we esplicitly use a computation partition. whether the
partition ad heres to the oivnercomputes rule or not.
It is interesting to note that static loop scheduling on shared menlor? multiprocessors
can be viewed as a restricted form of computation partitioning. Loop scheduling only
partitions parallel loops. while computation partitioning can partition sequential loops as
~vell: conlputation partitioning of a sequential loop corresponds to a wavefront or pipelined
scheduling of loop iterations [19]. In addition. loop scheduling is restricted to a linear
arrax of processors to map parallel loop iterations. while computation partitioning maps
the iterations of a loop nest (consisting of many loops) onto an ndimensional processor
geomet ry.
2.3 Related Work
In this section. we summarize heuristic algorithms developed in the past decade for de
riving da ta partitions on distributed memory multiprocessors. These algorithms require
compiletime performance estimation in order to evaluate the effectiveness of candidate
data partitions. Hence. compiletime performance estimation has also been an active area
of research [I L. 3 I].
2.3.1 Gupta and Banerjee
Gupta and Banerjee develop an algorithm to determine static data partitions on distributed
memory multiprocessors [21. 221. Their technique is developed as part of the Parafrase2
restructuring compiler ['L3]: the compiler accepts a Fort ran;; program and generates a
SPbID program with explicit communications.
The algorithm analyzes array references in each statement in the program to determine
the array elements that must be allocated together. For the purpose of representing array
references in the program. Gupta and Banerjee estend Li and Chen's Component .4flnity
Gmph (CAG) [24. 2.51. The CAG is a weighted undirected graph. in which each dimen
sion of every array in the program is a node. There is an edge between tivo nodes if the
subscript espressions of corresponding dimensions of the arrays are affine functions of same
loop iterator. Gupta and Banerjee assign each edge a weight. which corresponds to the
comrnuriication penalty incurred if the nodes connected by the edge are not aligned. i.e..
are not ultiniately mapped to the same dimension of the processor geometry. These weights
arc estimated b'ased on the analysis of comnlunication in the program with an arbitrary
alignment other than the onc suggested by the edge.
Gupta and Banerjee use a Iieuristic algorithm to partition the C.4G into disjoint sets of
nodes. such that the sun1 of tveights of edges between nodes in different sets is minimized.
thus minimizing t h e cost of interprocessor comrnrrnication. Either a C y c l i c or Block dis
tribution attribute is chosen to partition array dimensions. based on the relative merit of
each attribute.
.I 2dimensional processor geometry is used to partition the arrays to minimize the
search space of possible processor geometries. The number of processors onto which the
arrays are mapped is selected using an eshaustive search of possible processor geometries.
This was the first algorithm to present a complete solution for deriving static data
partitions for a program. As Bisby et al. ['XI and Anderson and Lam [19] have shown.
however. selecting only static da t a partitions may not be sufficient. and sometimes it is
rlccessary to repartition the arrays to achieve good performance.
2.3.2 Bixby, Krerner, and Kennedy
Bisby et al. formulate the probleni of deriving data partitions on distributed memory mul
tiprocessors as a 0 1 integer programming problem [20. 26. 251. Their basic approach is to
partition a program into phases. each consisting of one or more loop nests. They determine
partitions for arrays in each phase and allow the arrays to be repartitioned only between
p h<lses.
The alignment constraints i n each phase are represented by a separate C.\G. As in
Ciopta and Banerjee ['LLI's approach. the edges of the C;\C are assigned a weight that
indicates the cornniunication penaltv for not aligning tlie nodes connected bg the edge. The
CAC; is partitioned into disjoint sets. tising 0 1 integer programming. to minimize the sum
of weights of edges that connect nodes in different sets. The result is the alignment of
arrays with respect to each other in cacti phase. This alignment is captured by using a
template. Candidate data partitions to be evaluated are obtained by partitioning each of
the dimensions of the template. using Block and Cycl ic distribution attributes.
The dimensionality of t tie processor geoniet ry is chosen according to the dimensionality
of the template. The candidate partitions. along with possible processor geometries. are
used to derive the global static/dyrlamic data partitions for tlie program. also by the use of
a similar 01 integer programming formulation.
Although the 01 integer programming Formulation suggests that an optimal solution
is obtained for the problem. Bisby et al. reduce the search space through their problem
Formulation. For csaniple. they do not consider the replication of arrays, and their prototype
irn plenwntation <assumes a single dimensional processor geoniet ry. .is a result. only a sub
set of the da ta partitions are evaluated. Sonetheless. the coniputational coniplesity of their
approach is Leery high ['LO].
2.3.3 Palermo and Banerjee
Palermo and Banerjee estcnd Gupta and Banerjee's algorithm in order to derive dynamic
data partitions on distributed memory multiprocessors ['LS]. Similar to the approach of
Bisby et al.. they decompose the program into phases and assume that data repartitioning
is beneficial only betiveen phases. They derive the phases recursively. Initially. the entire
program is viewed as a single phase. and a static data partition is determined for the pro
gram using Gupta and Banerjee's algorithm. They use a weighted directed graph. called the
commtrnicntion graph. to represent data flow betiveer. statements. The nodes of the graph
correspond to c he statements. and edges correspond to the data ff ow between statements.
The incoming edges of each node are assigned weights that correspond to the cost of com
niunication u s i n ? the derived static data partitioning. The graph is partitioned into two.
using a maximalcut aigorithm. The program is divided into two phases t,hat correspond
to the partitions if and only if the sum of the execution times of the phases with their best
static partitions is iess than the esecution time of the original program with the original
static partitions. This process of dividing the program into phases is recursively applied to
the derived phases until no more benefit can be obtained.
The cost of array redistribution is then considered. For this purpose. Palerrno and
Banerjee analyze the hierarch?; of phases obtained during the recursive decomposition of
the proqrarn. Tho? use an acyclic qraph. called the phase transition gmph. in which the
nodes represent pl~asss and the ed5es represent data flow between phases. The nodes
are assigned the cost of esecution of the corresponding phases with their best static da ta
partitions. while the edges are assigned a weight that is the cost of repartitionins between
the phases. The shortest path in the phase transition graph yields the data partitions for
the proqam.
.\[though the formulation of the problem is eleqant. the algorithm relies on static par
titions in each $ven phase. obtained ~rsing C;upta and Banerjees aigorithrn. tvhich obtains
the communication costs for partition selection using arbitrary alignments.
2.3.4 Garcia et al.
Garcia et al. propose a method to derive data partitions for distributed memory multipro
cessors using a 01 integer programming formulation similar to that of Bisby et al. ['LS]. The
authors use a variant of the C.\G called the Communication Parall~lism Cruph (C'PG). .As
in a C.lG. nodes in a C'PC correspond to the dimensions of arra~s in the program. However.
the CPG has edges corresponding to all possible alignments between nodes. [n contrast
to a C'.iCi. which uses comrn~lnication penalties a s edge weights. the edges in CPC; have
n ~veight that represents the benefit ot' aligning two dimensions. In addition. the nodes in
the CPG that correspond to array dimensions having a parallel loop index in their sub
script expressions are connected by a hyperedge. The weight of a hyperedge represents the
esecu tion time that is saved when the loop is paralielized.
Similar to the partitioning of C.4Gs. the CPG of the program is partitioned into disjoint
sets. Hoivever. the partitions of the CPG are such that the sum of the weights of edges
l~etiveen nodes i n different sets is maximized. and the sum of the weights of hyperedges that
connect nodes in different sets is minimized. Integer programming is rised t,o partition the
CPG.
One Iimitation of t h i s approach is that the processor geometry is limited to a linear
array of processors. In addition. the algorithm derives only static data partitions. in order
r.o limit. computational effort.
2.3.5 Anderson and Lam
Anderson and Lam present an alqebraic frame~vork tbr deterrninin< data and computation
partitions for both distributed memory multiprocessors and SS!vll,[s [LO. 301. The input
consists of a program with a sequence of loop nests i n which parallelism h a s heen moved to
outer nesting levels using unimocfular transformations.
The algorithm has three main steps. [ n the first step. the alqorithm determines commu
nicationfree partitions for each of the loop nests i n isolation. For this purpose, Iincierson
and Lam lbrrnl~late an algebraic representation of the relationship between conlprrtation
and data. and derive static cornmrrnicationfree data and computation partitions. T h i s
formulation ensures that computation is impticitly performed where the data resides. The;
rhen use a n iterative algorithm ro derive s ta t ic data partitions. considering all the loop
nests i n the program. In doing so. chey tracieoff estra degrees of parallelism that rnw be
available in loops to avoid commrinication.
CC'hen i t is not possibie t.o cietermine communicationfree static data partitiotls. they
derive pipelined computation partitions in the second step of their algorithm. This step is
performed to evaluate the benefit of partitioning sequential loops. while maintaining static
data partitions.
The third step of the algorithm is used to derive dynamic data partitions. either when
communicationfree partitioning cannot be obtained or when s loop nest cannot be pipelined.:'
This step eliminates the largest amounts of communication. by obtaining s ta t ic partitions
for the most frequentIy executed loop nests. If the static partition chosen for the frequently   
'Tvpicallv. a Loop nest cannot be pipelined when the dependence distances are unknown.
execr~ted loop nest does not result in communicationfree partitions for the less frequently
executed loop nests. then s new data partition is chosen for the less frequently esecuted
loop nests. Thus. by using this *.greedy approach. they place cornniunication in the least
esecu ted segments of the program.
It should be noted that. by default. the algorithm uses the Block distribution attribute.
The Cyclic distribution attribute is used ivhen the workload is not balanced. while the
BlockCyclic distribution attribute is used when a loop nest with unbalanced workload is
pipelined. Data transformations are finally used to allow the processors to access contiguous
da ta regions.
This techniqrrc uses the ownercomputes rule to partition computations. ie.. it re
quires that data bc allocated \vhere t tie computation is performed. Consequently. when
a communicationfree data partition cannot be determined. data will be repartitioned. even
if the cost of accessing remote data is less than the cost of repartitioning.' Hence. the algo
rithm considers significantly fewer data partitioning candidates than are possible. and may
result in suboptima! data partitions for applications on SShlbIs. The algorithm does not
determine a processor geometry and block sizes for BlockCyclic distribution attributes. In
addition. this technique relies on accurate profiling information to indicate the esecution
frequencies for loop nests.
2.4 Discussion
.\I1 of t he esisting techniques. except Anderson and Lam's algorithm. derive data parti
tions for distributed memory multiprocessors. Although Anderson and Lani's algorithm is
intended for SS.\IbIs as nell. it is strongly influenced by techniques for distributed nlern
ory multiprocwors. in that the algorit hrn uses the ownercompu tes rule. Therefore. the
major focus of existing techniques has been the minimization of comniunication between
processors.
Our research focuses on taking into account shared memory effects on SSbISIs while
deriving computation and data partitions. In Chapter 4. we identify the shared memory
effects that must bc considered in the derivation of conlputation and da ta partitions on
SShIXIs. I n the nest chapter. we introduce new coniputation and data partitions that are
especially usefuI on SSSTlls.
"\Ve will see nn example of this in f f t3d, in Chapter 7 .
CHAPTER 3
New Computation and Data Partitions
This chapter describes the new computation and data partitions that we have introduced.
This chapter is organized as fo1lots.s. First. we describe sis new distribution attributes
that can be used to partition data and computation. Sr~bsequently. ive describe how new
data partitions are derived by mapping each distributed dimension of an array to t he same
dimension or many dimensions of t h e processor geometry. FinaIly. we conclude this chapter
by describinq why the usefulness of these neiv computation and data partitions may be
limited to scalable shared memory rnultiprocessors.
3.1 New Distribution Attributes
I n addition to the traditiorlal distribution attributes1. we introduce sis new distribution at
tributes: RBlock. RCyclic. RBlockCyclic. BlockRBlock. CyclicRCyclic. and BlockCycl
icRBlockCyclic. Of t hesc distribution attributes. the first three are rcrcr.w distribution
attributes and the last three are compound distribution attributes.
3.1.1 Reverse Distribution Attributes
The reverse distribution attributes are RBlock. RCyclic. and RBlockCyclic. These dis
tribution attributes are the reverse of t h e Block. Cyclic. and BlockCyclic distribution
attributes respectively. The assignment of different segments of a n array dimension (or
iterations of a loop) to the processors is made i n a decreasing order, starting with processor
P and ending with 1: hence the [lame "reverse." This is unlike the traditional distribution
attributes. where assigrinmlt to processors occurs in an increasing order. starting with pro
cessor 1 and ending with p. Figure 3.1 s h o w examples of partitioning a 1dimensional array
' ~ h e s e are the Block. Cyclic. and BlockCyclic distribution attributes. described in Chapter 2 .
17
Figure 3.1: Esarnples of da ta partitions using reverse distribution attr ibutes (P=4).
using the reverse distribution attributes. For esarnple. consider the partition ~(~Block{l))
mapped onto a one dimensional processor geometry consisting of 4 processors. The first
block of the array is mapped onto processor 4 and the last block of the array is mapped
onto processor I . In contrast. had the array been partitioned using the Block distribution
attribute. instead of the RBlock distribution attribute. the first block of the array will be
mapped onto processor L and the last block will be mapped onto the last processor. i.e..
processor 4.
tt is interesting to note that the reverses' distribution attr ibutes can be viewed as
renumbering the processors in reverse. However. it is not sufficient t o implement reverse
distribution attributes by processor renumbering since t h i s can affect the mapping of other
arrays and loops.
The reverse distribution attributes can be obtained in HPF by using a n alignment
directive along with a trmplatc. For esarnple. the data partition A(RBlock{l}) can be
obtained in HPF b. using the following four statements. assuming tha t the dimension of
the array is N.
CHPF$ PROCESSORS P (4
CHPF$ TEMPLATE TMPL(N)
CHPF$ DISTRIBUTE TMPL(BL0CK) ONTO P
CHPFS ALIGN A(I) WITH TMPL(NI)
In this example. the alignment statement associates the last element of the array with
the first element of the template and vice versa. Hence. by partitioning the template.
using only the traditional at tr ibute Block. the RBlock distribution attr ibute is obtained.
Ttre reverse distribution attributes obtained using HPF can be viewed a s dcricfd a t tribute
types. However. ire set out the reverse distribution attributes as fundamental attribute
types required for partitioning computation and data. This distinction is important. because
it allows us to definc the compound distribution attribute. as will be described in the nest
scc t ion.
[l 'f3(4t);k L B ( . 4 , ) w h e w Part ition3i=e(.4,. P k ) = 1
C'yclic(.I,. Pk. I ) = { ( l  LB( .  l i ) ) mod Pk) + 1
Figure 3.2: !tIapping functions for traditional distribution attributes.
RBlock((.1, . Pk. I ) = Pk  Block(.\, . Pk. I ) + 1 R C ' ~ c l i c ( .  l ~ . Pk. 1 ) = PI.  Cyclic(.\,. Pk. 1 ) + 1
R BlockC'yclic( .I,. PI.. I ) = P:,  BlockC'yclic( .4i . Pk. I ) + 1
Figure 3.3: 1Iapping functions for reverse distribution attributes.
Before we discuss the functions used to map data using the reverse distribution at
tributes. it is important to introduce the functions that map da t a using the traditional
distribution attributes. This is because the functions that map da ta using the reverse
distribution attributes are defined based on the functions of the traditionai distribution
attributes. The generic functions that map array elemenrs onto processors using the tra
ditional distribution at tri bu ces. which are Block. Cyclic. and BlockCyclic. are given i n
Figure 3.2. Given an array A w i t h lower and upper bounds LB(.I,) and l B( .4 , ) in dimen
sion i. and a processor grid nith Pk processors i n dimension k. the functions map an i d e s I
of A i n dimension i onto a processor i n dimension k of the processor grid. Part i t ionSize for
the Block distribution at tribute specifies t h e size of each block along an array dimension.
Recall that the block size. b(Ai). for t h e BlockCyclic distribution attribute. on the other
hand. is the number of contiguous elements that must be colocated as specified by the
distribution attribute.
The functions that map the elements of an array onto processors using the reverse
distribution attributes are shown i n Figure 3.3. Given an array A nith lower and upper
bounds. LB(.li) and l  B ( d i ) respectively. i n dimension i. and a processor geometry with
Pk processors in dimension k. the functions map an array element indesed by 1 in dimension
i of A onto a processor in dimension b of the processor geometry. It should be noted that
the division of arrays into smaller segments for both the traditional and reverse distribution
attributes is the same. It is the mapping of the divided segments of a dimension of an array
Figure 3.4: Esamples of data partitions using compound distribution attributes.
onto the processors that distinguishes the reverse attributes from the traditional attributes.
The functions that map the iterations of a parallel loop are similar to the array mapping
functions.
3.1.2 Compound Distribution Attributes
The compound distribulion attributes are a s>mthesis of both the traditional and reverse
distribution attributes. BlockRBlock. CyclicRCyclic. and BlockCyclicRBlockCyclic are
the con~pound distribution attributes. \Vhen a dimension of an array (or iterations of
a loop) is partitioned using a compound distribution attribute. the array dimension (or
iterations of the loop) is divided into two halves. The first half of the array dimension (or
iterations of the loop) is partitioned using the appropriate traditional distribution attribute.
The second half of the array dimension (or iterations of the loop) is partitioned using the
appropriate reverse distribution attribute. Figure 3.4 shoivs esamples of partitioning a
1dimensional array using the conipound distribution at tributes. Consider the partition
A ( B ~ O C ~ R B ~ O C ~ { I } ) mapped onto a one dimensional processor geometry consisting of 4
processors. The Ldimensional array being partitioned is first divided into tivo halves. I n
order to map the first half segment using the Block distribution attribute. the half segment
is further split into sn~allcr pieces. The first piece of the first half segment of the array will
be mapped onto processor number 1. The last piece of the first half segment of the array
pill be mapped onto processor number 4. However. to map the second segment. the RBlock
distribution attribute is used. The first piece of the second half segment tvill be mapped
onto processor number 4. The last piece of the second half segment trill be mapped onto
processor number 1.
The functions that map an arraj. A using the compound distribution attributes are shoivn
in Figure 3.5. Ttiesc functions assume that the size of an array dimension with a compound
distribution attribute is divisible by 2 * Pk. \!.hen this is not the case. an equal number of
data clcrne~lts cannot be assigned to each processor along the array dimension. The array
B l ~ c k R B l ~ ~ k ( .  l ~ . Pk. 1 ) = B l ~ ~ k ( . i , , P k , l ) if 1 < ( C V B ( . 4 , )  L B ( . 4 , ) ) / 2 RBlocA.(.li. Pk. 1 ) otherwise
C'y~li~RC'y~li~(.l~.P~.i) = C y c l i ~ ( .  l ~ . Pk.I ) if 1 < (C:B(4;)  L B (   l t ) ) / 2
R C ' y ~ l i c ( . 4 ~ . Pk, I ) otherwise
BlockCyclicRBlockCycl ic(.li . Pk. I) = B l ~ ~ k C y d i ~ ( .  l ~ . Pk, I ) if I < ( I  B(. l i )  L B ( . i i ) ) / 2 R BlockCyclic(.i, . Pk. 1 ) otherwise
Figure :l . . j : l lapping functions for compound distribution attributes.
dinleiision is divided into two segments such that the subsequent divisions in the first half
segment are all of equal sizes. Each processor may not get equal number of data. elements
in the second half segment. which is partitioned using the reverse distribution attribute.
3.2 New Data Partitions
Traditionally. cacti dimension of an array with a distribution at tr ibute has been implicitly
associated with a unique dimension of the processor geometry [lG. 21. 27. 301. \Ve introduce
a nurnbcr of interesting and useful d a t a partitions by relaxing the strict onetoone rela
tionship betneen the distributed dimension of an array and the dimension of the processor
geometry. Three new data partitions can be derived by using the mapping betrveen the di
mensions of an array and the dimensions of the processor geometry. They are manytoone.
i.c.. mapping many array dimensions onto one dinlensio[i of the processor geometry: one
tonrnny. i.e.. mapping one array dimension onto more than one dimension of the processor
geometry: anti mrmytorrlrrrly, i.e.. mapping many array dimensions onto many dinlensions
of the processor gcomet ry.
T h e three new mappings are not used to partition computation. The relased mapping is
not generally used between parallel loops and processor geometry dimensions because such
a relaxation i) adds to the loop overhead introduced to map iterations onto the dimensions
of t lie processor geometry.' ii) irlcreases the search space of possible computation partitions.
and iii) has not proved to be beneficial. in our esperience.
'LVc tio not have to explicitly identify the home Location of each array element because of the shared rncniory. However. we do not have such 'an option with respect to the iteration spaces. We have K O partition computation among the processors.
Figure 3.6: Two ar ray dimensions are mapped on to t h e same dimension of processor geom etry.
L = {II . I 2 . .,.. 1 " )
.\lapping(.l. P. k. L ) = { S .\lap(.\,. Pk. l i ) ) mod Pk + I ( .  P . 1,) = { .4 i i r ibui f (   l i . Pk. 1,)  1 )
if a r r a y dimension i is m a p p e d onto processor dimension At
Figure 3.7: Functions for m a n y  t e o n e mapping.
3.2.1 ManytoOne Mapping
T h e manytoone mapping is a result of mapping multiple array dimensions on to a single
dimension of the processor geometry. Figure 3.6 shows an example in which tivo dimensions
of an ar ray A are mapped on to a one dimensional processor geometrv with 4 processors. using
a (Blockil). Block{l}) partitioning. The array is sliced into blocks of contiguous elements
along both its dinlensions because of tile Block distribution at t r ibute. The resultant sub
ar ray blocks are assigned to processors such tha t s a m e processor is not assigned tivo blocks in
t h e s a m e colunln o r row of the tessellated geometry. T h a t is. a block (i. j ) of the tessellated
ar ray maps t o processor ((i  1) + (j  1)) mod P + 1 in the linear array of P processors.
Th i s partitioning of t he array is called a iutin square. and it represents one possible mapping
of nlultiple din~ensions of the array onto the s a m e dimension of the processor geometry.
Figure 3.7 sho\vs the function tha t determines which processor an array element is
mapped to when many array dimensions a re mapped o n t o the same dimension of t he proces
sor geometry. This function determines the processor in the kth dimension of the processor
geometry P. on to which an array reference A ( l I . 1 2 . .... I,) is mapped. T h e processor onto
which an array element is mapped is determined in two steps. First. t he processor numbers
o n t o which the array clement is mapped are determined along each of the dimensions of the
array. using the distribution attribute functions. Second. the processor numbers of the array
dimensions that map onto the kth dimension of the processor geometry are added together
to determine the processor in that dimension. Since the processor i n the kth dimension of
the processor geometry must remain within the limits of 1 . . Pk. to be a vaIid processor.
a modulus operation is performed to obtain the processor onto which the array element is
mapped.
3.2.2 OnetoMany Mapping
The onetomany mapping is a result of mapping a single dimension of an array onto multiple
dimensions of the processor Seometry. Figure 3.8 sho~vs an example of a 2dimensional arra!
A that is partitioned using (Block(1.2). r ) . In t h i s example. the first dimension of the array
is mapped onto both dimensions of a two dimensional processor geometry. with 4 processors
in each of its dimensions. Only the first dimension of the arrax h a s a Block distribution
attribute. Hence. the array must be sliced into blocks of contiguous elements along the first
dimension. The number of blocks into which the dimension must be divided is dictated
by the number of processors associated with this dimension. Since both dimensions of the
processor geometry partition the array. the number of segments into which the array must
be divided is the product of the number of processors along each of the dimensions of the
processor geometry. Hence. the array is divided into 16 segments. wi th one segment for each
of the 16 processors ( 4 .< 1). Conceptually. the partitioning of the first dimension of A onto
the two dimensions of the processor geometry can be viewed as a tno step process. The
first step is to divide the array into 4 segments and map these segments onto the second
dimension of the processor 2eonietry. The second step is to further divide and map the
segments onto the first dimension of the processor geometry.
The function that maps an clement of an array i n xhich one of the array dimensions has
a onetomany mapping is made up of three steps. First, the multiple processor geometry
dimensions partitioning an arm! dimension are linearizedvn to a single dimension. Second.
the processor number in the linearized geometry onto which the array element is mapped is
determined. using the distribution attribute functions. Finally. the processor nurn ber dong
each of the multiple processor geometry dimensions is determined. based on the processor
number in the linearized geometry and the linearization function.
'The Fortran column major order is followed.
A(Block{ 1 21. * )
Figure 3.3: A n array dimension mapped onto multiple processor geometry dimensions.
For example, consider a one dimensional amah. A( 1 : 100) that is mapped onto a three di
mensional processor geometry (2.5.5). using a (Block{ 1.2.3)) mapping. Let u s determine
the processor onto ivhich the array element A(77) maps. The three dimensional processor
geometry consists of a total of 50 processors. In a linear processor geometry of 50 proces
sors. we can determine that tlie arm) element A(77) maps to processor number 39. using
the mapping functions described for t h e distribution attributes. Based on the linearization
function. in this example ive find that the processor number 39 is ( I . 5.4) in the three
diniensional processor geoniet ry.
3.2.3 ManytoMany Mapping
The combination of manytoone and onetomany partitioning results in manytornany
mapping. Figure 3.9 stioas an esan~ple in which a two dimensional arrav A is mapped
onto a two dimensional processor geometry with 4 processors in each dimension. using
(Block{l. 2 ) . Block{l)). This partitioning of the array results in both the dimensions of
the array being divided arid mapped onto tlie processor geometry diniension 1. and the
first diniension is f u r t h e r divided and partitioned along the processor geometry dimension
2. The combination of (~lock{l}. ~lock(l)) and (~lock{l. 2 ) . * ) partitions discussed i n
tlie previous su bsections is the partition (~lock(l.2). ~lock(1)).
The furictio~ls for the manyternany mapping are obtained by applying the manytoone
and oneternany functions. The order in which these functions are applied is determined
by the mapping of the array onto the higher dimensions of the processor geometry. First.
the mapping onto the highest dimension of the processor seometry is determined. Subse
A(Block{ I.?}. Block( i 1 )
Figure 3.9: Slanytoman!. mapping of array dinicnsions to processor geometry dimensions.
qnently. the processor nurn bers along the lower dimensions of the processor geometry are
determined. In this example. a onetomany function is first applied to obtain the pro
cessor numbers along the second dimension of the processor geometry. The manytoone
mapping is then applied on the subdivided array to determine the processor number along
the first tiin~ension of the processor geometry. However. the manytoone and onetomany
functions are not sufficient ivtwn many dimensions of an array are mapped onto many of
the same dinlerisions of t h e processor geometry. Consider. for example, the data partition
(Block{ 1.2). Block{1.2}). [ n such cases. linearization. along wit 11 the onetomany and/or
manytoone Functions. is applied to determine the processors onto which the array elements
are mapped.
3.3 Summary
I I I this chapter ive have described sis neiv distribution at tributes. These distribution at
tributes extend the set of possi bie computation and data partitions that have been discussed
in the literature. In addition. by allowing any mapping between dimensions of an array and
the dimensions of the processor geometry. we have derived new data partitions that are
unique and interesting.
The onetoone mapping of array dimensions onto processor geometry dimensions allows
for simple functions that determine the processor onto which the data are mapped. Hotv
cvcr. if array dimensions can be mapped onto any dimension of the processor geometry. the
functions that determine the processor onto which data are mapped become complicated.
On distri hu ted memory m~~l t ip rocessors . the ownercomputes rule is used t o partition com
putat ion and t o de te rmine t he owner ef each of the a r ray elements. The s ta tements in
the program a r e yarded to ensure t ha t only t he owner of an a r r ay element can update
it. LVit,h onetoone mappings. the guards in most cases a r e simple a n d can be eliminated.
by using conlpiie t ime analysis and by rewriting t h e loop bounds. In contrast . t h e one
tomany. manytoone. and manytomany mappings will generate a program in which t he
elimination of such guards is a nontrivial t,ask. becmse sirnpie loops cannot be written. O n
SS,L[,L[s. we can obtain guardfree code. because coherence is maintained by hardware. LYE?
hypothesize t ,hat in t he absence of guards. these mappings can he beneficial in improving
program performance o n SSbI?i[s.
CHAPTER 4
Shared Memory Effects Influencing the Select ion
of Computation and Data Partitions
This chapter presents experimental evidence to show that shared memory effects influence
the selection of computation and d a t a partitions on SSb141s. We show t,hat the c o m p ~ ~ t a t i o r ~
and d a t a partitions (lerived for SS>Kvls may be different From those derived for 4istriblited
menlory m~~ltiprocessors. This cli:rpter is organized <as foHoms. First. we identify tire per
formance factors t h a t affect the cierivation of computation arid d a t a partitions on SSh.114~.
Su bsrquently. w w present. <.sperinien tal results t,o show that factors i ~ c l i <as cache affin
ity. memory (on tention. .iyochronization overheads. and false sharing are important. and
that they must, he considered. i n addition to remote memory access. in the derivation of
computation ;rnd da ta partitions. \,toreover. wire also show how a tlata partition using the
manytoone mapping described in r.he previol~s chapter can help to minimize memory con
tention and synchronization overheads. Finally. we concl~~rie this chapter 1, reviewing the
problem of ( i e r iv in~ cornp~lt,ation partitions in t,he presence of SSXISI specific performarice
fat: t.0 rs.
4.1 Performance Factors
The prima!. factor that affects the performance of a parallel applicatiofl on a distributed
memory mtiltiprocessor is t,he relatively high cost of interprocessor communication. Horn
ever. o n SS.L~IlIs. additional performance factors. such <as cache affinity. memory contention.
synchronization overheads. and false sharing. can have n significant impact on t, he choicc of
appropriate c:omprrtation anti d a t a partitions. In this section. we describe these Factors and
explain \\;!I: t,liey were not considered significant for distributed rnemory multiprocessors.
4.1.1 Cache Affinity
Caches are used in SShMs to reduce memory access time and reduce contention in the
interconnection network. Cache affinity results when array elements that are reused across
the program are retained in the cache. Llemory access times are reduced because of two
tpes of da ta reuse: spatial reuse and temporal reuse. Data is transferred between cache
and memory in units of cache line. Typically. a cache line contains multiple array elements.
Although only a single data element is accessed by a processor. a cache line is transferred
from the memory to the cache. Spatial rerrsr occurs when all the array elements in a cache
line are used bx a processor before the line is flushed from the cache. Temporal reuse occurs
when an array element in a cache line is reused before the cache Iine is evicted from the
cache.
The performance of an application depends to a large estent on the ability of the cache to
esploit spatial and temporal reuse. In some cases. esploiting reuse may be difficult because
of the limited capacity and associativit?; of caches. Data brought into a cache by a reference
or a prefetch may be evicted before being used or reused. because of either a capacity or
a conflict miss caused by a subsequent reference. Cache misses on SSSIlts adversely affect
perforrnance. since evicted data must be retrieved from their home memory. which may be
remote to the processor.
.\ltIiougfi caches are important in improving the perforniance of applications on dis
tributed memory multiprocessors. remote data is not directb. fetched to a processor's cache.
First. t lie remote data is fetched. using the comnlrrnication routines, into the local memory
of the processor. Subsequently. data is cached from the local memory [\*hen a particular data
itern is accessed by the processor. Hence. caches play a less important role in distributed
memory mu1 ti processors than i n SSlIlIs. because cache misses result esclusively in local
memory accesses. iv hic h are inexpensive in corn parison to in terprocessor con~rnunications.
4.1.2 Memory Contention
llernory contention occurs when many processors access data in a single memory module a t
t h e s ame time. lIcmory contention can degrade the performance of an application. Since
t h e communication protocol in SSSISIs is receiverinitiated. and transfers data in units of
relatively small cache lines. a large number of requests to the same memory can overflow
rncniory buffers and cause excessive delays in memory response time [92].
1Iernory con tention has been considered less of a performance bot tlencck on distributed
rnertiory multiprocessors because of senderinitiated communication (ie.. each processor is
responsible For sending data that it owns). The order in which the data is to be sent
is determined at compile time. i n addition. in programs written for distributed memory
multiprocessors. data is communicated using large messages and infrequently. Applications
on distributed memory ninltiprocessors also use collective cornn~unications [XI] to further
reducc memory contention.
4.1.3 Synchronization Overheads
Synchronization is introduced in programs to maintain program correctness. On SSXIkls.
synchronization is explicit. and is generally in the form of barriers at the start and the end
of each parallel loop. Barriers are expensive. because the cost of barrier synchronization
typically increases linearly wit11 the number of processors. The speedup of parallel applica
tions on SSM.\Is can be significantly limited due to barrier synchronization overhead [34].
Tile overhead due to barrier synchronization on S S l l l l s can become a performance bot
tlerieck [:l.j]. and must be minimized. However. i n distributed memory multiprocessors.
synchronization is implicit. and is achieved through da ta communication.
4.1.4 False Sharing
In SSltlIs. data on the same cache line may be shared by more than one processor. and the
line may exist in more than one processor's cache at the same time. True .daring occurs
ivhen trvo or marc processors access the same data on a cache line, and it reflects necessary
data communications i n an application. On the other hand. false sharing occurs when
two processors access different pieces of data 011 the same cache line. On a hardivare cache
coherent multiprocessor. if at least one of the processors continuously writes while the other
processor continuously reads or writes to the same cache line. the cache consistency hardware
causes t!!e cache line to be trat~sferred back and forth between processors. leading to a "ping
porlg" effect [:)(j]. False sharing causes extensive invalidation traffic and can considerably
dcgrade performance. False sharing does not occur on distributed memory multiprocessors.
because the arrays are partitioned and mapped into separate address spaces.
4.2 Experimental Evaluation
The degradation caused by such factors as the amount of remote data retained i n the
cache. memory contention. synchronization overheads. and false sharing can be mitigated
by changing the computation and data partitions. First. we present an experiment using the
Mult igrid application. in which the selection of an appropriate processor geometry ensures
that cache affinity and program performance are improved. Subsequently. we describe an
esperiment using the AD1 application. in which memory contention and synchronization
overheads are reduced by seiecting a data partition wi th manyteone mapping. Finally. we
present an esperimcnt using the tred2 application. in which false sharing is minimized by
selecting appropriate data and computation partitions.
4.2.1 CacheConscious Computation and Data Partitions
The IiSR 1 multiprocessor is used to present how cache affinity plays a key role in the
selection of computation and data partitions. The KSR 1 multiprocessor has a medium
sized cache and hardivare monitoring. The presence of this hardware enables u s to measure
the number of nonlocal memory accesses and the number of cache misses that occur for
a processor. t n addition. on this machine. ive focus only on determining computation
partitions. The data partitions are dictated by the computation partitions. as data migrates
to the cache menlory of a processor \vhen i t is accessed, bccause of the COhI.4 architecture.
The architecture of t h e IiSR1 multiprocessor is described in Chapter 7 on page SS.
The Multigrid application from the S.4S suite of benchmarks illustrates why computa
tion and data partitions must be cacheconscious. Using this application. we also illustrate
that problem size is critical in determining computation and data partitions. Multigrid
is a three dinler~sional solver that calculates the potential field on a cubical grid. lye fo
cus on the subroutine psinv. ivhich uses tivo threedimensional arrays U and R. as shown in
Figurc I. 1. This application has data access patterns typical of many scientific applications.
The psinv subroutine contains a loop nest ivith three parallel loops. Lye choose not
to paralleiize the innermost loop to avoid cache line false sharing and cache interference,
because successive iterations of this loop access successive elements on the same cache
line. Hence. to partition the two outer parallel loops onto the processors. we choose a two
dimensional processor geoniet ry. Since this application does not have ioad imbalances. and
2 f o r a l l i = 2 t o N1 3 forall j = 2 t o N1 4 forall k = 2 t o N1 5 U ( k , j , i) = U ( k , j , i) + 6 C(O)*R(k, j , i ) + 7 C ( l ) * ( R(k1, j , i ) + R ( k + l , j , i) + R(k , j1, i ) + 8 R(k , j + l . i ) + R(k , j , i  1 ) + R ( k , j , i + l ) ) + 9 C ( 2 ) * (R(k1, j1. i) + R ( k + l , j1, i ) + R(k1, j+l. i ) 10 R(k+ l , j + I , i ) + R(k, j 1 , i  1 ) + R ( k , j + l , i 1 ) + 1 1 R(k, j 1 , i+ l ) + R(k, j + 1 . i+l) + R(k1, j , i 1 ) + 12 R(k+ l , j , i1) + R(k1, j, i + l ) + R ( k + l , j. i + l ) ) + 1 3 C(3)*(R(k1, j 1 , i 1 ) + R ( k + l , j 1 . i 1 ) + R(k1, j + l , i  1 ) + 14 R(k+ l , j + l , i 1) + R(k1. j1, i + l ) + R ( k + l , j1. i + l ) + 15 R(k1, j + l . i + l ) + R ( k + l , j+l, i + l ) 16 end f o r 17 e n d f o r 18 end f o r
Figure 4.1: The psinv subroutine.
has near ne ig l~bo~~r references such as i  1. i. and i + 1. the Block distribution attribute
is typically chosen (221 to partition the parallel loops. We map the outermost parallel
loop onto dimension 2 of the processor geometry and the inner parallel loop onto processor
dimension I. Thus. based on computation partitioning. the data partitioning of the arrays
arc (*. ~lock(1). ~lock(2)).
\Vc have to choose the number of processors to be assigned to each of the two dimensions
of the processor geometry. \ l W i t h 16 processors. i t is possible to choose the ( 16.1). (8.2). (1.1).
(2 .8 ) . or ( 1.16) processor geometry. Tlie cl~oice of processor geometry affects the number
of processors that csccutc each parallel loop in the loop nest. For esample. a processor
geometry of (8.2) iniplies that there are 8 processors assigned along the first dimension and
'L processors along the second dimension of the processor geometry.
Figure 4.1 shows the esecution t ime of the application for various processor geonletries.
with the ( t . Block{l]. B~oc~{z)) partition for the arrays. on the KSR1 with 16 processors.
normalized with respect to (16.1) processor geometry. Far a small data size (64sG4s61).
escctition time is minimized by a partition with an equal number of processors in each
dimension. i.e. (1.4). However, when the data size is large. the processor geometry (4.1)
no longer performs the best. The execution time is minimized with a processor geometry
of (8.2).
Figure 4.2: Sormalized esecution time of Multigrid on KSR 1.
The impact of processor geometry on performance is due to cache affinity. as can be
deduced from Figures I.:j(a) and 1.3(b). Figure 4.3(a) shows the normalized result of the
number of cache lir~es accessed from remote mernor? modules for the various processor
geometries. wit ti respect to ( 16.1) processor geornet ry. Figure 4.4(b) shows the normalized
number of cache misses. again with respect to (16.1) processor geometry. In Figure 4.R(a).
the number of remote memory accesses is minimal when the processor geometry is (4.4)
for a11 data sizes. [C'hen the data size is small (64~64x64). the data used by a processor
fits into the 2.Xk processor cache. and the rnisses from the cache. in this case. reflect
remote meniory accesses that occur in the parallel program. Hence. the predominant factor
affecting performance is interprocessor communication. and the best performance is attained
using the (1.4) geometry. This confirnis the appropriateness of this partition for distributed
memory multiprocessors.
However. when the arrays are relatively large (14Lsl44~144). the cache capacity is no
longer sufFicient to hold data from successive iterations of the outer parallel loop. and the
number of cache misses increases. LVhen the number of processors assigned to the outer
loop increases. the number of misses from the cache also increases. The (4.4) processor
geometry minimizes the number of remote rnernorv accesses. but the (16.1) processor ge
ometry minimizes the number of cache misses. The partition with (8.2) processor geometry
strikes a balance between the cost of remote memory access and the increased cache afFin
ity. resulting in the best overall performance. in spite of a relatively high number of remote
meniory accesses.
Similar conclusions that indicate that cache affinity plays a key role can also be derived
arialytically for the program by determining the amount of data accessed by an iteration
(a ) Remote memory access. ( b ) Cache misses.
Figure 4.J: Observations From the PhION hardware monitor.
Table 4.1: Requirements for the psinv subroutine.
Cache Requirement
of the outer parallel loop. as shown in Table
the inner parallel loop increases. the amount
4.1. As the number of processors assigned to
of data accessed by one iteration of the outer
parallel loop decreases. \\.'hen t lie data size is small (6ls64x64). the data used by a processor
is less than L2SK for each of the processor geometries. Hence. the best performance is
attained by minimizing interprocessor communication. which occurs at the (4.4) geometry.
However. when t h e data size is large (lfiOx160~160). the data used by a processor is greater
than the cache size for some processor geometries. Hence. the best performance for the
application is obtained only when there is a balance between the number of remote memory
accesses and the amount of the data retained i n the cache across iterations of the outer
parallel loop.
2 f o r i t e r = I t o MaxIter
3 / / Phase 1: AD1 forvard & backvard sueeps along rovs 4 for j = 2 t o N 5 f o r a l l i = 1 t o N 6 b ( i . j) = f { a ( i , j ) , b ( i . J1). x(i. J ) } 7 . .  8 end for 9 end f o r LO . .  21 / / Phase 2: AD1 foruard & backuard sweeps along columns 22 f o r a l l j = 1 t o N 2 3 for i = 2 t o N 24 b ( i , J ) = h { a ( i . J ) , b ( i  1 . j ) , x ( i , j ) } 2 5 .  . 2 6 end for 27 end f o r 28 . . . 32 end f o r
Figure 1.4: Outline of the AD1 program.
4.2.2 Contention and SynchronizationConscious
Computation and Data Partitions
The Hector multiprocessor is used to illustrate how contention and synchronization can
have adverse effects on the performance of an application without the inicrference of cache
effects: cache coherence is maintained by the software. The arctiitecture of the Hector
nlultiprocessor is described in Chapter 7 on page 97.
The Altering Direction lritegration ( A D I ) program is used to illustrate the choice of
data and corn putat ion partitions to minimize contention and synchronizatiorl overheads. In
addition. \i.e use this esperiment to shoiv t that. on SShlhIs. computation does not necessarily
have to b e partitioned according to data. and vice versa.
T l ~ e outline of the A D 1 program is shown in Figure 4.4. This program accesses three
2dimensional arrays A. B and X. A single iteration of a n outer sequentially iterated loop
consists of a forward and a backward stveep pilase along the rows of three arrays. followed
by another forward and backivard sweep phase along the columns of the arrays [37]. in this
application. parallelism is along the columns in the first phase. and along the rows in the sec
ond phase. This application is typical of other programs, such as 2DFFT. 3DFFT, turbo3d.
data partition
computation partition
I 
, ,
Phase 1 Phase 2
Figure 1..5: Partitioning requirements of the different phases.
and Erlebacher. that have parallelism i n orthogonal directions i n different phases of the
program.
\\'e partition the parallel loops using the Block distribution attribute. because the A D 1
application does not have any load imbalances.
Page placement policies fail to enharlce rnernork* IocaLity for the AD1 application. Pages
can be placed i n a firsthit or roundrobin manner among the processors. it7hen the first
hit policy is used. most of the data accessed by a processor nil l be placed in the local
memory of the processor i n the first ph<ase of the program. 4 page is shared only when
data acccssed by two iterations assigned to different processors are on the same page. Since
Block distribution attributes are used to partition computation. the sharing of data only
occurs in a small number of pages in the first phase. However. performance degrades in
the second phase of the program, because all the processors contend to read data from the
memory module of one processor i n phaselock ivith one another. The roundrobin policy
of page placement does not offer relief. Processors continue to access data in a phaselock
on each page. escept now the pages are i n different memory modules. This policy aIso
incrcascs nieniory access latency. because data is not resident in the local memory during
the first phase. Hence. irrespective of the page placement policy. the performance of the
program degrades because of contention.
The data partitioning requirements for each phase of the program are shown i n Fig
data partition Barrier Synchronizations
Phase 1 Phase 2
Figure 1.f;: ( * . Block{l]) d a t a partition with pipelined computation.
!]re 4.5. Each phase bas a different requirement for partitioning the array. There are three
possible alternatives for partitioning the da ta in the program. The first choice is to partition
the da ta that satisfies one of the loops and incur the additional penalties for not conforming
to the requirement of the loop with the conflicting requirement. The second choice is to
partition d a t a i n the loops such that the da ta partition is optimal for each of the loops.
This method requires data to be repartitioned ( redistributed). ie.. remapped bettveen the
esecution of the different loops. Depenrling on the nlultiprocessor. the cost of repartitionins
can be very high. offsetting the benefit of the optimal partitioning of the arrays. The third
choice is to select a partition that is suboptimal for both the loops. but ivhich minimizes
the overall program esecution time. The best da ta partition for AD1 remains an issue of
debate [9. 371. Amarasinghe et al. [I)] fo l lo~ the first choice for partitioning the data. while
Iirenier [:I;] follows the sxorld approach and concludes that repartitioning is beneficial.
First. we \rill analyze the (* , Block{l}) d a t a partition i n conjunction with the owner
computes rule. The (* , Block{l)) d a t a partition conforms to the requirement of the first
phase of t h e program. Folloiving the ownercomputes rule. the second phase of the program
results i n a pipelined coniputation partitioning. as shown in Figure 4.6. During the first
phase of t lie program. all the processors access local data and require no remote accesses.
However. during the second phase. the parallelisnl is orthogonal to the direction of da ta
partition. Strict adherence to t h e ownerconiputes rule requires that the computations
data partition
computation partition
Phase 1 Phase 2
Figure 4.7: ( * . Block(1J) data partition with relaxed computation rule.
be performed b> processors on the chunk of columns that they own. Thus. processor
i has to ibait for processor i  1 to f inish the computation on its chunk of the column
before proceeding. A large number of synchronizations is required to maintain the ordering
involved in the pipelined computation.
The synchronization overhead can be eliminated by relasing the ownercomputes rule
in the second phase and allo\ving the processor to nrite the results to remote memory mod
ules. Figure 1.7 illustrates the data and computation assigned to each processor in both
phases of computation. This partitioning of computation eliminates synchronization over
head at the expense of an increased number of remote memory accesses. The performance
of tlir program does not improve. because the relased computation rule. alorlg with the
(* ,Block{I}). partition results i n heavy memory contention. Each processor is responsible
for computing a chunk of columns: hence. each processor accesses every memory module
in sequence. Thus. each memory module is accessed bp every processor at the same time.
leading to the memory contention.
The data partition (~lock(1). Block{l)). along with the relaxed computation rule. is
another alternative. Figure 4.S illustrates the data accessed by the processors in each of
tlie two phases. \Vi th this partition. processors access data from remote memory modules
in both phases of the program. In both phases. processors start working on the columns
assigned to them by accessing data in different memory modules. thus avoiding memory
data partition
computation partition 4
4 I 1
I 1
Phase I Phase 2
Figure 4 3 : (Block(1). ~lockfl)) data partition with relased coniputation rule.
contention. [ t must be noted that because of the relaxed computation rule. the computation
is partitioned only based on the parallelism. The overhead due to synchronization is not
present because of the absence of pipelining. The use of the ownercomputes rule with
t h i s data partition ivill not result. i n zood performance. Oivncrship tests must be must be
introduced in the body of the loops. leading to increased overhead.
Figure 1.9 siiows the results of esecuting the A D 1 application on the Hector multipro
cessor for a data size of 2.56~2.56. xit ti various data partitions and compute rules. The
(Block(1). lock{^)) data partition that relases the ownercomputes rule outperforms all
other data partitions that adhere to the rule. Repartitioning of the array across the ttvo
phases. i.e.. adhering to the best data partitions required i n the individual phases. performs
almost as well as the (Block(1). Block(1) j data partition ivith relased computation rule.
The figure also indicates that oivnership tests degrade performance. [t is also dear that
the use of data partitioning improves performance over the use of operating system poli
cies to manage data (the no distributions curve). The performance bottlenecks of various
0     .    *
3  Owner Computes( Block{ 1 ). Block( I ) ) .   .
Sequentla1 + No D~smbut~on '  4 9  
( *.Block( l 1 ) K TC
  ? Owner Computes( *.Block{ 1 ) ) &.
edisulbutionc *.Block{ l } )/(Block{ 1 I.') *. ( B l o c k ( I ) .Block( I 1 ) 0 
I I 1 I I I I 1 0 2 4 6 9 10 12 14 16
Number of Processors
Figure 1.9: AD I Performance on Hector (2.56~256).
I ('. Block{ I))/! Block{ 1). ') ! OwnerComputes ( Repartitioning 1 1
Table?ID[
partitions for AD1 are summarized in Table 4.2.
Performance Bottleneck I _l[ernory Contention
Synchronization 1Iernory Contention /
r I
I i
1 ( Block{ 1). Block{ I}) 1 OwnerComputes
4.2.3 FalseSharingConscious Computation and Data Partitions
Data Partition 1 Compute Rule Sone 1 Relased I
( * . Block{ 1) 1 j OwnerC'ompu tes i*. %lock{ 1)) 1 Relased
, Ownership tests I
t
The IiSR1 r~iultiprocessor is usei1 to illustrate the effect of false sharing. The KSR1
il Block{ 1 }. Block{ 1) ) / Relased High Remote hlemory Access I
rriultiprocessor is chosen because of its long cache lines.
The tred2 program ( t v h i c h is part of eispack) is used to illustrate the choice of data
and computation partitions to minimize false sharing. This program contains inner loop
parallelism and has considerable load imbalances. The parallel loop iterators are part of
the subscript espressions along the cache line dimension of the arrays i n the program. The
outline of the application is shown i n Figure 4.10. This application is similar to mdg and
trfd. which are part of the perfect club suite of benchmarks.
Typically. to balance the load. the parallel loops are partitioned using Cyclic computa
tion partitioning ['L?]. This partitioning of computation causes more t h a n one processor to
share the same cache line. leading to false sharing. The impact of this false sharing is shown
in Figure 4.1 [(a). The figure shows the execution time of the application using Cyclic and
1 REAL Z(N, N), D(N) 2 for i = 2 to N 3 . . . 3 for j = 1 to Ni 5 forall k = j to Ni 6  . Z ( k . j ) . . . 7 .  . 8 end for 9 end for 10 .  . 1 1 f o r a l l j = 1 to iI 12 . . . D C j ) .   13 end for 1 4 . . . 15 end for
Figure 1. LO: Outline of the tred2 proqram.
BlockCyclic partitioning on I to 16 processors. The use of the C y c l i c partition resuits in a
large number of cache misses. as can be seen in Figure  I . l l (b ) . The resulting overhead due
to cache misses causes t.he esecution time to increase as the number of processors increases.
Each data element contained i n the cache Iine will b e written to by a different processor.
IL'hen the loop and. therefore. t.he arrays are partitioned i n a BlockCyclic manner. making
t.he size of the block q u a i t o the size of the cache line. false sharing is effectively elimi
nated. \L+hen the number of processors is smal l , t.he load is relatively wellbalanced. and the
elimination of false sharing improves performance. However. as the number of processors
increases. the load becomes increasingly imbalanced. and the negative impact of this load
imbalance begins to outweigh the benefits of eliminating false sharing.
4.3 Summary
Altholigh large SSIISIs are built based on an architecture w i t h distributed memory. the
shared memory paradigm introduces performance issues t h a t are different from t h ~ s e en
countered in distributed memory multiproce~sors. The high cost of interprocessor commu
nication in distributed men~ory multiprocessors makes the minimization of communication
the predominant issue in selecting data partitions and in partitioning computation. In this
chapter. ive have shown tha t . on SShIlCs
( a ) Effect of False Sharing (b) Cache .\.Iisses
Figure 4.1 1: Performance of tred2 on KSR 1.
0 Cache afinity. memor? contention. synchronization. and false sharing play an impor
tant role in t he derivation of computation and data partitions on.
0 \Ie need not strictly adhere to the ownercomputes rule. \Ye can use the shared ad
dress space and the hardivare/softtvare coherence mechanisms to implement a relaxed
cornpu tat ion rille.
\\'e rise the observation that we d o not
to derive the C'DP algorit hrn for finding
perforn~ance of applications on SSlIlIs.
lave to adhere strictly to the ownercomputes rule
corn putation and data partitions that improve the
CHAPTER 5
The Computation and Data Partitioning
Algorithm
[ n Chapter 4. we discussed ivhy shared memory effects must be considered in deriving
compl~tation and da ta partitions. This chapter describes the CDP algorithm. which derives
appropriate computation and data partitions for an application on SSIISIs. The chapter is
organized as follotvs. First. ~ve describe the input program model. Second. ive describe the
output of the CDP algorithm. Third. rve present an outline of the different steps involved
i n obtaining the required output. These steps are elaborated i n the s o bsequent sections.
5.1 The Input Program Model
The input to the CDP algorithm is a program consisting of a sequence of loop nests. in which
parallel loops are identified. The loop nests targeted by the CDP algorithm are identified
as folloirs. i n each loop nest in the program. the nesting levelL 1; of the outermost parallel
loop in the nest is identified. The smallest value of .\; (i.e.. the value for the outermost
parallel loop) for all nests i n the program is used to delineate the target loop nests for the
algorithm. This is illustrated i n Figure 5.1. The loop nests targeted by the CDP algorithm
are highlighted for each example. Figure 5.L(a) illustrates a case i n which all the loop levels
in each of the loop nests are considered. Figure 5 . L(b} illustrates a case i n tvhich only the
innermost parallel loops are considered. Figure 5 . L(c) illustrates a case in ivhich an outer
sequential loop enclosing a parallel loop is ignored. Figure ri.l(d) also illustrates a similar
case. Hence. by delineating target loop nests using the smallest .\;. the CDP algorithm
ensures that all parallel loops in t h e program are considered. Although tve do not directly
include the sequential loops that enclose the target loop nests i n the selection of computation
'The nesting level of a loop reflects the number of loops that encloses it [35]. Hence. the nesting level of the outermost loop is 0. <and the nesting level of a loop enclosed by n outer loops is n. tVe denote the nesting level of a loop r n by .\I:,.
Nesting level
Nesting level
0 fo r i=atob 1 for j=c tod
x(1, j) = X(i+l. j+1} . . a .
end for end for
0 for i = a to b 1 forall j = c to d
Y(i, j) = Y(i+l , j) . . a .
end for end for
Nesting level
0 for !=a to b 1 f G a l m 7  2 fork=etof
..... end for
end for
...... end for
0 for i = a to b 1 forall j = c to d 2 fork=etof 3 forall I = q to h . . .  . . .
end for end for
end for e r i d f o t
0 f o r i=a tob 1 fo; j y,;tztbf 2 ora
. .  *
end for end for
end for
0 f o r i=a tob 1 for l=c tod 2 forall k = e to f
..*... end for
end for end for
0 for i = a to b 1 f ~ ~ i l k 2 forall k = e to f
, . . * .  0 K K l f 0 ~ 
end for end for
( b ) Example 1
Nesting level
0 for i = a t o b
..,... end for
end for  end for
for I = q to h forall rn = x to y
. . ... . sndfor  
end for
1 fo r j=c tod 2
 for k = e to t
3 forall I= q to h .....*
end for end for
end for end for
( c ) Example 3 (dl Example 4
Figure 5.1: Esaniples of loop nests targeted by t he CDP algorithm.
L I :
CS CDP Pmccssors (4.4)
REAL'8 Xt5I2.512. 512)
CSCDP A('. Block( l 1. Block( I . 2 ) )
CSCDP r Block ( 2 ) forall k = 2 to Nl
CSCDP (Block( l l ) forall j=?toN1
, . . . . . . . . . end far
end for end for
for t = L to U
CSCDP t Block { I ) ) fod l = 2 to NI
for i = 2 to Nl .Ui. j. t ) =
end for
m d for end for
Figure 5.2: .A sample output.
and data partitions. they are used in the cost estimation of the CDP algorithm to increase
the cost of execution of the target loop nest by the number of iterations of the sequential
loop.
5.2 The Output of the CDP Algorithm
The output of the CDP algorithm is a computation partition for the loop nests and data
partitions for the arrays i n the input program. The derived computation and data partitions
improve the performance of the input program. The computation and da ta partitions are
represented as directives. which can be used by either a compiler or a runtime system to
execute the program in parallel.
.\ sample program with output directives that specify computation and data partitions
is sl~own i n Figure 5 . 2 . where the directives arc preceded by .*CSCDP."
The output directives specify ( i ) processor geometry. [ i i ) data partition. and ( i i i ) com
putation partition. The first directive in the program shown in Figure 5.2 specifies a two
dimensional processor geometry. rv here each dimension of the processor geometry contains
1 processors. Thus. a total of 16 processors is used to partition both computation and data.
The nutpu t directives for data partitions are specified using a distribution attribute for
cach dimension of the arra_v and a mapping of the array dimensions onto the dimensions
of the processor geometry. In the program of Figure 5.2. the first dimension of array A is
partitioned using a r distribution attribute. The second and third dimensions of the array
are partitioned using the Block distribution attribute.' The second dimension of the array
is mapped onto the processor geometry dimension 1. The third dimension is mapped onto
the processor geometry dimensions 1 and 2.
Figure 5 . 2 does not s h o ~ dynamic partitions that the CDP algorithm is capable of
deriving. \\*hen an array is dynamically partitioned. the algorithm outputs more than one
directive for the array. These directives are output at the start of a loop nest where the
(iata partition ot'an array changes.
The computation partitioning directive for a loop is placed immediately before the
loop in the program. The directives for computation partitioning specify the distribution
attribute and an assignment of a processor 5eornetry dimension. I n the sample program.
the two parallel loops in loop nest L i have a computation partitioning directive. Both the
parallel loops are partitioned using t tte Block d i ~ ribution att ribure. The outermost parallel
loop is mapped or1 to dinlension L' of the processor geometry. whereas r tie inner parallel loop
is tnapped onto dimension 1 of the processor geometry.
Figure 5.2 does not show the output directives for pipelined esecution of loops that
the CDP algorithm is capable of deriving. .A computation partition directive is used for
pipelined esecution. and it is placed immediately before the sequential loop to be pipelined.
The dist ribution attribute is used to select the granularity of the pipelined computation
partitioning.
'IYhen Blockcyclic disrribution attributes 'are chosen, the block sizes follow the dis t r ibut ion attribute spccificcztion for each dimension of the array.
5.3 Outline of the CDP Algorithm
The goal of the C'DP algorithm is t.o derive good partitions for arra_vs and loops. This is
accomplished by using the notion of afinity between parallel computation and data. Affinity
is said to esist between a parallel loop and an array dimension. because of a reference to
the arra?. if the parallel loop iterator appears in the subscript expression of the array
dimension. Yonlocal rnernorj accesses can be avoided for such a n array reference by using
the same distribution attribute to partition the parallel loop and the array dimension. and
by mapping both the array dimension and the parallel loop to t h e same dimension of the
processor geometry. Since multiple references can occur to the same arra? in one or multiple
loop nests. a conflict i n the selection of the distribution attribute and/or the mapping to
processor geometry dimensions can arise. and a partitioning conflict is said to esist. There
are three types of partitioning conflicts that can esist for an array in a program: .wquentinl
conflicts. distribution conflicts. and prrrnll~li~cm conflicts.
A sequential conflict occurs when the subscript expression in a partitioned dimension
of a n array is not a function of a parallel loop iterator (i.e.. the subscript espression is a
furicrion of onl_t sequential loop iterator(s)]. This type of conflict occurs. for example. in
a program ~vtleri the subscript espression in an array dimension is a function of a parallel
loop iterator in one loop nest. and the subscript espression i n t h e same array dimension in
another loop nest is a function of only a sequential loop iterator. If the array dimension is
partitioned. then remote memory accesses will result in the second loop nest. Similarly. if
the array dimerlsion is not partitioned. remote memory accesses will result i n the first loop
nest.
.I distribution conflict occurs when an array is accessed i n more than one loop nest and
there is a nlisnlatch in the dist ributiori attribute and/or the processor geomet rv dimension
assignment for an array dimension. For esarnple. consider an array A t h a t is accessed in two
loop nests. Let the subscript espression in a dimension of A be the function of a paralIel
loop iterator that is assigned a processor dimension { I} in the first loop nest. and let the
subscript espression i n t tie same dimension of A be a function of a parallel loop iterator that
is =igned a processor dimension (2) i n the second loop nest. The array dimension must be
mapped onto the processor dimension ( I ) to minimize remote memory accesses in the first
loop nest. and must be mapped onto processor dimension {2) to minimize remote memory
L1: f o r j = 1 to N1 f o r a l l i = j to N1
A(i.j) = (B(i) + B(i+l))*A(i,j+l) end for
end f o r
L 2 : f o r a l l j = I t o N f o r i = 2 t o N
A(=,,) = A(i1,j)  B(j) + C(Nj+l,i) end for
end for
Figure 5.3: Runnins esample # 1.
accesses in the second loop nest. \lapping the arraj dimension onto both dimensions of the
processor geometry will also result i n remote memory accesses in both loop nests.
4 parallelisnl conflict occurs when t.he subscript expressions in more than one dimension
of the array are functions of a single paralIel loop iterator in a loop nest. For esample.
r h i s type of conflict can occur when the subscript expressions i n both dimensions of a 2
dimensional arrax A are functions of a single parallel loop iterator i. say A ( i . i). In this
case. only elements of A along the diagonal are accessed. LC'hen both dimensions of A are
partitioned and mapped onto a singledimensionaf processor geometry. then many remote
memory accesses occur due to poor memory locality (Chapter 3 ) . Parallelism conflicts
seldom occur in programs.
Sequential and (list ri bu tion conflicts are iIlustrated by the esamples i n Figure 5 .3 and
Figure 5.4. Fiqurc 5 . 3 shoivs an ssarnpie program i n which a sequential conflict occurs for
array A. The prosram consists of two loop nests L1 and L2. each hatins t ~ o loops. The
program accesses two '2dimensional arrays A and C and a 1dimensional array B. t n loop
nest
The
nest
the
L1. the inner iloop is parallel. while in the loop nest L2. the outer jloop is parallel.
first dinlension of array A is accessed using the parallel loop iterator i in the loop
Ll. and is accessed along the second dimension using the parallel loop iterator j in
loop nest L2. Sonlocal memory accesses can be minimized for array A in loop nest
Ll. if t,he first dimension is partitioned similar to the parallel loop i. However. nonlocal
memory accesses can be minimized for array A i n loop nest L2. if the second dimension is
partitioned similar to the parallel loop j. Sequential conflict exists for array A in loop nest
L1 because the subscript espression i n the second dimension of A is a function of only a
L1: forall 1 = 2 to N1 forall k = 1 to N
forall J = I to N forall i = 1 to N ~ ( i , J , k) = B(i, j yk,ll)
+B(i,j,k,l+l)+A(i,j,k) end for
end for end for
L2: forall 1 = 1 to N forall k = 2 to N1
forall j = 2 to N1 forall i = 1 to N
C(i, j yk,Nl+l) = A(i, J1,l)  ~ ( i , j+l,l)+B(i, j,k,l)
end for end for
end for
Figure 5.4: Running example $2.
sequential loop iterator j. Similarly. sequential conflict esists for array A in loop nest L2
because the subscript expression i n the first dimension of A is a function of only a sequential
loop iterator i. 111 order to resolve t h i s conflict. arrax A can be partitioned such that only
the first dimension is partitioned similar to the i loop in L1. only the second dimension is
partitioned similar to the j loop i n L2. or A is repartitioned between the tcvo loop nests.
Figure 5.4 sho~vs an example program i n ivhich a distribution conflict occurs for array
A. The program consists of tno loop nests LI and L2. each having four parallel loops. The
third dimerlsion of array A is accessed i n L1 using the parallel loop iterator k and i n L2
using the parallel loop iterator 1. There is a distribution conflict for the third dimension of
arm? A. when the processor geometry dimension assignments of kloop in L1 and 1loop in
LZ are not the same. In contrast to array A. the subscript espressions in the first. second.
third. and fourth dimensions of all references to B in both loop nests are functions of the
parallel loop iterators i, j. k. and 1 respectively. Therefore. there is affinity between the
dimensions of' B arid corresponding loop iterators. There are no partitioning conflicts for
arraj. B. Hence. nonlocal memory accesses can be minimized if each array dimension and
the corresponding parallel loop are partitioned and mapped sirnilarl~.
\i.tlen there are no partitioning conflicts for an array. i t is possible to derive a unique
Algorithm : cdpalgorithm begin
// Phase 1 l a ) selectprocessorgeomet rydimenslonuli t y
/ / This step provides candidate computation and data partitions 1 h) establishdatacornputatronnfindy
/ / Phase 2 if (candidate data part it ions require reevaluation) t h e n f o r each array n that requires reevaluation
a ) j ina l lx da ta par td lons(a) end for
for each loop nest 1 in t he program 2 b) ~inalrzecomputationpurtrtions(f)
end for end if
/ / Phase 3 3 ) y rncessorgeomef ry rnnpplny
end
Figure .i..lj: The CDP Algorithm.
static da ta partition that minimizes nonlocal memory accesses to the array i n all loop
nests. Hoivever. when there are partitioning con flicts. there exists nrore than one possible
partition for the array. All of thc possible partitions must be evaluated to determine ~vhich
ones result i n n l in ind esccution time.
The ttvo running esarnplcs illustrate the sequential and distribution partitioning conflicts
that can arise in a program. I n general. the number of possible partitions lor a program
which has partitioning conflicts is exponential. and esamining all possible partitions is NP
hard [XI. The CDP algorithn~ uses the affinity relationships and a cost model to reduce
the number of possible partitions.
The CDP algorithm primarily consists of three main plnses. In the first phase. affinity
relationships between array dimensions and parallel loops are captured. using a graph r e p
rcscntatiou called the A L r \ G . tising these affinity relationships. distribution attr ibutes and
a mapping to din~cnsiorls of the processor geometry are derived for the array dimensions
and parallel loops. In this phase. the dimensionality of the virtual processor geometry is
also determined. In the second phase of the algorithm. airays with partitioning conff icts
are reesamined to determine partitions that minimize overall execution time. It is in this
phase that machinespecific information. such as the cost of cache. local. and remote mem
ory accesses. the penalty for memory contention. and the overhead of synchronization. is
considered. In the last phase of the CDP algorithm. a mapping of the virtual processors of
the processor geometry to physical processors is determined. Slachinespecific information
is also used in this phase. An outline of the CDP algorithm is shown in Figure 5 . 5 .
5.4 Processor Geometry Dimensionality
The first step i n the CDP algorithm is to determine the processor geometry dimensionality
for the input program. This processor geometry dimensionality is used in the subsequent
steps of the CDP algorithm. The processor geometry dimensionality for the given program is
determined bv the number of array dimensions that contain parallel loop iterators: it is those
array dimensions that must potentially be distributed. In order to reduce fragmentation of
arrays in memory. it is desirabIe to select a small processor geometry dimensionality. while
maintaining parallelism.
\i'e determine the processor geometry dimensionality using parallel ism rnalric~..~ for the
arrays accessed in the input program. .\ parallelism matris .\I.4 = jrn,,] for an array A
identifies the dimensions of the array associated \vith parallei loop iterators. The matrix
has a row for each loop nest in the program and a column for each dimension of the array.
A n entry m,, is set to L if t h e subscript expression in dinlension j of a reference to the
arraJ i n loop nest L , contains one or more parallel loop iterators. \Vhen the array is not
referenced in a loop nest Lk. the entries in row k of the niatris are marked X. indicating
t h a t this entry is irrelevant. .\I1 other entries i r i the matris are set t o 0.
\ITc use the parallelisn~ matrices t o obtain three vectors: ORMask. ANDMask, and ri.uib1~.
parn l l~ l i sn l (VP). The ORMask is defined as the result of ORing the matr is elements along
the columns. i.e.. along the dimensions of the arrav. The ANDMask is the result of ANDing
the elements along the columns. The VP is defined as the sum of elements in a row of the
parallelism matrix. Hence. the ORMask indicates which dimensions of the array are accessed
by a parallel loop iterator in at ie'ast one loop nest. SimilarI~, the ANDJask indicates which
ciimensions of the array are accessed by a parallel loop iterator in e w r y loop nest in the
program. Finally, the VP indicates the niasiniurn number of array dimensions that can be
distributed i n a loop nest.
I n order to determine the smallest number of array dimensions that can be distributed.
each array is considered individually. If the ANDMask of the array is not 0. then the number
of nonzero elements in the mask is used as the dimensionality of the processor geometry for
the array. This is because there is a t least one dimension of the array that can be partitioned
across the entire program. Arrays for shich both the ANDAask and the O R I a s k are 0 are
not distributed. and are replicated.
However. it is possible for the ORBask to be nonzero. and for the ANDXask to be 0.
indicating that a dimension of the array is accessed by a parallel loop iterator in some. but
not all. loop nests in the program. in this case. the dimensionality of the processor geometry
for the array is chosen by considering each loop nest in which the array is referenced. The
dimensionality of t h e processor geometr!. chosen for an a r r q in a loop nest is the smaller
of either the number of parallel loops or the VP. Xote that if we choose the larger of
VP and the number of partitionable dimensions. some of the dimensions of the processor
geometry may not be assigned to loops or array dimensions. Hence. we may not esploit all
the processors in performing the computation i n the loop nest. The dimensionality of the
processor geometry for the array is the one determined most often (ie.. statisticai mode)
for tile array. considering all the loop nests.
False sharing can be avoided by not partitioning an array along the first dimension of
tlir array."[ence. the bit corresponding to first dimension of the array in the ANDMask is
set to 0 when the number of nonzero cIenlents in the ANDJfask is greater than 1. I n this
case. dimensions of the array can be partitioned across the entire program. and yet false
sharing is avoided.
The dimensionality of the processor geometry selected for each of tho arrays in the pro
gram are used to determine the dimensionality of the processor geometry for the program.
I t is choseri as the statistical mode of the dirnensionalities of the processor geometries chosen
for the arrays in the program.
The specific dinlensions of each array that can potentially be distributed are determined
using the ANDMask and ORMask. If the number of 1's in the ANDMask of an array is greater
titan or equal to the dimensionality of the processor geometry. then the array dimensions
3 i V e <assume column major storage order of array in memory. Hence. contiguous elements in the first dirncnsion correspond to contiguous elements in rnernov.
Algorithm : .sel~ctproce.ssor~~om~tr~cfrrn~ns~onnlct~ begin
for each array a Const.ruct .C/,, . t, he pnrnllell.sm mat rtx for a Select, d.,. the processor geometry dimen~ionalit~y using .\%,
end for D = stat ist icnl mo& id, ,) / / where D is the processor geometry din~ensionalit,y for the program
end
AND Aask 1 0 ORJ¶ask 1 0
Figure 3.7: The parallelism matris for rile arrays in running example # L.
indicated by 1 in the ANDMask are chosen. and the array can pot.ential1: he distributed
only alonq these dimensions. Hotvever. if the number of 1's in the ANDMask is less than
the (limensionality of processor geometr?;. then all array dimensions indicated by 1 in the
ORMask of t h e parallelisnl matris are chosen. since it is a subset of these dimensions that will
potentially be iiistributeri. The selection of a dimensionality of the processor geometry i n the
CDP algorithm is accorn plished by the algorithm .~elec~proct .~.sor~n2etr~dirnen.~ionnli tr/ .
shown in Figure 5.6 .
The parallelism matris for the arrays in running example # L (Figure 5 .3 ) is sllown i n
Figure 5.7. rvhere A t and A2 correspond to the first and second dimension of array A. The
parallelism matr is tbr array A contairls a L entry along AI dimension. and a 0 entry along
A2 dimrnsiorl in the loop nest L1. Similarly. there is a 1 entry along A2 dimension. and a
0 entry along A l dimension in the loop nest L2. The parallelism matrix for C has X entries
ORJask 1 1 1 1 AND Mask 1 1 1 1
Figure 5.8: The parallclism matrix for the arrays in running esarnple #2 .
along both C1 and C2 dimensions. corresponding to the loop nest L1. .I one dimensional
processor geometry ~ i * i l l be chosen for this program. Since the ANDMask of array A is 0.
both dimensions A l and A? will be distributed based on the ORJask. Similarly. B l and C1
will be distributed because of the ANDJasks of B and C respectively.
The parallelism matrix for the arrays in running example f 2 (Figure 5.4) is shown
in Figure 5.8. where Al. Az. and A3 correspond to the first. second and third dimensions
of A respectively. The ANDXask of A indicates that all three dimensions are potentially
distributable dimensiorls. I n order to avoid false sharing. a two dimensional processor
geomctr is chosen for A. based on the ANDMask. Similarly. a three dimensional processor
geometry is chosen for B arid C. Hence. a three dimensional geometry is chosen for the
program. Al l the diniensions of A. i.e.. A l . A2. and Ag. are distributed based on the ORMask.
O n l ~ . the three diniensions B2. B3. and B4 of B. and the three dimensions C2. C3. and C4
of C are distributed based on their respective ANDXasks. Recall that Bl and C1 are not
partitioned to avoid false sharing. However. we cannot avoid partitioning A l because the
subscript espression i n the first dimension of A is a function of a parallel loop iterator.
5.5 DataComputation Affinity
Thc purpose of this phase of the algorithm is to establish affinity between arrays and parallel
loops in the program. The CDP algorithm uses the affinity relations to derive data and
computation partitions. This step of the C'DP algorithm is accomplished by the algorithm
e.ctnblishcicrtncompntctionc~finity shown in Figu re .?.!I.
5.5.1 The ALAG
.\ bipartite graph. called the .lrruy Loop 4 f i n i t y Graph I.\ L.4 C). is constructed to c a p
ture affinity relationships between arrays and parailel loops. The AL,JIG is a n undirected
bipartite graph (I. E). in which each vertex or node I. r I * corresponds to either a parallel
loop or an array diniension that can potentially be distributed. The nodes corresponding to
parallel loops are calletl loop nodes ( l i), and the nodes corresponding to array dimensions
are a r m g dimension noiks (I.,). Each edge c 6 E connects a loop node ( I n i ) to an array
diniension nodc ( 2 :,).
An array din~ensiori node has two subnodes: a Iorward sri bnode and a recerse s u b 
node. .\ forward s u bnode represents positive st ride accesses along the array dimension.
ivhereas a reierse su bnode represents negative stride accesses along the arra: dimension.
This representation is useful in colocating elements of tivo arrays when the! are accessed
~vith opposite strides. There is an edge betireen a loop node li and the forward subnode
of an arra!. dinlension if there is a reference to the array in which a subscript espression
along that dimension has a positive coefficient of the iterator i. Similarly. there is an edge
between a loop nodc 1, and the reverse subnode of an array dimension if there is a reference
to the array in ~vhich a subscript expression along that dimension has a negatite coefficient
of the iterator i. T~vo references to an array. one with positive and the other with negative
coefficients of the same parallel loop iterator. result in two edges from the loop node to the
array dimension node: one to the forward subnode and one to the reverse s u bnode.
Figure 5 . LO sholvs the .AL.AG for running esample # L . The nodes labeled L I i and L 2 j
corrcsponcl to the parallel loops in the program. Since the ANDMask of arraj. A is 0. both
dimensions Al and A? are chosen <as nodes i n the .\L.AG based on the ORJask. Sodes B1
and C1 are chosen as nodes based oti the ANDNask of arrays 0 and C respectively. For these
arrays. we have to partition the cache line dimension. since. that is the only dimension that
ive have selected to be distributable based on the array references and the parallelisrri in the
program. A n edge connects the forward nodc of Al with the loop node tii because of the
references to A i n L1. Similarly. an edge connects the forward node of A2 with the loop node
L 2 j because of the references to A i n L2. In contrast. an edge connects the re\erse node of
C1 to loop node L Z j because of the negative coeficient of j in the reference C(N  j + 1. i)
Algorithm : estnhltshciatrrcamputattonafinrtq
beg i n I . / / Constnlct the :!LAG
Create a loop node for each parallel loop Create <an dimension node for every array djmension to be dis tr ib~i ted / / Each army node has a forward m d a reverse subnotie. for each arra_v dimension node n
Constnlct a set of sub~cr ip t expressions S,, used for the array dimension end for for each expression e in 5,,
for each loop index I in e
if 1 corresponds to a loop node 1 then r f the coefficient of r in F is positive then
;ldd <an edge between nodes 1 ,and forward node of n
else .kid an edge between nodes I and reverse node of n
end i f end if
end for end for
/ / Select distribution attributes for the nodes in the .\LAC; for each loop node
Select initial distribution attribute end for for each forward mci reverse subnodes
Select ini t id distribution attribute end for ;// llodify initial distribution attributes to ensure that (I the connected nodes / / have the same distribution attribute propagcrterc.iolw
. I . / / Select block sizes for BlockCyclic distribution attributes / / for the nodes in the A L = l G for each node with BlockCyclic at t r ibute
Select initial block sizes end for for each node in the. ,\L\G with BlockCyclic attribute
Select f ind block sizes end for
1. / / Assign dimensions of the processor geometry t o loop nodes and array dimension nodes rrssrgnprocd~nr
end
Figure 5.9: Algorithm: cstnblkhdatacontp~~tatio~nfinit~ ( Phase l b ) .
forward node
A 1 revery node loop node
@%g 4 array node
Figure 5.10: The .\L.AC; for running esample #1.
1 s m y M d a
Figure 5.1 1: The .\LAC; for running esample # 2 .
in loop L2.
Figure 5.11 shows the hL.\C; for running example #2. The nodcs labeled LI1. L l r . L I j .
L l i . LZ1. L&. L 2 j . and L2i correspond to the parallel loops in t h e program. The array
dinlension nodes of A is selected based o n the ORNask of the arralV. The array dimension
nodes of B and C i n the ALr\C; are selected based on the ANDAask of the arrays. Sodes
labeled A t . A * . A3. B2. Bj. B4. C2. C3. and Cq correspond to the distributed dimensions of
arrays A. B. and C respectively. Edges are introduced between array dimension nodes and
loop tiodes based on the array references in the program. 'as sho~vn.
5.5.2 Deriving Distribution Attributes
The derivation of distribution attributes for t lie parallel loops arid the distributable arm?
dinicnsions is ilcconiplished in two steps. First. loop and array nodes in the ALAC are
ilssignrtl initial distribution attributes based on t lie load balancing and locality considera
tions For each inclividual node. Second. final distribution attributes are derived. using the
initial distribution attribute of a node and the attributes of ail the nodes connected to it.
That is. the second step modifies the initial distribution attributes so as to account For
the load balancing and locality considerations for all the connected nodes. It should be
noted tha t nonlocal memory accesses are minimized when all the connected nodes have the
same distribution at t ri blr te and are then mapped onto the same dimension of the processor
gclomet ry,
5.5.2.1 Initial Distribution Attributes
Loop nodes are assigned initial distribution attributes mainly to balance the workload of
the corresponding parallel loop. and secondarily to preserve locality of data accesses. Load
imhalance occurs when the computations inside a parallel loop increase or decr~ase with
the iteration number of the loop. or with the iteration number of a loop that mcloses the
parallel loop.
Traditionali:. the Cyclic distribution attribute has been used to balance the load.
In general. the CyclicRCyclic distribution attribute balances ivorkloads better than the
Cyclic distribution attribute. because the CyclicRCyclic distribution attribute reduces
the difference in the number of iterations assigned to processors. Fisure 512 shows the
difference in partitioning a triangular iteration space using the Cyclic and CyclicRCyclic
distribution attributes on two processors. \Vith the Cyclic distribution attribute. there is a
workload in~balarlce of .\*/"iterations. where S = ? i n the esanlple. In general. when there
are P processors. the Cyclic distribution at tribute h a s a ivorkload imbalance of .\; P.
j V i t h the CyclicRCyclic distribution attribute. the ~vorkload imbalance can be at most
.Y mod P iterations. [n the example. there is a workload imbalance of 4 iterations ivit h the
Cyclic distribution attribute. and there is no workload imbalance with the CyclicRCyclic
distribution attribute.
Hoirever. we opt to use CyclicRCyclic o n b for the outermost parallel loop. to reduce
the overhead associated ivith CyclicRCyclic. (The loop must be split into two loops when
in~plen~entirrg CyclicRCyclic.) Hence. the default distribution attribute for a loop node
corresponding to a parallel loop i n a loop nest ivith load imbalance is Cyclic. w i t h the
exception of the outermost parallel loop.
The Cycl icRCyc1i.c or Cyclic distribution attributes also improve locality when the
parallel loop iterator is a function of enclosing loop iterator(s) . For example. in Figure 5.12.
h*.  . Additional iterations assigned to
Processor I because o f  k .   .
Cyclic distribution nttnbute
. . . h..
. . .  .
fordl i = I C O Y L Z 1 2 1 2  1 3 t' for j = i to Y
. .   Partition Itention space partitioned A ( i . j j = .   onto using the Cyclic distribution attribute . . . . 1 Processors
 A end for J
cnd for  . 4  .
Iteration space pmi tioned using the CyclicRCyciic distribution attribute
Figure .i. 12: Esample shoiving the effectiveness of CyclicRCyclic distribution attribute.
if t hc j loop is parallel and the i loop is sequential. partitioning, j using the Block distribution
attr ibute ivill result i n poor locality across different iterations of the outer sequential loop.
Hence. CyclicRCyclic distribution attribute is used t o partition a loop ivhich is a function
of outer loop iterator(s1 i n order to improve locality. However. ivhen the parallel loop
iterator is a function of enclosing loop iterator(s) and an outer parallel loop is assigned a
CyclicRCyclic distribution attribute. then the parallel loop is =signed Cyclic distribution
attr ibute to reduce the overhead associated nit h CyclicRCyclic.
Loop nodes are assigned a * attribute ivhen it is not necessary to assign C y c l i c or
CyclicRCyclic distribution attributes for irnproleed load balance or improved locality. The
* attr ibute is used as a notation to indicate that the loop node may be partitioned in any
manner suitable t o the connected nodes.
Array dimension nodes are assigned distribution attributes to enhance access locality
for the corresponding array references. LVhen an array is accessed i n a loop with a single
reference pattern ~vhere each subscript expression is a function of a single loop iterator.
then there are no constraints on the selection of a distribution attribute. i.e.. every possible
distribution attr ibute is suitable for the array. Hence. array nodes introduced only because
of such references are assigned the + distribution attribute: that is. the array dimension
node may be partitioned i n any manner suitable to connected nodes. However. if a n array
is referenced in an iteration of a parallel loop more than once. with the same st ride of access.
all elements accessed by the iteration must be colocated to enhance locality.' For example.
if A ( a c i) and A ( a c i + c) are two references to an array A in an iteration of a parallel
loop i. then both d a t a elements accessed must be assigned to the same processor. This
is achieved by assigning the corresponding array dimension nodes the Block distribution
attribute.
\Chen an array is accessed with differing strides as with references. A(a * i) and A(b * i).
the two references are treated as t bough the references were to different arraxs. In a later
step of selecting initial block sizes. ive consider these references toget her in deriving a single
block size for the array.
\Vhen a n arrav subscript expression is a function of multiple loop iterators. the relative
nesting of parallel and sequential loops determines the distribution attribute of the array
dimension node. Consider an array A that is referenced as A ( a t i f b * j ) i n a loop nest.
where i (outer) and j (inner) are loop iterators. If the j loop is parallel and the i loop is
sequential. small segments of A are accessed by the iteration space of the j loop. and the
OII ter sequential loop i controls a sncep through t h e entire array. Hence. the array dimension
node is assigned a BlockCyclic distribution attribute. with the block size equal to b. the
coefficie~tt of the parallel loop iterator in the array subscript expression. In contrast. when
the i loop is parallel and the j loop is sequential. large chunks of the array A are accessed
h each processor. In this case. the array dimension node is assigned a Block distribution
attribute. I f both i and j loops are parallel. the array dimension node is assigned a Block
distribution at tribute. to favor outer loop parallelism.
The initial distribution attributes are assigned to the forward and reverse subnodes of
a n a r r a . dimension separately. Since an a r r q can be referenced in multiple loop nests. an
array dimension node may require conflicting initial distribution attributes. [n such cases.
a BlockCyclic attribute is used.
In running csample # L. the loop node L I i is assigned the CyclicRCyclic distribution
attribute to improve data locality. Since the load is balanced in L2 and there are no implicit
'\Ve d c h e the =may access drrde of ~m ' r a y dimension t o be the coefficient of a pcvallel loop iterator in that ~ m a y dimension.
Block RBlmk Cyclic RCyclrc
Figure 5.13: Conflict resolution graph.
locality considerations i n L2. loop node L Z j is assigned the * distribution attribute. The
forward subnode of array dimension node Bt is assigned a Block distribution attribllte.
Array dimension nodes A l . A?. and C1 are assigned the * distribution attribute.
In running example $2. loop node L l l is assigned CyclicRCyclic attribute to balance
the load. and L I k is assigned Cyclic attribute because of load imbalance/locality consid
erations in L 1. .\I1 other loop nodes are assigned a * distribution attribute. because load
balancing is not an issue for these iterators. The forward subnode of array dimension nodes
B4 a n d A? are assigned the Block distribution attribute. Ill other array dimension nodes
are czssigned the * distribution attribute.
5.5.2.2 Final Distribution Attributes
The initial distribution attributes may not ensure that parallel loops and array dimensions
n hose subscript espressions are functions of the same parallel loop iterators are partitioned
similarly. Hence. in this step of the algorithm. connected nodes in the 4LlC; are made
to have the same distribution attribute: we refer to such a condition as consensus. This
step of the CDP algorithm is accomplished by the algorithm p r o p a g a t e  r ~ . d r shown i n
Figure 5.11.
\\'hen the distribution attributes of two connected nodes i n the AL.\G are not the same.
a conflict is said to esist. This conflict is resolved using the conflict r~so lut ion gmph shown
in Figure 5.13. The resolution of tno distribution attributes is the least common ancestor
in the conflict resolution graph. For esample. the attributes Cyclic and Block resolve
to BlockCyclic. The BlockCyclic attribute allotvs locality of access to be maintained
t t l rough the selection of an appropriate block size. and also allons the load to be balanced
by distributing the blocks Cyclically. A node in the conflict resoIu tion graph can be its own
Algorithm : propagate r~.solre begin repeat; / I For each array node. ensure that the forward subnode distribution a t t r i b u t ~ / / is the comptement of the reverse subnode distribution attribute. I . for each array dimension node a
DI + Distribution attribute of the forward subnode D, + Distribution attribute of the reverse subnode Df resolve( Df . reverse! D, ) ) D, + reverse( D )
end for / / Ensure that the nodes that are connected have the same distribution attribute 2 . for each loop node. forward. and reverse subnode i
f o r each loop node. forward. and reverse subnode j connected to i D, Distribution att,ribute of nods i D, c Distribution attribute of node j D,  resolve(D,. D j )
end for end for
u n t i l distribution attributes of the nodes of AL.4C do not change end
Figure 5.14: Algorithm: propagater~colre.
least common ancestor. .I distribution attribute in conflict with the * attr ibute resolves to
the distribution attribute itself.
For each array dimension node. the distribution attributes of the for~vard and reverse
subnodes are first made consistent (usin? t h e conflict resolution graph) . by having the
distribution attr ibute of the forward subnode be the reverse of the distribution attr ibute
of the reverse subnode. An iterative process is then used to reach consensus. In each
iteration. the distribution attribute of a forward node is compared to that of each node
directly connected to it. .A conflict is resolved as described above. Since all distribution
attributes have one common ancestor. the process is guaranteed t o terminate.
X special case occurs ivhen all the nodes that are connected are assigned a t distribution
attr ibute a t the end of the algorithm propagatemsofre. In this case. an arbitrary forward
array s u b n o d e ivith a * distribution attribute is assigned a Block distribution attr ibute
and the propagater~oolm algorithm is applied again. This step can be viewed as assigning
the Block distribution attribute to parallel loops and array dimensions that do not have
any preferred distribution attributes based on loadbalancing and locality considerations.
Figure 5.15 shoivs the \L.\G with the final distribution attr ibutes for running esanlple
BCRBC BCRBC
Figure 5.15: XL.\G rvith the final distribution attributes for running example # 1.
BCRBC BCRBC
BCRBC
BCRBC
BCRBC BCRBC C
Black n
A h f b \ Block
Black
Figure 516: .\L.lC; with the final distribution attributes for running example #2.
# 1. The distribution attribute of B1 is forced to be BlockCyclicRBlockCyclic(BCRBC).
resolving the distribution attribute Block and the CyclicRCyclic distribution attr ibute of
loop node L l i connected to it. The nodes L l i . L2j. A t . A 2 . B L . and C1 are partitioned using
the BCRBC distribution attribute when consensus is reached.
Figure 5.16 shoivs the .\L.\G 'vith the final distribution attributes for running example
g2. \Vhen consensus is reached. nodes L l l . L I r . L21. LZt. As. 84. B3. C4. and C3. are
partitioned using the BCRBC distribution attribute. while the nodes L l j . L l i . L2j. LZi. Al.
A?. B?. arid C2 are partitioned using the Block distribution attribute.
5.53 Selecting Block Sizes
The nest step of the CDP algorit hrn is to select block sizes for the distribution at tributes as
signed to the nodes in the .[La\G. The block sizes for the Cyclic. RCyclic. and CyclicRCyclic
distribution attributes are set to L. The bIock sizes for the Block. RBlock. and BlockRBlock
distribution at tributes can be determined in a straightforward manner after we determine
the number of processors assigned to each of the dimensions of the processor geometry.
In t h i s section. we describe a technique to select block sizes for the nodes of the ALAG
t. hat have the remaining distribution attributes. namely Blockcyclic. RBlockCyclic. or
BlockCyclicRBlockCyclic. For these distribution attributes. we select the block sizes in
two steps. First. we select initiaI block sizes for the array dimension nodes in the AL.4G
based on the array subscript espressions in each loop nest in isolation. A n initial block size
of I is selected for aII the loop nodes in the ALIG. Subsequently. we use the aIgorithm
.wfectblocksix of Figure 5.17 to select the final block sizes for all the nodes in the ALAG.
55.3.1 Initial Block Size Selection
The array dimension nodes are assigned initial block sizes to ensure that a certain number
of elements are celocated. [n particular. tvs select an initial block size along a dimension of
a n array based on the minimum number of elements along the array dimension that must
be colocated for one iteration of a parallel loop.
First. we consider a simple case where an array has a single reference in a loop nest. The
initial block size along a dimension of such an array is determined by the access stride along
that dimension. For esanlple. consider a one dimensional array A. with an array reference
A(c * i) and a parallel loop i. The array elements are accessed in a stride of c. Therefore.
a block size of c ensures that each parallel iteration of i will access an array element from
different partitions." ro te that. in this case. there are no other references that enforce the
need for colocating all array elements accessed by a parallel loop iterator together in the
same block. In addition. with a single reference. the offsets in the subscript expressions do
not affect the selection of initial block sizes.
CVhen there are two references to an array. the initial block size is not only dependent
on the array access stride but also on the offsets in the array subscript espressions. It is
'IVhen an array subscript expression is a function of multiple loop iterators. we use the array access stride dong the outermost parallel loop iterator as the block size for the array.
necessary to consider the orsets i n array subscript expressions only if the two references
have the same access stride. For example. consider two references A(c * i) and A(c * i + d)
to an array A i n a parallel loop i. The array dimension must be partitioned i n bIocks of
at / e a t (d + 1) elements to ensure that one iteration of the paralleI loop will access both
elements of t.he array from the same partition. However. the stride of c requires an initial
block size of c. Therefore. the initial block size is chosen to be the least common multiple
(Icrn) of the stride and the offset. In this example. an initial block size of lcmtc. ( d t I ) ) is
chosen for the array dimension node of array A. Note that. nhen the access strides in the
two references are not equal. there will be nonlocal accesses irrespective of the block size
chosen. In such cases. we choose the maximum of the two strides as the initial block size of
the array dimension node,
AS a general rule. w h e n there are more than two references to an array with the same
stride. the initial block size is chosen by first selecting the block size for s pair of array
references at a time. The initial block size for the array dimension is selected as the least
common multiple of the block sizes selected for each pair of references. Thus. the initial block
size selected ensures colocality of arra_v elements accessed with the same access stride. CC'it h
differing strides of access. only the references wi th the largest access stride are considered
in the block size selection.
.I special case occurs when the partitioned array dimension is the cache line dimension.
In this case. the initial block size is chosen to be the number of array elements in a cache
line. i n order to avoid false sharing.
Finally. the initial block size for an array dimension is chosen to be the least common
multiple of the initial block sizes selected for the array dimension in each of the loop nests
in the entire program.
I n running example $1. B1 requires a block size of 2. based on its offset and stride
requirements. To avoid false sharing. the bIock sizes of A l . B1. and C1 are selected as CL
( the number of elements that can be in the cache line size of the machine). Since the cache
line is a. multiple of 2. lcm(2. CL) = CL is chosen as the bIock size for the array B1.
In running esainple #2. B4 requires a block size of 3 . based o n the offset requirements
in loop nest L l .
AIgorit hm : seircthlof:ksm /',/ . \ I1 parallel loops in the program are ;~ssumed to be normalized / / with a step of 1. begin repeat 1. f o r each loop node I E L
f o r each array dimension node a connected to 1 bl t lcm(hr. {h , , /S tr idc(n . 1 ) ) )
end for .) . f o r each array dimension node a connected to I
h, , c lcm(b,,. { b l c .Z l r i c fe (cz . I ) ) ) end for
end f o r u n t i l n o block size changes in the nodes of ;\LAIC; end
Figure 5.17: Algorithm: selectblocksize.
5.5.4 Final Block Size Selection
The initial block sizes for the nodes in the AL.4C are used to select final block sizes
for the nodes. .&orit hm selectb10r:ksize. sllown i n Figure 5 . L7. selects final block sizes for
nodes in the ;\L.AC;. This algorithm repeatedly updates block sizes of loop nodes. based on
the block sizes of connected array nodes. The block sizes of array dimension nodes are in
turn uptf ateti. hcased on the block sizes of connected loop nodes. u n t i l there are no changes
i n the block size of t.he nodes i n the ALAC. The algorithm will terminate because there is
a number that is the least common multiple of all possible block sizes.
Note tfi;~t. i n some rare cases. the block size of a parallel loop may turn out to be very
large. and it ma; hide the parallelism in the program. Similarly. if the block size of a n array
dimension is very large. the array dimension may not be partitioned among processors. AS
an optimization. we limit the maximum block sizes to be the block size for t h e Block
distribution attribute. assuming that the parallel loop or the array dimension is mapped
onto all the processors i n the system.
[n runn ing example # 1. t h e array dimension nodes A l . B1. and Cl have a block size of CL.
the number of elements contained in the cache line of the machine. In both loop nests. the
stride along all the ar ray dimensions is 1. ,\pplying the aelecl6lock.si~e algorithm selects a
block size of CL for all the nodes in the ;\LAG. In running example #2. a block size of 3 is
chosen for all the nodes with the BCRBC distribution attribute.
5.5.5 Processor Geometry Dimension .Assignment
Parallel loops and distributed array dimensions must be assigned processor geometry dimen
sions to complete the partitioning of computations and data. The goal of th i s assignment
is to ensure that elements of arrays required by an iteration of a parallel loop are assigned
to the same processor that executes the iteration. in other words. it is desired to have
connected nodes in t l~e .\L.iC; m a p onto the same processor geomet ry dimension.
The processor geometry dimensions are first assigned to loop nodes and iLre then prop
agated to the connected array dimension nodes in the AL.\C;. The number of parallel loops
in a loop nest m a y be equal. greater than. or less than the dimensionality of the processor
geometry. CCe first assign processor dimensions to loop nests that have parallel loops equal
to the processor qeometry dimensionality. This is a simple case. because we do not have
to select the parallel loop that will not be assigned a processor dimension. or the processor
dimension that will not be assigned to a parallel loop.
In t h e loop nests in which the number of parallel loops is equal to the dimensionality of
t, he processor geometry. all parallel loops will indeed esecu ce in parallel. These loop nests are
first assigned processor geometry dimensions. CC'e start the processor dimension <assignment
with one such loop nest. Parallel loops are assigned geometry dimensions from outermost to
innermost. assignin% the highest geometry cfimension to the outermost loop and the lowest
dimension to the innermost loop. The assignment of dimensions to loops is then propagated
to array dimensions using the AL.[(I;. The 5eometry dimension assigned to iL loop node is
also assigned to d l array nodes co~~necteci to the loop node. A n a r ray dimension node may
be assigned more than one dimension of t he processor geometry. depending on tshe number
of loop nodes connected ro it. Processor 5eornetrF dimensions are assigned from outer to
inner. because this order espIoits outer loop parallelism and avoids inner parallelism.
The nest loop nest in which the number of parallel loops is equal to the geometry di
mensionality is considered. Parallel loops whose corresponding loop nodes i n the ALAG are
connected to array dimension nodes that have already been assigned a geometr? dimension
are assigned the same geometry dimension. Paralle[ loops that are not assigned geometry
dinlensions in this way are assigned a dimension as described For the first loop nest. from
outermost to innermost. but only geometry dimensions t h a t have not been assigned to a
loop node i n the current loop nest are considered. The dimension assignment to each loop
Figure 518: Processor geometry assignment for running esample # 1.
node is then propagated to all the array dimension nodes connected to it. and the process
is repeated for the remaining loop nests in which the number of parallel loops is equal to
the geometry dimensionality.
\17hen the array dimension nodes connected to a loop node have more than one processor
geometry dimension. then the loop node is assigned a processor geometry dimension that
is assigned to the n ~ a s i m a l number of the connected array dimension nodes."
In loop nests in which the number of parallel loops is not equal to the geometry dimen
sionality. either some parallel loops will not be assigned a geometry dimension. and hence
will execute sequentially. or some of the geometry dimensions will go unused. Such loop
nests are also considered one at a time. First. geometry dimensions are assigned to parallel
loops by propagating geonietrj~ dimensions From array nodes to loop nodes and by assigning
available gcomct ry diniensiorls to parallel loops that remain without a geoniet ry dimension.
aud also from outermost loop to innermost loop in a loop nest.
Figure 5.18 shows the processor geometry dimension assignments for running example
# I . tn the esample. the processor geometry is a linear grid. The processor geometry
dimension available for assignment is {I}. In the .\LC\G. loop node L I i is assigned processor
dinlension 1. Consequently. the array dimension nodes A1 and B1 connected to L I i are also
assigned t tic processor geomet ry dimension I . In the second loop nest LZ. the loop node L 2 j
is assigned the processor geornetry dimension I . since the array dimension node B1 connected
to it is assigned tile dimension. Array dimension nodes A2 and CI that are connected to L 2 j
are also assigned the processor geometry dimension 1. For arrays B and C. no partitioning
conflicts exist and static partitions are determined. However. there is a sequential conflict
'When this does not resolve conflicts, the assignment of processor geometry dimension is delayed until after all other Loop nodes in the loop nest under consideration are Lasigned processor geometry dimensions. :Is a last resort, we resolve the conflict by choosing one of the possible choices arbitrarily.
Figure 5.19: Processor geometry assignment for running esample #2.
for the array A.
Figure 5 . LO shoivs the processor geometry assignment for running example #2. Loop
nodes L I l . LIk. and Ll are assigned geometry dimensions 3. 2 . and I respectively. These
assignments are propagated to array dimension nodes A?. A3. B2. B3, and B4. LOOP nodes
L21. L2k. and L Z j are assigned dimensions 3. 2. and 1 respectivel? based on the assignnlents
of B4. B3. and B2. Consequently. the array dimension nodes C4. Cg. and C2 also are assigned
geometry dinlensions 3. 2. and 1 respectively. Because A3 is connected to both L l k and
LZ1. i t gets the geonietry assignment of both these loop nodes i.e.. {'L. 3 ) . Loop nodes L I i
and L 2 , are mapped onto the nonexistent processor geometry dimension {O). Similarly.
A, is also mapped onto processor geometry dimension (0). As in running esample # 1. no
partitioning conflicts esist for arrays B and C. and static part i t ions are determined. However.
there is a distribution conflict for the array A.
5.6 Dynamic Array Partitions
The partitions derived so f a r by the algorithm attempt to preserve the affinity between
data accessed arlcl computations through static array partitions. For arrays for which a
onetoone mapping between the distributed dimensions of the arrays and the dimensions
Algorithm : asszgnprocdrm begin
for each loop nest L / / where L is ordered according to the number of parailel loops in its bod! / / such that L in which the number of parallel loops equal the processor qeometry are first. / / Both forward and reverse subnode of an array dimension node are assigned / / t he same processor geometry dimension. Hence. we do not distinguish forward / / and reverse in processor geometry dimension assignment.
/ / PD is the set of all possible possible processor geometry dimensions. Po c { 1 . 2. . . . . k } / / where k is the processor geometry dimensionality
f o r each loop 1 5 L f o r each array dimension node a connected to I
if u is <assigned processor geometry dimension d then %sign 1 processor geometry dimension d: L t L  1 PG 6 PD  d
end i f end f o r propagate(d.1)
end for f o r each I E L
if Po is not empty then assign I processor geometry dimension d from P.i L  L  I : PD + PD  d
end if propagate (d.1)
end f o r end f o r
end
Subprogram: propagate ( d l ) begin
for each node n i f n is an a r r v dimension node tvith an edge from 1 then
add d to n's list of dimensions end if
end for end
Figure 520: 4lgorit hm: assignprocdim.
of the processor geometry esists, static partitions make accesses to the arrays local across
all loop nests in the program. For arrays i n which a onetoone mapping cannot be used.
remote memory accesses occur i n some or all of the loop nests. The geometry dimension
assignment was made for such arrays in order to satisfy multiple locality requirements in
the different loop nests. A parallel loop is partitioned along only a single dimension of
the processor geometry. Hence. nonlocal memory accesses d l occur for an array if the
subscript espression along a dimension contains the parallel loop iterator and the array
dimension is partitioned along multiple dimensions of the processor geometry.' The CDP
algorithm ensures that one of the dimensions of the processor geometry onto ~vhich t h e array
dimension is mapped Nill be same as the processor geometry dimension that the parallel
loop is mapped to.
Similarly. partitioning multiple dimensions of the array along a single dimension of the
processor geometry also results in nonlocal acces~es.~ If t.he subscript espression along one
of the dimensions of such an array is a loop iterator that corresponds to a parallel loop
mapped onto the same processor dimension. then nonlocal memory accesses ivili occur
because of the latinsquaretype partitioning of the array."
Hence. the partitions of arrays that do not have aonetoone mapping are reevaluated to
determine if d>namic partitioning may result in better program performance. I n addition.
we have to only consider the loop nests in which the array without the oneteone mapping
is referenced.
The assignnlent of geometry dimensions to the arry, dimension is esplored in selecting
*narrlic data partitions. The permutations of the geometry dimensions (including dirnen
sion O or no partitioning) for each dimension of an array is the set of possible data partitions
for t lie array in t h e program.
In running esample # I . the 2dimensional array A is partitioned on a linear processor
geometry using A(BcRBc{I}. BCRBC{i)). and its partitioning should be reevaluated because
two dimensions of the arra:; are mapped onto a single dimension of the processor geometry.
The set of all possible data partitions includes A(BCRBC{O). BCRBC{O}). rvhich replicates the
'This is a result of the distribution conflict that we described in Section 5.3. 'This is a result of the sequentid conflict that we described in Section 5.3. l~herr the subscript expressions dong the different dimenjions of the array are functions of a loop it erator
corresponding to a pardleI loop that is mapped onto the same processor dimension as the array, then the partitioning of the m a y will result not only in nonlocal accesses but also in memory contention. This is the parallelism conflict described in Section 5.3.
array: A(BCRBC{I}. BCRBC{O)). which results in local accesses to the array in the first loop
nest: A(BCRBC{I), BCRBC{O}), which results in local accesses to the array in the second loop
nest: and A(BCRBc{l}. BCRBC{ I)). tvhich results in nonlocal accesses in both loops.
CVhen sequentiaI conflict exists for an array in a loop nest. two computation partitioning
rhoices must be evaluated i n addition to the data partitioning choices: f i ) the computation
partition in which the candidate data partition incurs contention overhead. This candidate
data partition is same as the partition that was determined using the .AL.IG. where only
parallel loops are partitioned: (i i) a pipelined computation partition that incurs synchre
nization overhead. This computation partition is a result of partitioning a sequential loop
that is the source of the sequential conflict. The computation partition changes only when
pipelining is chosen for a loop nest when evaluating the candidate data partitions for an
array.
I n running esample #'L. 2 dimensions of the three dimensional arrav A are partitioned
on a three dimensional processor geometry sing A ( * . Block{l}. BCRBC{Z. 3)): hence. its
partitioning should be reevaluated. In this esample. the first dimension is not partitioned.
the second dimension is mapped onto the first dimension of the processor geometry. and
the third dimension of the array is mapped onto both second and third dimensions of the
processor geometry. The set of possible data partitions includes A(*. block{^}. BCRBC{O}).
wliicli replicates the array completely: A ( * . ~lock{1}. BCRBC{O}). A(*. Block{O}. BCRBC{~)).
A ( * . lock{^ 1. BCRBC{J}). and A ( r . lock{^}. BCRBC{Z. 3)) . which partially replicate the ar
ray: A ( + . Block{l).BCRBC{2}). tvhich results in local accesses to the array in t he first loop
nest. but not the second: A ( * . B~OC~{~}.BCRBC{~)). which results in local accesses to the ar
ray in the second loop nest. but not the first: and A ( * . ~lock{l}. BcRBc{~. 3)). tihich results
in nonlocal accesses in both loops. Altt~ougti the second dimension of the array does not
have any conflicts and is mapped onto a single dimension {I} of the processor geometry. we
consider that dimension too i n the reevaluation. in order to evaluate the benefit of repli
cation. Notc that the group of data partitions that are being reevaluated for the array is
not the estiaustivc set of possible data partitions. but a subset of data partitions obtained
by exploiting the affinity relationship that h a s been established using datacomputation
afi nity. For esample. by referring to datacorn putation affinity. we neither partition the
first dimension of the array. nor consider data partitions like A(*. Block{2). BcRBc{~}).
\Ye define a cost matrix for an array. where each element of the matris represents the
(BCIRBC'(O}. (BCIRBC{O). (BC'RBC'{l). (BCIRBC'{ l ) . BCRBC'{O)) BC'RBC'{l)) BCRBC'{O}) BC'RBC{I})
L o o p nest I 163840 66048(25088004) '24.576 33024 Loop n e s t 2 :32761'30 !0960 1.585 1.5.2 (50913.5'2 G ) 66045
Figure .i.2 1: The cost matris for array A on Hector multiprocessor in running example # 1.
(BC'RBC1{O}. (BC'RBC'{O}. (BC'RBC1{1). (BC1RBC'{L}. BC'RBC'{O)) BC'RBC{ I}) BC'RBC'{O)) BC'RBC'{I})
L o o p nest 1 204800 92800(:371200~) 25600 92800 Loop nes t 2 6.5.536 4.5824 2.523 1X6(699:392'C") 180224
Figure 5.22: The cost matris for array A on Convex multiprocessor in running esample # 1.
cost of accessing the array in a loop nest using a particular candidate data partitions. The
cost rnatris for an array is a matrix with as many rows as the number of loop nests in
the program. and as many columns as the number of candidate data partitions selected for
reevaluation. A n entry i n the cost matris. C'(1,. (1,). corresponding to a loop nest I , and a
da ta partition d,. contains the cost of accessing the arra!. ~vith the data partition (1, and
the computation partition derived using the .\L.\G for the loop nest.
111 order to determine the cost of accessing the elements of an array i n a loop nest
with a given candidate partition. machinespecific information. s u c h as cache. local. and
remote memory accesses latencies. cost of synchronization. penalty for memory contention.
and cost of redistribution is required. The cost estimation heuristics used b> the CDP
algorit h r n are described i n Chapter 6 (algorit hrn .Lrray.LcceasCb.qt on page 9 1) . For the
ease of presentation. in this chapter the algorithm for cost estimation is treated as a .black
box'. assumed to provide a metric of the estimated execution time of an input loop nest
with a candidate data partition.
The cost rnatris for the array A in running esample # I on Hector and Con\yes multipro
cessors is shown i n Figures 5.21 and 522. respectively (for a problem size of N=256). The
entries with an G** in the cost matris correspond to the masimum of the cost of accessing
the array rvit ll contention or with pipelined computation partition incurring synchroniza
tion overhead. The cost rnatris for tile array A i n running esample #2 is similar and is not
shonn here.
Loop nest 1 Loop nest 2 Loop nest I Loop nest '2
Figure 523: Reaching matris for array A i n running example # l .
In order to determine the points in the program where an array repartition should occur.
we use a reaching matrix for the array. which is constructed using Jlou graph analysis [39]
(see Section 6.4.3.2). The reaching matris of a n array is a square matris ivith a dimension
equal to the number of Ioop nests in the program. An element. R~ach(k. I ) . of the reaching
rnatris of a n array A is I i f loop nest k follows loop nest I i n the program esecution and
both loop nests k and I access the array A: otherwise. the element is 0. Figure 5.23 s h o ~ s
t h e reaching matris for array A in running esample # 1. Since the running esample has only
two Loop nests. and control flows from loop nest 1 to 2. there is onIy one nonzero entry in
the reaching matris.
The candidate data partitions of an array are searched to determine the da ta partitions
that minimize t h e overall esecution time. The objective is to derive for each loop nest i.
one da t a partition d, for the array such that
is minimized. ~vhere D ( m ) corresponds t o the da ta partitioning (1, in loop nest rn and
RP(d, . d,) is the cost of changing the partitions of the array from d l to d,. The cost
of repartitioning is 0 when the data partitions are the same. Bisby et a!. have shown
that. this optimization problem is SPComplete [26]. Ho~vever. since only the arrays that
lack onetoone mapping between array dimensions and processor geometry dimensions are
considered. arid each arra! is considered by itself. the size of the search space is limited in
most applications. allo~ving a n exhaustive search to be practical. 4 depthfirst search ivith
pruning is used to further reduce the size of the search space. The cost of esecuting the
program with the best static data partition is used to prune the depthfirst search. The
ajgorit hm finnli,Edatapartitions accomplishes the dept hfirst search to determine the final
da ta partition for each loop nest.
Figure 5.26 sho\vs the search space of possible da t a partitions for array A in running
Algorithm : final~zedatapart 1t1ons/.4 I / / Returns candidate data partition in each ioop nest that maximizes / / program performance begin 1. f o r each candidate data partition i for arra_v 4
f o r each loop nest j C'(i. j)  =l\rray~~ccessCost(.l. j. i )
end for C', + x, C'(i . j )
end for 2. BestStaticC'ost t min(C', ) 3. for each loop nest j
.\linC*ost, 6 min(C ' ( i . j ) ) end for
1. B e s t DynamicCost x, .\linCost, + (.\I inJedi .s t Cost) .7. if ( Best DynarnicCost < BestStaticC'ost ) then
/ / Repartitioning could be beneficial t for each candidate data partition j
P.\TH + {i 1. j )} Cost + C'( 1. j j BestCost + [nfinity BestPath + SULL 
I . DFSRepartition( 1. j . Cost. P.4TH. Bestcost. Best Path) end for
S. i f (Bestcost < BestStaticCost) t h e n PATH contains the loop nests and tho data partitions for the array 4
else Partition for a r r q 4 t i with min(C',)
end if else
Partition for arra! 4 + i with min(C*r) end if
end
Figure 5.24: Algorithm: finalizedatapartitions ( Phase 'a).
DFSrepartit ion( Pret~.LLe.st . Prev Dim.lsst. Cost. P.YTH. BestCost. Best Path) begin
if (Cost >= Beststaticcost or Cost >= Bestcost) then return / / Pruned Search
end i f
if (P.ITH contains all the loop nests) then C'pdate Cost orwring all 1s in reaching matrix are accounted
3ewCost c Cost + RepartitioningCost(1. j) i f (SewCost < BcstCost) then
BestCost t NewCost BestPath t P:ITH
end if else
1 t loop nest not i n PATH f o r each candidate data partition C'urr.\sst
P.ITF1. i P.ITH + ( I . C'urr.Isst) XewCost t Cost + C'(1. CurrXsstj + RP(PrevDirn.Asst. Curr:lsst) DFSRepartition(/. Curr;\sst. SewCost. P.L\TH. BestCost. Best Path)
end for end if
end
Figure 3.25: Subprogram DFSRepartition.
esample # I . There are four possible d a t a partitioning choices for the array in each of
the tivo loop nests. Hence. ti.e must consider 16 possible d a t a partitioning choices for the
program. Running esanlple # 2 will also result in a similar search space for array A.
5.7 Determining Final Computation Partitions
Corn putation partitions have been determined by the d a t a computation affinity phase
of the CDP algoritlim using the AL.\C;. Subsequently. for each array. the findirerrrrczg
portilions algorithm determines a final set of data partitions. In this process. the algorithm
also determines ivhether a loop nest should be pipelined or not. Pipelining results in par
titioning a sequential loop instead of a parallel loop in the loop nest. Similarly. arrav
replication also leads to a change in conlputation partitioning for the loop nests in which
the replicated array is written. Hence. pipelining and array replication lead to a change in
the coniputation partition. and final coniputation pact itions must be determined.
if t h e reevaluatior~ of da ta partitions for all the arrays in a loop nest results in a pipelined
Limp N a t l
Figure 5  2 6 : Search space of possible partitions for array A i n r u n n i n g esample #L.
Algorithm : jinrlllze(romptrtntlonpc~rtrtlon.s(f begin 1. , / l F i s up ronlputation particions duo to the selection of pipelining.
P  number of arrays referenced in I select~ng pipelining .I' number of arrays referenced in 1 if ( P > .C*  P ) then
Select pipelined computation partition for 1 end if
2 . / / Fix up computation partitions due to replica f o r each array a referenced in the loop nest 1
D,, + d a t a partition of array a in 1 i f (D., is replicated and u is written in I ) then
Update computation partitions for I end if
end for end
arrays.
Figure 5.2;: .Algorithm: finalizecomputationpurtilions (Phase 2b).
Algorithm : processorgeometrymappmg begin 1. / / Select number of processors along each dimension of the processor geometry
P, t possible processor geometries for a given number of processors P for each processor geometry P,
Estimate the cost of esecuting the program with chosen da ta and computation partitions end for Select a procpssor geometry with minimal cost
2. / / >lap virtual processors ndimensional geometry onto linear physical processor geometry 1
(pl. P? . . .. P.) maps onto x:=I p i r ; l l Pj end
Figure 523: .Algorit hm: processorgeometrymapping (Phase 3) .
coniputation partition for the loop nest. then the loop nest is pipelined. However. a conflict
arises rvhen a pipelined computation partition is chosen For a loop nest for some arrays and
a partition ivith no pipelining is chosen for others. In this case of conflict within a loop nest.
the decision to pipeline the loop nest is based on whether the majority of arrays require a
pipelined partition for the loop nest.
Computation partition is also altered \vhen a replicated array is ~vritten in a loop nest.
In this case. all the processors must update their local copies. The computation partition
is altered to contain the entire iteration space of a loop nest. so that the array can be
coniputed by all the processors. Hoivever. we require other techniques when a loop nest
accesses some arrays that are replicated and others that are partitioned. When legal. loop
distribution [101 can be used to split the loop nest into two. ~vith one loop nest containing
replicated arra? writes. and the other loop nest containing ivrites to tlie partitioned arrays.
IVhen loop distribution is not legal. rve use conditional guards to protect tlie partitioned
array tvrites. adhering to the ownercomputes rule.''
5.8 Processor Geometry Mapping
The final step i n the CDF algorithm is to determine the number of processors in each di
mension of the processor geometry. and to map its virtual processors to physical processors.
Factors of the numhcr of processors. P. are used to generate possible processor geome
tries. For example. wticrl P=8. possible two dimensional processor geometries are ( 1. 8). (2.
10 The prototype conipiler does not implement loop distribution.
4 ) . (1. 2). and (S. 1). The costs of cache. local. and remote memory accesses for loop nests
are determined given the data and comptitation partitions for each processor geometry. The
qeometry with the minimal cost is select,ed. The heuristics used to calculate the costs of
local and remote memory accesses. and the number of cache misses because of a limited
cache size. are discussed in Chapter 6.
The physical processors are viewed as a linear array. and virtual processor (pi. p:!. . . . . p,)
is assiqwd to r he physical processor numbered x:=L p , Pi. Thus. for a two dimen
.5ion,zl processor geomet ry. t h i s mapping implies a colu m nmajor order assignment of virtual
processors to physical processors. This mapping allotvs inner loops to esecu te on adja
cent physical processors. which typically improves performance. because on SSLIlk remote
memory access latency to nearby processors is lower.
5.9 Summary
!Ve have described the C'DP algorithm for derivins computation and data partitions chat
take into account the shared memory effects on SS1Ih[s. The computational complexity of
the algorithm is reduced by restricting t h e reevaluation of partitions to those arrays that
may benefit from such reevaluation. and by selecting a ctirnensionalit~ of the processor
qeometry b a e d o n the parallelism i n t h e program. CVe experimentally evaluate the com
pr~tational efficiency. and present the effectiven~ss. of the data and computation partitions
derived by the C'DP alqoritlim i n Chapter 7 . I n the nest chapter. rve (lescribe t h e static
estimation of a metric for the esecution time of a loop nest used bx the CDP algorithm.
Cost Model for Performance Estimation
The CDP algorithm described i n Chapter 5 requires a static estimate of esecution times of
input loop nests in order to compare alternative candidate computation and da ta partitions.
Determining the absolute esecution time of a loop nest is nontrivial. given the need for
a detailed mode[ of' rnachirle architect ure and of compiler optimizations. Therefore. our
objective in this chapter is to approximate the esecution time of a loop nest. for the purpose
of comparing the relative effectiveness of candidate computation and data partitions. The
rtietric that we use to express the esecution time is the approximate number of processor
cycles. \\'e first show how to derive approximate esecution time for the target machine.
assuming infinite caches. Subsequently. ire take into accourit the cache size on the target
rriachine.
\ye present the estimation of the approsirnate esecution time o f a loop nest i n five parts.
First. a.c identify the parameters that are most relevant i n estirriating the esecution time
of a loop nest. \Ye classify these parameters as machincdrptndcnt and programdependerl~
parameters. Second. tve provide the niathcmatical formulation for obtaining the esecution
time of a given loop nest. Third. ire describe techniques that are used to derive the nlactiine
arid programdependent parameters. Fourth. ire show ho\v these parameters are con1 bined
to obtain the esecution time of a given loop nest. Finally. we describe how the esecution
time is affected I>. tlw actual size of the cache on the target nlachir~e.
6.1 Performance Estimation Parameters
The parameters for estimating the esecutiorl time of a loop nest are summarized i n Ta
blc 6 . I . These paranicters are clilssificd as either rnachinedepeudent or programdependent.
Ilacl~iricdepender~t parameters depend on the arcliitecture of the target machine and are
Table 6.1: Parameters for performance estimation.
hlachine
parameters
s OC'P
Program .Vc ciepe~ldcnt .Y/ parameters .V,.
fl fL'
.Y s
cachepaccess latency local memory access latency remote memory access latency memory contention factor cost of synchronization overhead for partitioning the cache line dirriension number of eIements accessed from the cache n ~ ~ m b e r of cache lines accessed from local memory number of cache lines accessed from remote memor! number of arrays written in the loop nest number of svnchronization operations if the loop nest is pipelined.
independent of the input program. Conversely. programdependent parameters depend on
the data access patterns in the input loop nest and are independent of the target machine.
We elected to adopt such a ciassification to simplify the task of compiling several programs
to potentially man!. target machines. In this section. both of these parameters are described:
t .hc techniques used to estirnate their values are described i n sections 6.3 and 6.4.
6.1.1 MachineDependent Parameters
The first machinedependent parameter is the cache access latency denoted by C'/. It is the
number of processor cycles taken to load an array element from the cache into a register
of a processor on the targct machine. The nest two machinedependent parameters are
the local nicniory access latency. denoted by A l l . and the remote memory access Latency.
denoted by .\I,. They are the number of processor c~c le s taken. in the absence of contention.
to load a cache line into the processor's caclie from the local and from the remote memories
respectively.
The memory contention factor, denoted by c f . is used to model the percentage increase
i n local and remote memory access latencies due to contention. L\,'hen candidate da ta and
computation partitions do not result in contended memory accesses. the memory contention
factor is 1. The cost of synchronization. S. is the number of processor c~*cles taken for P
processors to esecu te one barrier sy~lcii ronization operation.
The OC'P factor is used to modcl the percentage increase in the latencies for accessing
the caclic, local. and remote memories when the cache line dimension of an array is parti
tioned. Candidate data partitions that partition the array along the cache line dimension
incur an overhead i n accessing the elements of the array from the different levels of mem
ory hierarchy.' This is because implementing these data partitions on SSXIlIs artificially
increases the number ot' array dimensions by 1. thus increasing the index computations for
each array reference."
6.1.2 ProgramDependent Parameters
The programdependent parameters are the number of elements accessed from the cache.
.V,: the number of cache lines accessed from the local memory. .V/: the number of cache
lines accessed from the remote memory. .L;: the number of arrays that are written in a loop
nest. au.; and the number of synchronization operations that occur in a loop nest. .Vs. The
parameters ;Vc. .V!. and .V,. are computed separately for each array that is referenced in the
given loop nest. .\', and .\< are the numbers of cache lines that will be transferred from
the local and remote memory. respectively. assuming an infinite cache. .\, is the number
of elements of the array that will be accessed from the cache due to spatial and temporal
locality. The estimation of .vc. Vl. and .V, requires additional compiler analysis techniques
that will be described in the following sections.
The number of arrays t h a t are written. au.. in the given loop nest is important in
estimating the synchronization overhead. as tvill be seen later i n the model formulation.
The number of s~nclironization operations. .\*s. is the number of barriers t ha t occur
when the give11 loop nest is pipelined. Irrespective of which candidate data partition is
used. sequential loops in the loop nest give rise to a number of sychronization operations.
even when a loop nest is not pipelined. Consequently. the synchronization operations that
are introduced because of sequential loops are ignored. i.c.. the number of synchronization
operations is considered to be 0 when a loop nest is not pipelined.
6.2 Model Formulation
A block diagram of the performance estimator is shown in Figure 6.1. The inputs to the
performance estimator are the machine and programdependent parameters. The output
of the performance estimator is a metric of the estimated execution time of the loop nest in
'Falsc sharing is minimized by the selection of an appropriate block size. 'TIIC implementation of data partitions is explained in Appendix :I.
Input Loop Nest  and Candidate Prognm Partitions Dependent
Parameters
A metric of Estimated
Performance Estimator L Execution Time of the Loop Nest
A .Machine C I Dependent .M Panmeters I
M r
Target Machine Chmctsristics
Figure 6.1: The block diagram of the performance estimator.
terms of the number of processor cycles. In this section. we mathematically formulate the
performance estimator.
\I'e split the execution time of a loop nest into t ~ o components. namely the computation
component and the memory access componenr."Ve assume that the computation in the
loop nest can be divided equally among the processors for all the data and computation
partitions." Hence. the computation time is immaterial when the candidate conipu tarion
and data partitions are compared. However. ivi t 11 certain candidate data partitions. the
processors require additional esecution time due to synchronizations needed for the parti
tions. Therefore. onl> the increase in computation time due to synchronization overhead is
included in t he execution time.
The rneniory access component includes the time to access scalar data and array elements
that are referenced in the loop nest. However. we ignore the cost of accessing scalar data in
our model. because most of these tend to be either in registers or cache. Hence. the primary
contributor to the memory access component in a loop nest are array references. If there
are m different arrays that are accessed in a loop nest. the estimated memory access time.
T L . can be ~vrit ten as:
3.\lthough today's superscdar processors allow the memory operations to occur concurrently with the cuithmetic operations, we do not account for this overlap.
"iVhen a repticated array is written in a loop nest, then ail the processors redundantly perform additional computations that write to the replicated array. However, the increase in execution time due to additional computations can be ignored. when comparing replicated data partitions with nonreplicated da ta partitions. because the number of memory accesses that occur for the replicated array will be higher.
where .IrtC'fk) represents the cost of accessing the elements of array k that are referenced
in the loop nest.
The array access cost for a given array can be expressed as a s u m of the costs of accessing
arra elements from the cache. local. and remote memories:
This estimate of array access cost must be adjusted to account for contention. synchr*
nization. and cache line partitioning. The formulation of the CDP algorithm requires that
the cost of synchronization he expressed per array. Hence. all the arrays that are written
in a pipelined loop nest share t he synchronization overhead equally. The synchronization
overhead for the readonly arrays i n the loop nest are not included. because they can be
replicated. Hence. the access time of a n arrav. including these overheads. can be espressed
as:
.I.LC'(k) = {.\, * C'l + (.Sl * .\Il + * 11,) * cf} * OC'P f .V.s * Sjnir ( 6.3)
6.3 Estimating MachineDependent Parameters
Tllc number of processor cyc l~s for cache. local. and remote memory access latencies is
obtained from the architect~~ral specification of the target machine. For esample. the latency
for accessing data from the cache. local. and remote memories on the C'onves Esernplar
multiproc~ssor are I . 50. and 200 processor cycles respectively.
IVhen available. ive use analytical models of the target machine for estimating the
rnachinedependent parameters. In cases where such analytical models are not available.
lve use a training set"based approach to estimate the machinedependent parameters. 4
"training set" is a collection of kernel loop nests designed to measure machinedependent
parameters. Balasundaranl et. al. introduced and used this approach to model distributed
memory machines. and shoived that it is both accurate and portable across different ma
chines [dl]. The set of kernels we use are included in Appendix B.
The memory contention factor for a multiprocessor is determined by measuring the per
formance of training set loop nests. RecaIl that contention occurs when all processors access
the same memorj. module. Since. the effect of contention is highly machinedependent. an
alytical models that model contention tend to be conlples. Hence, to estimate the memory
cor~tention factor. ire use a training set that consists of two loop nests. In the first loop nest.
all the processors access a certain number of array elements from the same memory mod
ule. In the second loop nest. all the processors access the same number of array elements
.as in the first loop. but from different remote memory modules. The memory contention
factor. c f. is which is the ratio of the esecution time of the first loop nest. t I . and
Table (j.2: llachincdependen t parameters for modelling mu1 tiprocessors. .
the esecution time of t , l~e second loop nest. t?.
Inlike memory contention. the cost of synchronization can be analytically n~odelled for
most machines. For esample. the cost of'a barrier synchronization on the Conves SPPlOOO
is approximately (S + P) psec [u]. where P is the number of synchronizing processors. In
t h e absence of analytical models. the synchronization cost for a given number of processors
can also be estimated by using training set loop nests. The training set for estimating the
cost of s~nchronization lias two loop nests. In the first loop nest. a loop nest is pipelined.
The second loop nest is the same as the first loop nest. but without all the synchronization
operations. The cost of synchronization. 5'. is ( t i  tZ)/.Y.s. ivhere .\s is the number of
synchronizations that lvere perfornied i n tlie f rst loop nest. and t i and t 2 are the esecution
tinics of the first and second loop nests . respectively.
The OC'P factor is also determined by using training set loop nests. The training set
loop nests are executed on a single processor to eliminate the overheads due to contention
a n d synchronization. The training set consists of two loop nests in whicti a 2dimensional
array is accessed. The cache line dimension is partitioned i n the first loop nest. a n d the
second dimension is partitioned i n the second loop nest. The O C P factor is t l / t z . which
is tlie ratio of the esecution time of the first loop nest. t I . and the esecution time of the
OC'P
1.1 1.4
second loop nest. t 2 .
The machinedependent paranleters used in modeling the Hector and Conves multipro
cf
2 1.2
cessors with I6 processors are shown i n Figure 6.2.
S (cyctes)
1600 2400
C'l
(cycles) 1 L
.\ ll (cycles)
10 5 0
*
\Ir (cycles)
17 200
rnultiprocessor
Hector Convex
6.4 Estimating ProgramDependent Parameters
In order to estimate the esecution time of a loop nest. the programdependent parameters
must also be estimated. Of the programdependent parameters. it is straight forward to
determine the number of arrays written in the loop nest. au*. and the number of synchro
nization operations. .'.l;. Depending on the computation and data partitions chosen for
the loop nest. and the loop bounds for each of the loops i n the loop nest. the number of
synchronization operations that occur when the loop nest is pipelined can also easily be
determined. The nest task is to estimate V,,. I[. and ,V,. In order to estimate these pa
rameters. ne have to ( i ) summarize sections of the arrays accessed in the loop nest. and (ii)
determine if array elements are accessed from the cache.
[ n titis section we describe ( i ) how we summarize the sections of the arrays that are
accessed in a loop nest. ( i i ) how the number of cache lines accessed from local and remote
memory is estimated. and (iii) the . 4 m y Flow Graph (AFG) that is used to estimate the
number of elements accessed from the cache across loop nests.
6.4.1 Estimating Array Access Ranges
\\'e use b o t ~ n d d rrgdnr sections [131 to s u mrnarize the array access information. .I bounded
regular section is denoted using triplets along every dimension of a n array access being
summarized. ivherc a triplet consists of a lower bound. an upper bound. and a stride.
L'sing the triplet notation to summarize accesses along each dimension of an arra!. ive can
represent dense regions such as columns. rotvs. and blocks. The stride can be modified
suitabb to represent certain sparse regions.
The following example illustrates the use of bouncld r q u l a r s~c t ions to represent array
access regions.
for 1 = L , , I ; , s, B(2 + r + I ) = A ( i ) + A ( t + 1 )
end for
It is convenient to represent ranges of the loop iterators using triplet notation as well.
The range of i. the loop iterator. is represented as the triplet [Li:l,:Si]. ~vhere Li is the lower
bound. C, is the upper bound. and S, is the stride. The array section is obtained by using
the range of the loop iterator. and the subscript espressions. Hudak and Kennedy present
an algorithm for corn puting the array sections accessed. based on the subscript expressions
and the loop iterators [43]. For example. the array section for the reference A ( i ) in the loop
nest is [L,:Li:S;]. However. the array section for the reference A ( i + 1 ) in the above loop nest
is the triplet [Li+1:C;+l:Si]. because of the constant +l in the subscript expression. The
array section for the reference B ( 2 r i + 1) i n the above loop nest is [2*L,+1:2*lt+1:2*S;].
ii'hen there are two or more references to the same arra? in a loop nest. then the access
ranges of an array are merged together using an union operation [131. For instance. if the
val~le of the stride for the iterator i. S;. is 1. then the arrqv section of A is [L,:Cl+l:l].
which is obtained by merging the array references A ( i ) and A ( i + 1). ie.. A ( i ) U A ( i + 1). The
value of the stride plays a key role in the merging of array sections. In the absence of stride
information. the number of array elements accessed in a loop nest can be overestimated.
6.4.2 Estimating Local and Remote Accesses
The bounded regular section representation is used to estimate the amount of data accessed
from cache. local. and remote memory. given candidate data and computation partitions
for a loop nest. It is assumed that no data is in the cache when the esecution of the loop
nest starts. In the nest section. we relas this assumption in order to take into account the
effect of cache reuse across loop nests.
The section of ar ras A accessed in the loop nest. S,. can be determined by analvzing the
input loop nest."oonie of the elements in the array section S, ivill be from local memory
and others ivill be from remote memory. I'sing the data partition of the arra!. wc car1
estimate the array section that is mapped onto the local memory of a processor. S1. The
elements that are common to the two a r r q sections S, and S1 ivill be accessed from local
n~emory." Thus. the elements accessed from local menlory are S, n S1. The elements that
remain in S1 and i\*hich are not accessed from local memory will be accessed from remote
memory. i.e.. S1  Sans1. The number of cache lines transferred from the local and remote
nlernories is estimated based on the stride information along the cache line dimension of the
array. The analysis. in this section. takes into account only the data reuse within a loop
nest. ie.. data reuse across loop nests has been ignored. In the nest section. the analysis is
5The ~array section is a synthesis of the triplets dong every dimension of an array. Array range is used to refer to a triplet along a dimension. For simplicity. we do not distinguish between = m a y sections and array ranges.
6Finding the elements that are common between tw sections is c d e d the rn ter~ec t ton operation [43].
estencled so as to include the effect of temporal data reuse in the estimation of the number
of local and remote memory accesses.
6.4.3 Including Temporal Reuse Across Loops in the Estimation of the
Cache Accesses
In order to determine the section of an array that is in the cache at the start of esecution
of a loop nest. it is necessary to know the total number of array elements accessed by each
loop nest in tlie program. The section of a given array that remains in the cache a t the
start of the execution of a loop nest is estimated in a t tms tep process. First. a cache dnlo
flotr graph (CDFG) is coristructed for the input program. Second. the CDFG is used as a
template to construct an arnly flow graph (:\FG) for each array in the program. The AFG
represents the flow of control between loop nests that access the array.
6.4.3.1 The Cache Data Flow Graph
The C'DFC; is similar to the flow graphs used in optimizing compilers to portray the basic
blocks and their successor relationships [:19]. The CDFG is a directed graph (I,. E). in
~vhich the nodes c c I, represent loop nests and the edges t c E represent the flow of control
between pairs of loop nests. Each node in the CDFG contains the amount of data accessed
by the corresponding loop nest.' There is a directed edge from loop nest Ti to loop nest T2
if the esecu tion of the loop nest T2 can irrlmfdifi lf ly follow the esecution of the loop nest
T I . Depending on the flow of control in the program. tlie CDFG can be a linear. c!clic. or
a n acyclic graph.
The CDFC; for the program in Figure 6.2 is shown in Figure 6.3. The CDFG has 4
nodes. 7'1 . T2, T3. and T4. corresponding to the four loop nests. L l . L2. Ls. and L,. in the
program. The edges represent the flow of control between the loop nests.
The total number of array elcnients accessed by each loop nest depends on the compu
tation and data partitions. The candidate computation and static data partitions derived
during the datacomputation affinity phase of the CDP algorithm are used to estimate the
number of array elements accessed in each loop nest.
In the CDFG of Figure 6.3 . each node is annotated by tlie total amount of data accessed
in the corresponding loop nest by any processor. assuming 4= 256 on a 16 processor system.
' ~ h c m a y access ranges are used to estimate the amount of data accessed in each loop nest.
real * 8 A(N. N j . B(N. N) . C(N. N)
f o r a l l j = 1 t o N forall i = 1 t o N
L l (TL J: A ( 1 . j ) = B ( i . 3 ) + C ( 1 . j ) end f o r
end f o r
100 : i f ( cond i t ion l ) then
return
end if
i f ( cond i t ion2) then
f o r a l l j = 1 to N f o r i = 1 t o N  1
L 2 (T?): B ( i . j ) = A ( i . j ) = B ( i  1 . j )
end f o r
endf o r
else f o r a l l j = 1 t o N
f o r i = 2 t o N
L 3 (73: B ( i . j ) = B ( i  l . j ) f C ( i . j j end f o r
end f o r
end i f
f o r j = 1 to N
f o r a l l i = I t o N
L4 (T4b c ( i . j ) = B ( i . j )  ~ ( i . j  1) end f o r
end for
got0 100
Figure 6.13: CDFG for the esarnple.
Figure 6.2: .in example to illustrate the CDFC;.
In T I . Sfjli bytes of data nill be accessed by each procesor.J Howeker. in Tr. Tr3. and T4.
only 64I< bytes of data tvill be accessed b>+ each processor.
Thc algorithm to build a CDFG is shown in Figure 6.4.3.1. An edge is added between
T, and TI when:
1. a loop nest T, folloivs the loop nest T,.
2. an ur~conditional branch folloiving T, leads to T,. or
3. a condition branch follotving T, leads to T,.
"here are 3 ~ m q  s , each of size 256 x 256. Each element is assumed to be Y bytes long. [n this example. because of the 'array accesses m d c he one dimensional processor geometry determined by the CD P algorithm. the 'arrays wilI be divided e q u d l y among processors irrespective of the da ta partitions (exclucling replication).
Algorit hrn : buildCDFG begin I. Create a node for each loop nest i n the program 2. f o r each loop nest (T,)
add the statement that follows the loop nest to the List to evaluate (L) while List(L) is not empty
remove an entry i n the list which is the statement (S) to be analyzed if (current statement(S) = loop nest (TI)) then
Add an edge from T, to Tj else i f (current staternent(S) = conditional branch) then
add the first statement of the paths to the List else i f (current statement (S) = unconditional branch) then
add the first statement of target of branch to tlie List e l s e
if (current statement(S) is not return or esit) then add the statement following the current statement to the List
end if end if
end while end
Figure (j.!: Algorithm: buildCDFG'.
6.4.3.2 The Array Flow Graph
In order to deterniine the section of the array that is present i n the cache at the start of
esecution of each loop nest. we construct a n army flow gmph (.\FG) for each array. The
'\FG of a n array is similar to tlie C'DFG. but it only contains nodes that correspond to loop
nests i n which tlie array is referenced. In addition. the nodes corresponding to loop nests
that do not contain any pamllcl loops arc not included in the AFG. The directed edges of
the AFC; have weights of 0 or I . A n edge between tueo nodes TI and T2. corresponding to
loop nests L I and L?. has a weight of 1 i f the total number of array elements accessed by
the loop rlest L is less than the size of the cache. The assumption here is that when the
total number of array elenlents accessed by the loop nest is less than the size of the cache.
all the data accessed by the loop nest L I . obtained from the CDFG. will remain in the cache
for the loop nest L2 at the end of esecution of loop nest L l . All other edges have a weight
of 0. A n edge is added between all predecessors and successors of a node that is removed.
Figure fi..i: .\FC; for the arrajs in the esample.
These edges are given a weight of 0."
K e assume that the arraj elements are reused from the cache in a loop nest correspond
ing to a node Tt . i f and only if all the edges reaching the node T, have a weight of 1. This
is because a wei5ht of 0 on a path indicates that it is possible array elements might not be
retained in the cache. The intersection of the array access ranges of all the predecessors Tj
of a node T, is used to estimate the array access range thar is retained in the cache when
T, begins esecrl tion.
The AFG for arrqvs A. B. and c in the program shown in Figure 6.2 are shown in
Figure 6.5 . The :\FG s h o ~ v s the array sections that are contained i n the cache of processor
number 4. at the end of execution of each of the loop nests. The AFG for array A contains
only tt\o nodes: I; and T4 are not present in the AFC; because A is not accessed in loop
nests 3 arid 4. The .\FC; for array C contains three nodes: T2 is not present i n the .IF<;
because C is not accessed in loop neat 2. EIowever. the AFG for arrav 0 in the program is the
same <as the C'DFC; for the progwn. with the edges marked appropriately. For purposes of
illustration. assuming thar the cache size of the target multiprocessor is greater than 9BIi.
the edges are marked 0 or 1. based on all the predecessors for each loop nest.
The reaching matrix required by the CDP algorithm in the dynamic array partitions
phase can be calculated using the ,\FG. If there is an edge i n the AFG connecting the node
I to node r n . then there will be a 1 in ( m . I ) of the reaching matrix.  
"lye assume that data might not remain in the cache because of the execution of an intervening loop nest. which wit! access different data.
6.5 Putting It All Together
Algorithm: .~my.4ccessCost (Array A. Loop Xcst T. XFG. Array Partition) / j For a given Array Partition with a processor dimension assignment. / / .\waylccessCosf returns the cost of cache. Local and remote / / access of the partitioned array i n a loop nest T. begin I . Given processor geometry ( G ) . computation partition (C),
identify the iterations ( I ) to be executed on a processor 2. access range .\ccessRange(.l,) along a dimension i of array t U,,~,cc,,sof..r f ( l ) 3. C'acheRange(:l,) + nr,,.,,,(~) AccessRange(,4, )*Edge(Parent (T) . T) I. Carhe:lccess(.1, ) i .\ccessRange(.l, ) Tr CacheRange( .I, ) 5. LocalXccess(:l, ) t. (LocalPartition(1,) n AccessRange( :I,))
Local=\ccess(.1, ) t Local Xccess(.t, )  Locai.Access(.4, ) n Cache.lccess( 4, ) (i. Total :lscess( .l) t n:=, AccessRange(.l, )
Cact~e,\ccess( .I ) c ny= Cache.Iccess(.~, ) LocnlAccess(.l) c n:=, Local.\ccess(.4, ) + n,., n,., Local.\ccess(.li) * Cache.\ccess(:l, ) where S E { 1 . . . . . o} and K = { l . . . . .n}
Remote.\cscess( .l) t Totalt\ucess( 4)  Local.\ccess(.l)  Cache.\ccess( 4 ) Cost t CacheXccess(.4) *CactleLatcncy +
Local.\ccess(.4) * Local Latency + Remote.\ccess(.1) * RemoteLatency if contended access then
cost[ t CosfT * cf if loop can be pipelined then
C'O.S~? C ' O S ! ~ f 57 *  V S / U U ; C'ost 1 t minirnum(Cost 1 . C o s t ? )
end if = C'ost 1
end if i f partitioned along cache Line dimension then
C'oslr 4 C'flsrT * OC'P end if
end for end
Figure 6.6: Algoritllrn: .Lrmy.tccessCo.~.
The algorithm to estimate the cost of accessing an array in a loop nest. given a data
partition for the array. is shown i n Figure 6.6. In defining loop nests i n the CDP algorithm.
we have ignored sequential loops that enclose a loop nest and the selection statements.
Hcncc, the sum of the execution time of the loop nests does not reflect the true program
execution cost. If a loop nest is enclosed within a sequential loop, then the array access cost
is incre,ased. based on the nunlbcr of iterations of the enclosing sequential loop. Similariy.
we reduce the array access cost i n a loop nest when the loop nest is cncloscd within selection
statements. based on thc probability of esecution.
6.6 Cache Utilization Factor
In Section 6.4.2, we have assumed that the data accessed within a Ioop nest will be retained
in the cache across the iterations of a loop in the loop nest and that no capacity misses
will result. Such misses can he ignored ~vhile selecting dynamic da ta partitions i n the
CDP algorithm lo. but they are critical i n determining processor geometry mapping. For
esample. in Chapter 4. we saw that capacity misses play a n important role i n determining
the processor geometry. Hence. we introduce a factor. called the cache u t i l i x t i o n /actor. to
reflect the percentage increase in the array access time. based o n the cache misses that will
occur in a loop nest.
We use a cache utilization factor of 1 when the amount of data accessed by a loop nest
is less than the size of the cache. 4 cache utilization factor greater than L indicates that
data does not fit in the cache. and cache misses can occur due to limited cache capacity.
!Ve estimate the cache utilization factor for a loop nest by using the number of cache
misses that can occur at each loop le~7el. For a given loop level. the num bet of cache misses
that can occur is estimated as the ratio of the total number of array elements accessed in
the body of the loop and the cache size. The product of all the cache misses of all the loops
i n the loop nest forms the cache utilization factor.
The cache utilization factor is used lor selecting the number of processors assigned to
each of the dimens~ons of the processor geometry. The esecution time of a loop nest is
estimated by adding the cost of each a r r a accessed for a given processor geometry. By
ir~cluding the cache utilization factor as a part of the array access cost. Lve model cache
affinity in the selection of computation and data partitions. The cache utilization factor
is an indication of the number of capacity misses. This is only an approsimation. since
detailed cache behaviour is hard to predict a t compile time.
\Ve have presented a technique for estimating the esecution times of loop nests. The CDP
algoritllrn uses these estimates to assess the effectiveness of candidate computation and
data partitions. \Ve have divided the parameters for performance estimation into machine
''We chose a fixed processor geometry for dynamic array partition selection because of the interdependence between processor geometry mapping and dynamic array pcutition selection.
dependent and programdependent categories. The parameters t h a t characterize t he ma
chine a r e derived using a corn bination of analytical and empirical evaluations of t he ta rge t
architecture. CVe have also shown how we use the AFG and the sections of t h e a r ray ac
cessed in a loop to est imate the programdependent parameters. This cost model is simple.
ye t realistic enough to guide t he CDP algorithm in selecting suitable d a t a and computa t ion
part i t ions For a n application. as will be illustrated in Chap te r 7.
 CHAPTER 1
Experimental Results
This chapter presents esperimental results t o show t h a t the CDP algorithm improves the
performance of a suite of eiqhr benchmark applications. compared to t,he reliance on the
nat ive operating system pago placement policies for d a t a management. This chapter is
organized 'as fol1oiv.j. First. Lve (lisc~lss t he characteristics of benchmark applications and
,lescri be the esperirnental platforms. Subsequently. tve analyze the performance of the
sui te of benchmark applications on the esperimental platforms using the d a t a partitions
derived by the CDP algorithm. In addition. the performance of the prototype compiler in
analyzing the benchmarks is discussed. Finally. we empirically compare ou r algorithm with
r KO other automatic data partitioninq techniques to s b o ~ t he efficiency and effectiveness of
ou r algorithm.
7.1 Benchmark Applications
Eight benchn~ark applications representative of scientific programs are used to evaluate the
CDP algorithm. T h y are the vpenta. mw. and f f t 2d kernels from nasa; in !,he SPEC92
Hoatinqpoint benchmark suite. tomcatv. also from the SPEC92 floatingpoint benchmark
suite. the A D 1 stencil computat ion. svd from eispack. psinv subroutine in multigrid from
the SIS sui te of benchmarks. and f f t 3 d from the ARC0 suite of benchmarks. Table 7.1
summarizes the characteristics of these applications.
The vpenta kernel inverts three pentadiagonal matrices. There a re S loop nests in the
program. of which 7 have parallel loops. This application uses seven '?dimensional arrays
and two 3dimensional arravs.
The mxm kernel repeatedly multiplies two matrices For a fixed number of iterations. This
kernel operates o n three .'dimensional matrices. TWO of the three arrays a re readonly
Table 7.1: Application characteristics.
Brief Summary
Yo. of parallel
b p nests
r Yo. of
.  h a y s
inverts three pentadiagonal matrices matrix multiplication mesh generation program st*encil computation 2 D fast fourier butterfly computation riecomposm n 2D array ~:ornprltes 3D potential field 3 D fC*t fourier but terflv computation
I Lines I No. of .1pplic:ation I of Proc 1 Code 1 edures
I f
.I r r ay ciirnensi onality
and one of tlie arrays is written. This application has two initialization loop nests and two
cornp~itational loop nests. One of t,lie two mnlp~ltational loop nests primarily reinitializes
an army. ivhile t,he orher loop nest performs matrix mtiltiplication. In the latter loop nest.
r l l r tico ollter loops are parailel. O n l y one of the three arrays is updated. while the other
t,uo arrays are rendon I!. Esecu ting bot 11 the outer loops i n parallel requires replication of
both readonl~ arrays. If only one of the parallel loops is executed in parallel. then only
one of the readonly arrays requires replication. A n important aspect of this application is
rtl;rt ivlien tlie problem size is .;mall. ;dl the data fit into the cache. and no remote or locai
memory nccrssc.5 occur d 11 ring t lie repeatd rn~i lti plication process.
Tlie tomcatv is ;r mwii .r;enerxtion program t,hat operates on seven 2dimensional arrays.
The application has 1.1 loop nests. of ivllicll only 9 h a v e parallel loops. .\I1 tlie 9 loop nests
~ v i t ii parallel loops have x t~vo llirnensional iteration space. Some of these loop nests 40 not
have any dependence and are full?; parallel. while t,he rest of tlie loop nests carry dependences
across columns of the arrazs anti t,llus contain only inner loop parallelism.
The altering direction integrat,ion ( A D I ) program is used to solve partial differential
equations. The application was described in Chapter 4. I t operates on three 'Idimensional
arrays and has tivo plicxjes: the f irst phase sweeps along the columns of the arrays atid the
second phase sweeps along t tie rows.
The f f t 2 d kernel performs a frrat fourier trnnsform (FFT) butterfly computation on a
t,rvo dimensional array. The computation is performed repeatedly for a number of iterations.
This application accesses a 2dimensional complex array. two 1dimensional complex arrays.
I
1
/ i 1 1
vpenta ) I 1 2 I 7 nlsm 2 2
t ronlcatv 195 / 1 i !I .I D I Kt2d svd psinv
and a 1dimensional integer array. The integer array is used t o index various elements in
the 2dimensional array. T h e Courier transformation is first performed on columns of the
?dimensional a r r ay followed by computation along rows of t he array.
T h e svd routine is one of a collection of Fortran subroutines t h a t compute eigenvalues
and eigenvectors of classes of matrices. The .scd subroutine determines the singular value
decomposition (.I = (5'1.:~) of a real rectangular matr ix. This program operates on three
2dimensional arra_vs ( C  . I. and 4). There are 23 loop nests in the routine. of which 16
have parallel loops. T h e amount of parallelism in t h e program is small because most of the
parallel loop nests opera te on only one of the dimensions of t h e arrays. ie.. N elements of
the NxN matrices. In addition. the sweeps across t he c o l ~ l m n s and rows of the array are
interleaved. .A nun1 ber of scalar values are computed based o n the arrays. These scalar
values introduce synchronizations t o ensure program correctness.
T h e ps inv subroutine is from the multigrid application. which has been described in
Chapter 4. It is used to illustrate t h e impact of t he choice of processor geometry on
performance.
T h e f f t 3 d is a program from the ARC0 suite of benchmarks. T h e program performs a
3D complextocomples FF'T on a 3dimensional array. T h e application performs a FFT
on each o f the ciimensions of the 3dimensional array. [n each loop nest in the application.
parallelism is along the remaining two dimensions on which the FFT is not performed.
In each Loop nest. the dimension on which the FFT is performed is first copied into a
temporary Idimensional array. ;\I1 t he computat ions a re performed on this t.emporary
array. T h e temporary array is written back into the original array. This application is
compu teintensive.
7.2 Experimental Platforms
The three multiprocessor architectures. Hector. Convex SPP L000. and the KSR 1. are con
sidered t o evaluate t he CDP algorithm. Each of t he three muItiprccessor architectures has
unique characteristics in terms of the ratio of remote m e m o r y access time t o local memory
access time, cache capacitv. and memory contention and synchronization penalties. The
characteristics of these multiprocessors are summarized in Table 7.2.
7.2.1 Hector
Table 7.2: .Ilultiprocessor characteristics.
Hector [3] is a scalable shared memory multiprocessor that consists of a set of processing
modules connected by a hierarchical r ing interconnection network. Four processing modules
are connected by a bus to form a station. Stations are connected by a local ring to form a
drrster. Clusters are then connected by a central ring to form the system. Each processing
module consists of a 11otorola $8000 processor with 16 Kbytes of fast cache and a 4XIbyte
local portion of shared memory. .A processing module accesses nonlocal portions of shared
memory over rhe ring interconnect. Hector has no hardware mechanisms for cache consis
tency. Cache coherence is maintained by software [U]. Esperimental resd ts presented in
th i s thesis have been conducted on a 16processor cluster consisting of 4 stations on a single
local ring.
7.2.2 Convex Exemplar
I
The Convex SPP 1000 [ti] consists of lip to L6 h y p e r n o k s , each containing processors with
a cross bar connection to a .j 12 lib>tes portion of shared memory. The crossbar provides
~lniforrn access to the local memory for processors within a hypernode. Each processor is a
iieivlettPackard P.AT1OO RISC microprocessor running at 100 blHz with separate 1)[byte
instruction and data caches. Hypernodes are connected together with the Coherent Toroidal
Interconnect (CTI). a system of rings based on the SC'I standard interconnect. The cache
access latency is 1 clock cycle. or LO nsec. and the cache line size is 32 bytes. Cache misses
to retrieve data from the local hypernode memory incur a latency of 50 cycles. or .500 nsec.
1Iisses to data on remote hypernode memory incur a latency of 'LOO cycles. or 2000 nsec.
Local
Convex KSR 1
.irchi I Cache tecture 1 Access
RemoteL/ I ratio
Hector
Cache I Memory Synch .iccess , Remote2 I
1 Penalty
1 .5 0 200 LO
2 1 LY / L O ..
1  9.4/29.4
Low I Low  iledium 1 High
  
111 1 3 6 K 
19/29

1.9,/2.1) / L6K High High
7.2.3 KSRI
The KSRL (51 consists of 32 to 10% processing cells interconnected by a twolevel ring
hierarchy. Thirtytwo processing cells are connected to a firstlevel ring. which is referred to
as ring:O. Cp to 34 ring:0 rings can be connected to a secondlevel ring. which is referred to
a s ring: 1. The system on which xe conducted our experiments consists of 16 processors in
the single 32processor ring:0. The processing cell consists of a 64 bit superscalar processor.
a 5 12Kbyte firstlevel cache referred to as t h e subcache. and a 32,CIbyte secondlevel cache.
which serves as the cell's main memory. and is referred to as the local cache. The KSRL is
a Cache Only .l[ernory Access ( C'OhL1) architecture. Data is replicated and migrated from
one portion of the shared memory to another on demand.
Due to the inherent migration of data. the COX[[ architecture makes the implementa
tion of data partitions somewhat different. The data partitions i n a program are dictated by
the computation partitioning. C'OXI.4 permits data partitions only with oneteone m a p
ping of array dimension to processor geometry dimension. because there is no fised memory
= to corn i n which a data item can reside. I n order to implement data partitions accordin,
putation partitions. data transformations are ~rsed. Data ~ransfomM.ti0n is the process of
moving the partitioned dimensions to higher dimensions of the array. using dimension per
n i~~ta t ion operations. This not only minimizes cache line false sharing. but also ensures that
the data accessed bx a processor is allocated contiguously to minimize cache conflicts.
7.2.4 Comments on Machine Characteristics
The characteristics of the machines dictate the data and computation partitions derived us
ing the CDP algorithm. The Hector multiprocessor. the Conves SPP1000. and the IiSR1
represent a spectrum of machine characteristics with respect to cache size. local and re
mote memory access latencies. and cost of memory contention and synchronizations (see
Table 7.2) . The processors on Hector have a relatively small cache of 16K bytes: the proces
sors on Conves SPP LOO0 have a relatively large cache of LO'LlK bqtes: and the processors
on KSR 1 have a mediumsized (primary) cache of 'l.'jtjK bytes.
The ratio of remote memory access time to Iocal memory access time is relatively small
on the Hector n~ultiprocessor (1.9 for remote memory on the same station and 2.9 for remote
rnemory offstation): the ratio on the Conves multiprocessor is relatively high (4.0): and
t Cache Locality Enhancement
hlrmory Locality Enhancement t Parailel Program
Firgure 7.1: .Jasmine compiler block diagram.
the ratio on the LSR 1 multiprocessor is quite high (9.4 for remote memory on t h e same
rinq and 29.4 for remote memory offring).
The Hector multiprocessor is representative of an SShILI where the penalty for con
tention is very high: the penalty for contention on the Conves multiprocessor is low: and
the penalty for contention on the KSR 1 multiprocessor is moderate.
The cost of synchronization o n the Conves nlultiprocessor is relativel?; low. and both
the Hector multiprocessor and the IiSR1 multiprocessor have a relatively high cost of
svnchronization.
The diverse characteristics of these machine.; present an opportunity to esperimentally
determine the adapcabi[it> and effectiveness of the CDP algorithm.
7.3 The Compiler Prototype
The CDP algorithm has been implemented as a part of the Jasmine compiler prototype.
The overall structure of Jasmine is shown i n Figure 7.1. The compiler accepts a Fortran  t program and generates a parallel program. I t consists of four major phases: parallelism
detection. cache locality en hancernent. memory locality enhancement. and code generation.
The Ii.\P preprocessor from tiuck and Associates and the Polaris compiler are used for
the parallelism detection phase. The li.\P preprocessor and the Polaris compiler also per
Table 7.3: Execution t ime of sequential appIication on 1 processor of the indicated machine in rnilli Seconds (Problem Size is shown in parenthesis).
Machine/ I Hector 1 Convex I IiSRl fl
msm torncatv .I D I fft'ld svd psinv fft3d
Application vpenta
form procedure inlining. T h e CDP algorithm primarily constitutes the memory locality
enhancement phase of the .Jasmine compiler. and is used t o automatically determine d a t a
and computat ion partitions for applications. The ou tpu t of the prototype compiler is a C++
program with runtime calls to NCSI.KROS [GI] for implementing d a t a and computation
partitions.
7.4 Overall Performance
:W, L7O ( L28)
T h e data partitions derived by the compiler for the rnajor' arrays in the applications on
the multiprocessors is shonn in Table 7.4. For all the applications. the processor geome
t ry determined bj. the CDP algorithni was a linear array of processors. unless otherwise
indicated.
Table 7.3 shows the serial execution times of the benchmark applications on the three
machines considered. These execution times are used for calculating the speedups. 1 n the
table. t h e numbers in parenthesis indicate the problem size for the respective benchmark
application.
T h c performance of the applications on the Hector multiprocessor without d a t a parti
tions. compared t o tlieir performance ivith the computation and d a t a partitions derived us
ing the CDP algorithm. is shown in Figure 7.2. T h e performance of the applications without
data partitions delegates d a t a management to the operating system. The two page place
ment policies used by operat ing system t o manage d a t a are "firsthit" and *roundrobin."
'The largestsized m a y s in the program ~ u e considered major arrays in this thesis.
2 1.49 1 ( 128) 267.240 ( 128)
Table 7.4: Data partitions derived by the CDP algorithm.
.Ipplication vpenta m s m
tomcatv AD r
fft2d
5 vd psinv proc. georn. fft3d proc. georn.
Furthermore.
Hector ( 16 Processors) F(*. Block{ 1 ). *) A ( * . *) c(*. Block(1)) RX(B~OC~{I). *) x(B~oc~{I}. B ~ o c ~ { I ) )
Convex (30 Processors) F(+. BI O C ~ { 1). * ) A(*. * ) C(*. Block{l)) RX(B~OCR{~). t )
x(* . srock{r)) / Pipelining x(*. ~lock(1)) /X(Block{l). * ) U(BCRBC{I). BCRBC{I)) U(* , Block(1). Block(2)) (6. 5 ) Z(*. Block(1). Block(2)) I 1. 30)
KSR ( L6 Processors) FI*. Block{l). + ) A ( * . * ) C(*. Block{l)) R X ( B ~ O C ~ { ~ } . * ) X(*. Block{l}) /X(~lock{l}, * ) X(*. Block{l)) /XfBlock{l}. *) U(BCRBC{O). BCRBC{I)) u(+. B ~ o c ~ { I ) . ~lock(2)) (8. 2 ) Z(*. Block( 1). Block(2)) (1. 16)
shen operating system data management is used. only the parallel loops at
the coarsest granularity that would be chosen by a parallelizinq compiler are partitioned
among processors. The performance of the applications ~vith data partitions outperform
both the operating system data management policies.
\ik first comment o n the salient features that are responsible for improving the perfor
mance of the benchmark applications on the Hector multiprocessor. The memory Iocality
and contiguous allocation of data using data partitions in each processor's memory module
improves the performance of vpenta. The replication of one of the matrices being multi
plied was t h e key to improving the performance of the mnn application. The perforn~ance of
tomcatv is improved due to the reuse of data across the loop nests in the program. In th i s
application there are two t>.pes of loop nests. The first type of loop nests has both outer
and inner loop parallelisn~ and the second type of loop nests has only inner loop parallelism.
The parallelizing compiler strategies esploit outer loop parallelism when available and do
not use inner loop parallelism. Across different loop nests. each processor accesses different
data elements. In contrast. the CDP algorithm selects inner loop parallelism across all the
loop nests. increasing the data reuse. The performance of tomcatv with and without data
partitions is poor. however. because of the overhead due to synchronization betiveer1 the
loop nests [:)!I. St i l l the application rvit h data partitions out performs the operating system
policies. In the A D 1 application. the operating system data management techniques result
i n contention. The conlproniise data partition selected by the CDP algorithm eliminates
No Data Partitions  "Round Robin" Page Placement
No Data Partitions  "FirstHit" Page Placement
% Derived Partitions
8.7
vpenta mxm tomcatv adi svd psinv fR3d
Figure 7.2: Performance on a 16processor Hector.
contention. Repartitioning of the arrays improves the performance of the f f t 2 d application
by eliminating contention. In contrast. in the fft3d application. a static d a t a partition that
incurs contention performs well because the three dimensional array being transformed is
read and tvritten only once in the contended loop nest. The performance of svd on the
Hector is poor because of the overhead involved in part itionin: both dimensions of an array
in the application. Besides. the application characteristics are poor lor parallelization. This
is an application for which the operating system da ta management performs slightly better
than the derived da ta partitions. because of the overhead involved in partitioning data.
The performance of the applications on a 30processor Conves Exemplar multiprocessor
rvithout da ta partitions is compared rvith the performance of the computation and data
partitions derived by the CDP algorit hrn in Figure 7.3. The only page placement policy
available on Conves is .*roundrobin." The data partitions derived by the algorithm outper
form the operating system page placement policy on the Conves Exemplar multiprocessor.
The vpenta application exhibits superlinear speedup because of improved cache utilization
with da ta partitions. For the f f t 3 d application. the performance without d a t a partitions
is slightly better than the partition derived by the algorithm. The performance of the a p
plication with d a t a partitions is lower because of the overhead involved in partitioning the
arravs. The application is computationintensive. and the remote o r local memory access
cost incurred i n the program is small and cannot offset the d a t a partitioning overhead.
0 No Data Partitions
Derived Partitions
vpenta mxm tomcatv adi fwd svd psinv
Figure 7.3: Performance on a 30processor Convex.
18 T a No Data Partitions 16.7 4~ 3
ffl Derived Partitions
10.5
vpen ta mxm tomcatv ad i svd psinv
Figure 7.4: Performance on a 16processor IiSR 1.
The performance of applications on the KSR 1 multiprocessor with outer loop paral
lelisrn and the computation partitions derived by the CDP algorithm are shown in Fig
ure 7.4.' The performance of AD1 results i n superlinear speedup because of repartitioning.
which results i n better spatial locality in the loop nests in the application. Overall. data
partitions derived by the CDP algorithm enhance the performance of the applications.
The main rriacliine characteristics that affect the choice of computation and data parti
tions are summarized i n Table 7.5. A n X" in the table indicates that the corresponding
niachine characteristic tends to influetlce the selection of computation and data partitions
for the benchmark. Xote that the computation and data partitions for the remaining three
' Both f f t 2d and f f t3d werc not executed on the KSR 1 multiprocessor because of the lack af a C++ compiler for implementing the complex class corresponding to the complex data type in Fortran.
Table 7.5: )lain machine cl~aracteristics that affect the choice of computation and d a t a
Table 7.6: Impact of cache on data partition setection: performance of psinv application.
partitions o n the chosen suite of benchmarks.
fi 1Iachine 1 Hector 1 Convex I KSR fl 1 Data partition I U(t. Block{l}. ~lock{2)) 1 I I
Synchronization
.Y
benchmarks. namely vpenta. m m . and tomcatv. are not affected by the machinespecific
characteristics. It is not necessary to consider machinespecific cllaracterisrics for these
applications because the data partitions derived using datacomputation affinity have a
orictoone mapping betivcen the array dinlensions and processor geometry dinlensions. and
are hence static.
The ratio of remote memory access latency to the local memory access latency influences
the selection of d a t a and computation partitions in all t lie benchmark applications. Anlong
the bcnchniarks. pipelining was possible only in ADI. and hence. only in this application did
the cost of synctironizatiori affect the choice of computation and d a t a partitions.
rI'he processor gcomctry mapping is only required in psinv and fft3d applications
I~ecause only in these applications is the dimensionality of the processor geometry greater
than 1. The size of the cache plays a rriajor role in determining the processor geometry
mapping in order to improve cache affinity. as described in Chapter 4.
T h e impact of the size of tlie cache in tlie selection of d a t a partitions can be demon
s t rated using the p s inv application. Cising LG processors. the processor geometries selected
by the algor i thn~ t o enhance cache affinity are (16. 1). (I. 4). (8. 2) for the Hector. the
C'onves. and the IiSR 1 rriultiprocessors. respectively. The performance of the application
Cache size
S S
Ratio of remote to Iocal memory access
x S X .Y .Y 
Contention
.Y
.Y
.Y
X
Application
.I D I fft2d svd psi nv f t 3 d
(a) vpenta
( c ) tomcatv.
(b) mxm.
Figure 7.5: Comparing the performance of different data partitions rvit h the partitions derived by the CDP algorithm: Applications vpenta. m s m . tomcatv. and ADI.
o n the three n~oltiprocessors with L(i processors is summarized in Table 7.G. On the Conves
rrlultiprocessor. a (1. I) processor geometry is selected because of the large cache: the (I.
I) processor geometry minimizes remote memory access. In contrast. to improve the cache
affinity. a (8. 2) processor geometry is chosen on the KSR multiprocessor. in spite of a higher
remote memory access cost. as was discussed i n Chapter 4. .\ ( L6. 1) processor geometry is
chosen on the Hector multiprocessor. because of the very small cache size. to enhance cache
locality.
Figures 7.5 and 7.6 compare the speedups of benchmark applications when using the
cornputation and data partitions dcrivcd by the CDP algorithm with the speedups of the
benct~ mark applications rvhcn using several ot tier possible data partitions. For convenience.
the figures show this coniparison only on the Convex multiprocessor.
{a) fft2d. (b) svd.
( c ) psinv. (d ) fft3d.
Figure 7.6: Comparing the performance of different data partitions with tlie partitions derived by tlie CDP algorithm: .Ipplications fft2d. svd. psinv. and fft3d.
7.5 Compiler Performance
This section describes how the eight benchmark applications arc analyzed by the algori t h rn.
The t ime taken for each of the different phases and the criterion for choosing specific phases
of the algorithm for the specific applications are discussed.
7.5.1 DataComputation Affinity Phase
The esecution time and data partitions selected by the datacomputation affinity phase of
t lie algorithm are shown i n Table 7.7. The esecution time of the compiler is measured on
a SUX SPARCstation LO. it is clear that the time taken for the data computationaffinity
phase of the algorittln~ for all the benchmark applications is small (less than 40 mSec).
Table 7.7: ,\Icasurernents From datacomputation affinity phase.
Xppli cation
vpcnta
msm
tomcatv .I D 1 fft 2cl svd psinv fft3d
Processor Geometry
Dimensionality
Yumber of Array nodes
in the A L .I G
Sumber of Loop nodes
in the :I LAG
9 ( T )
Data partition for major arrays
The C'DP algorithm selected a one dimensional processor geometry for six of the eight
benchmark applications. Only psinv and f f t3d require a processor geometry dimensionai
ity of 2. because there are tno levels of paraltelism that can be esptoited i n each loop nest
i n these applications. .Uthough there are tlvo levels of parallelisn~ in the mxm application. a
one dimensional processor geometry was selected to avoid cache line false sharing.
The number of dimensions of the arrays that are selected for partitioning in the .lL.lG
is a subset of all the dimensions of the arra>.s in the program. For example. in the vpenta
application. though there are two 3clin~ensional arrays and seven 2dimensional arrays.
resulting i n 20 possible dirncnsions that must be considered. only 9 of these array dimensions
hrrn array dinlension nodes i n the .\L.lC;. Similarly. man!, of the array dimensions in other
applications are also not considered. This filtering is possible because of datacomputation
affinity. rsing datacomputation affinity. we have selected the potentially distributable
dimensions of the array baed on the array subscript espression(s) and the parallelism in
the program. Thus. the number of data partitions that must be considered is minimized.
The number of loop nodes in the .4L.!G for each application is shown in the table.
Although all the parallel loops in the program become loop nodes in the .\L.\C;. only a
ski bset of t hesc nodes are assigned processor dimensions: hence. the corresponding parallel
loop lvill be esectlted i n parallel: all other loops are executed sequentially.3 For esample.
"'The number of parallel Loop nrjdes that arc cassigned a processor geometry dimension is shown in the pcuent hesis.
in the p s inv application. only two of the three loops are selected for parallel esecution.
and only these t ~ o loops have to he mapped onto the processor geometry. Thus. the
number of compu tation partitions that must be considered for processor geometry mapping
is minimized.
The da ta partitions derived by the datacomputation affinity phase for major arrays i n
the applications are also shonn in Table 7.7. The partitioning attribute for all the array
dimension nodes and loop nodes in all the applications except svd is Block. Load balancing
and locality considerations in svd force a BlockCyclicRBlockCyclic partitioning for the
array dimension and loop nodes in the AL.1G.
[n four out of the eight applications (vpenta. mxm. tomcatv. and psinv). the data
computation affinity phase derives static data and computation partitions for the program.
I n three of these four applications (ie.. all but psinv) . the selected processor geometry is
linear. and only one dimension of the arrays is partitioned. Thus. these applications do not
require any further analysis.
In lour of the eight applications ( ADI. f f t2d . svd. and f f t 3 d ) . dynamic da ta partitioning
may be beneficial. because some of the arrays in these applications do not have a oneto
one mappinq between the distributed array dimensions and the dimension of the processor
geometry.
Thus. only a subset of the applications require machinedependent analysis. Indeed.
in all applications. only 6 o u t of 3.3 a r r a y and 30 out of 54 loop nests are considered for
dynamic arraJ partitioning. and 4 arraFs and 4 loop nests are considered for processor
geometry mapping. In cases ivhere static data partitions are possible. the C'DP algorit hrn
clerives these partitions using just the datacomputation affinity phase.
) I
r 9.2 Dynamic Array Partition Phase
The Hector multiprocessor is chosen to be a representative platform to illustrate com
pilation analysis for the selection of dynamic array partitions. Only the arrays that may
benefit from dynamic partitioning are considered in the reevaluation for the dynamic array
partition selection. The esecution time and the number of data partitions analyzed by
this phase of the corn piler for the four applications are shown in Table 7.3. The execution
time and the number of nodes searched are comparable for the other two multiprocessor
Table 7.8: ,CIeasurernents from dynamic array partition phase.
I Number of 1 Sumber of 1 .\;umber 1 TotaI I Number of I( .Ipplication 1 Time I arrays I loops 1 of I combination I nodes 11
Table 7.9: h[easuremeri ts from processor geometr? mapping phase.
AD1 fft2d svd fft:fd
platfornis.
I n ail four applications. the time required for the selection of appropriate data partitions
is sniall ( a maximum of about 5 seconds). The CDP algorithm minimizes the time required
by ( i ) minimizing the number of arrays reevaluated. ( i i ) minimizing the number of loops
to be analyzed. and (iii) using pruning to limit the search space.
The number of arrays that are considered for reevaluation for dynamic array partition
selection is a subset of the arrays i n the application. For example. i n the f f t 2 d application.
only one of tlie ttvo arrays is reevaluated. In contrast. in the AD1 application. all of the
three arrays i n the application require reevaluation.
Only tlie loop nests in tvhich tlie array is accessed are considered in the reevaluation
process. For esample. in the svd application. only L:l of the 16 loop nests are considered.
The remaining three loop nests in this application do not have a reference to the array that
is being reevaluated.
The depthfirst search ~ v i t h pruning in the CDP algorithm determines a solution by
evaluating only a small subset of the search space. For esarnple. the search space that must
be considered for the svd application is (IL3 = 67108P6L). Ho~vever. the CDP algorithm
orlly considers 210 nodes.
(mS) 271
5161 197.5 504
7.5.3 Processor Geometry Mapping Phase
P s i n v and f f t 3d are the two applications in which the selected processor geometry
reevaiuated 3 o u t o f . 3 I o u t o f  1 1 out of 7 1 ou t of 2
%umber of loops analyzed
1 3
  Time
(mS) 179 177
.ipplication
psinv fft3d
analyzed LI
9 13 3
Sum ber of processor geometry choices (16 procs.)
.5 5
partitions 4 1 L L 6
of choices 3'1024 262 144
67 10886.1 4096
searched 116
1.391 24 0 16
Y
Table 7.10: Features of the algorithm applications exercise.
is greater than 1. and t h u s require a selection of an appropriate processor geometry, The
C'DP algorithm selects a processor neometry for the entire program by analyzing the possible
geometry choices. On a 16processor machine. tvith two dimensional processor geometry.
five processor geometry choices are evaluated. The execution time for processor geometry
selection and the number of processor %eornetry choices are shown in Table 7.9.
w C
( .a.4 Comments on the Characteristics of Applications
Salient feature Effectiveness in a simple appiication RepIication of arrays
it 1 I 1
Each of r h e eight applications exercises a different feature of the CDP algorithm. as
illustrated in Table 7.10. The vpenta application illustrates the effectiveness of the CDP
algorithm on a simple application in deriving static data partitions. The mxm application
illustrates the c~ase in i~ehich the algorithm replicates an array LO enhance performance.
Although the CDP slgorithni tries to avoid partitioning the cache line dimension. i n the
tomcatv application the cache line dimension is partitioned to exploit cache affinity across
loop nests.
The A D 1 application is an esample of an application that requires dynamic arrav parti
tion selection. The computation and da ta partitions selected across the three multiproces
sors are different because of the machine characteristics. The compromise d a t a partition
is selected on the Hector multiprocessor because of the high penalty for contended access
and the high cost of synchronization. .A d a t a partition with pipelined con1 pu tation parti
tioning is selected on the Conves multiprocessor because of its large cache and the low cost
of synchronization. Repartitioning is selected on the KSR L multiprocessor because of the
high cost of remote memory access. Fft2d also requires dynamic array partition selection.
In contrast t o the A D 1 application. the d a t a partitions selected for the f f t 2 d application
across the three multiprocessors are the same. and require repartitioning of the arravs.
Application vpenta msm
I I I I 1
tomcatv I Cache line dimension partitioning .I D 1 / Reevaluation. Different data partitions on machines fft2d 1 Reevaluation. Same data partitions on machines svd psinv fftM
Load balancing Cache affinity, processor geometry selection Reevaluat ion. processor geometry select ion
Table 7.1 1 : Bisby. Kremer. and Kennedy's approach.
Application I
vpenta mxm torncatv :ID1 fft'ld svd psinv fft3d
Xumber of variables
230.5 170
19.10 175 480
9840 1 3
49.5
Template rlirnensionali ty
The svd application illustrates the choice o f t he BlockCyclicRBlockCyclic distribution
attribute to balance the load among processors and to avoid false sharing. The p s i n v
application illustrates hotv the processor geometry mapping varies rvit h the size of the
cache on a multiprocessor. The fft3d application requires the selection of dynamic array
partitions and the processor geometry mapping. It is the only application that exercises all
the different phases of the CDP algorithm.
Candidate data partitions 16 processors
7.6 Comparison with Other Approaches
tn this section. the C'DP algorithm is compared to the 01 integer programming formulation
of Bisby et al. [.LO. 261 and to Anderson and Lams algebraic framework [19. :HI!. The
nietrics used to compare the different algorithms are the problem sizes evaluated at compile
tinle. anti the qualit of the solutions obtained.
The sizes of t h e 01 integer progranlniing problems that are sol\,ed for deriving data
partitions for the applications are shown i n Table 7.11. The number of program phases
(i.e.. one or more loop nests) here represents all the loop nests in the program. It must be
noted that the phases include all loop nests in the program. even if there are no parallel
loops i n a loop nest. For esample. in the mxm application. there are four loop nests. of
nhich trvo do not hate parallel loops. The template dimensionality and load balancing
requirements dictate the number of candidate data partitions that are evaluated.
I n the implementation of Bisby et al.. the time taken for executing a 2386~71.3 01
integer programming problem using CPLES [46]. a general purpose integer program solver.
is measured to be an average 3.8 seconds. However. some 0 I integer programming problems
took longer than I hours PO]. The CDP algorithm partitions the applications depending on
their characteristics. So. for applications like vpenta. mxm and tomcatv. the CDP algorithm
can derive computation and data partitions merely by analyzing datacomputation affinity.
without evaluating all possible data partition choices. This is in contrast to the approach of
Bisby et al.. which has to solve 01 integer programming problems in order to determine the
da ta partitions for these applications. In the four applications in which dvnamic partitions
are considered. the CDP algorithm determines a solution efficiently. and in a reasonable
time. using a pruned depthfirst search. Furthermore. in evaluating data partitions in the
presence of load imbalances. Bisby et al. consider only the C y c l i c and Block distribution
attributes. However. the CDP algorithm includes several additional distribution attributes
to balance the load i n tttc application.
Anderson and Lam use profiling to limit the search space of data and computation par
titions. The size of the search space analyzed to determine data and computation partitions
is shown in Table 7.12. In the applications shown. we determined the frequently esecuted
loops by analyzing the applications manually. The search space comprises data and compu
tation partitions selected for each loop nest individuallg, as well as possi bIe changes to these
partitions. It must be noted that the number of data and computation partitions analyzed
is very small. Hence. this technique has a better compile time performance than the CDP
algorithm. However. this technique only determines the dimension of the array that is to
be partitioned. Heuristics are used to select a data partitioning attribute. Issues of Load
balancing. determining blocksize for BlockCyclic distribution attribute. and determining
the processor geonletrj. to partition data and computation are riot addressed. In contrast.
o u r C'DP algorithm determines data and computation partitions, including the block sizes
for the BlockCyclic distribution attributes and the processor geornetr). mapping that will
rnasimize cache affinity in the program.
.\lthough the algebraic approach has a better compile time performance than the CDP
algorithm. the quality of solutions obtained by this approach may not be as good. The
algebraic approach is dependent o n the profiling information to determine the frequently
executed loop nests. Depending on which loop nest is analyzed first. data partitions de
rived by the algebraic approach ma: be different. For example. i n the A D 1 application.
the data partition selected for the program could be (t.~lock{l)) or (~lock(1). * ) (with
pipelined esecution of some loop nests), depending on tile starting loop nest. The esecution
Table 7.12: .Anderson and Lam's approach.
11 Application I Search space j Search space j/
I I msrn I tomcatv I
i I
Table 713: Quality of solutions obtained by Anderson and Lam's algebraic solution on the
vpenta
time for the A D 1 application. using these data partitions. is presented in Table 713. The
( *. ~lock{l)) data partition i s i t h pipelining perf~rms 3 1% better than the (~lock(1). * )
data partition. This is due to the overhead involved in partitioning the cache line dimen
sionm4 I n contrast. our CDP algorithm distinguishes the cache line dimension and avoids
partitioning the cache line dimension. Hence. the application performance is improved
significantly by using the CDP algorithm.
The algebraic approach favours a dynamic partition even tvhen a static data partition
ivith conlnlunicatior~ can result in better performance because of shared memory effects.
This case is illustrated by the fft3d application. Data partitions tvith repartitioning is
the only choice offered by the algebraic approach. However. a static data partition would
improve the performance of the application by IS%. as shown in Table 7.L3. The CDP al
gorithm determines that the static solution is better when it evaluates the possible dynamic
(Data part i t ions) I (Computation partitions) 3 I T L o
Hector multiprocessor.
"Additional data transformations are applied by the algebraic approach to avoid partitioning the cache line dimension.
Slowdot\*n 1.3 1
L 4s
Application .'L D 1
! Proc. Geom = ( I . L6) 1 I Z(*.*.BIock{l})/ 1 SL.12.imSec ;
t I Pipelining
fft3d I Zi *. ~lock{l}. 81ock{2)) I 61.345 mSec
Data Partitions 1 Esecu tion t ime (* . Block{l))/ 1 4T .Z fE mSec
Pipelining (Block{ I). * I / 63.0.55 mSec
array partitioning choices.
7.7 Summary
[n this chapter. the performance of a s u i t e of eight bencf~mark applications using the parti
tions derived by the C'DP algorithm on three different multiprocessors was analyzed. Our
results show tha t the computation and da t a partitions derived by the CDP algorithm im
prove the performance of the benchmark applications. compared to the reliance on the
native operating system page placement poiicies for d a t a management. CL'e have presented
empirical evidence tha t the CDP algorit hrn is efficient and effective in deriving corn pu tation
and d a t a partitions for applications. CVe have found that datacomputation affinity rela
t.ionships are r~seftll abstractions in effectively derivins computat ion and d a t a partitions.
Lsing the datacomputation affinity relationships. t he CDP algorithm effectively classifies
the applications into two categories: ( i ) applications where ail arrays require s tat ic parti
tions. and ( i i ) applications where some arrays require dynamic partitions. CCe have also
shown tha t t he CDP algorithm can obtain solutions of bet ter quality than other techniques
tha t a11 tomatically derive d a t a and computation partitions
CHAPTER 8
Conclusion
I n this thesis. we have shown that computation and data partitions are effective in enhancing
data locality in regular (i.e.. densematris) scientific applications on SS4IMs. !Ve have
described a new and efficient algorithm. called CDP. to automatically derive computation
and data partitions on SSLISIs. \Ve have presented esperimental evidence that indicates
shared memory effects. such as cache affinity. memory contention. synchronization overhead.
and false sharing. must be taken into account. in addition to remote memory accesses. in
deriving data and computation partitions on SSh[l[s.
The CDP algorithm described i n this thesis derives computation and data partitions i n
three main phases: ( i ) establishing datacomputation affinit~.. (ii) deriving dynamic data
partitions. and (iii) determining the virtual processor geometry and mapping it onto phrsical
processors. The problem of deriving computation and data partitions is con~putationally
hard. Dividing the solution to the problem into phases resulted i n a relatively efficient
algorithm. T hc first phase determines affinity relationships and uses them to select initial
cornputation and data partitions. using asirnple iterative technique. These initial partitions
arc the final partitions for many applications. for which it is sufFicicnt to partition data
statically on a linear array of processors. In the second phase. only the subset of the arrays
that \vill potentially benefit from dynamic repartitioning are considered for further analysis.
In this phase. a paran~eterized cost model of the target nlultiprocessor is used to evaluate the
effcctivcness of the candidate partitioning choices. Finaliy. in the third phase. the number
of processors it1 each dirncnsion of the virtual processor geometry is determined.
The CDP algorithm iv~as implemented as a part of the Jasmine compiler prototype at
the Lhiv~rsity of Toronto. Our esperimcnts demonstrate that the parallel performance of
a suite of' benchmarks on three muitiprocessor platforms using derived data and computa
tiori partitions compares favourably to the performance of the applications using operating
system policies. Indeed. t h e performance of the application is improved. on an average by
a factor of 2.1.3 on the Hector multiprocessor. 1.9 L on the Conves multiprocessor. and '2.04
on the KSR 1 multiprocessor.
8.1 Contributions
This thesis made two main contributions:
a Eflectirenc.r;.l; of computation and data partitions on SS,\l.\ls
\Ye have shown that partitioning of both computation and data significantly enhances
tlle performance of applications on SSh,IbIs. \lie have also shown that the selection
of data and computation partitions on SShIXls is not only dependent on the cost of
remote memory accesses. but is also influenced by shared memory effects such as cache
affinity. memory contention. synchronization. and false sharing.
I n this thesis. ne have described the C'DP algorithm for efficiently deriving data and
coniputation partitions that take into account the shared memory effects o n SSl I l l s .
Esperirriental e\aluation of tl~c CDP algorithni on three SS.\I.\Is demonstrates the
effectivcness of derived partitions in improving the performance of a suite of bcnch
mark applications. both when compared to the reliance on the native operating svsterrl
for data management. and ~vhen compared to the use of data partitions derived by
algorithms for distributed nleniory multiprocessors.
8.2 Directions for Future Research
T h i s ~vork car1 be esterided in a number of ways.
8.2.1 Interprocedural Analysis
T l ~ e current implerneritation of the CDP algorithm analyzes programs t\*ithin procedural
boundaries. Ilence. the in~plernentation requires all the procedures in the program to be
irllined. 1Iowevcr. wit 11 largc applications. inlining is expensive. or even infeasible. How the
information from interprocedural analysis should be accounted for in the datacomputation
aRinity relationships remains an open problem.
8.2.2 Dynamic Processor Geometries
The CDP aigorithni derives a fixed processor geometry for the entire program. In some
programs. it may be desirable t o alter the processor geometry between loop nests. Deter
mining the processor geometries for the individual loop nests and the cost of repartitioning
(because of change in processor geometry) betiyeen the loop nests is another optimization
problem for which integer programming o r heuristics can be utilized. Analysis on large
programs and problem sizes is required t o determine the extent of benefits produced by
dynamic changes in processor geometry.
8.2.3 Performance Estimation
The cost estimation heuristic will be accurate only when the number of iterations of loops
and the size of arrays can be determined a t compile time. However. in the absence of
compile time information. default values are used by the prototype implementation. Like
HPF compilers. the CDP algorithm and its prototype implementation require that the
number of processors executing the application be knoivn a t compile time. In the absence
of such inforniatiori a t con~pile time. threshold values can be used to determine a small set
of d a t a partitions, one of n.hict1 can be selected a t runtime. Further studies are required
to analyze the benefit of such an approach.
8.2.4 Hybrid Multiprocessor Systems
The author envisions that largescale systems will be built in the future by amalgamating
distributed memory multiprocessor and SSX11,I technologies. Several SSL,Il,Is will be con
ncctecl together with an intercon~iection network to form a large scale multiprocessor with
scvcral hundred processors. Esploiting parallelism on these macliines will require not only
d a t a partitioning tcchr~iqucs designed for distributed memory multiprocessors but also t be
SSAIlI specific con1 pilation tcchniqiies. The applicability and extensibility of t hc CDP al
gorithm for determining d a t a and computation partitions on such hybrid machines requires
further investigation.
Bibliography
[ I ] Daniel Lenoski. dames Landon. liourosh C; harachorloo. Cl'olfDiet rich ii'eber. .\noop Gupta. John Hennesy. lIark Horowitz. and hlonica Lam. The Stanford DISH blulti processor. lEEE Computer. 2.5(:3):6379. llarch 199'2.
[2] Jeffrey liuskin. David Ofelt. Slark Hein rich. John Heinlein. Richard Simoni. Iiourosh C: harachorloo. John C'hapin. David Yakahira. Joel Baster. hlark Horowitz, Anoop Gupta. hlendel Rosenblum. and .John Hennessy. The Stan ford FL4SH llultiprocessor. In Proceedings of the 2lst .lnnunl International Synrposium on Computer .lrrhitecture. pages 302313. April 1994. http:,//tvww flash.stanford.edu/architecture/papers/ISC=\9l.
[3] Zvonko ltanesic. lIichael Stumm. David Lewis. and Ron iyhite. The Hector ~Iultiprocessor. lEEE C'ornputer. ( ) :  . .January 1991. It p://ftp.cs.toronto.edu/pu b/parallel/l'ranesicetaUEEEC.ps.2.
[I] Zvon ko \ranesic. Stephen Brown. LIichael Stumm. Steven Caranci. Ales Grbic. Robin Grindley. LIitch Cusat. Orran tirieger. G u y Lemieus. Kevin Loveless. Naraig hlan jikian. Zeljko Zilic. Tarek A bdelrahman. Benjamin Gamsa. Peter Pereira. lien net h Sevcik. A. Elkateeb. and Sinisa Srbljic. The SL11.!chine ?Ilultiprocessor. Technical Report CSRI3'14. Computer Systems Research Institute. L'ni~senity of Toronto. 199.5. l~ttp://iv~vrv.eecg.toronto.edu/parallel/numachin.flat~numachin.html.
[5] liendall Square Research. KSR 1 Principks of Operation. \l'aalt ham. 11.4. 199 1.
[6] Conves Cornpu ter C'orporation. Concex Exemplar System Ocerric u.. Richardson. T S . C3.A. 1994.
[7] Silicon Graphics Inc. The SGI Origin 20000. llountain Liew. C.4. L996.
[S] Bill Blu me. Rudolf Eigenman n. lieit h Faigin. John Grout. .Jay Hoeflinger. David Padua. Paul Petersen. Bill Pottenger. Lawrence Rauchwerger. Peng Tu. and Stephen \Vest herford. Polaris: Improving the effectiveness of parallelizing compilers. I n Keshav Pingali et al.. editors. Languages and Compilers for Parallel Computing. pages 14 11.54. Springer\erlag. 1994. ht t p://wiv~v.csrd.uiuc.edu/report/ l 3 . p s . g ~ .
[9] Saman :\marasinghe. Jennifer Anderson. llonica Lam. and Amy Lim.  I n overview of a compiler for scalable parallel machines. In I'tpal Banerjee et al.. editors. Lan guages and Compilers jor Parallel Computing. pages 253272. SpringerVerlag. 1993. ht tp://suif.stanford.edu/papers/aall93.p~.
Iiuck and .Associates. The h.1 P Preprocessor. 199.5.
IBkI Corporation. .iL Fortran Cbmpiler Reference .Ilanual. 1997.
Richard LaRowe .Jr.. James \Vilkes. and Carla Ellis. Esploiting Operating System Support for Dynamic Page Placement on a SC.C[.A Shared LIemory .LIultiprocessor. In Principles and Prrlct ices of Parallel Programming. pages 122 13'2. 199 1.
Tarek Abdelrahman and Thomas Wong. Distributed array d a t a management on ?iU4IX muf tiprocessors. In Proceedings of the Scalable HighPerformance Comp?r+in,n Confer ence. pages 5.5 1559. 1991. ht t p://www.eecg.toronto.edu/ tsa/shpccW.ps.
Sudarsar~ Tandri and Tarek .Ibdelrahman. Computation and da ta partition ing on scalable shared memory multiprocessors. In Proceedings of Pamllel and Distributed Processing Techniques and .lpplications. pages 4 150, 199.5. http://www.eecg.toronto.edu/ tsa/jasmine/pdpta95.ps.
Seenla Hiranandani. Ken Kennedy. and ChauWen Tseng. Evaluating compiler opti mizations for Fortran D. .Journal of Pamllel and Distributed Compuiing, 'Ll(1):2iIS. April 1994. htt p://suif.stanford.edu/' tseng/papers/jpdc94.psS
Charles lioelbel. David Loveman. Robert Schreiber. Guy Steefe J r.. and lLIary Zosel. The High P~rforrnance Fortran flandboob. The SIIT Press. Cambridge. ~Iassachusetts . 1994. http://~v~v~vmitpress.mit.edu/mitp/recentbooks/comp/highperf.html.
Tarck S. r\bdeIrahrnan. Saraig Manjikian. and Sudarsan Tandri. The .Jasmine Com piler. t~ttp://ww~v.eecg.toronto.edu/'tsa/jasmine.
.\[ary .\ [ace. .\[emery storage patterns in parallel processing. Iiluner Academic Publish ers. 19S7.
.Jennifer Anderson and SIonica Lam. Global optimizations for parallelism and locai ity on scalable parallel machines. In Proceedings of the .LC.tI SIGPL.4.V C o n f m n c f on Progmmminy Language Design nnd Impl~nz~ntation. pages 1 12 125. June 1993. tit t p://suif.stanford .edu/papers/anderson93.ps.
I'lricti Krerner. .tutornatic data layout for distributed memory machines. PhD thesis. Department of Computer Science. Rice University. 1995. h t t p://at hosru tgers.ed u/ uli/CRPCTR955.59S.ps.gz.
SIanish Gupta and Prit hviraj Banerjee. Automatic d a t a partitioning on distributed memory multiprocessors. IEEE Transactions on Pamlkl and Distributed Systems. :I(?) : 179 l!X3. l larch 1992.
llanish Gupta . .l etonratic data partitioning on distributed memory multiprocessors. Ph D thesis. Department of Computer Science. University of Illiniois a t Crbana Champaign. 1992. ftp://Ft p.crhc.uiuc.edu/pu b/Paradigm/phdg'L.g.ps.Z.
Constantine Polgchronopolis. !vIilind Girkar. hlotiammed Haghighat. Ctiia Lee. Bruce Lcung. and Dale Sctiouten. The structure of Parafrase2: an advanced parallelizing compiler for C and Fortran. In David Gelernter e t al.. editors. Languages and Compilers for Pnm[lel Computing. pages 123453. Pitman. London. 1990.
.Jingke Li and Marina Chen. Synthesis of explicit communication from sharedmemory program references. I n Procdings of Supercomputing. pages 86.5876. Xovem ber 1990.
.Jingke Li and Marina Chen. Indes domain alignment: 1Iinimizing cost of cross reFerencing between distributed arrays. [n Frontiers of .C(assic~ly Parallel Computation Proceedings. pages 1'2443.3. 1990.
Robert Bisby. Iien Kennedy. and Vlrich krerner. Automatic data layout ns ing 0 1 integer program ming. In Procredings o/ the International Con ferencc on Pnmflel .trrhittctures and C'ompilntion Techniques. pages 111122. August 1994. gopher://rv~v~v.cs.rice.edu/1)9/soFtlib/CRPCTRs/reports/CRPCTR93349S.ps.
l i en Kennedy and Llrich Iirerner. Automatic data layout for High Per formance Fort ran. In Prnre~r1ing.s 0 Supercompr~t ing. Decern ber 1995. http:/ /at hos.rutgers.edu/uli/SCS.'j.ps.
Daniel Palermo and Prithviraj Banerjee. Automatic selection of dynamic data parti tioning schemes for distri butedmemory multicomputers. I n Proceedings of 8th Hork shop on Languages and Compilers for Parallel Computing. pages 392406, 199.5.
.Jodi Garcia. Eduard Ayguade. and Jesus Labarta. 4 novel approach towards au tomatic data distribution. In P r o c ~ ~ d i n g s of the TC,hrk.shop on .4utomatic Data Lay out nnd Perfomnnce Pr~dictiori. :\pril 1995. ftp://softlib.rice.edu/softlib/CRPC T Rs/reports/C'RPC1).5.5LIY.p~.
Jennifer Anderson. Saman .lmarasinghe. and llonica Lam. Data and computation transformations for multiprocessors. In Proceedings of 5th .l C1i SIG'PL.4 .C' Sympo sium on Principles and Practice o/ Parallel Progmmming. pages 166 178. J u1y 1995. ht t p://suif.stanford.edu/ sarnan/papers/anderson9.i/paper. ht mi.
Thomas Fahringcr. Roman Blasto. and Hans Zima. Automatic performance predic tion to support parallelization of Fortran programs for massively parallel systems. In Proc~~ding.5 of International Con ferenre on Supercomputing. pages U;:Ji6. duly 1992.
Iiarim HarzaIlah and Ken net h Setecik. Hot spot analysis in large scale shared memory n~ultiprocessors. I n Proceedings of Supercomputing. pages $9.5905. Xovem ber 1993.
Seema Hiranandani. Ken Kennedy. and ChauLVen Tseng. Compiling Fortran D for hII\ID distributedmemory machines. S'omrnunications o/ the 4C.V. :35(8):66$0. Au gust 1992. http://suif.stanford.edu/ ' tseng/papers/cacm92.ps.
Chau\L7en Tseng. Compiler optimizations for eliminating barrier synchronization. In Procf~dings of 5th 4 C.Ii SIC PL.4 .\i* Symposium on Principks and Pmct ice of Parallel Programming. pages 144 155. J uly 199.5.
Robert \Visnieivski. Leonidas Kontothanassis. and Xlichael Scott. High performance synchronization algorithms for multiprogrammed multiprocessors. In Proceedings of the 5th .I C.11 Symposium on Principles and Practice of Pa rollel Programming. pages 190206. July 199.5. ft p://Ftp.cs.rochester.edu/pub/u/kt hanasi/!Tj.PPoPP. IEiehperfsvncal~orit t~n~s_formultiprogrammedmultiprocessors.ps.gz.
tt'iliiam Bolosky. .L[ichael Scott. Robert Fitzgerald. Robert FowIer, and Alan Cox. NL?/I.\ policies and their relation to memory architecture. In Proceedings of 4th Inter national Cbn ference on .\ rchitect urn1 Support for Programming Languages and Oper ating Sgstems. pages 2 1222 1. April 109 1.
Clrich Iiremer. Automatic data layout for distributedmemory multiprocessors. Tech nical report.. Center for Research on Parallel Computation. Rice Vniversity. February 1 XL3.
Ctpal Banerjee. Loop Transformations /or Restructuring Compilers. Kluwer Academic PII blishers. 1993.
Alfred .I ho. Ravi Set hi. and .Jeffery Clirnan. Compilers Principl~s. Techniques and Tools. AddisonCVesley. Reading. L[assachusetts. 1986.
David Bacon. Susan Graham. and Oliver Sharp. Corn piler transformations for high performance computing. .I C.ll C'omputing Surreys. pages 34.5420. December 1994. I~trp://~vw~v.acm.org:R'L/pu bs/toc/.\bstracts/03600300/ 197406.html.
L'asant h Balasundaram, Geoffre_v Fox. Ken Kennedy. and Ulrich Iiremer. .\ static performance estimator to guide data partitioning decisions. In Proceedings of 3rd ..IC.11 SiCPL.4 .\+ Symposium on Principles and Pmctice of Pamilel Programming. pages 2 13 223. .April 1991.
Ilpesh Amin. Overhead of synchronization on conves exemplar. Personal Communi cations. 199.5.
Paul Havlak and lien Kennedy. An [mplernentation of Interproced ural Bounded Regu lar Section .ina1~sis. l E E E Trnnsactions on Parail~f and Distributed Systems. .'(3)::350 360. .J 11 I! 199 1 .
Benjamin Gamsa. RegionOriented lIain 1Lemory 1Ianagement in Shared.\.Iemory S C7.\[\ Slultiproccssow. 1Iaster's thesis. Department of Computer Science. Cniver sit? of Toronto. September 1992.
Hui L i and Kenneth Sevcik. ?;Lll=\C'ROS: Data parallel programming on SCllA mul ti processors. I n Proce~ding.5 of i l h Symposium on Erp~rienc~.? with Distributed and ,1lultiprocessor Sy.5t~rn.s. pages 2472fi3. 1993.
CPLES Optimization. Inc. C'PLES JIired Integer Solcer. Incline \.*illage. NL. 1997.
APPENDIX .A
Implementing Data Partitions on SSMMs
This appendix outlines a technique to implement da ta partitions on SSh[,LIs. This technique
is utilized by the .Jasmine compiler to map distributed array da ta onto mernor.. modules.
On a sequential machine. accessing an array element requires the base address of the
array and an offset from the base to the data element. Thus. a multidimensional array is
stored as a contiguous linear segment with one base address. The offsets are computed based
on array indices a t run time using compilergenerated espressions. This typical technique
of accessing the array element w i t h a base and an offset is illustrated in Figure A.l(a).
Data partitions are implemented on a SSlISI using multiple base addresses. This pro
ririces severat seqments of the array: the base address of each segment is assigned to a
processor according to the partitioning of data. 411 tho segments accessed by a processor
are grouped toqether and mapped onto pases t h a t tvill be allocated in t h e local memory of
the processor. This is depicted in Figure 4.1 ( 6 ) . The array indes functions for the different
dimensions of the array are split into two sets: one set contributes to the base address and
the other set is used to compute the offset from the base.
i n general. the number of dimensions that contribute to defining the base address of
an array can be reduced by adding more dimensions to the offset calculation. CVhen all
the dimensions are used to calculate the offset. this technique becomes the tjpica1 array
indexing strategy used on sequential machines.
In our implementation, all dimensions escept the cache line dimension are used to define
the base address. The cache line dimension is used to compute the offset in each segment
of the array. The partitioning of the data in the shared address space is realized bv the
allocation of the segments in the memory modules based on the distribution attributes.
Some da t a partitions do indeed partition the cache line dimension, and these data parti
double aW][N] double* a[N] /I P PROCESSORS
foralli= I toN (Cyclic) forall i = 1 to N (Cycl ic)
forj = I to N
. . . ahI I[iI I
base = address( a ) base = address(alj I ]
offset = [(jI )*N + t i 1 ) I offset = [i1 1
Page Page
(a ) Openting System tb ) Explicit
Figure A.1: Data management i n SS.LI.LI.
t,ions are implemented using one of the following two techniques. First. data transformations
such as array transpose are applied so that the transformed array is partitioned along a di
mension other than the cache line dimension. However. data transformations do not suffice
when ail dimensions of a n a r r a y are partitioned. In s u c h cases. the array is redefined to
Ilave one additional dimension. by converting the cache line dimension of the array into the
last two dimensions of the redefined array. The last dimension of the redefined array is
chosen to be at least the size of a cache Iine. 411 dimensions except the last dimension of
the redefi ned arra? are partitioned.
On the KSR 1 machine. the partitioning of da ta takes on a slightly different meaning.
because there is no fised home location for array elements. In this case. data transforma
tions are used to partition the array. All the partitioned dimensions are moved to higher
dimensions of the array. using dimension permutation operations such as transpose. to
ensure that data accessed by a processor are allocated contiguousiy.
Data partitions obtained using manytoone. onetomany. and manytomany mappings
of array clitrlensions to processor geometry dimensions cannot be implemented on the IiSRI
mu1 ti processor. because data is always copied into the local cache of the processor accessing
the data. r\utornatic copying of data by the hardivare makes it impossible to fis the location
of data. ~vllicl~ is nccessar!. to implement the manytoone. onetomany. and manyto
rriatly mappings of a r r q dirncnsions to processor gconletry dimensions. .\ccordingly. it
is possible to irnplernent only the onetoone mapping of array din~ensions to processor
geometry climensions on the KSR 1.
Data repartitioning of an array in the program represents the presence of different data
partitions of the array. A copy of the array is created for each of the data partitions.
Only orlc copy of the a r r a y is valid at any instance in the program. Data repartitioning
entails copying the array from one data partition representation to anottier data partition
representation.
APPENDIX B
Training Set Kernels
This appendix describes the training set kernels that Lve used to estimate the program
dependent parameters described in Chapter 6. The kernel loop nests For estimating the
memory contention factor. cost of synchronization. and the O C P factor are presented here.
B.l The Memory Contention Factor
The kernel For estimating the memory contention factor is shown below: it consists of two
loop nests. In the first loop nest. all the processors access array elements that are assigned
to processor #1. Ilernory contention results because all processors access data assigned to
a single mernor>* module. I n the second loop nest. all the processors access array elements
that are assigned to different processors. The contention factor is t h e ratio of the execution
time of the first loop nest and the esecution time of the second loop nest. .A 2clin~ensional
array of size .i 12x5 12 is used so that the number of array elements accessed is large enough
to reduce the errors due to tinlin?.
/ / PROCS is t h e maximum number of processors i n t h e system / / myPid is my processor i d which ranges from O..PRCCS1 / / fromProc is t h e processor t h a t will be contended f o r
/ / DoBlock is a macro t h a t takes t h e loop i t e r a t o r , start, end and /I' t h e processor i d o f t h e i t e r a t i o n s t h a t the cu r ren t processor / / must execute.
/ / EndBlock is a macro f o r barrier synchronizat ion
start = TIME() DoBlock(i, 1 , 512, fromProc)
f o r a l l j = 1 , 512 C ( j , i) = B ( j , i) + ~ ( j , i )
end f o r EndBlock end = TIME0
tl = end  start
/ / c l u s t e r  s i z e is the number of processors i n a c l u s t e r t h a t share / / the same memory module / / myNewPid is t h e remote processors d a t a t ha t myPid processor w i l l access
start = TIME0 DoBlock(i, 1 , 512, r n y ~ e u ~ i d )
f o r a l l j = 1 , 512 C ( j , i ) = B ( j , i) + A ( j , i)
end f o r EndBlock end = TIME0
t 2 = end  start
content ionf a c t o r = t 1/t2
B.2 The Cost of Synchronization
The kernel for estimating the cost of synchronization is s h o ~ n below: i t also consists of two
loop nests. The cost of synchronization is measured by timing two loops that are esecuted
i n a pipelined manner. The barrier synchronization operations are present in the first loop
nest. b u t are removed in the second loop nest.
/ / For given PROCS, t h i s kernel es t imates t h e cos t of synchronizat ion
// Pipelined computation is used here because that's the // synchronization that we want to measure start = TIME0 for s = 1, 512+PROCS
curstart = max(s  512, 1) curend = min(s, PROCS) for r = curstart, curend
j = s  r ; if (r1 .eq. myPid) then
for i = (rl)*NP+l, r*NP C(j, i) = B(j, i) + A(j, i)
end for end if
end for BARRIER SYNCHRONIZATION^)
end for end = TIME0
t1 = end  start
start = TIME0 for s = 1, 512+PROCS
curstart = max(s  512, 1) curend = rnincs, 512) for r = curstart, curend
j = s  r ; if (r1 .eq. myPid) then
for i = (rl)*NP+I, r*NP C(j, i) = B(j, i) + A ( J , i)
end for end if
end for end for end = TIME0
t2 = end  start
Costof synchronization = (tl  t2) / (512+~R0CS)
B.3 The OCP Factor
The kernel for estimating the overhead for partitioning the cache line dimension (OCP
/actor) is sliown below: it too consists of two loop nests. This kernel is executed on a
single processor to eliminate the overheads due to contention and synchronization. In the
first loop nest. the arrays in which the cache line dimension is partitioned are accessed.
Subsequently. in the second loop nest. the arrays in which the cache line dimension is not
partitioned are accessed. The OCP factor is the ratio of the esecution time of the first loop
nest and the esecution t ime of the second loop nest.
/ / PROCS = 1
start = TIME0 Do,Block(i, 1, 512, myPid)
forall j = 1, 512 F ( i , j ) = E ( i , j) + D(i, j)
end for EndBlock end = TIME() tl = end  start
start = TIME() Do,Block(i, 1, 512, rnyPid)
forall j = 1, 512 C(j, i) = B(J, i) + A ( j , i)
end for EndBlock end = TIME0 t2 = end  start
IMAGE EVALUATION TEST TARGET (QA3)
APPLIED 1 IMAGE. lnc 1653 East Main Street  .
,  Rochester. NY 14609 USA     Phone: 71614820300 7    Fax: 71 6/2885989