How Much Nonstrictness do Lenient Programs Require Klaus E Schauser Seth C Goldstein Department of Computer Science Computer Science Division University of California Santa Barbara University of California Berkeley Santa Barbara CA Berkeley CA schausercsucsbedu sethgcsb erkeleyedu contribute to the result thus decreasing parallelism How Abstract ever nonstrictness can also b e combined with eager evalu Lenient languages such as Id have b een touted as among ation This combination called lenient evaluation Tra the b est functional languages for massively parallel machines exhibits more parallelism than lazy evaluation while retain AHN Lenient evaluation combines nonstrict semantics ing much of the latters expressive p ower with eager evaluation Tra Nonstrictness gives these Unfortunately nonstrictness comes at a high implemen languages more expressive p ower than strict semantics while tation cost since it requires negrained dynamic schedul eager evaluation ensures the highest degree of parallelism ing and synchronization Nonstrict semantics can make it Unfortunately nonstrictness incurs a large overhead as it imp ossible to statically determine the order in which ar requires dynamic scheduling and synchronization As a re guments are evaluated and op erations execute Expressions sult many p owerful program analysis techniques have b een can b e evaluated only after all of the arguments they dep end develop ed to statically determine when nonstrictness is not on are available This dynamic scheduling is exp ensive on required CPJ Tra Sch commo dity micropro cessors which eciently supp ort only This pap er studies a large set of lenient programs and a single thread of control and incur a high cost for context quanties the degree of nonstrictness they require We switching identify several forms of nonstrictness including functional Much research has b een devoted to analysis techniques conditional and data structure nonstrictness Surprisingly that determine when the full generality of nonstrictness most Id programs require neither functional nor condi is not required These techniques include strictness anal tional nonstrictness Many b enchmark programs however ysis Pey backwards analysis Hugb path analysis make use of a limited form of data structure nonstrictness BH and partitioning Tra SCvE HDGS For The pap er refutes the myth that lenient programs require lenient languages the compilation approach is to schedule extensive nonstrictness instructions statically into sequential threads and have dy namic scheduling only b etween threads The task of identi fying p ortions of the program that can b e scheduled stati Intro duction cally and ordered into threads is called partitioning Tra Two op erations can b e placed into the same thread only Nonstrict functional languages have b een widely regarded if the compiler can statically determine the order in which as an attractive basis for parallel computing Unlike sequen they execute tial languages they exp ose all the parallelism in a program In Sch we presented a new thread partitioning al In sideeectfree functional languages the arguments to a gorithm separation constraint partitioning which improves function call can b e evaluated in parallel Further nonstrict substantially on previous work Tra HDGS SCvE execution can substantially enhance parallelism since func To evaluate our partitioning algorithm we compared b ench tions can start executing b efore all of their arguments have mark programs compiled using our algorithm and using strict b een provided In a language with nonstrict semantics it partitioning Strict partitioning ignores p ossible nonstrict is p ossible to dene functions which return a result even if ness and compiles functions and conditionals strictly thus one of the arguments diverges Among other things this representing the b est p ossible partitioning Obviously strict makes it p ossible to create recursively dened and cyclic partitioning pro duces an incorrect partitioning ie leading data structures since p ortions of the result of a function to a deadlo ck for programs which require nonstrictness call can b e used as arguments to that call Nonstrictness Surprisingly almost all of our b enchmark programs still ran increases the expressiveness of the language but requires a correctly an indication that nonstrictness is rarely used in more exible strategy than strict evaluation which evalu lenient programs ates all arguments b efore calling a function This observation led us to pursue a more detailed study Nonstrictness is usually combined with lazy evaluation of how much nonstrictness lenient programs use and to which delays evaluation of an expression until it is known to fo cus on a larger set of programs In this pap er we eval uate the strictness prop erties of a large collection of pro grams written in Id a nonstrict functional language that To app ear in th Annual ACM SIGPLANSIGARCH uses lenient evaluation We dene three catagories of non Conference on Functional Programming Languages and strictness functional conditional and datastructure non Computer Architecture FPCA strictness We nd that functional and conditional non strictness are rarely used in lenient programs On the other hand data structure nonstrictness is used extensively We more expressive power catagorize datastructure nonstrictness into circu further M-structures recursive and dynamically scheduled nonstrictness and lar I-structures e see that the exp ensive dynamically scheduled nonstrict w determinate is seldom required ness Functional core referentially transparent this study our fo cus is on whether nonstrictness is In determinate required and if it is what kind is required for executing simpler semantics lenient programs correctly Therefore the study is not af fected by whether the programs are executed in parallel or sequentially We chose to study the sequential execution Figure The three layers of Id from Nik b ehavior However evaluating functions even strict func tions nonstrictly can increase parallelism We nd that nonstrictness is rarely used suggesting that future work on elements Like functional arrays Istructures provide e lenient languages should fo cus less on techniques for deter cient indexed access to the individual elements In addi mining when nonstrictness is not used and more on when tion Istructures provide elementbyelement synchroniza strict functions and conditionals should b e evaluated non tion b etween the pro ducer and consumer Istructures are strictly not purely functional since they lose referential transpar The remainder of the pap er is structured as follows Sec ency Any function obtaining a p ointer to an Istructure tion summarizes the dierent evaluation strategies for func may store into it On the other hand determinacy is pre tional languages strict lenient and lazy and previous ar served b ecause each lo cation can b e stored into at most once guments for lenient evaluation as the most suitable way to Nondeterministic computation can b e expressed with M write programs for massively parallel machines Section structures mutable data structures that provide supp ort for identies and illustrates three kinds of nonstrictness con atomic up dates ditional functional and data structure nonstrictness Sec tion describ es the metho dology and the b enchmark pro Evaluation Strategies grams which were used for this study and presents the re The two most widely used evaluation strategies for func sults which show the typ e of nonstrictness each program tional languages are strict and lazy evaluation We com requires Section discusses related work and Section pare them to lenient evaluation the strategy used in Id suggests directions for future work The three strategies dier in how they handle the evalua tion of typ e constructors and function calls As presented Lenient Evaluation in Tra to evaluate a function call f e e 1 n This section summarizes dierent evaluation strategies for Strict evaluation rst evaluates all of the argument ex functional languages strict lenient and lazy The three pressions e to e and then evaluates the function 1 n evaluation strategies dier in their expressiveness paral b o dy passing in the evaluated arguments lelism and eciency Many arguments have b een made Lenient evaluation starts the evaluation of the function in favor of lenient evaluation as emb o died in the language 1 b o dy f in parallel with the evaluation of all the argu Id as the b est choice for massively parallel machines ment expressions e to e evaluating each only as far 1 n AHN Nik Being nonstrict lenient evaluation retains as the data dep endencies p ermit much of the expressive p ower of lazy evaluation at a much lower overhead while exhibiting more parallelism than b oth Lazy evaluation starts the evaluation of the function b o dy strict and lazy evaluation Tra passing the arguments in an unevaluated form The evaluation rules for constants arithmetic primitives The Lenient Language Id and conditionals are the same for the three strategies The Id is a functional language augmented with synchronizing evaluation of a constant yields that constant Arithmetic data structures It consists of three layers as shown in Fig op erators are strict in their arguments so they evaluate the ure The functional core has all of the prop erties of purely arguments b efore p erforming the op eration The evaluation functional languages including referential transparency and of a conditional if e then e else e rst evaluates the pred 1 2 3 determinacy Id provides