DOCSLIB.ORG

Practical Partial Evaluation for High-Performance Dynamic Language Runtimes

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Practical Partial Evaluation for High-Performance Dynamic Language Runtimes Practical Partial Evaluation for High-Performance Dynamic Language Runtimes Thomas Wurthinger¨ ∗ Christian Wimmer∗ Christian Humer∗ Andreas Woߨ ∗ Lukas Stadler∗ Chris Seaton∗ Gilles Duboscq∗ Doug Simon∗ Matthias Grimmery ∗ y Oracle Labs Institute for System Software, Johannes Kepler University Linz, Austria fthomas.wuerthinger, christian.wimmer, christian.humer, andreas.woess, lukas.stadler, chris.seaton, gilles.m.duboscq, [email protected] [email protected] Abstract was first implemented for the SELF language [23]: a multi- Most high-performance dynamic language virtual machines tier optimization system with adaptive optimization and de- duplicate language semantics in the interpreter, compiler, optimization. Multiple tiers increase the implementation and and runtime system, violating the principle to not repeat maintenance costs for a VM: In addition to a language- yourself. In contrast, we define languages solely by writ- specific optimizing compiler, a separate first-tier execution ing an interpreter. Compiled code is derived automatically system must be implemented [2, 4, 21]. Even though the using partial evaluation (the first Futamura projection). The complexity of an interpreter or a baseline compiler is lower interpreter performs specializations, e.g., augments the in- than the complexity of an optimizing compiler, implement- terpreted program with type information and profiling infor- ing them is far from trivial [45]. Additionally, they need to mation. Partial evaluation incorporates these specializations. be maintained and ported to new architectures. This makes partial evaluation practical in the context of dy- But more importantly, the semantics of a language need namic languages, because it reduces the size of the compiled to be implemented multiple times in different styles: For code while still compiling in all parts of an operation that are the first-tier interpreter or baseline compiler, language op- relevant for a particular program. Deoptimization to the in- erations are usually implemented as templates of assem- terpreter, re-specialization in the interpreter, and recompila- bler code. For the second-tier optimizing compiler, language tion embrace the dynamic nature of languages. We evaluate operations are implemented as graphs of language-specific our approach comparing newly built JavaScript, Ruby, and compiler intermediate representation. For the runtime sys- R runtimes with current specialized production implementa- tem (code called from the interpreter or compiled code us- tions of those languages. Our general purpose compilation ing runtime calls), language operations are implemented in system is competitive with production systems even when C or C++. they have been heavily specialized and optimized for one We implement the language semantics only once in a sim- language. ple form: as a language interpreter written in a managed high-level host language. Optimized compiled code is de- Categories and Subject Descriptors D.3.4 [Programming rived from the interpreter using partial evaluation. This ap- Languages]: Processors—Run-time environments proach and its obvious benefits have been described already Keywords dynamic languages; virtual machine; language in 1971 as the first Futamura projection [14]. Still, to the best implementation; optimization; partial evaluation of our knowledge no high-performance dynamic language implementation has used this approach so far. 1. Introduction We believe that a simple partial evaluation of a dynamic High-performance virtual machines (VMs) such as the Java language interpreter cannot lead to high-performance com- HotSpot VM or the V8 JavaScript VM follow the design that piled code: if the complete semantics for a language oper- ation are included during partial evaluation, the size of the compiled code explodes; if language operations are not in- cluded during partial evaluation and remain runtime calls, performance is mediocre. To overcome these inherent prob- lems, we write the interpreter in a style that anticipates and embraces partial evaluation. The interpreter specializes the executed instructions, e.g., collects type information and [Copyright notice will appear here once ’preprint’ option is removed.] profiling information. The compiler speculates that the inter- 1 2016/11/16 preter state is stable and creates highly optimized and com- regular call pact machine code. If a speculation turns out to be wrong, runtime g i code transfer to interpreter i.e., was too optimistic, execution transfers back to the in- f h PE boundary call terpreter. The interpreter updates the information, so that the e next partial evaluation is less speculative. interpreter host language method This paper shows that a few core primitives are sufficient code d to communicate all necessary information from the inter- preter to the partial evaluator. We present our set of primi- c b dx1 bx2 tives that allow us to implement a wide variety of dynamic bx1 cx1 by1 cy1 languages. Note that we do not claim that our primitives are a ax1 ay1 necessary, i.e., the only way to make partial evaluation of dynamic language interpreters work in practice. interpreter entry compiled code compiled code function x() function y() Closely related to our approach is PyPy [6, 8, 36], which also requires the language implementer to only write an Figure 1: Interactions of interpreter code, compiled code, interpreter to express language semantics. However, PyPy and runtime code. does not use partial evaluation to derive compiled code from the interpreter, but meta-tracing: a trace-based compiler ob- serves the running interpreter (see Section 9 for details). the guest language interpreter methods (code) and the inter- In summary, this paper contributes the following: preted program (data). The interpreted program are all the data structures used by the interpreter, e.g., interpreter in- • We present core primitives that make partial evaluation structions organized as an abstract syntax tree. The language of dynamic language interpreters work in practice. They implementer does not have to provide any additional lan- allow a language-agnostic dynamic compiler to generate guage specific input to the language-independent optimizing high-performance code. compiler. • We present details of the partial evaluation algorithm and In dynamic languages, the full semantics of seemingly show which compiler optimizations are essential after simple operations are complex. For example, addition in partial evaluation. JavaScript can be as simple as the addition of two numbers. • We show that our approach works in practice by compar- But it can also be string concatenation and involve the in- ing our language implementations with the best produc- vocation of complex conversion functions that convert arbi- tion implementations of JavaScript, Ruby, and R. trary object inputs to numbers or strings. Addition in Ruby can again be just the addition of two numbers, but also the 2. System Structure invocation of an arbitrary addition method that can be rede- fined at any time. Addition in R can be just the addition of guest language We implement many different s in a managed two vectors of numbers, but also involve a complex method host language . Only the interpreter and the runtime system lookup based on the classes of its arguments. We claim that for a guest language is implemented anew by the language a simple PE that always captures the full semantics of every developer. Our framework and the host language provide a operation in compiled code is infeasible: it either leads to core set of reusable host services, such as dynamic com- code explosion if all code for the operation is compiled, or pilation (the focus of this paper), automatic memory man- mediocre performance when only parts of the operation are agement, threads, synchronization primitives, and a well- compiled and runtime calls remain in the compiled code for defined memory model. the full semantics. For the concrete examples and the evaluation of this pa- We solve this problem by making the interpreter aware of per, we implemented multiple guest languages (JavaScript, PE. While interpreting an operation, the interpreter special- Ruby, and R) in the host language Java. We require only one izes the instructions, e.g., collects type information or pro- implementation for every guest language operation. Since filing information. In other words, for each instruction the the interpreter and the runtime system are written in the same interpreter stores which subset of the semantics is actually managed host language, there is no strict separation between used. PE uses the specialization information. For this, the them. Regular method calls are used to call the runtime from instructions are assumed to be in a stable state where sub- the interpreter. sequent changes are unlikely, although not prohibited. PE Optimized compiled code is inferred from the interpreter eliminates the interpreter dispatch code and produces opti- Partial evaluation using partial evaluation. (PE) is the pro- mized machine code for a guest language function. cess of creating the initial high-level compiler intermedi- 1 Figure 1 illustrates the interactions of interpreter code, ate representation (IR) for a guest language function from compiled code, and runtime code. The interpreter methods 1 To distinguish the languages in this paper, function always refers to the a to d call each other, and call the runtime methods e to guest language while method always refers to the host language i. Two guest language
Load more

Recommended publications
  • The LLVM Instruction Set and Compilation Strategy
    The LLVM Instruction Set and Compilation Strategy Chris Lattner Vikram Adve University of Illinois at Urbana-Champaign lattner,vadve ¡ @cs.uiuc.edu Abstract This document introduces the LLVM compiler infrastructure and instruction set, a simple approach that enables sophisticated code transformations at link time, runtime, and in the field. It is a pragmatic approach to compilation, interfering with programmers and tools as little as possible, while still retaining extensive high-level information from source-level compilers for later stages of an application’s lifetime. We describe the LLVM instruction set, the design of the LLVM system, and some of its key components. 1 Introduction Modern programming languages and software practices aim to support more reliable, flexible, and powerful software applications, increase programmer productivity, and provide higher level semantic information to the compiler. Un- fortunately, traditional approaches to compilation either fail to extract sufficient performance from the program (by not using interprocedural analysis or profile information) or interfere with the build process substantially (by requiring build scripts to be modified for either profiling or interprocedural optimization). Furthermore, they do not support optimization either at runtime or after an application has been installed at an end-user’s site, when the most relevant information about actual usage patterns would be available. The LLVM Compilation Strategy is designed to enable effective multi-stage optimization (at compile-time, link-time, runtime, and offline) and more effective profile-driven optimization, and to do so without changes to the traditional build process or programmer intervention. LLVM (Low Level Virtual Machine) is a compilation strategy that uses a low-level virtual instruction set with rich type information as a common code representation for all phases of compilation.
    [Show full text]
  • A Status Update of BEAMJIT, the Just-In-Time Compiling Abstract Machine
    A Status Update of BEAMJIT, the Just-in-Time Compiling Abstract Machine Frej Drejhammar and Lars Rasmusson <ffrej,[email protected]> 140609 Who am I? Senior researcher at the Swedish Institute of Computer Science (SICS) working on programming tools and distributed systems. Acknowledgments Project funded by Ericsson AB. Joint work with Lars Rasmusson <[email protected]>. What this talk is About An introduction to how BEAMJIT works and a detailed look at some subtle details of its implementation. Outline Background BEAMJIT from 10000m BEAMJIT-aware Optimization Compiler-supported Profiling Future Work Questions Just-In-Time (JIT) Compilation Decide at runtime to compile \hot" parts to native code. Fairly common implementation technique. McCarthy's Lisp (1969) Python (Psyco, PyPy) Smalltalk (Cog) Java (HotSpot) JavaScript (SquirrelFish Extreme, SpiderMonkey, J¨agerMonkey, IonMonkey, V8) Motivation A JIT compiler increases flexibility. Tracing does not require switching to full emulation. Cross-module optimization. Compiled BEAM modules are platform independent: No need for cross compilation. Binaries not strongly coupled to a particular build of the emulator. Integrates naturally with code upgrade. Project Goals Do as little manual work as possible. Preserve the semantics of plain BEAM. Automatically stay in sync with the plain BEAM, i.e. if bugs are fixed in the interpreter the JIT should not have to be modified manually. Have a native code generator which is state-of-the-art. Eventually be better than HiPE (steady-state). Plan Use automated tools to transform and extend the BEAM. Use an off-the-shelf optimizer and code generator. Implement a tracing JIT compiler. BEAM: Specification & Implementation BEAM is the name of the Erlang VM.
    [Show full text]
  • Rubyperf.Pdf
    Ruby Performance. Tips, Tricks & Hacks Who am I? • Ezra Zygmuntowicz (zig-mun-tuv-itch) • Rubyist for 4 years • Engine Yard Founder and Architect • Blog: http://brainspl.at Ruby is Slow Ruby is Slow?!? Well, yes and no. The Ruby Performance Dichotomy Framework Code VS Application Code Benchmarking: The only way to really know performance characteristics Profiling: Measure don’t guess. ruby-prof What is all this good for in real life? Merb Merb Like most useful code it started as a hack, Merb == Mongrel + Erb • No cgi.rb !! • Clean room implementation of ActionPack • Thread Safe with configurable Mutex Locks • Rails compatible REST routing • No Magic( well less anyway ;) • Did I mention no cgi.rb? • Fast! On average 2-4 times faster than rails Design Goals • Small core framework for the VC in MVC • ORM agnostic, use ActiveRecord, Sequel, DataMapper or roll your own db access. • Prefer simple code over magic code • Keep the stack traces short( I’m looking at you alias_method_chain) • Thread safe, reentrant code Merb Hello World No code is faster then no code • Simplicity and clarity trumps magic every time. • When in doubt leave it out. • Core framework to stay small and simple and easy to extend without gross hacks • Prefer plugins for non core functionality • Plugins can be gems Key Differences • No auto-render. The return value of your controller actions is what gets returned to client • Merb’s render method just returns a string, allowing for multiple renders and more flexibility • PartController’s allow for encapsualted applets without big performance cost Why not work on Rails instead of making a new framework? • Originally I was trying to optimize Rails and make it more thread safe.
    [Show full text]
  • 1 Lecture 25
    I. Goals of This Lecture Lecture 25 • Beyond static compilation • Example of a complete system Dynamic Compilation • Use of data flow techniques in a new context • Experimental approach I. Motivation & Background II. Overview III. Compilation Policy IV. Partial Method Compilation V. Partial Dead Code Elimination VI. Escape Analysis VII. Results “Partial Method Compilation Using Dynamic Profile Information”, John Whaley, OOPSLA 01 (Slide content courtesy of John Whaley & Monica Lam.) Carnegie Mellon Carnegie Mellon Todd C. Mowry 15-745: Dynamic Compilation 1 15-745: Dynamic Compilation 2 Todd C. Mowry Static/Dynamic High-Level/Binary • Compiler: high-level à binary, static • Binary translator: Binary-binary; mostly dynamic • Interpreter: high-level, emulate, dynamic – Run “as-is” – Software migration • Dynamic compilation: high-level à binary, dynamic (x86 à alpha, sun, transmeta; 68000 à powerPC à x86) – machine-independent, dynamic loading – Virtualization (make hardware virtualizable) – cross-module optimization – Dynamic optimization (Dynamo Rio) – specialize program using runtime information – Security (execute out of code in a cache that is “protected”) • without profiling Carnegie Mellon Carnegie Mellon 15-745: Dynamic Compilation 3 Todd C. Mowry 15-745: Dynamic Compilation 4 Todd C. Mowry 1 Closed-world vs. Open-world II. Overview of Dynamic Compilation • Closed-world assumption (most static compilers) • Interpretation/Compilation policy decisions – all code is available a priori for analysis and compilation. – Choosing what and how to compile • Open-world assumption (most dynamic compilers) • Collecting runtime information – code is not available – Instrumentation – arbitrary code can be loaded at run time. – Sampling • Open-world assumption precludes many optimization opportunities. • Exploiting runtime information – Solution: Optimistically assume the best case, but provide a way out – frequently-executed code paths if necessary.
    [Show full text]
  • Dynamic Extension of Typed Functional Languages
    Dynamic Extension of Typed Functional Languages Don Stewart PhD Dissertation School of Computer Science and Engineering University of New South Wales 2010 Supervisor: Assoc. Prof. Manuel M. T. Chakravarty Co-supervisor: Dr. Gabriele Keller Abstract We present a solution to the problem of dynamic extension in statically typed functional languages with type erasure. The presented solution re- tains the benefits of static checking, including type safety, aggressive op- timizations, and native code compilation of components, while allowing extensibility of programs at runtime. Our approach is based on a framework for dynamic extension in a stat- ically typed setting, combining dynamic linking, runtime type checking, first class modules and code hot swapping. We show that this framework is sufficient to allow a broad class of dynamic extension capabilities in any statically typed functional language with type erasure semantics. Uniquely, we employ the full compile-time type system to perform run- time type checking of dynamic components, and emphasize the use of na- tive code extension to ensure that the performance benefits of static typing are retained in a dynamic environment. We also develop the concept of fully dynamic software architectures, where the static core is minimal and all code is hot swappable. Benefits of the approach include hot swappable code and sophisticated application extension via embedded domain specific languages. We instantiate the concepts of the framework via a full implementation in the Haskell programming language: providing rich mechanisms for dy- namic linking, loading, hot swapping, and runtime type checking in Haskell for the first time. We demonstrate the feasibility of this architecture through a number of novel applications: an extensible text editor; a plugin-based network chat bot; a simulator for polymer chemistry; and xmonad, an ex- tensible window manager.
    [Show full text]
  • Using JIT Compilation and Configurable Runtime Systems for Efficient Deployment of Java Programs on Ubiquitous Devices
    Using JIT Compilation and Configurable Runtime Systems for Efficient Deployment of Java Programs on Ubiquitous Devices Radu Teodorescu and Raju Pandey Parallel and Distributed Computing Laboratory Computer Science Department University of California, Davis {teodores,pandey}@cs.ucdavis.edu Abstract. As the proliferation of ubiquitous devices moves computation away from the conventional desktop computer boundaries, distributed systems design is being exposed to new challenges. A distributed system supporting a ubiquitous computing application must deal with a wider spectrum of hardware architectures featuring structural and functional differences, and resources limitations. Due to its architecture independent infrastructure and object-oriented programming model, the Java programming environment can support flexible solutions for addressing the diversity among these devices. Unfortunately, Java solutions are often associated with high costs in terms of resource consumption, which limits the range of devices that can benefit from this approach. In this paper, we present an architecture that deals with the cost and complexity of running Java programs by partitioning the process of Java program execution between system nodes and remote devices. The system nodes prepare a Java application for execution on a remote device by generating device-specific native code and application-specific runtime system on the fly. The resulting infrastructure provides the flexibility of a high-level programming model and the architecture independence specific to Java. At the same time the amount of resources consumed by an application on the targeted device are comparable to that of a native implementation. 1 Introduction As a result of the proliferation of computation into the physical world, ubiquitous computing [1] has become an important research topic.
    [Show full text]
  • Comparative Studies of Programming Languages; Course Lecture Notes
    Comparative Studies of Programming Languages, COMP6411 Lecture Notes, Revision 1.9 Joey Paquet Serguei A. Mokhov (Eds.) August 5, 2010 arXiv:1007.2123v6 [cs.PL] 4 Aug 2010 2 Preface Lecture notes for the Comparative Studies of Programming Languages course, COMP6411, taught at the Department of Computer Science and Software Engineering, Faculty of Engineering and Computer Science, Concordia University, Montreal, QC, Canada. These notes include a compiled book of primarily related articles from the Wikipedia, the Free Encyclopedia [24], as well as Comparative Programming Languages book [7] and other resources, including our own. The original notes were compiled by Dr. Paquet [14] 3 4 Contents 1 Brief History and Genealogy of Programming Languages 7 1.1 Introduction . 7 1.1.1 Subreferences . 7 1.2 History . 7 1.2.1 Pre-computer era . 7 1.2.2 Subreferences . 8 1.2.3 Early computer era . 8 1.2.4 Subreferences . 8 1.2.5 Modern/Structured programming languages . 9 1.3 References . 19 2 Programming Paradigms 21 2.1 Introduction . 21 2.2 History . 21 2.2.1 Low-level: binary, assembly . 21 2.2.2 Procedural programming . 22 2.2.3 Object-oriented programming . 23 2.2.4 Declarative programming . 27 3 Program Evaluation 33 3.1 Program analysis and translation phases . 33 3.1.1 Front end . 33 3.1.2 Back end . 34 3.2 Compilation vs. interpretation . 34 3.2.1 Compilation . 34 3.2.2 Interpretation . 36 3.2.3 Subreferences . 37 3.3 Type System . 38 3.3.1 Type checking . 38 3.4 Memory management .
    [Show full text]
  • Bohm2013.Pdf (3.003Mb)
    This thesis has been submitted in fulfilment of the requirements for a postgraduate degree (e.g. PhD, MPhil, DClinPsychol) at the University of Edinburgh. Please note the following terms and conditions of use: • This work is protected by copyright and other intellectual property rights, which are retained by the thesis author, unless otherwise stated. • A copy can be downloaded for personal non-commercial research or study, without prior permission or charge. • This thesis cannot be reproduced or quoted extensively from without first obtaining permission in writing from the author. • The content must not be changed in any way or sold commercially in any format or medium without the formal permission of the author. • When referring to this work, full bibliographic details including the author, title, awarding institution and date of the thesis must be given. Speeding up Dynamic Compilation Concurrent and Parallel Dynamic Compilation Igor B¨ohm I V N E R U S E I T H Y T O H F G E R D I N B U Doctor of Philosophy Institute of Computing Systems Architecture School of Informatics University of Edinburgh 2013 Abstract The main challenge faced by a dynamic compilation system is to detect and translate frequently executed program regions into highly efficient native code as fast as possible. To efficiently reduce dynamic compilation latency, a dy- namic compilation system must improve its workload throughput, i.e. com- pile more application hotspots per time. As time for dynamic compilation adds to the overall execution time, the dynamic compiler is often decoupled and operates in a separate thread independent from the main execution loop to reduce the overhead of dynamic compilation.
    [Show full text]
  • CDC Build System Guide
    CDC Build System Guide Java™ Platform, Micro Edition Connected Device Configuration, Version 1.1.2 Foundation Profile, Version 1.1.2 Optimized Implementation Sun Microsystems, Inc. www.sun.com December 2008 Copyright © 2008 Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, California 95054, U.S.A. All rights reserved. Sun Microsystems, Inc. has intellectual property rights relating to technology embodied in the product that is described in this document. In particular, and without limitation, these intellectual property rights may include one or more of the U.S. patents listed at http://www.sun.com/patents and one or more additional patents or pending patent applications in the U.S. and in other countries. U.S. Government Rights - Commercial software. Government users are subject to the Sun Microsystems, Inc. standard license agreement and applicable provisions of the FAR and its supplements. This distribution may include materials developed by third parties. Parts of the product may be derived from Berkeley BSD systems, licensed from the University of California. UNIX is a registered trademark in the U.S. and in other countries, exclusively licensed through X/Open Company, Ltd. Sun, Sun Microsystems, the Sun logo, Java, Solaris and HotSpot are trademarks or registered trademarks of Sun Microsystems, Inc. or its subsidiaries in the United States and other countries. The Adobe logo is a registered trademark of Adobe Systems, Incorporated. Products covered by and information contained in this service manual are controlled by U.S. Export Control laws and may be subject to the export or import laws in other countries. Nuclear, missile, chemical biological weapons or nuclear maritime end uses or end users, whether direct or indirect, are strictly prohibited.
    [Show full text]
  • Insert Here Your Thesis' Task
    Insert here your thesis' task. Czech Technical University in Prague Faculty of Information Technology Department of Software Engineering Master's thesis New Ruby parser and AST for SmallRuby Bc. Jiˇr´ıFajman Supervisor: Ing. Marcel Hlopko 18th February 2016 Acknowledgements I would like to thank to my supervisor Ing. Marcel Hlopko for perfect coop- eration and valuable advices. I would also like to thank to my family for support. Declaration I hereby declare that the presented thesis is my own work and that I have cited all sources of information in accordance with the Guideline for adhering to ethical principles when elaborating an academic final thesis. I acknowledge that my thesis is subject to the rights and obligations stip- ulated by the Act No. 121/2000 Coll., the Copyright Act, as amended. In accordance with Article 46(6) of the Act, I hereby grant a nonexclusive au- thorization (license) to utilize this thesis, including any and all computer pro- grams incorporated therein or attached thereto and all corresponding docu- mentation (hereinafter collectively referred to as the \Work"), to any and all persons that wish to utilize the Work. Such persons are entitled to use the Work in any way (including for-profit purposes) that does not detract from its value. This authorization is not limited in terms of time, location and quan- tity. However, all persons that makes use of the above license shall be obliged to grant a license at least in the same scope as defined above with respect to each and every work that is created (wholly or in part) based on the Work, by modifying the Work, by combining the Work with another work, by including the Work in a collection of works or by adapting the Work (including trans- lation), and at the same time make available the source code of such work at least in a way and scope that are comparable to the way and scope in which the source code of the Work is made available.
    [Show full text]
  • EXE: Automatically Generating Inputs of Death
    EXE: Automatically Generating Inputs of Death Cristian Cadar, Vijay Ganesh, Peter M. Pawlowski, David L. Dill, Dawson R. Engler Computer Systems Laboratory Stanford University Stanford, CA 94305, U.S.A {cristic, vganesh, piotrek, dill, engler} @cs.stanford.edu ABSTRACT 1. INTRODUCTION This paper presents EXE, an effective bug-finding tool that Attacker-exposed code is often a tangled mess of deeply- automatically generates inputs that crash real code. Instead nested conditionals, labyrinthine call chains, huge amounts of running code on manually or randomly constructed input, of code, and frequent, abusive use of casting and pointer EXE runs it on symbolic input initially allowed to be “any- operations. For safety, this code must exhaustively vet in- thing.” As checked code runs, EXE tracks the constraints put received directly from potential attackers (such as sys- on each symbolic (i.e., input-derived) memory location. If a tem call parameters, network packets, even data from USB statement uses a symbolic value, EXE does not run it, but sticks). However, attempting to guard against all possible instead adds it as an input-constraint; all other statements attacks adds significant code complexity and requires aware- run as usual. If code conditionally checks a symbolic ex- ness of subtle issues such as arithmetic and buffer overflow pression, EXE forks execution, constraining the expression conditions, which the historical record unequivocally shows to be true on the true branch and false on the other. Be- programmers reason about poorly. cause EXE reasons about all possible values on a path, it Currently, programmers check for such errors using a com- has much more power than a traditional runtime tool: (1) bination of code review, manual and random testing, dy- it can force execution down any feasible program path and namic tools, and static analysis.
    [Show full text]
  • Development of Benchmarking Suite for Various Ruby Implementations
    MASARYKOVA UNIVERZITA FAKULTA}w¡¢£¤¥¦§¨ INFORMATIKY !"#$%&'()+,-./012345<yA| Development of benchmarking suite for various Ruby implementations BACHELOR THESIS Richard Ludvigh Brno, Spring 2015 Declaration Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Richard Ludvigh Advisor: RNDr. Adam Rambousek ii Acknowledgement I would like to thank my supervisor RNDr. Adam Rambousek who has supported me throughout my thesis. I would also like to thank my advisor Ing. Václav Tunka for advice and consultation regarding technical aspects of work as well as guidance and feedback through- out my thesis. Access to the CERIT-SC computing and storage facilities provided under the programme Center CERIT Scientific Cloud, part of the Op- erational Program Research and Development for Innovations, reg. no. CZ. 1.05/3.2.00/08.0144, is greatly appreciated. iii Abstract Ruby is a modern, dynamic, pure object-oriented programming lan- guage. It has multiple implementations which provide different per- formance. The aim of this bachelor thesis is to provide a container- based tool to benchmark and monitor those performance differences inside an isolated environment. iv Keywords Ruby, JRuby, Rubinius, MRI, Docker, benchmarking, performance v Contents 1 Introduction ............................3 2 State of the art ...........................4 3 Ruby performance ........................6 3.1 Introduction to Ruby ....................6 3.2 Ruby implementations ...................7 3.2.1 MRI or CRuby . .7 3.2.2 JRuby . .7 3.2.3 Rubinius .
    [Show full text]