Functional parallels of sequential imperatives (short paper)

Abstract

Symbolic parallelism is a fresh look at the decade-old problem of turning sequential, imperative, code into associative reduction kernels, based on the realization that map/reduce is at its core a staging problem: how can programs be separated so that part of the computation can be done before loop-carried dependencies become available? Previous work has investigated dynamic approaches that build symbolic summaries while the actual data is processed. In this short paper, we approach the problem from the static side, and show that with simple syntax-or type-driven transformations, we can readily transform large classes of imperative groupby-aggregate programs into map/reduce parallelism with deterministic overhead.

HACCLE: metaprogramming for secure multi-party computation

“…However, rewriting the HIR code in Figure 9 in a functional style as (bids zip bidders).map(..).reduce(..) allows us to abstract over the reduction pattern and substitute the linear sequence with a tree reduction pattern that yields a circuit of logarithmic depth that allows efficient parallel computation. Using known techniques for extracting functional dependencies from imperative loops [16,33], this transformation could be automated and applied automatically to for loops in Harpoon.…”

Precise reasoning with structured time, structured heaps, and collective operations

“…An approach closely related to ours transforms Java code to a functional IR and then to Apache Spark, after a rewriting and simplification process that, e.g., maps loop-carried dependencies to group-by operations [Radoi et al 2014]. There is also work on synthesizing MapReduce programs from sketches [Smith and Albarghouthi 2016], on defining language subsets that are guaranteed to have an efficient translation [Rompf and Brown 2017], and work in the space of just-in-time compilers to reverse-engineer Java bytecode at runtime and redirect imperative API calls to embedded DSLs .…”

“…Over the last decade, a thriving line of research has demonstrated that even more aggressive transformations such as automatic parallelization are imminently practical for domain-specific languages (DSLs) that restrict mutability and make collective operations such as map, reduce, filter, groupBy, etc., first-class, so that the DSL compiler can reason about them algebraically when making optimization decisions, potentially coupled with auto-tuning and/or search for the best implementation based on cost models and dynamic programming. These systems outperform comparable code written in general-purpose languages by orders of magnitude and achieve asymptotically better parallel scaling [Brown et al 2016Ragan-Kelley et al 2013;Rompf et al 2013Steuwer et al 2015Steuwer et al , 2017. And while the orignal goal was for programmers to write DSL code directly, recent research has also shown that it is often practical to łdecompilež low-level legacy code into high-level DSLs, whose role shifts to that of an intermediate representation [Ahmad and Cheung 2016;Kamil et al 2016;Mendis et al 2015;Radoi et al 2014;Raychev et al 2015;Rompf and Brown 2017;.…”

“…These systems outperform comparable code written in general-purpose languages by orders of magnitude and achieve asymptotically better parallel scaling [Brown et al 2016Ragan-Kelley et al 2013;Rompf et al 2013Steuwer et al 2015Steuwer et al , 2017. And while the orignal goal was for programmers to write DSL code directly, recent research has also shown that it is often practical to łdecompilež low-level legacy code into high-level DSLs, whose role shifts to that of an intermediate representation [Ahmad and Cheung 2016;Kamil et al 2016;Mendis et al 2015;Radoi et al 2014;Raychev et al 2015;Rompf and Brown 2017;.…”

“…To the best of our knowledge, no previous work models first-class collective operations in a general-purpose program analysis setting. There are specialized uses in aggressive optimizing compilers that aim to retarget legacy code to high-performance DSLs [Ahmad and Cheung 2016;Kamil et al 2016;Mendis et al 2015;Radoi et al 2014;Raychev et al 2015;Rompf and Brown 2017;, but these systems (a) are specific to a given target DSL, and (b) only deal with flat arrays, not linked lists or dynamic memory allocation. Likewise, simple classes of structured heap models have been used in previous work [Dillig et al 2011b;Tan et al 2017], but these are restricted to separating container instances.…”