Ziria

Stewart, Gordon; Gowda, Mahanth; Mainland, Geoffrey; Radunović, Božidar; Vytiniotis, Dimitrios; Agullo, Cristina Luengo

doi:10.1145/2694344.2694368

Cited by 18 publications

(8 citation statements)

References 27 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…It then becomes possible for both ends of a pipeline to interact with the I/O system, perhaps reading an input file and writing an output file in explicit chunks, or prompting for input as it is required by the program. Both the Pipes [Gonzalez 2012] and Conduit [Snoyman 2011] packages for Haskell provide this kind of facility.…”

Section: :2mentioning

confidence: 99%

Faster coroutine pipelines

Spivey

2017

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

Coroutine pipelines provide an attractive structuring mechanism for complex programs that process streams of data, with the advantage over lazy streams that both ends of a pipeline may interact with the I/O system, as may processes in the middle. Two popular Haskell libraries, Pipes and Conduit, support such pipelines. In both libraries, pipelines are implemented in a direct style by combining a free monad of communication events with an interpreter for (pseudo-)parallel composition that interleaves the events of its argument processes. These implementations both suffer from a slowdown when processes are deeply nested in sequence or in parallel. We propose an alternative implementation of pipelines based on continuations that does not suffer from this slowdown. What is more, the implementation is significantly faster on small, communication-intensive examples even where they do not suffer from the slowdown , and comparable in speed with similar programs based on lazy streams. We also show that the continuation-based implementation may be derived from the direct-style implementation by algebraic reasoning.

show abstract

Section: :2mentioning

confidence: 99%

Faster coroutine pipelines

Spivey

2017

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

show abstract

“…Ziria [31], a language for wireless systems' programming, compiles high-level reconfigurable data-flow programs to vectorized, fused C-code. Ziria's tick and process (pull and push respectively) demonstrate the benefits of having both processing styles in the same library.…”

Section: Related Workmentioning

confidence: 99%

Stream fusion, to completeness

KiselyovOleg¹,

BiboudisAggelos²,

PalladinosNick³

et al. 2017

SIGPLAN Not.

View full text Add to dashboard Cite

Stream processing is mainstream (again): Widely-used stream libraries are now available for virtually all modern OO and functional languages, from Java to C# to Scala to OCaml to Haskell. Yet expressivity and performance are still lacking. For instance, the popular, well-optimized Java 8 streams do not support the zip operator and are still an order of magnitude slower than hand-written loops. We present the first approach that represents the full generality of stream processing and eliminates overheads, via the use of staging. It is based on an unusually rich semantic model of stream interaction. We support any combination of zipping, nesting (or flat-mapping), sub-ranging, filtering, mapping—of finite or infinite streams. Our model captures idiosyncrasies that a programmer uses in optimizing stream pipelines, such as rate differences and the choice of a “for” vs. “while” loops. Our approach delivers hand-written–like code, but automatically. It explicitly avoids the reliance on black-box optimizers and sufficiently-smart compilers, offering highest, guaranteed and portable performance. Our approach relies on high-level concepts that are then readily mapped into an implementation. Accordingly, we have two distinct implementations: an OCaml stream library, staged via MetaOCaml, and a Scala library for the JVM, staged via LMS. In both cases, we derive libraries richer and simultaneously many tens of times faster than past work. We greatly exceed in performance the standard stream libraries available in Java, Scala and OCaml, including the well-optimized Java 8 streams.

show abstract

“…Continuations κ in the semantics map directly to labels, although we avoid labels except when necessary for producer-consumer coordination. As a result, we also avoid the overhead inherent in the tick/proc execution model used by Stewart et al [2015] and instead generate straight-line C for Ziria code that does not perform IO.…”

Section: Implementing the Operational Semanticsmentioning

confidence: 99%

“…SDR. Our work is inspired by and based on the original Ziria system [Stewart et al 2015]. We benchmark our system against the original Ziria compiler using its accompanying WiFi implementation and much of its standard library routines, such as FFT, IFFT, and Viterbi.…”

Section: Related Workmentioning

confidence: 99%

“…More typically, the FPGA is used as a fixed-function block, and the łsoftwarež part of the SDR platform runs on a commodity CPU [Balan et al 2013;Ettus Research 2017;Tan et al 2009]. The most common tool for programming these sorts of SDR platforms is the GNU Radio environment [Blossom 2004], although there are numerous other approaches to programming SDR applications [Bansal et al 2012;Dutta et al 2013;Rondeau et al 2013;Sora Core Team and Tan 2012;Voronenko et al 2010].…”

Section: Related Workmentioning

confidence: 99%

See 1 more Smart Citation

Better living through operational semantics: an optimizing compiler for radio protocols

Mainland

2017

Proc. ACM Program. Lang.

Self Cite

View full text Add to dashboard Cite

Software-defined radio (SDR) promises to bring the flexibility and rapid iterative workflow of software to radio protocol design. Many factors make achieving this promise challenging, not least of which are the high data rates and timing requirements of real-world radio protocols. The Ziria language and accompanying compiler demonstrated that a high-level language can compete in this demanding space [Stewart et al. 2015], but extracting reusable lessons from this success is difficult due to Ziria's lack of a formal semantics. Our first contribution is a core language, operational semantics, and type system for Ziria. The insight we gained through developing this operational semantics led to our second contribution, consisting of two program transformations. The first is fusion, which can eliminate intermediate queues in Ziria programs. Fusion subsumes many one-off optimizations performed by the original Ziria compiler. The second transformation is pipeline coalescing, which reduces execution overhead by batching IO. Pipeline coalescing relies critically on fusion and provides a much simpler story for the original Ziria compiler's łvectorizationž transformation. These developments serve as the basis of our third contribution, a new compiler for Ziria that produces significantly faster code than the original compiler. The new compiler leverages our intermediate language to help eliminate unnecessary memory traffic. As well as providing a firm foundation for the Ziria language, our work on an operational semantics resulted in very real software engineering benefits. These benefits need not be limited to SDRÐthe core language and accompanying transformations we present are applicable to other domains that require processing streaming data at high speed.

show abstract

Ziria

Cited by 18 publications

References 27 publications

Faster coroutine pipelines

Faster coroutine pipelines

Stream fusion, to completeness

Better living through operational semantics: an optimizing compiler for radio protocols

Contact Info

Product

Resources

About