DOCSLIB.ORG

Compiler and Runtime Support for Continuation Marks Matthew Flatt R

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Compiler and Runtime Support for Continuation Marks Matthew Flatt R Compiler and Runtime Support for Continuation Marks Matthew Flatt R. Kent Dybvig University of Utah Cisco Systems, Inc. USA USA [email protected] [email protected] Abstract 1 Binding and Control Continuation marks enable dynamic binding and context Suppose that a program needs to call a function with out- inspection in a language with proper handling of tail calls put redirected to a file instead of the current default output and first-class, multi-prompt, delimited continuations. The stream. One way a language can support such redirection simplest and most direct use of continuation marks is to is by having a global variable like stdout hold the default implement dynamically scoped variables, such as the current output destination for functions like printf, and then a output stream or the current exception handler. Other uses program can temporarily change the value of stdout and include stack inspection for debugging or security checks, restore it when the function call returns: serialization of an in-progress computation, and run-time elision of redundant checks. By exposing continuation marks FILE *orig_stdout = stdout; to users of a programming language, more kinds of language stdout = f_output; extensions can be implemented as libraries without further func(); changes to the compiler. At the same time, the compiler and stdout = orig_stdout; runtime system must provide an efficient implementation of continuation marks to ensure that library-implemented This approach has several potential problems. If the host language extensions are as effective as changing the compiler. language supports threads, then stdout must be a thread- Our implementation of continuation marks for Chez Scheme local variable so that redirecting output in one thread does (in support of Racket) makes dynamic binding and lookup not interfere with other threads. If the host language sup- constant-time and fast, preserves the performance of Chez ports exceptions, then a form analogous to try–finally is Scheme’s first-class continuations, and imposes negligible needed to ensure that stdout is reset on an exception escape. overhead on program fragments that do not use first-class If the host language supports proper handling of tail calls, continuations or marks. then func no longer can be called in tail position (in contrast CCS Concepts: • Software and its engineering ! Com- to passing the output stream explicitly to func and having pilers; Runtime environments; Control structures. it threaded throughout func’s computation), which might limit the use of this kind of redirection. If the host language Keywords: Dynamic binding, context inspection supports first-class continuations, then in case a continua- tion is captured during the call to func, stdout should be ACM Reference Format: set and restored using a mechanism like Scheme’s dynamic- Matthew Flatt and R. Kent Dybvig. 2020. Compiler and Runtime wind (which is a kind of generalization of try–finally), Support for Continuation Marks. In Proceedings of the 41st ACM but that adds a winding cost for jumping into or out of a SIGPLAN International Conference on Programming Language De- sign and Implementation (PLDI ’20), June 15–20, 2020, London, UK. continuation. ACM, New York, NY, USA, 14 pages. https://doi.org/10.1145/3385412. All of these issues are related to using global state to track 3385981 an intent about a program’s dynamic extent. A language implementation must already include some explicit repre- sentation of dynamic extent as a continuation, whether or not that continuation is exposed as a first-class value. The con- PLDI ’20, June 15–20, 2020, London, UK tinuation may be implemented as a call stack, for example. © 2020 Copyright held by the owner/author(s). Publication rights licensed The language implementer must have taken care to select to ACM. a representation of the continuation that is efficient and ex- This is the author’s version of the work. It is posted here for your personal pressive enough for the language’s control constructs. So, use. Not for redistribution. The definitive Version of Record was published instead of having users of a language track dynamic extent in Proceedings of the 41st ACM SIGPLAN International Conference on Pro- gramming Language Design and Implementation (PLDI ’20), June 15–20, 2020, through external state, the language should include built-in London, UK, https://doi.org/10.1145/3385412.3385981. constructs to reflect on continuations, provided that support- ing these additional constructs does not unduly burden the PLDI ’20, June 15–20, 2020, London, UK Matthew Flatt and R. Kent Dybvig implementation. Built-in operations enable a more expres- same as for delimited continuations with tagged prompts. sive and efficient implementation that takes advantage of Although all control and binding constructs (including con- internal representations of continuations. tinuation marks) can be encoded with effect handlers or In Racket, the output-redirection example is written delimited continuations, recent work on effect handlers in- cludes direct semantic support for specialized constructs, (parameterize([current-output-port f-output]) partly on the grounds that they can be more efficient [9, (func)) 10] including for dynamic binding [5]. We are following a where current-output-port is defined to hold a dynami- similar path, but with a baseline implementation of contin- cally scoped binding, and that binding is used by functions uations that tends to be much faster already compared to like printf. In this example, the output stream is set to f- other existing implementations. output during the call to func, which is called in tail position Contributions in this paper: with respect to the parameterize form and might capture • We offer the first report on implementing direct com- its continuation. If it does capture the continuation, the dy- piler and runtime support for continuation marks. namic binding of current-output-port to f-output sticks • We demonstrate that the implementation of continu- with the continuation without increasing the cost of captur- ation marks is compatible with a high-performance ing or restoring the continuation. The parameterize form implementation of first-class, delimited continuations. is a library-implemented language extension (i.e., a macro), • We demonstrate that compiler and runtime support but it relies on a lower-level form that is built into the core for continuation marks can improve the performance language and compiler: continuation marks [7]. of applications. Like closures, tail calls, and first-class continuations, con- tinuation marks enable useful language extensions without 2 Using Continuations Marks further changes to the compiler’s core language. Continua- The core Racket constructs for continuation marks include tion marks in Racket have been used to implement dynamic operations to set a mark on the current continuation and to binding [17], debugging [8, 22], profiling [1], generators [16 get marks of any continuation. §4.14.3, 26], serializable continuations in a web server [23], security contracts [24], and space-efficient contracts [14]. 2.1 Setting Marks To support a Racket implementation on Chez Scheme [15], we add continuation attachments to the Chez Scheme com- The expression form piler and runtime system. This even-simpler core construct (with-continuation-mark key val body) supports a layer that implements Racket’s rich language of maps key to val in the current continuation and evaluates continuation marks and delimited continuations [17], which body in tail position. Since body is in tail position, its value in turn supports Racket’s ecosystem of library-implemented is the result of the with-continuation-mark expression. languages and language extensions. The performance of con- For example, tinuation marks in Racket on Chez Scheme compares favor- ably with the traditional implementation of Racket, which (with-continuation-mark 'team-color "red" (player-desc)) sacrifices some performance on every non-tail call to provide better performance for continuation marks. produces the result of calling player-desc while the key Our implementation of continuation attachments for Chez 'team-color is mapped to the value "red" during the call. Scheme is nearly pay-as-you go, imposing a small cost on pro- If key is already mapped to a value in the current contin- grams that use first-class continuations and dynamic-wind uation frame, then with-continuation-mark replaces the and no cost on programs that do not use them (or continua- old mapping in that frame. If key is instead set in a more tion marks). The implementation is modest, touching about nested continuation frame, then the nested mapping for key 35 (of 18k) lines in Chez Scheme’s C-implemented kernel and is left in place while a new mapping is added to the current 500 (of 94k) lines in the Scheme-implemented compiler and frame. run-time system. Compiler-supported continuation attach- For example, in ments perform 3 to 20 times as fast as an implementation (with-continuation-mark 'team-color "red" without compiler support; for Racket on Chez Scheme, that (place-in-game improvement makes continuation marks perform generally (player-desc) better than in the original Racket implementation. (with-continuation-mark 'team-color "blue" (all-teams-desc)))) Relatively few languages currently offer first-class contin- uations, much less the richness of Racket’s control constructs. then the call to player-desc sees 'team-color mapped However, interest is growing around delimited continuations, to "red", while the call to (all-teams-desc) sees 'team- particularly in the form of algebraic effect handlers [25], and color immediately mapped to "blue" and also mapped the implementation strategies for effect handlers are the to "red" in a deeper continuation frame; overall, it sees Compiler and Runtime Support for Continuation Marks PLDI ’20, June 15–20, 2020, London, UK (list "blue" "red") as a list of mappings for 'team- (define(all-team-colors) color. Whether a list of mappings or only the newest map- (continuation-mark-set->list(current-continuation-marks) ping is relevant depends on how a key is used in a program.
Load more

Recommended publications
  • An Optimized R5RS Macro Expander
    An Optimized R5RS Macro Expander Sean Reque A thesis submitted to the faculty of Brigham Young University in partial fulfillment of the requirements for the degree of Master of Science Jay McCarthy, Chair Eric Mercer Quinn Snell Department of Computer Science Brigham Young University February 2013 Copyright c 2013 Sean Reque All Rights Reserved ABSTRACT An Optimized R5RS Macro Expander Sean Reque Department of Computer Science, BYU Master of Science Macro systems allow programmers abstractions over the syntax of a programming language. This gives the programmer some of the same power posessed by a programming language designer, namely, the ability to extend the programming language to fit the needs of the programmer. The value of such systems has been demonstrated by their continued adoption in more languages and platforms. However, several barriers to widespread adoption of macro systems still exist. The language Racket [6] defines a small core of primitive language constructs, including a powerful macro system, upon which all other features are built. Because of this design, many features of other programming languages can be implemented through libraries, keeping the core language simple without sacrificing power or flexibility. However, slow macro expansion remains a lingering problem in the language's primary implementation, and in fact macro expansion currently dominates compile times for Racket modules and programs. Besides the typical problems associated with slow compile times, such as slower testing feedback, increased mental disruption during the programming process, and unscalable build times for large projects, slow macro expansion carries its own unique problems, such as poorer performance for IDEs and other software analysis tools.
    [Show full text]
  • Bisimulations for Delimited-Control Operators
    Logical Methods in Computer Science Volume 15, Issue 2, 2019, pp. 18:1–18:57 Submitted Apr. 24, 2018 https://lmcs.episciences.org/ Published May 24, 2019 BISIMULATIONS FOR DELIMITED-CONTROL OPERATORS DARIUSZ BIERNACKI a, SERGUE¨I LENGLET b, AND PIOTR POLESIUK a a University of Wroclaw e-mail address: fdabi,[email protected] b Universit´ede Lorraine e-mail address: [email protected] Abstract. We present a comprehensive study of the behavioral theory of an untyped λ-calculus extended with the delimited-control operators shift and reset. To that end, we define a contextual equivalence for this calculus, that we then aim to characterize with coinductively defined relations, called bisimilarities. We consider different styles of bisimilarities (namely applicative, normal-form, and environmental) within a unifying framework, and we give several examples to illustrate their respective strengths and weaknesses. We also discuss how to extend this work to other delimited-control operators. 1. Introduction Delimited-control operators. Control operators for delimited continuations enrich a pro- gramming language with the ability to delimit the current continuation, to capture such a delimited continuation, and to compose delimited continuations. Such operators have been originally proposed independently by Felleisen [26] and by Danvy and Filinski [21], with nu- merous variants designed subsequently [34, 66, 32, 25]. The applications of delimited-control operators range from non-deterministic programming [21, 45], partial evaluation [58, 19], and normalization by evaluation [24] to concurrency [34], mobile code [89], linguistics [84], oper- ating systems [43], and probabilistic programming [44]. Several variants of delimited-control operators are nowadays available in mainstream functional languages such as Haskell [25], OCaml [42], Racket [29], and Scala [76].
    [Show full text]
  • An Operational Foundation for Delimited Continuations in the Cps Hierarchy
    Logical Methods in Computer Science Vol. 1 (2:5) 2005, pp. 1–39 Submitted Apr. 1, 2005 www.lmcs-online.org Published Nov. 8, 2005 AN OPERATIONAL FOUNDATION FOR DELIMITED CONTINUATIONS IN THE CPS HIERARCHY MALGORZATA BIERNACKA, DARIUSZ BIERNACKI, AND OLIVIER DANVY BRICS, Department of Computer Science, University of Aarhus IT-parken, Aabogade 34, DK-8200 Aarhus N, Denmark e-mail address: {mbiernac,dabi,danvy}@brics.dk Abstract. We present an abstract machine and a reduction semantics for the lambda- calculus extended with control operators that give access to delimited continuations in the CPS hierarchy. The abstract machine is derived from an evaluator in continuation- passing style (CPS); the reduction semantics (i.e., a small-step operational semantics with an explicit representation of evaluation contexts) is constructed from the abstract machine; and the control operators are the shift and reset family. We also present new applications of delimited continuations in the CPS hierarchy: finding list prefixes and normalization by evaluation for a hierarchical language of units and products. 1. Introduction The studies of delimited continuations can be classified in two groups: those that use continuation-passing style (CPS) and those that rely on operational intuitions about con- trol instead. Of the latter, there is a large number proposing a variety of control opera- tors [5,37,40,41,49,52,53,65,70,74,80] which have found applications in models of control, concurrency, and type-directed partial evaluation [8,52,75]. Of the former, there is the work revolving around the family of control operators shift and reset [27–29,32,42,43,55,56,66,80] which have found applications in non-deterministic programming, code generation, par- tial evaluation, normalization by evaluation, computational monads, and mobile comput- ing [6,7,9,17,22,23,33,34,44,46,48,51,57,59,61,72,77–79].
    [Show full text]
  • Hy Documentation Release 0.12.1+64.G5eb9283
    hy Documentation Release 0.12.1+64.g5eb9283 Paul Tagliamonte Apr 14, 2017 Contents 1 Documentation Index 3 1.1 Quickstart................................................4 1.2 Tutorial..................................................5 1.2.1 Basic intro to Lisp for Pythonistas...............................5 1.2.2 Hy is a Lisp-flavored Python..................................7 1.2.3 Macros............................................. 12 1.2.4 Hy <-> Python interop..................................... 13 1.2.5 Protips!............................................. 14 1.3 Hy Style Guide.............................................. 14 1.3.1 Prelude............................................. 15 1.3.2 Layout & Indentation...................................... 15 1.3.3 Coding Style.......................................... 16 1.3.4 Conclusion........................................... 17 1.3.5 Thanks............................................. 17 1.4 Documentation Index.......................................... 18 1.4.1 Command Line Interface.................................... 18 1.4.2 Hy <-> Python interop..................................... 19 1.4.3 Hy (the language)........................................ 21 1.4.4 Hy Core............................................. 47 1.4.5 Reader Macros......................................... 65 1.4.6 Internal Hy Documentation................................... 66 1.5 Extra Modules Index........................................... 72 1.5.1 Anaphoric Macros....................................... 72 1.5.2
    [Show full text]
  • The Evolution of Lisp
    1 The Evolution of Lisp Guy L. Steele Jr. Richard P. Gabriel Thinking Machines Corporation Lucid, Inc. 245 First Street 707 Laurel Street Cambridge, Massachusetts 02142 Menlo Park, California 94025 Phone: (617) 234-2860 Phone: (415) 329-8400 FAX: (617) 243-4444 FAX: (415) 329-8480 E-mail: [email protected] E-mail: [email protected] Abstract Lisp is the world’s greatest programming language—or so its proponents think. The structure of Lisp makes it easy to extend the language or even to implement entirely new dialects without starting from scratch. Overall, the evolution of Lisp has been guided more by institutional rivalry, one-upsmanship, and the glee born of technical cleverness that is characteristic of the “hacker culture” than by sober assessments of technical requirements. Nevertheless this process has eventually produced both an industrial- strength programming language, messy but powerful, and a technically pure dialect, small but powerful, that is suitable for use by programming-language theoreticians. We pick up where McCarthy’s paper in the first HOPL conference left off. We trace the development chronologically from the era of the PDP-6, through the heyday of Interlisp and MacLisp, past the ascension and decline of special purpose Lisp machines, to the present era of standardization activities. We then examine the technical evolution of a few representative language features, including both some notable successes and some notable failures, that illuminate design issues that distinguish Lisp from other programming languages. We also discuss the use of Lisp as a laboratory for designing other programming languages. We conclude with some reflections on the forces that have driven the evolution of Lisp.
    [Show full text]
  • Continuation Passing Style for Effect Handlers
    Continuation Passing Style for Effect Handlers Daniel Hillerström1, Sam Lindley2, Robert Atkey3, and KC Sivaramakrishnan4 1 The University of Edinburgh, United Kingdom [email protected] 2 The University of Edinburgh, United Kingdom [email protected] 3 University of Strathclyde, United Kingdom [email protected] 4 University of Cambridge, United Kingdom [email protected] Abstract We present Continuation Passing Style (CPS) translations for Plotkin and Pretnar’s effect han- dlers with Hillerström and Lindley’s row-typed fine-grain call-by-value calculus of effect handlers as the source language. CPS translations of handlers are interesting theoretically, to explain the semantics of handlers, and also offer a practical implementation technique that does not require special support in the target language’s runtime. We begin with a first-order CPS translation into untyped lambda calculus which manages a stack of continuations and handlers as a curried sequence of arguments. We then refine the initial CPS translation first by uncurrying it to yield a properly tail-recursive translation and second by making it higher-order in order to contract administrative redexes at translation time. We prove that the higher-order CPS translation simulates effect handler reduction. We have implemented the higher-order CPS translation as a JavaScript backend for the Links programming language. 1998 ACM Subject Classification D.3.3 Language Constructs and Features, F.3.2 Semantics of Programming Languages Keywords and phrases effect handlers, delimited control, continuation passing style Digital Object Identifier 10.4230/LIPIcs.FSCD.2017.18 1 Introduction Algebraic effects, introduced by Plotkin and Power [25], and their handlers, introduced by Plotkin and Pretnar [26], provide a modular foundation for effectful programming.
    [Show full text]
  • An Industrial Strength Theorem Prover for a Logic Based on Common Lisp
    An Industrial Strength Theorem Prover for a Logic Based on Common Lisp y z Matt Kaufmannand J Strother Moore Personal use of this material is permitted. particular style of formal veri®cation that has shown consid- However, permission to reprint/republish this erable promise in recent years is the use of general-purpose material for advertising or promotional pur- automated reasoning systems to model systems and prove poses or for creating new collective works for properties of them. Every such reasoning system requires resale or redistribution to servers or lists, or considerable assistance from the user, which makes it im- to reuse any copyrighted component of this portant that the system provide convenient ways for the user work in other works must be obtained from the to interact with it. IEEE.1 One state-of-the-art general-purpose automated reason- ing system is ACL2: ªA Computational Logic for Applica- AbstractÐACL2 is a re-implemented extended version tive Common Lisp.º A number of automated reasoning of Boyer and Moore's Nqthm and Kaufmann's Pc-Nqthm, systems now exist, as we discuss below (Subsection 1.1). In intended for large scale veri®cation projects. This paper this paper we describe ACL2's offerings to the user for con- deals primarily with how we scaled up Nqthm's logic to an venientªindustrial-strengthºuse. WebegininSection2with ªindustrial strengthº programming language Ð namely, a a history of theACL2 project. Next, Section 3 describes the large applicative subset of Common Lisp Ð while preserv- logic supportedby ACL2, which has been designed for con- ing the use of total functions within the logic.
    [Show full text]
  • Structured Foreign Types
    Ftypes: Structured foreign types Andrew W. Keep R. Kent Dybvig Indiana University fakeep,[email protected] Abstract When accessing scalar elements within an ftype, the value of the High-level programming languages, like Scheme, typically repre- scalar is automatically marshaled into the equivalent Scheme rep- sent data in ways that differ from the host platform to support resentation. When setting scalar elements, the Scheme value is consistent behavior across platforms and automatic storage man- checked to ensure compatibility with the specified foreign type, and agement, i.e., garbage collection. While crucial to the program- then marshaled into the equivalent foreign representation. Ftypes ming model, differences in data representation can complicate in- are well integrated into the system, with compiler support for ef- teraction with foreign programs and libraries that employ machine- ficient access to foreign data and debugger support for convenient dependent data structures that do not readily support garbage col- inspection of foreign data. lection. To bridge this gap, many high-level languages feature for- The ftype syntax is convenient and flexible. While it is similar in eign function interfaces that include some ability to interact with some ways to foreign data declarations in other Scheme implemen- foreign data, though they often do not provide complete control tations, and language design is largely a matter of taste, we believe over the structure of foreign data, are not always fully integrated our syntax is cleaner and more intuitive than most. Our system also into the language and run-time system, and are often not as effi- has a more complete set of features, covering all C data types along cient as possible.
    [Show full text]
  • Chez Scheme Version 5 Release Notes Copyright C 1994 Cadence Research Systems All Rights Reserved October 1994 Overview 1. Funct
    Chez Scheme Version 5 Release Notes Copyright c 1994 Cadence Research Systems All Rights Reserved October 1994 Overview This document outlines the changes made to Chez Scheme for Version 5 since Version 4. New items include support for syntax-case and revised report high-level lexical macros, support for multiple values, support for guardians and weak pairs, support for generic ports, improved trace output, support for shared incremental heaps, support for passing single floats to and returning single floats from foreign procedures, support for passing structures to and returning structures from foreign procedures on MIPS-based computers, and various performance enhancements, including a dramatic improvement in the time it takes to load Scheme source and object files on DEC Ultrix MIPS-based computers. Overall performance of generated code has increased by an average of 15–50 percent over Version 4 depending upon optimize level and programming style. Programs that make extensive use of locally-defined procedures will benefit more than programs that rely heavily on globally-defined procedures, and programs compiled at higher optimize levels will improve more than programs compiled at lower optimize levels. Compile time is approximately 25 percent faster. Refer to the Chez Scheme System Manual, Revision 2.5 for detailed descriptions of the new or modified procedures and syntactic forms mentioned in these notes. Version 5 is available for the following platforms: • Sun Sparc SunOS 4.X & Solaris 2.X • DEC Alpha AXP OSF/1 V2.X • Silicon Graphics IRIX 5.X • Intel 80x86 NeXT Mach 3.2 • Motorola Delta MC88000 SVR3 & SVR4 • Decstation/Decsystem Ultrix 4.3A • Intel 80x86 BSDI BSD/386 1.1 • Intel 80x86 Linux This document contains four sections describing (1) functionality enhancements, (2) performance enhance- ments, (3) bugs fixed, and (4) compatibility issues.
    [Show full text]
  • Drscheme: a Pedagogic Programming Environment for Scheme
    DrScheme A Pedagogic Programming Environment for Scheme Rob ert Bruce Findler Cormac Flanagan Matthew Flatt Shriram Krishnamurthi and Matthias Felleisen Department of Computer Science Rice University Houston Texas Abstract Teaching intro ductory computing courses with Scheme el evates the intellectual level of the course and thus makes the sub ject more app ealing to students with scientic interests Unfortunatelythe p o or quality of the available programming environments negates many of the p edagogic advantages Toovercome this problem wehavedevel op ed DrScheme a comprehensive programming environmentforScheme It fully integrates a graphicsenriched editor a multilingua l parser that can pro cess a hierarchyofsyntactically restrictivevariants of Scheme a functional readevalprint lo op and an algebraical ly sensible printer The environment catches the typical syntactic mistakes of b eginners and pinp oints the exact source lo cation of runtime exceptions DrScheme also provides an algebraic stepp er a syntax checker and a static debugger The rst reduces Scheme programs including programs with assignment and control eects to values and eects The to ol is useful for explainin g the semantics of linguistic facilities and for studying the b ehavior of small programs The syntax c hecker annotates programs with fontandcolorchanges based on the syntactic structure of the pro gram It also draws arrows on demand that p oint from b ound to binding o ccurrences of identiers The static debugger roughly sp eaking pro vides a typ e inference system
    [Show full text]
  • Supplementary Material Forrebuilding Racket on Chez Scheme
    Supplementary Material for Rebuilding Racket on Chez Scheme (Experience Report) MATTHEW FLATT, University of Utah, USA CANER DERICI, Indiana University, USA R. KENT DYBVIG, Cisco Systems, Inc., USA ANDREW W. KEEP, Cisco Systems, Inc., USA GUSTAVO E. MASSACCESI, Universidad de Buenos Aires, Argentina SARAH SPALL, Indiana University, USA SAM TOBIN-HOCHSTADT, Indiana University, USA JON ZEPPIERI, independent researcher, USA All benchmark measurements were performed on an Intel Core i7-2600 3.4GHz processor running 64-bit Linux. Except as specifically noted, we used Chez Scheme 9.5.3 commit 7df2fb2e77 at github:cicso/ChezScheme, modified as commit 6d05b70e86 at github:racket/ChezScheme, and Racket 7.3.0.3 as commit ff95f1860a at github:racket/racket. 1 TRADITIONAL SCHEME BENCHMARKS The traditional Scheme benchmarks in figure1 are based on a suite of small programs that have been widely used to compare Scheme implementations. The benchmark sources are in the "common" directory of the racket-benchmarks package in the Racket GitHub repository. The results are in two groups, where the group starting with scheme-c uses mutable pairs, so they are run in Racket as #lang r5rs programs; for Racket CS we expect overhead due to the use of a record datatype for mutable pairs, instead of Chez Scheme’s built-in pairs. The groups are sorted by the ratio of times for Chez Scheme and the current Racket imple- mentation. Note that the break-even point is near the end of the first group. The racket collatz benchmark turns out to mostly measure the performance of the built-in division operator for rational numbers, while fft and nucleic benefit from flonum unboxing.
    [Show full text]
  • Mixing R with Other Languages JOHN D
    Mixing R with other languages JOHN D. COOK, PHD SINGULAR VALUE CONSULTING Why R? Libraries, libraries, libraries De facto standard for statistical research Nice language, as far as statistical languages go “Quirky, flawed, and an enormous success.” Why mix languages? Improve performance of R code Execution speed (e.g. loops) Memory management Raid R’s libraries How to optimize R Vectorize Rewrite not using R A few R quirks Everything is a vector Everything can be null or NA Unit-offset vectors Zero index legal but strange Negative indices remove elements Matrices filled by column by default $ acts like dot, dot not special C package interface Must manage low-level details of R object model and memory Requires Rtools on Windows Lots of macros like REALSXP, PROTECT, and UNPROTECT Use C++ (Rcpp) instead “I do not recommend using C for writing new high-performance code. Instead write C++ with Rcpp.” – Hadley Wickham Rcpp The most widely used extension method for R Call C, C++, or Fortran from R Companion project RInside to call R from C++ Extensive support even for advanced C++ Create R packages or inline code http://rcpp.org Dirk Eddelbuettel’s book Simple Rcpp example library(Rcpp) cppFunction('int add(int x, int y, int z) { int sum = x + y + z; return sum; }') add(1, 2, 3) .NET RDCOM http://sunsite.univie.ac.at/rcom/ F# type provider for R http://bluemountaincapital.github.io/FSharpRProvider/ R.NET https://rdotnet.codeplex.com/ SQL Server 2016 execute sp_execute_external_script @language = N'R' , @script =
    [Show full text]