Program Transformations in the POLCA Project

Transcription

1 Program Transormations in the POLCA Project Jan Kuper 1, Lutz Schubert 2, Kilian Kemp 2, Colin Glass 3, Daniel Rubio Bonilla 3, and Manuel Carro 4 1 University o Twente, Enschede, The Netherlands 2 Ulm University, Ulm, Germany 3 High Perormance Computing Center, Stuttgart, Germany 4 Imdea Sotware Institute, Madrid, Spain Abstract The POLCA project develops annotations on ragments o imperative code to guide program transormations or better utilization o resources. These annotations express the computational essence o the code ragments without reerring to memory usage or execution time. That makes the annotations mathematical in nature such that provably correct transormations can be applied to them and the corresponding code ragment can be transormed accordingly or more optimal resource usage, or example on a multi-core platorm or on an FPGA. Keywords: Program transormations, code partitioning, ormal methods, optimization. I. INTRODUCTION It is widely recognized that parallelism o applications plays an increasingly important role or application developers. However, writing an eicient parallel program is diicult and converting an exitsing iterative program into a parallelised version is is not as straight-orward as in particular the processor manuacturers would have us believe. In act, it is easy to write code which perormance declines once parallelised. The key actor that hampers perormance is thereby the data dependency between parallel threads: concurrent access to memory, in particular read-write dependencies, not only eectively serialises the code again, but also easily leads to lower perormance because o increasing data access times. Much eort is being invested into automating the parallelisation o code and into providing libraries and language extensions to support that. Yet, hardly any o them take the pattern o an algorithm into consideration, a pattern is rather seen as a sotware engineering recommendation than as a characterization o the code itsel. The POLCA project considers the repetitive pattern o an algorithm as a key concept or parallelisation and or improving perormance. This is o particular importance in the areas o High Perormance Computing (HPC) and Embedded Systems, where most applications eectively perorm strongly repetitive tasks on huge data sets or on massive streaming data. In this paper we use the term repetition structure or the regularity with which (a part o) an algorithm is executed multiple times over dierent sets o data. Such repetition structures may thereby take dierent orms, rom iterating over an array, to complex mathematical equations per (sub)set o data. Corresponding author: j.kuper@utwente.nl Repetition structures act over time and space, speciically (a) the data space over which the algorithm acts and (b) its iterations and processing over (simulated and actual) time. Typical examples are escience applications such as luid dynamics, where the algorithm acts over the 3-dimensional space o the luids and objects (expressed as data structures in memory) and the time or processing each iteration on the one hand and or simulating the low over time (ourth dimension) on the other hand. When the repetition structure is known, expert HPC sotware developers can try parallelising the algorithm by breaking up the dependencies and typically distributing the space-time dimension o the algorithm over the dierent processors in a ashion that the dependencies are minimised. Within this paper we will show that the repetition structure can not only explicitly expressed to make it visible or developers, but also that it can be exploited or applying transormation patterns that convert repetition structures into dierent parallel versions with dierent perormance. We exploit this act in the POLCA project to automate not only parallelisation, but also to exploit inrastructure heterogeneity, e.g. by adapting the code to vector platorms, exploiting intrinsics o GPUs or even FPGAs. In the project we develop a method that uses such inormation to partition an algorithm and express that in a datalow graph such that a good mapping can be ound on a given hardware platorm. This paper will explain the underlying mathematical basis, i.e. the repetition structures and how appropriate transormations can be identiied and applied. Related work.: In the POLCA project the mathematical characterization and their transormations o repetition structures in algorithms is investigated to act as annotations on programming ragments in existing code, in order to analyse possibilities or partitioning the code and to distribute it over various platorms. The mathematics will thereby serve as a basis or the analysis o the costs o the dierent distributions. This approach is rooted in a long tradition o mathematical approaches towards program speciication and program development, and goes back to languages such as Iverson s APL (see [Ive62]). Notations used in this classic were later also used in Squiggol, as developed by Bird and Meertens (see [Mee86], [BdM97]), with the bi-annual conerence series Mathematics o Program Construction, started in 1989, as a major platorm. Closely related to a mathematical approach are design methods based on datalow graphs such as the Teralux project

2 ([Gio14, GS15]). The annotations exploited in the POLCA project can indeed be seen as ormal characterizations o data dependencies, but the ocus o the POLCA project is on code transormations based on the (provable) equivalence o dierent variants o an annotation. OpenMP and FORTRAN compilers exploit similar inormation, in particular loop iterations over arrays to break up the code into parallel segments. However, typically these approaches rely on intrinsic concurrency o the inner loop segment, i.e. that the iterations show no data dependencies across iterations, or at best highly controllable one. We deviate rom these approaches in our strong ocus on the structure that is expressed by various higher order unctions (see Figure 1), and by varying on the notation o those structures such that the transormations and the proos o their correctness become more algebraic. Acknowledgment: The work presented here was partially unded by the European Commission under FP7-ICT , grant agreement II. REPETITION STRUCTURES In this section we will elaborate some core repetition structures (time and space iterations) that orm the basis o many computationally intensive problems, i.e., that require perormance through exploitation o the platorm and parallelism. For the purpose o explanation, we will restrict ourselves to one-dimensional structures, several o which are given in Figure 1. In the irst column the name o the structure is given, in the second column its graphical representation, and in the third column the notation in terms o the unctional programming language Haskell 1. Below we will also introduce a more mathematical notation or some repetition structures which gives the possibility to prove the correctness o transormations by algebraic reasoning. As can be seen rom the graphical representation o these repetition structures, some o them can be executed in parallel. This notably holds or map and zipwith, whose results consist o lists o values zs. Other structures, such as oldl, are accumulative in nature, and contain data dependencies, though depending on the platorm, the individual unctional applications still may be executed at the same time. The accumulative structures in Figure 1 all have a starting value a, and an end value w, and sometimes a sequence o intermediate values zs. Finally, the argument n o itn (or iterate) indicates how oten the unction has to be repeated. The iteration structures presented in Figure 1 are higher order unctions in a unctional language, most o them being standard predeined unctions in, e.g., Haskell. A novel aspect o the POLCA project is that, unlike the standard view in a unctional programming language, these higher order 1 We ollow the Haskell convention and separate the arguments o a unction by spaces rather than by commas, and we (usually) will not surround arguments by brackets. Some urther remarks on notations standard in Haskell parlance: we use xs, ys, etc., rather than x, y, or vectors and lists, where xs indicates the plural o x. Likewise, xss denotes a sequence o sequences o values. The operation : denotes the cons operation, i.e., the extension o a given list with an element in ront, denotes concatenation o two lists, [ ] stands or the empty list. unctions are not considered as recursively deined unctions, but rather as denoting computational structures, as shown in Figure 1, and which can be manipulated and transormed by mathematical means. Note also that the repetition structures in Figure 1 may be seen as hardware architectures which makes it possible to translate the structures directly into hardware, or example on an FPGA (see [Baa15]). Though the graphical representation o the various structures should be clear in itsel, we nevertheless give a small example o every structure to illustrate its usage. In the examples below we use the ollowing deinitions: x = 2x1 g a x = (ax, ax) The ollowing examples should explain the meaning o the higher order unctions above: itn 2 5 = 95 itnscanl 2 5 = [2, 5, 11, 23, 47, 95] map [1, 2, 3, 4, 5] = [3, 5, 7, 9, 11] zipwith () [1, 2, 3] [1, 2, 3] = [2, 4, 6] oldl () [1, 2, 3, 4, 5] = 15 scanl () [1, 2, 3, 4, 5] = [, 1, 3, 6, 1, 15] mapaccuml g [1, 2, 3, 4, 5] = (15, [1, 3, 6, 1, 15]) We illustrate the usage o some o the above structures by the dot product o two (equally long) vectors u and v, deined as ollows: n 1 u v = u i v i i= That is, the elements in the vectors u and v are irst multiplied element-wise, and then added. Figure 2 shows how a combination o zipwith and oldl may deine the dot product, expressed as (using us, vs instead o u, v): us vs = oldl () (zipwith us vs) We introduce the ollowing mathematical notation or the two higher order unctions involved here: oldl () a xs : a xs zipwith () xs ys : xs ys These operations are deined as ollows: a [ ] = a a (x:xs) = (ax) xs [ ] [ ] = [ ] (x:xs) (y:ys) = (xy) : (xs ys) In this notation, the deinition o the dot product is: us vs = (us vs)

3 Name Structure Haskell Imperative Code itn a w w = itn a n w = a; or (i = ; i < n; i) w = (w); x x1 x2 x3 x4 map zs = map xs or (i = ; i < n; i) zs[i] = (xs[i]); z z1 z2 z3 z4 zipwith x y x1 y1 x2 y2 x3 y3 x4 y4 zs = zipwith () xs ys or (i = ; i < n; i) zs[i] = xs[i] * ys[i]; z z1 z2 z3 z4 oldl a x x1 x2 x3 x4 w w = oldl () a xs w = a; or (i = ; i < n; i) w = w xs[i]; scanl a x x1 x2 x3 z z1 z2 z3 x4 z4 z5 zs = scanl () a xs zs[] = a; or (i = ; i < n; i) zs[i1] = zs[i] xs[i]; mapaccuml x x1 x2 x3 x4 a w (w, zs) = mapaccuml a xs w = a; or (i = ; i < n; i) (w,zs[i]) = (w,xs[i]); z z1 z2 z3 z4 Figure 1. Some repetition structures u v u 1 u 2 u 3 u v Figure 2. Composition o structures: dot product u 4 III. TRANSFORMATION RULES In this Section we discuss some transormation rules to manipulate the structure o an algorithm, as indicated by higher order unctions which are given as annotations to ragments o imperative code o which they give the computational structure. The transormations on the annotations are mathematical in nature, hence provably correct, and are mirrored by corresponding transormations on the imperative code which by themselves would be very hard to ind. The intention o such transormations is to ind a better distribution over the available hardware and exploit the speciic characteristics o the hardware better, such that the perormance o an algorithm may be improved, as supported by cost models. Here we mention just two types o transormations: Structural transormations ocus on rules or higher order unctions and change the global structure o an algorithm without changing the algebraic ormula that is computed. These rules aim at redistributing an algorithm over space and/or time. Algebraic transormations change the algebraic operations that are present in an algorithm and may inluence the number o algebraic operations, such as additions and multiplications, that are needed. In this paper we limit ourselves to the irst group o transormations and their eect on an imperative algorithm, and illustrate how a correctness proo o a transormation rule looks like. We choose a simple example to discuss the transormation rules: the summation o a sequence o numbers o which we give a ew equivalent ormulations exploiting transormation laws. The basic algorithm is the sequential addition o all the values in vs, as shown as the irst structure in Figure 3, and which is expressed by the unction oldl in Figure 1, where also a corresponding imperative program is given. The variants A, B, C can all be derived by ormal transormations, which we will give below. In order to ormulate these transormations, we will assume a unction s m which splits a list vs o length n into k consecutive sublists o length m (or simplicity we assume that n is divisible by m). For example: s 3 [1, 2, 3, 4, 5, 6] = [[1, 2, 3], [4, 5, 6]] Hence, i vss is deined as s m vs, we have that concat vss = vs. a) Variant A: This variant splits the total list in subsequences o length m by the unction s m. Then all values in the irst subsequence are added, ater which the result o that is used as the starting value or the addition o the second

4 Basic structure: v total Variant A: v total Variant B: v Variant C: total v 1 total Figure 3. Structures or the summation o a row o numbers subsequence, etcetera, see Figure 3. This variant may be useul when the total sequence is too long to it on, e.g., an FPGA. With this transormation it may be cut in pieces where the same combinational circuit is re-used. Here we will ignore the act that in such a case some memory elements should be put in between. In order to derive the speciication o this structure, consider one box as a single operation with a starting value on the let, and a sequence xs rom above, leading to a result y at the right. This value y then is the starting value o the next subsequence. According to Figure 1, the operation on a subsequence is the operation. Thus, the operation has to be repeatedly applied to the sequence o subsequences, starting with. In other words, this again is the oldl structure, but now not over a sequence o numbers, but over a sequence o sequences o numbers. Hence, Haskell-like ormulation the speciication o this partitioning is total = oldl (oldl ()) vss whereas in mathematical notation it is total = vss The advantage o the mathematical ormulation is that the proo o the correctness o this transormation is a straightorward algebraic reasoning. We have to prove: (s m vs) = vs (1) We need one lemma: Lemma 1. a (xs ys) = (a xs) ys Proo. By induction on the list xs: a ([ ] ys) = (a [ ]) ys a ((x:xs) ys) = a (x : (xs ys)) de = (a x) (xs ys) IH = ((a x) xs) ys de = (a (x:xs)) ys Below, the notation xss stands or a sequence o (sub)sequences and concat xss is the concantenation o all subsequences in xss. We prove the ollowing theorem: Theorem 2. a xss = a (concat xss). Proo. By induction on the list xss: a [ ] de = a de = a [ ] = a (concat [ ]) a (xs : xss) = (a xs) xss IH = (a xs) (concat xss) L1 = a (xs concat xss) = a (concat (xs : xss)) Now equation (1) ollows immediately, since concat (s m xs) = xs. b) Variant B: In variant B all values within subsequences are added independently, and then the results are added. Note that or this variant the acts that the operation is associative and that is the unit element o are used. In Haskell ormat the speciication o variant B is ( pts stands or partial totals ): total = oldl () pts where pts = map (oldl () ) vss In mathematical ormat this is expressed as: total = ( vss) Now equation (2) can be proven by the same algebraic reasoning as with Variant A: ( (s m vs)) = vs (2)

5 c) Variant C: The elements in the subsequences are added element-wise in parallel, starting with a sequence o zeroes o adequate length, and add the results. Here, is assumed to be associative and commutative, and is the unit element o. Let zs be the equence o m zeroes needed or the vector o start values or the additions, then this partitioning can be deined in a Haskell-style ormalism as ollows: total = oldl () pts where pts = oldl (zipwith ()) zs vss In a mathematical ormalism the deinition now is be: total = (zs vss) As beore the proo o the relevant equation is by algebraic reasoning: (zs (s m vs)) = vs (3) d) Imperative code.: Figure 4 shows the imperative code that corresponds to the variants A, B, C mentioned above. We remark that the imperative code is (apart rom some cosmetic renamings o variables) generated automatically based on the transormations on the annotations. The automatic code generation is not yet ully developed, as or example can be seen rom the redundant assignment pts=zs in the code or Variant C. However, the power o being guided by the annotations in this code generation is that the annotations are ormulated purely in terms o data dependencies only, and thus memory dependencies, which make traditional code transormations next to impossible, are not a relevant notion. IV. FURTHER REMARKS, FUTURE WORK In the previous sections we sketched the basic idea o the POLCA project: to annotate ragments o imperative code by its essential computational structure which then may guide code transormations or better perormance on alternative platorms, supported by provably correct ormal transormations o the annotations. In addition to the initial linear examples discussed in the previous sections, the POLCA project works on more complex structures, such as underlying vector products, matrix products, image iltering, signal processing, image processing, etc. Also transormations o combinations o various structures are being investigated. We conclude this paper with a short illustration o a somewhat more involved case: the already mentioned dot product o two vectors (see Figure 2). In Figure 5 the partitionings are shown graphically, whereas in Figure 6 the corresponding annotations with the automatically generated imperative code is given, where is deined as ollows: a (u, v) = a u v The unction zip turns the two lists us and vs into one list o 2-tuples (u i, v i ). We conclude with the mathematical orm or this version o the dot product: Variant A or (i = ; i < k; i) { or (j = ; j < m; j) { vss[i][j] = vs[i * m j]; total = ; or (i = ; i < k; i) { or (j = ; j < m; j) { total = total vss[i][j]; Variant B or (i = ; i < k; i) { or (j = ; j < m; j) { vss[i][j] = vs[i * m j]; or (i = ; i < k; i) { pts[i] = ; or (j = ; j < m; j) { pts[i] = pts[i] vss[i][j]; total = ; or (i = ; i < k; i) { total = total pts[i]; Variant C or (i = ; i < m; i) { zs[i] = ; or (i = ; i < k; i) { or (j = ; j < m; j) { vss[i][j] = vs[i * m j]; pts = zs; or (i = ; i < k; i) { or (j = ; j < m; j) { pts[j] = pts[j] vss[i][j]; total = ; or (i = ; i < k; i) { total = total pts[i]; Figure 4. Imperative code or variants A, B, C dotpr = (zip us vs).

6 u v u 1 u 2 u 3 u 4 u 5 u v u v u 1 u 2 u 3 u 4 u 5 [Mee86] Lambert Meertens. Algorithmics towards programming as a mathematical activity. In J.W. de Bakker, M. Hazewinkel, and J.K. Lenstra, editors, Mathematics and Computer Science, volume 1 o CWI Monographs, pages North-Holland Publishing Company, u v Figure 5. Two partitioning variants or the dot product dotpr = oldl () (zipwith () us vs) or (i = ; i < n; i) { ws[i] = us[i] * vs[i]; dotpr = ; or (i = ; i < n; i) { dotpr = dotpr ws[i]; dotpr = oldl ( ) (zip us vs) dotpr = ; or (i = ; i < n; i) { dotpr = dotpr us[i] * vs[i]; Figure 6. Imperative code or the two dot products As has been shown by this paper this orm annotation and transormation allows to easily exploit the behavioural patterns o algorithms without having to express them in a complicated ashion and beyond simple inormation such as loopindependent or similar. With the kind o annotation that is close to the actual intention o the algorithm, we can easily generate a set o dierent types o provably identical code with dierent properties and degrees o parallelism. REFERENCES [Baa15] Christiaan P.R. Baaij. Digital Circuits in CλaSH Functional Speciications and Type Directed Synthesis. PhD thesis, University o Twente, The Netherlands, 215. [BdM97] Richard Bird and Oege de Moor. Algebra o Programming. Prentice Hall, [Gio14] Roberto Giorgi, et al. TERAFLUX: Harnessing datalow in next generation teradevices. Micronprocessors and Microsystems, 38:976 99, 214. [GS15] R. Giorgi and A. Scionti. A scalable thread scheduling co-processor based on data-low principles. Future Generation Computer Systems, 53:1 18, 215. [Ive62] Kenneth E. Iverson. A Programming Language. John Wiley and Sons, 1962.