CAMAS-TR Progress Report **************** ESPRIT III PROJECT NB 6756 **************** CAMAS COMPUTER AIDED MIGRATION OF APPLICATIONS SYSTEM

Transcription

1 CAMAS-TR Progress Report COMMISSION OF THE EUROPEAN COMMUNITIES **************** ESPRIT III PROJECT NB 6756 **************** CAMAS COMPUTER AIDED MIGRATION OF APPLICATIONS SYSTEM **************** CAMAS-TR SAD/PARASOL II Progress report **************** Date : SEPT.1993 Rev. 2.0 ACE - U. of AMSTERDAM - ESI SA - ESI GmbH - FEGS - PARSYTEC - U. of SOUTHAMPTON.

2 Progress Report SAD/PARASOL II ( march 15 - sept ) By Jan de Ronde, Berry van Halderen, Marcel Beemster and Peter Sloot. Unversty of Amsterdam September 1993 Contents: 1-Introducton 2-Development of the SAD formalsm Research focus Data Dependent control nformaton The reducton/compresson phase 3 - PARASOL II: Smulatons/Experments The undetermnable X 4 - Implementaton ssues: F2SAD 4.1- How to get from Fortran to a SAD descrpton 4.2- Structure of the front-end of the f2sad compler 4.3- The semantcs and back-end of the f2sad compler 4.4- Status Appendx : -Abstractng the SAD formula of an F77 kernel by hand -Addtonal nformaton to the SAD formula: Data Dependent control -Mathematcal manpulatons on the SAD formula 1. Introducton The above mentoned perod effort has been spent on the desgn and development of several tools (boxes n the overvew pcture below) that the Unversty of Amsterdam contrbutes to the CAMAS Workbench.

3 f77 spmd program IDA F2SAD reducable SAD data dependent control nformaton ntellectual SAD parameter ntalsaton reductons/ compressons guesses SAD nput DDT allocaton PARASOL II (smulatons/ experments) reductons/compr. Machne model n data structure parasol I seg. data MAP Tme estmates 2. Development of the SAD formalsm. The development of SAD (Symbolc Applcaton Descrpton) whch s the mathematcal formalsm that descrbes the tme complexty of sequental and SPMD Fortran programs has been one of the focal ponts ths perod. Frstly t was recognzed that a mathematcal formalsm descrbng such programs n order to represent a tme complexty descrpton of the program, should consst of three separate levels: We descrbe SPMD programs by the followng functonal herarchy: 1) Statement block level (fxed complextes, machne dependent) 2) Control flow level (control dependent complextes) 3) Data localty level (data dstrbuton dependent complextes) 2.1 Research focus Investgatons have been done on a formalsm that can capture the frst two levels n a descrpton. Therefore several typcal Fortran 77 programs/program parts have been analysed by hand. As the example n the appendx shows the frst two levels of the functonal herarchy allow a generc descrpton of the form: SAD = M N =1 m K k P k X m S[Block()]

4 Where N s the number of solated statement blocks (contanng no control flow characterstcs whatsoever), P k descrbes the k -th nested branch probablty of the total of K branches n whch S[Block()] s nested. Analogously X m descrbes the loop-count of the m --th nested loop of a total of M loops n whch S[Block()] s nested. S[Block()] s the tme complexty of an solated statement block labelled. 1) The tme complexty of a so called statement block S[Block()] s gven by cumulaton of all the ndvdual tme complextes occurrng n the block. For example an expresson lke: a = a + b * c has a tme complexty of T assgn + T multply + T addton The correspondng actual tme measures n such formal expressons are flled n by the machne database (the parametersed machne descrpton). 2) The control flow level ntroduces ndetermnablty nto the tme complexty descrpton. In general the executon path taken, gven a specfc set of nput parameters, s only determnable by means of explct executon. We approach ths level n a (quas) statstc manner by descrbng the possblty of branchng n some specfc drecton along the executon graph. Branch drectons n f..then..else constructs are specfed by probabltes P 1, P 2, P 3... P n (where we assume the number of branchng drectons = n) whereas n loop constructs the number of unkown teratons s presented by a stochastc varable X. So a parametersed descrpton on these two levels leads to a mxture of the tme-complextes of basc statement blocks, probabltes and stochastc varables. 3) The localty level descrbes the fact that some fracton of data s nvolved n communcaton and the remanng part s not. So far only the frst two levels have been consdered n the SAD formalsm. How exactly the 3rd level wll eventually appear n the tme complexty formula s part of future work. Ths wll among others depend on how the MAP subtask wll evolve. 2.2 Data dependent control nformaton As s clear from the overvew pcture PARASOL II plays a key-role n the Workbench structure. What n fact happens n PARASOL II s actualsaton of the parameters present n the SAD formula. The machne parameters are obtaned from the machne database developed under Parasol I and have a clear orgn (some exstng or what-f hardware archtecture that s). The other parameters orgnatng from control flow and -when the 3rd level wll be concerned- from data localty also need to be ntalzed n order to obtan a tme complexty measure for the program of nterest.the queston of how to actualze these parameters s to be answered n PARASOL II. Control dependency nformaton wll be substracted from the parse tree generated n the F2SAD transformaton sequence. The deas behnd the mplementaton of such an automatc transformaton tool wll be dscussed n one of the paragraphs below. Furthermore n the appendx an dea of what control dependences wll be substracted wll be gven. At ths pont obvously the Interprocedural Dependency Analyser of Southampton can be brought nto the pcture. 2.3 The reducton/compresson phase Gven a general F77 numercal applcaton. It can consst of thousands of lnes of code and consequently performng F2SAD on t wll lead to a formal expresson that s out of proporton. Therefore n order to have an expresson that s manageable t has to be reduced

5 n sze by means of compresson and reducton technques. One can thnk of purely mathematcal manpulatons as the "Smplfy" operaton n Mathematca or reductons based on nformaton obtaned from data dependency analyss. For some examples of such reducton and compresson operatons see the appendx. The mathematcal manpulaton package Mathematca offers the possblty of performng reducton/compresson technques and several reductons/compressons can also automatcally be performed wthn the F2SAD tool The reducton task conssts of manpulatng the SAD formula usng control dependency nformaton (and probably also expert programmers knowlegde) to do realstc actualsatons of the parameter set that comprses the SAD formula. So the manpulatons are reductons/compressons and actualsaton of parameters. Both have to be done usng some mathematcal manpulaton package. The soluton to problems arsng n actualzng the parameters are part of future research. The paragraph below wll shed some lght on the status of the smulaton strateges as they have been developed untl now. 3 PARASOL II: smulatons/experments The goal of PARASOL II s : gven the followng: - A reduced SAD descrpton of a data parallel (SPMD) Fortran 77 applcaton - A Machne parameterzaton - A Mappng tool whch optmzes the data dstrbuton to obtan a predcton of the tme consumpton of the applcaton gven a spectrum of nput values and machne parameters (PARASOL I). Ths would mean n the dealzed case: Fll n the varous nput parameters to the SAD expresson and the tme complexty gven the specfc actualzaton rolls out of the black box. Due to the undetermnablty of control flow ths procedure wll only work for generc applcatons when n fact the code s executed. Program executon s undesrable for a varety of reasons: -Probably performance predcton on a "What-f machne", or "stll-to-be-bult "machne s desred so that executon s not possble. -The tme complexty response on "What-f" nput may be of nterest. -Smulaton allows for the exploraton of dfferent codng strateges for core codes wthout actually beng forced to mplement every strategy explctly. 3.1 The undetermnable X The SAD contans a number of specfc parameters orgnatng from the three herarchcal levels. Some of these parameters wll depend trvally on nput parameters (e.g. problem sze = N) others wll depend on the entre program evoluton (e.g. the stop condton n a matrx nvertng algorthm ). The parameters wth trval dependendce are to be dentfed usng control dependency analyss. The problematc ones are to be approxmated usng stochastc modellng. That s: based on characterstc features of a parameter (of mportance) that can be suppled by the expert programmer or that can be derved from the source code (reversblty) the respons of such a parameter on varatons δi of the nput vector I can be approxmated/modelled. Notatonal: I represents the lst of nput parameters that s gven as ordnary nput to enable an applcaton to execute. E.g. : the elements of a matrx and a vector when the calculaton of a matrx vector product s concerned. Formally we shall denote the lst wth nput values as: I = { 1, 2,..., n }

6 In general the parameters X or P that descrbe loop and branchng constructs n the SAD are functons of the nput vector I : X = f ( I ). What s desred s an estmaton of ths functon, as the only way to get the exact representaton of X = f ( I ) s executon of substantal parts of the applcaton. Furthermore,some measure tellng how probable ths functon tells the "truth" s convenent. E.g. for a specfc X you can show that wthn a devaton of δf( I) the used functon s approxmated. In other words: X = f ( I ) + δf( I) The pcture below gves an dea how ths undetermnable behavour would appear n the tme complexty functon when varyng one of the nput parameters, the other paramters kept constant. The error bar characterzes the uncertanty for specfc that the tme complexty formula T (= SAD formula) has at ths pont. These error bars are present for the whole spectrum of. T() error bar So X s n general a functon whch depends on the nput vector I. Suppose we have a row of M functons f 1 f 2 f 3...f M ( I) where f g means: the functon f actng on the functon g that consecutvely operate on I. The complexty of these functons determnes f you can calculate the response that these functons cause n a smple manner or that one has to flee to approxmaton methods. One can roughly dscrmnate several grades of complexty to obtan knowlegde about the dependence of a parameter X on the nput lst: - X drectly corresponds to some element of I : X = - X depends on I va a smple functon and ths functon s tractable va some data dependency analyss. - X depends on I va a functon that s not smple but corresponds to the computaton of sgnfcant parts of the applcaton. The problem wth approxmatng the responses usng some devaton functon les n the fact that n general the sequence of functons that act on the specfc nput lst changes when a fluctuaton δ I s superposed on I. So a contnous varatonal soluton method s not applcable to ths problem (see pcture below for elucdaton). Formally one could wrte ths down as:

7 m T( m ) m +δ m T( m +δ m ) T( m +δ m ) - T( m ) =? where T denotes the tme complexty formula and m denotes an nput varable whch s vared and s an element from the nput lst : I = { 1, 2,..., n } The? denotes the fact that a small varaton n the nput can lead to small varatons n the response functon and to large non-lnear jumps. So t s clear that the problem of how to model/estmate response functons n ths area s part of future research. dependng on the nput lst another trajectory through the functon tree below s actualzed T(I) = f(g1(h1(i))) h1 f g1 h2 T(I+δI)= f(g1(h2(i+δi))) Input lsts g2 w1 w2 T(I+δI')= f(g2(w1(i+δi'))) T(I+δI'')= f(g2(w2(i+δi''))) The pcture above vsualzes the non lnear behavour of the respons to varatons of the nput lst. f, g1, g2, h1, h2, w1, w2 are functons. 4. Implementaton ssues : F77 to SAD 4.1 How to get from Fortran to a SAD descrpton To obtan a SAD descrpton of a Fortran program, a transformaton of the source code has to be done. Ths translaton process, mplemented as a compler, takes Fortran 77 source code augmented wth communcaton prmtves for the SPMD programmng model as nput and bulds the SAD formula wth the correspondng data dependent control flow and addtonal nformaton about the program. In the secton below the general structure of such a translator s dscussed. We then turn to the mplcatons of tryng to process Fortran. Fnally we turn to the way the translaton process can be mplemented. 4.2 Structure of the front-end of the f2sad compler Fortran was the frst hgh level programmng language ever developed. Unfortunately, durng the development of ths early programmng language a number of decsons were made whch turned out to be bad practse n computer language desgn. Therefore the standard tools (lex & yacc) for compler engneerng are not drectly applcatve to Fortran 77.

8 There are several dffcultes wth Fortran whch must be solved before standard tools can be used. These problems wll be dscussed n the software layer where they are solved. SPMD F77 f2sad front-end characters fle reader preprocessor fltered characters lex generated lexcal analyzer stream of tokens yacc generated syntax analyzer parse-tree The structure of the front-end of the f2sad compler s structured as shown n the above fgure, whch s comparable to the generc model of a compler [1]. The source program -- Fortran 77 code-- s read usng a separate module. Ths module performs tasks lke bufferng, keepng track of the fle poston, lne and column numberng. It also contans routnes for returnng errors back to the user. Ths stream of characters s then fltered usng a preprocessng module. Its output s a modfed stream of characters where the followng set of problems s solved. - If a lne starts wth a label then t wll be preceeded by a specal ndcatng character. Ths wll enable the lexcal analyzer to dstngush these labels from ntegers, whch n turn s needed n the syntactc analyzer. Labels after goto's and other jump statements are not preceeded by ths ndcator because the syntactc analyzer does not need to know ths. - All spacng characters except newlnes are removed. Many programmng languages have a free layout (spacng characters may be nserted freely between tokens), Fortran unfortunately takes ths even one step further: spacng characters are nsgnfcant. If you separate the characters wthn the keyword f wth a space (makng f) the compler should stll recognze t as one keyword f nstead of two varables and f. - Contnuaton lnes are glued together to produce one lne. - Comment lnes are deleted. - Snce Fortran offcally only defnes uppercase letters,the compler s so frendly to convert lowercase letters to uppercase. - Note that ths preprocessor module breaks the drect correlaton between the lne numbers n the nputand the output. We want however to be able to go back from the generated SAD descpton to the source code, therefore ths correlaton needs to be restored. Ths s solved by the module whch reads the fle. The semantcs descpton s able to refer to the fle poston of the tokens usng a seperate nformaton passng mechansm.

9 The lexcal analyzer for Fortran s wrtten usng lex, a tool for generatng lexcal analyzers usng regular expressons. Because the preprocessor has made some changes to the source nput t s now possble to tokenze the nput. The lexcal analyzer not only converts characters nto tokens, t also stores the lexcal value (lexeme) for later use. The followng rregular behavour patterns were necessary n the mplementaton of the lexcal analyzer (usng lex). - If a label ndcator s encountered n the nput stream then the next token s a label nstead of an nteger. The label ndcator character s further gnored. - Wthn certan contexts, the context-free parser cannot dstngush an assgnment to an array element from a functon defnton statement (ths s dscussed further on). Therefore the lexcal analyzer ndcates, on request of the parser, by nsertng a specal token whether ths statement s an assgnment or a functon defnton statement. It can determne ths by lookng f the dentfer n the statement s defned. If the dentfer s ndeed defned to be an array then we are dealng wth an assgnment, otherwse wth a functon defnton or an error. - As sad earler; Fortran consders whte spaces as nsgnfcant. Suppose we have the nput f foo. Ths should be tokenzed nto two tokens, the keyword f and the dentfer foo. Unfortunately, because spaces are deleted and lex always tres to match the longest token t wll consder f foo as one dentfer ffoo. By checkng prefxes of lexemes we can detect keywords, bypass the ``longest matchng token'' rule and consder the remanng characters as part of the next token. 4.3 The semantcs and back-end of thef2sad compler The yacc generated syntax checker, s normally used to make a parse tree. A parse tree represents the nput source program n a structured way, n the same way the grammar s wrtten down. Yacc does not automate the buldng of the parse tree, but allows you to execute actons on the nodes of the abstract parse tree. In ths way you can buld the parse tree yourself. The translaton process of the compler can be vewed as the rewrtng process of the parse tree nto a tree representng the output. The output can then be generated by a traversal of the latter tree. There are tools (e.g. [2]) avalable whch assst n couplng the syntax checker and a parse tree manpulator, but most tools have the dsadvantage of defnng ther own lexcal and syntax analyzng languages. These restrct the classes of languages that can be handled and snce Fortran parsng needs some specal tunng of the lexcal and syntax analyzers ths presents a severe problem. It s possble to overcome these problems by creatng an addtonal layer or by usng a self-made tool. The rewrtng proces of the Fortran parse tree nto the SAD formula s not extremely dffcult, the only complcaton s that Fortran may contan goto statements, possbly creatng so called spagett code. The data dependent control flow contans nformaton by whch the control flow can be descrbed n terms of ts nput parameters. Generatng ths data dependent control flow nformaton about the program s a more serous problem whch stll needs a lot of our attenton.

10 Modellng and analyzng data dependent control flow nteracts wth analyzng data dependency. Therefore technques used wthn the IDA (nterprocedural dependency analyzer) tool may be very smlar to technques we need to use. Informaton generated by the IDA tool may enhance the data dependent control flow nformaton. Future nteracton between SOTON and the UoA therefore seems frutful. 4.4 Status The lexcal- and syntax descptons, the fle reader and the preprocessor for Fortran are fnshed. The tool for buldng and rewrtng the parse tree s nearng completon (n the testng phase). The descrpton of the semantcs of Fortran s currently beng constructed. All fnshed parts are tested, but can only be tested thoroughly when the entre tool has been completed. Bblography [1] Alfred V. Aho and Rav Seth and Jeffrey D. Ullman Complers, Prncples, Technques and Tools Addson-Wesley 1986 [2] The TXL programmng language, Syntax and nformal semantcs, Verson 7

11 APPENDIX Abstractng the SAD Formula from a Fortran 77 kernel by hand In ths appendx the SAD formalsm descrbng the frst two levels of the functonal herarchy of Fortran 77 (or C) wll be derved usng a scentfc Fortran 77 kernel extracted from the so called Lvermore Loops. Ths example wll clarfy the SAD expresson that s chosen to descrbe the functonal structure of Fortran 77 programs. Several F77 examples have been transformed to SAD by hand and these have shown the drecton n whch the F2SAD tool currently s beng developed. The Lvermore Loop we're handlng as an example of F2SAD by hand has the followng form: BLOCK(1) BLOCK(2) BLOCK(3) BLOCK(4) BLOCK(5) BLOCK(6) PROGRAM SADTST PARAMETER (NN = 100, LOOP = 100) DIMENSION X(NN), V(NN) N = 1000 DO 23 J = 1, NN V(J) = EXP ((REAL(J) - 50.)**2) / X(J) = EXP ((REAL(J) - 50.)**2) DO 200 L = 1, LOOP II = N IPTNP = IPNT = IPNTP IPNTP = IPTNP + II II = II / 2 DO 2 K = IPNT + 2, IPNTP, 2 I = I X(I) = X(K) - V(K) * X(K-1) - IF( II. GT. 1) GO TO CONTINUE END The Lvermore Loop under consderaton descends from an ICCG (Incomplete Cholesky Conjugate Gradent). The basc statement blocks (level 1) are ponted out. Wrtng out the SAD expresson by hand leads to: SAD( program) = S[Block(1)] + X 1 S[Block(2)] + X 2 {S[Block(3)] + X 3 {S[Block(4)] + X 4 {S[Block(5)]} + S[Block(6)]}} or SAD( program) = S[Block(1)] + X 1 S[Block(2)] + X 2 S[Block(3)] + X 2 X 3 {S[Block(4)] + S[Block(6)]} + X 2 X 3 X 4 S[Block(5)] Where S[Block()] denotes the cumulaton of the atomc tme complextes n the statement blocks. For example: S[Block(1)] = T ac : That s the tme to assgn an nteger constant.

12 The other statement blocks have the same form though of course n large statement blocks much more dfferent atomc tmes are nvolved. Further: X 1 corresponds to the loop boundary of the DO loop X 2 corresponds to the loop boundary of the DO loop X 3 corresponds to the loop boundary of the IF(II.GT.1) GOTO 222 loop X 4 corresponds to the loop boundary of the DO loop We see that loop boundares (orgnatng from do loops or from f..goto loops) are parameterzed n the SAD expresson. Further nvestgatons of generc Fortran 77 constructs have shown that an equvalent parameterzaton can be appled for handlng the presence of f..then...elsef...endf constructs n Fortran 77. The varous branchng drectons offered n a branch construct are modelled by chances that descrbe the probablty that a branch n a certan drecton s realsed. It turns out that an analogous nested expresson arses as n the above expresson. Furthermore t became clear that the probablty and the loop boundary parameters could be handled as normal factors n a factorzed expresson. Therefore after havng done several F2SAD actons by hand we can state that as long as the code s structured (no spaghett) a symbolc expresson for such programs can be realzed and furthermore the general form for such a SAD expresson s: SAD = M N =1 m K k P k X m S[Block()] Where :P k descrbes the k -th nested branch probablty of the total of K branches n whch S[Block()] s nested. Analogously X m descrbes the boundary of the m -th nested loop of a total of M loops n whch S[Block()] s nested. Addtonal nformaton to the SAD formula: Data Dependent control As we consder the parameter set { X 1, X 2, X 3, X 4 } we notce the followng: X 1 = NN ----> Input X 2 =LOOP---> Input X 3 =functon of N:=f(N) ----> N :----->Input X 4 =functon of a functon of N: = g(f(n))--> N:----->Input So as was stated above: every parameter n the SAD expresson depends on the nput n a smple or less trval manner. Gven a specfc nput set all parameters can exactly be calculated f the functons f and g are relatvely smple. In the case of the example above some algebrac effort can determne the forms of the two functons f and g. As an example we'll derve the form for f: From the program shown above we note that the loop boundary that X 3 descrbes depends on a functon whch we call F. Ths functon has the followng formwhen t acts on ts argument II (double I not P). F(II) = II 2

13 Where the floor functon actng on argument a : a means: return the truncaton of the real value a. So 1.5 = 1, 2 = 2 etc... Further analyss by hand shows that the value of X 3 whch depends on the ntal value of II (= N) can be calculated usng the condton: ( ) > 1 F m II F m+1 ( II) 1 where F m = F m 1 (F) and m s nteger The value of m that satsfes the above condton s m = 2 log( N) = f(n). Analagously such types of dependency analyses can be performed for all parameters that have no drect correspondence wth an nput parameter. Of course very often the back tracng of such control flow dependences wll turn out to be executon n reverse order of the program. That s wat we do not want. How to crcumvent such problems s part of work to be done n PARASOL II. Mathematcal manpulatons of the SAD formula Now several possble reducton/compresson technques on the SAD formula wll be dscussed. A Smplfy acton: Generally the SAD expresson for an arbtrary statement block S[Block] s a cumulaton of all the atomc tme consumptons n the block. What a Smplfy acton (such as offered by the mathematcal manpulaton package Mathematca) does s accumulatng the tmes n the expresson of the same name. Example: and for a general expresson we can wrte S[Block] = T 1 + T 2 + T 1 + T l Smplfy[S[Block]] 3T l + T 2 S[Block] = T + T j + T k +...+T l Smplfy[S[Block]] α T where T, T j, T k etc... denote the varous atomc machneparameters. On control level: Suppose you have an expresson where P 1 * S[Block()] + P 2 * S[Block(j)]: S[Block()] = S[Block(j)] = and these statement blocks -although not related n any manner-turn out to satsfy the condton that the dfference n ther explct tme complextes s less than some small j α T β j T j

14 value ε, then one can compress the total expresson to a form n whch only one statement block descrbng the tme complextes of both orgnal blocks remans: f: β T j j j α T << ε ( p 1 + p 2 )S[Block(, j)] Another example of a possble reducton: gven two statement blocks that are added together; contracton of the prefactors of the atomc tmes s another compresson/reducton step: S[Block(j)] + S[Block()] = β T + α T (α + β )T Or suppose the expresson below arses: X * S[Block(j)] + S[Block()] When durng smulatons n PARASOL II X turns out not to be affected sgnfcantly by fluctuatons δi of the nput vector I. Then the varable nature of X can be omtted and replaced by a constant. Consecutvely one of the reducton technques that are mentoned above can be used to reduce the expresson further.