DOCSLIB.ORG

High Performance Python Through Workload Acceleration with OMR Jitbuilder

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
High Performance Python Through Workload Acceleration with OMR Jitbuilder High Performance Python Through Workload Acceleration with OMR JitBuilder by Dayton J. Allen Bachelor of Science, Computer Science University of the West Indies, 2017 A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF Master of Computer Science In the Graduate Academic Unit of Computer Science Supervisor(s): David Bremner, PhD, Computer Science Examining Board: Michael Fleming, PhD, Computer Science, Chair Suprio Ray, PhD, Computer Science External Examiner: Monica Wachowicz, PhD, Geodesy & Geomatics Engineering This thesis is accepted by the Dean of Graduate Studies THE UNIVERSITY OF NEW BRUNSWICK June, 2020 c Dayton J. Allen, 2020 Abstract Python remains one of the most popular programming languages in many domains including scientific computing. Its reference implementation, CPython, is by far the most used version. CPython's runtime is bytecode-interpreted and leaves much to be desired when it comes to performance. Several attempts have been made to improve CPython's performance such as reimplementing performance-critical code in a more high-performance language (e.g. C, C++, Rust), or, transpiling Python source code to a more high-performance language, which is then called from within CPython through some form of FFI mechanism. Another approach is to JIT com- pile performance-critical Python methods or utilize alternate implementations that include a JIT compiler. JitBuilder provides a simplified interface to the underlying compiler technology avail- able in Eclipse OMR. We propose using JitBuilder to accelerate performance-critical workloads in Python. By creating Python bindings to JitBuilder's public interface, we can generate native code callable from within CPython without any modifications to its runtime. Results demonstrate that our approach rivals and in many cases outperforms state- of-the-art JIT compiler based approaches in the current ecosystem { namely, Numba and PyPy. ii Acknowledgements First and foremost, I would like to thank my thesis supervisor Dr. David Bremner for his guidance and patience during my thesis project. Many times I have pivoted or ventured off into some alternate project and he would nudge me back on course. I would also like to thank all my CASA colleagues and IBM contacts that provided valuable help and feedback on my project. Thanks to all my Canadian friends that helped me to navigate being in a foreign country, thousands of kilometres away from home and family. Thanks to my family for their endless support. Last but not least, thanks to everyone I know outside Computer Science that showed interest in my thesis project and kept asking questions. I know this is not easy. iii Table of Contents Abstract ii Acknowledgments iii Table of Contents iv List of Tables vii List of Figures viii Abbreviations ix 1 Introduction 1 1.1 Motivation . 2 1.2 Contributions . 4 1.3 Organization . 4 2 Background & Related Work 6 2.0.1 CPython's Performance Woes . 6 2.0.1.1 Bytecode Optimizations or the Lack Thereof . 6 2.1 Making CPython Faster . 7 2.1.1 C Extension Modules . 7 2.1.2 Transpilers . 7 2.1.3 JIT Compilation & Other Implementations . 8 2.1.3.1 Repurposed JIT Compilers . 9 iv 2.1.3.2 Bolt-On JIT Compilers . 10 2.2 Regular Expressions . 12 2.3 JitBuilder . 13 3 Python Bindings to JitBuilder 17 3.1 JitBuilder's Polyglot Ambitions . 17 3.1.1 Python Language Bindings . 20 3.1.1.1 Mapping C & C++ Languages features to Python . 22 3.1.2 Autojit . 23 3.1.2.1 Workflow . 26 4 Regular Expression Engine 30 4.1 Design & Implementation . 30 4.1.1 Bindings to Rust's RegEx bytecode compiler . 31 4.1.2 RegEx Interpreter . 35 4.1.2.1 Regular Expressions & Finite Automata . 35 4.1.2.2 Matching Engine . 37 4.1.3 Specializing Regex Compiler . 39 5 Evaluation 44 5.1 Experimental Setup . 44 5.2 Testing our Implementations . 45 5.3 Discussion . 46 5.3.1 AutoJIT . 46 5.3.2 RegEx Engine . 52 6 Conclusions & Future Work 58 6.1 Conclusions . 58 6.2 Future Work . 61 v Bibliography 70 A Appendix A 71 A.1 Code Repositories . 71 Vita vi List of Tables 4.1 Summary of Supported Regex Features. 34 4.2 Regex Engine Matching (hjH)ello against \Hello World". See Sec- tion 4.1.1 for a discussion of the bytecodes used in the table above. 39 5.1 Relative Speedups versus CPython on our Iterative Fibonacci Bench- mark. 47 5.2 Relative Speedups versus CPython on our Recursive Fibonacci Bench- mark. 47 5.3 Relative Speedups versus CPython on our Dot Product Benchmark. 48 5.4 Relative Speedups versus CPython on our Mandelbrot Benchmark. 49 5.5 Relative Speedups versus CPython on our Matrix Multiplication Bench- mark. 50 5.6 Relative Speedups versus our Pure Python Regex Interpreter on Regex Benchmark Set #1. 54 5.7 Relative Speedups versus our Pure Python Regex Interpreter on Regex Benchmark Set #2. 56 5.8 Relative Speedups versus our Pure Python Regex Interpreter on Regex Benchmark Set #3. 56 A.1 Code Repositories. 71 vii List of Figures 3.1 JitBuilder Client versus Implementation API. 18 3.2 C API Virtual Function Emulation [5]. 21 3.3 Auto JIT Workflow. 27 3.4 Lowering 2D Arrays to JitBuilder. 29 4.1 Partial NFA for matching a single character: c. 35 4.2 Partial NFA that describes the alternation: n1jn2. 35 4.3 Partial NFA that describes matching n once or zero times: n?. 36 4.4 Partial NFA that describes matching n zero or more times: n∗. 36 4.5 Partial NFA that describes matching n one or more times: n+. 36 4.6 Partial NFA that describes the concatenation: n1n2. 36 4.7 (hjH)ello NFA Representation. 37 4.8 Regex Matching Engine Flowchart. 40 5.1 Iterative Fibonacci Benchmark. 46 5.2 Recursive Fibonacci Benchmark. 47 5.3 Dot Product Benchmark. 48 5.4 Mandelbrot Benchmark. 49 5.5 Matrix Multiplication Benchmark. 50 5.6 Compilation Times: Python+JitBuilder versus Numba. 51 5.7 Regex Benchmark Set #1. 54 5.8 Regex Benchmark Set #2. 55 5.9 Regex Benchmark Set #3. 57 viii List of Symbols, Nomenclature or Abbreviations JIT Just-in-Time Compiler Regex Regular Expression IL Intermediate Language IR Intermediate Representation DFA Deterministic Finite Automata NFA Non-Deterministic Finite Automata FFI Foreign Function Interface JVM Java Virtual Machine CLR Core Language Runtime ASDL Abstract Syntax Description Lanuguage MSIL Microsoft Intermediate Language WIP Work in Progress CASA Centre of Advanced Studies - Atlantic VARARGs Variable Argruments IP Instruction Pointer SP String Pointer PC Program Counter LIFO Last in, First out STDLIB Standard Library VM Virtual Machine API Application Programming Interface CPU Central Processing Unit AST Abstract Syntax Tree EOL End of Life RRC Rust's Regex Crate Epsilon ix Chapter 1 Introduction Python [44] is a high-level, dynamically-typed programming language. It is currently one of the most popular programming languages, a feat that can be attributed to its simplicity and relatively easy learning curve. These attributes and its rich ecosystem of high-quality libraries make it an attractive option within many domains. Despite its many pros, one of Python's major weaknesses is the relatively poor performance of its reference implementation (CPython). This lack of performance is mainly due to its runtime being bytecode interpreted as well as its dynamic nature. This dynamism renders many compiler optimizations infeasible. Several attempts have been made to overcome CPython's performance limitations, such as developing native C extension modules to the CPython runtime. C extension modules necessitate a deviation from writing pure Python code by requiring code to be developed in a lower-level programming language (C/C++). This can be both a tedious and error-prone activity even for experts. A related approach is to implement general-purpose performance-critical code in high-performance languages (e.g. C++, C, Rust) and interface with Python through some form of foreign function interface (FFI) layer. An FFI is an interface that allows one to call out to code developed in one programming language, from another potentially unrelated programming lan- 1 guage. In the end, this also leads to a C extension module, but the difference is that the module is a binding to functionality from the general-purpose library rather than a fully Python-specific module. This layer of indirection somewhat positions Python as a frontend to high-performance libraries versus a language one can im- plement high-performance code in. Finally, we can also improve the performance of CPython by employing the use of just-in-time (JIT) compilers. Aycock [4] describes JIT compilation as compilation that occurs after a program begins execution. This allows one to collect information during execution to better guide compilation and optimization decisions. Eclipse OMR [23] provides a rich set of language-agnostic reusable components for implementing high-performance programming language runtimes. OMR historically stood for \Open Managed Runtimes" but the name is no longer interpreted as an acronym and has persisted despite the project not being a managed runtime. Amongst the components that OMR provides is a compiler based on the IBM J9 Java Virtual Machine (JVM). Despite its JVM roots, the OMR compiler component is also programming language agnostic. Another component, and perhaps the most pertinent to this thesis, is JitBuilder. JitBuilder is a native acceleration library that provides a simplified interface to the underlying compiler technology available in OMR. 1.1 Motivation The current approaches to accelerating Python code leave room for improvement. Approaches that deviate too much from the CPython runtime [37] struggle with adoption due to not supporting CPython's C application programming interface (API) that many popular Python libraries are based on.
Load more

Recommended publications
  • Nuitka User Manual Contents
    Nuitka User Manual Contents Overview 1 Usage 1 Requirements 1 Command Line 3 Installation 3 License 3 Tutorial Setup and build on Windows 3 Setup 4 Install Python 4 Install Nuitka 4 Write some code and test 4 Create a folder for the Python code 4 Test your program 4 Build it using 4 Run it 5 Distribute 5 Use Cases 5 Use Case 1 - Program compilation with all modules embedded 5 Use Case 2 - Extension Module compilation 6 Use Case 3 - Package compilation 7 Use Case 4 - Program Distribution 7 Tweaks 8 Icons 8 Splash screen 9 Typical Problems 9 Memory issues and compiler bugs 9 Avoid 32 bit C compiler/assembler memory limits 9 Use LTO compilation or not 10 Switch the C compiler to clang 10 Add a larger swap file to your embedded Linux 10 Limit the amount of compilation jobs 10 Dynamic sys.path 10 Missing data files in standalone 10 Missing DLLs in standalone 10 Dependency creep in standalone 10 Onefile: Finding files 11 Windows Programs without console give no errors 11 Tips 11 Nuitka Options in the code 11 Python command line flags 12 Caching compilation results 12 Control where Caches live 12 Runners 12 Fastest C Compilers 12 Unexpected Slowdowns 13 Standalone executables and dependencies 13 Windows errors with resources 13 Windows standalone program redistribuation 13 Detecting Nuitka at run time 14 Performance 14 pystone results 14 Where to go next 14 Follow me on Twitter 14 Report issues or bugs 14 Word of Warning 15 Join Nuitka 15 Donations 15 Unsupported functionality 15 The co_code attribute of code objects 15 PDB 16 Optimization 16
    [Show full text]
  • Python in a Hacker's Toolbox
    Python in a hacker's toolbox v. 2016 Gynvael Coldwind Security PWNing Conference, Warszawa 2016 Keynote? Raczej prelekcja techniczna. O prelegencie All opinions expressed during this presentations are mine and mine alone. They are not opinions of my lawyer, barber and especially not my employer. Menu Sandboxing Język i VM Bezpieczeństwo RE Ta prezentacja zawiera fragmenty ● Data, data, data... ● "On the battlefield with the dragons" (+ Mateusz Jurczyk) ● "Ataki na systemy i sieci komputerowe" ● "Pwning (sometimes) with style - Dragons' notes on CTFs" (+ Mateusz Jurczyk) ● "Python in a hacker's toolbox" Język i VM Python 2.6, 2.7, 3, CPython?, IronPython??, Jython???, oh my... Python Python 2.6, 2.7, 3, CPython?, IronPython??, Jython???, oh my... Język rozwijany przez Python Software Foundation Python Python 2.6, 2.7, 3, CPython?, IronPython??, Jython???, oh my... Język rozwijany przez Python Software Foundation Python Python Enhancement Proposal (w skrócie: PEP) Python 2.6, 2.7, 3, CPython?, IronPython??, Jython???, oh my... Język rozwijany przez Python Software Foundation Python Python Enhancement Proposal (w skrócie: PEP) Python 2.6, 2.7, 3, CPython?, IronPython??, Jython???, oh my... Python Implementacje https://wiki.python.org/moin/PythonImplementations Python 2.6, 2.7, 3, CPython?, IronPython??, Jython???, oh my... CPython Brython CLPython Jython HotPy pyjs Python Implementacje PyMite PyPy pyvm SNAPpy RapydScript IronPython tinypy https://wiki.python.org/moin/PythonImplementations Python 2.6, 2.7, 3, CPython?, IronPython??, Jython???, oh my... Jython Python Implementacje https://wiki.python.org/moin/PythonImplementations Python 2.6, 2.7, 3, CPython?, IronPython??, Jython???, oh my... Brython Python Implementacje https://wiki.python.org/moin/PythonImplementations Python 2.6, 2.7, 3, CPython?, IronPython??, Jython???, oh my..
    [Show full text]
  • Nuitka Developer Manual Contents
    Nuitka Developer Manual Contents Milestones 1 Version Numbers 1 Current State 2 Setting up the Development Environment for Nuitka 2 Visual Studio Code 2 Eclipse / PyCharm 3 Commit and Code Hygiene 3 Coding Rules Python 3 Tool to format 3 Identifiers 4 Module/Package Names 4 Names for context manages start with with 4 Prefer list contractions over built-ins 5 Coding Rules C 5 The "git flow" model 5 Nuitka "git/github" Workflow 6 API Documentation and Guidelines 7 Use of Standard Python "__doc__" Strings 7 Special doxygen Anatomy of "__doc__" 7 Checking the Source 8 Running the Tests 8 Running all Tests 9 Basic Tests 10 Syntax Tests 11 Program Tests 11 Generated Tests 11 Internal/Plugin API 11 Working with the CPython suites 11 Design Descriptions 12 Nuitka Logo 12 Choice of the Target Language 13 Use of Scons internally 13 Locating Modules and Packages 15 Hooking for module import process 16 Supporting __class__ of Python3 16 Frame Stack 17 Parameter Parsing 18 Input 18 Keyword dictionary 18 Argument tuple 19 SSA form for Nuitka 19 Loop SSA 20 Python Slots in Optimization 21 Basic Slot Idea 21 Representation in Nuitka 21 The C side 23 Built-in call optimization 24 Code Generation towards C 24 Exceptions 24 Statement Temporary Variables 24 Local Variables Storage 25 Exit Targets 25 Frames 25 Abortive Statements 25 Constant Preparation 25 Language Conversions to make things simpler 26 The assert statement 26 The "comparison chain" expressions 26 The execfile built-in 27 Generator expressions with yield 27 Function Decorators 27 Functions
    [Show full text]
  • Tuplex: Data Science in Python at Native Code Speed
    Tuplex: Data Science in Python at Native Code Speed Leonhard Spiegelberg Rahul Yesantharao Malte Schwarzkopf Tim Kraska [email protected] [email protected] [email protected] [email protected] Brown University MIT Brown University MIT Abstract compute a flight’s distance covered from kilometers to miles Data science pipelines today are either written in Python via a UDF after joining with a carrier table: or contain user-defined functions (UDFs) written in Python. carriers= spark.read.load( 'carriers.csv') But executing interpreted Python code is slow, and arbitrary fun= udf( lambda m: m* 1.609, DoubleType()) Python UDFs cannot be compiled to optimized machine code. spark.read.load('flights.csv') We present Tuplex, the first data analytics framework that .join(carriers, 'code', 'inner') just-in-time compiles developers’ natural Python UDFs into .withColumn('distance', fun('distance')) efficient, end-to-end optimized native code. Tuplex introduces .write.csv('output.csv') a novel dual-mode execution model that compiles an opti- mized fast path for the common case, and falls back on slower This code will run data loading and the join using Spark’s exception code paths for data that fail to match the fast path’s compiled Scala operators, but must execute the Python UDF assumptions. Dual-mode execution is crucial to making end- passed to withColumn in a Python interpreter. This requires to-end optimizing compilation tractable: by focusing on the passing data between the Python interpreter and the JVM [41], common case, Tuplex keeps the code simple enough to apply and prevents generating end-to-end optimized code across the aggressive optimizations.
    [Show full text]
  • Epython: Extending Python to the Future
    EPython: Extending Python to the Future Background Python has had enormous success in part due to its ease of extensibility and interoperability with other systems. In particular, this has led to huge ecosystems of code that heavily leverage the existing C-API for Python. One such ecosystem is the NumFOCUS ecosystem that includes NumPy, Pandas, SciPy, Scikit-Learn, Numba, Dask, and Jupyter. This ecosystem has propelled Python to become the de facto language for data-science and machine-learning. ​ ​ The downside of this success is that the particular dependency on the C-API of these extensions has also made this ecosystem an anchor to the further developing of the C-Python runtime as well as other emerging run-times of Python such as PyPy, Jython, and RustPython. Many of the core Python developers and the steering committee members recognize this problem and are eager to see something done about it. Something can be done, but it will take a concerted technical and social effort lasting at least 5 years. Abstract We will create an embedded domain specific language (DSL) using the Python language itself along with the typing module and specialized objects as necessary to allow nearly all the existing extensions to be written using this DSL. For reference this language is called EPython. ​ ​ We will then port several key libraries such as NumPy, SciPy, and Pandas to use this DSL. We will also provide a runtime so these extensions can work on PyPy, C-Python, Jython, and RustPython. Timeline The initial MVP will be completed in 6 months from project kick-off in early 2020 and then a version of NumPy will be ported in the next 12 months.
    [Show full text]
  • 2014-14 Lucija Tustanic Brlekovic.Pdf
    SVEUČILIŠTE U ZAGREBU PRIRODOSLOVNO – MATEMATIČKI FAKULTET SEMINARSKI RAD PROJEKT „NUITKA“ Lucija Brleković Zagreb, svibanj 2014. 1 Uvod Pod implementacije Python-a podrazumijevaju se programi ili okoliši koji pružaju potporu izvršavanju programa pisanih u Python okruženju. Postoje različiti paketi koji omogućuju prepoznavanje različitih vrsta koda iz Pythona, neki su varijante ili modifikacije već postojećih dok su ostali napravljeni kao potpuno nove implementacije Python jezika. Npr. postoji čitav niz reimplementacija Pythona koji ne ovise nužno o CPython runtime jezgri. Većina njih koristi dijelove standardne knjižnice funkcija. TakoĎer je bitno za napomenuti da je većina njih još uvijek u stanju razvoja. Jedine implementacije koji su kompatibilne sa sadašnjom verzijom Python jezika su IronPython, Jython i PyPy. MeĎu različitim varijantama implementacije nalazimo i čitav niz compiler-a koji obično implementiraju nešto slično Pythonu, iako neki od njih nameću odreĎena ograničenja ali ne nužno. Neki od njih su: Cython (koristi se za optimizaciju pretvorbe Python koda u C compiler kod, i sl.), GCC Python Front-End (projekt koji je još uvijek u tijeku, compiler Python koda unutar GCC infrastrukture), Shed Skin (Python-to-C++ compiler, ograničen samo na neke komponente jezika) i Nuitka. Nuitka je Python-to-C++ compiler koji koristi libpython u run-time-u, u svrhu optimizacije, takoĎer koristi i CPython runtime. 1 Nuitka – Python – C++ Compiler Nuitka je nastala kao samostalni projekt informatičara K. Haye koji se bavi projektima na polju informacijsko komunikacijskih tehnologija. Uz ovo polje se vežu mnoge primjene Python programskom jezika. Pyhton se koristi ne samo kao alat za upravljanje procesima, nego i kao sigurnosni alat kojim se nadziru neki kritični procesi sustava.
    [Show full text]
  • Cython Cython Build Software That Combines Python’S Expressivity with the Performance “Cython Has Proven Itself and Control of C (And C++)
    Cython Cython Build software that combines Python’s expressivity with the performance “Cython has proven itself and control of C (and C++). It’s possible with Cython, the compiler and in many foundational hybrid programming language used by foundational packages such as NumPy, and prominent in projects including Pandas, h5py, and scikits- Python projects where learn. In this practical guide, you’ll learn how to use Cython to improve performance is critical. Python’s performance—up to 3000x—and to wrap C and C++ libraries in In this book, Kurt Smith Python with ease. walks you through Author Kurt Smith takes you through Cython’s capabilities, with sample everything you need to code and in-depth practice exercises. If you’re just starting with Cython, or want to go deeper, you’ll learn how this language is an essential part of any know to tap into Cython's performance-oriented Python programmer’s arsenal. power for your own projects.” ■ Use Cython’s static typing to speed up Python code —Robert Bradshaw Cython ■ Gain hands-on experience using Cython features to boost your Lead Cython Developer numeric-heavy Python A GUIDE FOR PYTHON PROGRAMMERS ■ Create new types with Cython—and see how fast object- oriented programming in Python can be ■ Effectively organize Cython code into separate modules and packages without sacrificing performance ■ Use Cython to give Pythonic interfaces to C and C++ libraries ■ Optimize code with Cython’s runtime and compile-time profiling tools ■ Use Cython’s prange function to parallelize loops transparently with OpenMP Kurt W. Smith discovered Cython’s power during his graduate research in com- putational plasma physics.
    [Show full text]
  • A Python Just-In-Time Compiler for Astrophysical Computations✩ J
    Astronomy and Computing 10 (2015) 1–8 Contents lists available at ScienceDirect Astronomy and Computing journal homepage: www.elsevier.com/locate/ascom Full length article HOPE: A Python just-in-time compiler for astrophysical computationsI J. Akeret ∗, L. Gamper, A. Amara, A. Refregier ETH Zurich, Institute for Astronomy, Department of Physics, Wolfgang Pauli Strasse 27, 8093 Zurich, Switzerland h i g h l i g h t s • We discuss the reasons for the lower execution speed of Python. • We present HOPE, a specialised Python just-in-time compiler. • The package combines the ease of Python and the speed of C++. • HOPE improves the execution speed up to a factor of 120 compared to plain Python. • The code is freely available under GPLv3 license on PyPI and GitHub. article info a b s t r a c t Article history: The Python programming language is becoming increasingly popular for scientific applications due to its Received 30 September 2014 simplicity, versatility, and the broad range of its libraries. A drawback of this dynamic language, however, Accepted 2 December 2014 is its low runtime performance which limits its applicability for large simulations and for the analysis Available online 10 December 2014 of large data sets, as is common in astrophysics and cosmology. While various frameworks have been developed to address this limitation, most focus on covering the complete language set, and either force Keywords: the user to alter the code or are not able to reach the full speed of an optimised native compiled language. Python In order to combine the ease of and the speed of , we developed , a specialised Just-in-time compiler Python C++ HOPE Python Benchmark just-in-time (JIT) compiler designed for numerical astrophysical applications.
    [Show full text]
  • MINGW-Packages Watch 63 Star 379 Fork 243
    Search Alexpux / MINGW-packages Watch 63 Star 379 Fork 243 Code Issues 118 Pull requests 9 Wiki Pulse Graphs Package scripts for MinGW-w64 targets to build under MSYS2. 5,906 commits 1 branch 0 releases 114 contributors master New pull request New file Find file HTTPS https://github.com/Alexpux/MIN G W-Dpaocwknagloeasd.g ZiItP fracting Merge pull request #1264 from fracting/tea-ci … Latest commit 7df9c69 32 minutes ago mingw-w64-FreeImage switch to sha256 checksums a month ago mingw-w64-LASzip liblas,liaszip: Name with lowercase 17 days ago mingw-w64-LibRaw libraw: Rename to lowercase. Update to 0.17.1 2 months ago mingw-w64-OpenBLAS-git add `pkgbase` entry 25 days ago mingw-w64-PKGBUILD-common build-kf5-shared: Pass --noconfirm to makepkg-mingw a month ago mingw-w64-PKGBUILD-templates switch to sha256 checksums a month ago mingw-w64-Pillow switch to sha256 checksums a month ago mingw-w64-ResIL add `pkgbase` entry 25 days ago mingw-w64-SDL switch to sha256 checksums a month ago mingw-w64-SDL2 switch to sha256 checksums a month ago mingw-w64-SDL2_gfx add `pkgbase` entry 25 days ago mingw-w64-SDL2_image switch to sha256 checksums a month ago mingw-w64-SDL2_mixer switch to sha256 checksums a month ago mingw-w64-SDL2_net switch to sha256 checksums a month ago mingw-w64-SDL2_sound-hg add `pkgbase` entry 25 days ago mingw-w64-SDL2_ttf switch to sha256 checksums a month ago mingw-w64-SDL_gfx switch to sha256 checksums a month ago mingw-w64-SDL_image switch to sha256 checksums a month ago mingw-w64-SDL_mixer mingw-w64-SDL_mixer: Add mingw-w64-smpeg as makedepends.
    [Show full text]
  • Rktracer Code Coverage Tool an Easy to Use Code
    RKTracer Code Coverage tool An easy to use code coverage tool for multiple programming languages, with low overhead instrumentation.Supports all compilers, cross compiler, and target architectures ​ Working principle -Source code Level Instrumentation and source code based code coverage Platforms supported - Linux 32bit & 64bit (all falvours) - Windows 10,8 - MacOS Programming Languages Supported SL/No Programming Supported language Compiler/Cross-Compile Languages Supported versions r supported/Targets supported 1 C Language K&R Supports all compilers, C89, Cross compilers, and C90, Target architectures C95, C99, C11, Embedded C 2 C++ Language C++98, Supports all compilers, C++03, Cross compilers, and C++11, Target architectures C++14, C++17, C++20 3 Obj-C (Apple) All versions are supported All versions are supported 4 Java Language Sun/oracle/OpenJDK All versions are supported/others just ask supported 5 Kotlin Language From 1.2.x to the latest All versions are version supported 6 JavaScript Language 6th Edition to Latest All versions are version supported 7 C# Language From 2.0 to the latest Microsoft compiler version , dotnet core CSC Mono C# Compilers .NET Compiler Platform ("Roslyn") Build environments 8 Python Language From 2.7 to the latest cython version mpy-cross jython nuitka pypy iron-python python 9 Golang Language From 1.5.4 to the latest All versions are version supported 10 Swift Language Swift versions up to 5.0 All versions are supported Target platforms - Supports all target platforms, embedded devices, including all the android devices, TizenRT devices - Works on target with or without a file system or with very limited memory.
    [Show full text]
  • Compact Native Code Generation for Dynamic Languages on Micro-Core Architectures
    Compact Native Code Generation for Dynamic Languages on Micro-core Architectures Maurice Jamieson Nick Brown [email protected] EPCC at the University of Edinburgh EPCC at the University of Edinburgh Edinburgh, United Kingdom Edinburgh, United Kingdom Abstract technologies. However, the trait that all these share is that Micro-core architectures combine many simple, low mem- they typically provide a very constrained programming en- ory, low power-consuming CPU cores onto a single chip. Po- vironment and complex, manually programmed, memory tentially providing significant performance and low power hierarchies. In short, writing code for these architectures, consumption, this technology is not only of great interest in typically in C with some bespoke support libraries, is time embedded, edge, and IoT uses, but also potentially as acceler- consuming and requires expertise. There are numerous rea- ators for data-center workloads. Due to the restricted nature sons for this, for instance, not only must the programmer of such CPUs, these architectures have traditionally been handle idiosyncrasies of the architectures themselves but challenging to program, not least due to the very constrained also, for good performance, contend with fitting their data amounts of memory (often around 32KB) and idiosyncrasies and code into the tiny amount (typically 32 - 64 KB) of on- of the technology. However, more recently, dynamic lan- core fast scratchpad memory. guages such as Python have been ported to a number of Little wonder then that there have been a number of at- micro-cores, but these are often delivered as interpreters tempts to provide programming technologies that increase which have an associated performance limitation.
    [Show full text]
  • HOPE: a Python Just-In-Time Compiler for Astrophysical Computations
    HOPE: A Python Just-In-Time compiler for astrophysical computations Joël Akeret∗, Lukas Gamper, Adam Amara, Alexandre Refregier ETH Zurich, Institute for Astronomy, Department of Physics, Wolfgang Pauli Strasse 27, 8093 Zurich, Switzerland Abstract The Python programming language is becoming increasingly popular for scientific applications due to its simplicity, versatility, and the broad range of its libraries. A drawback of this dynamic language, however, is its low runtime performance which limits its applicability for large simulations and for the analysis of large data sets, as is common in astrophysics and cosmology. While various frameworks have been developed to address this limitation, most focus on covering the complete language set, and either force the user to alter the code or are not able to reach the full speed of an optimised native compiled language. In order to combine the ease of Python and the speed of C++, we developed HOPE, a specialised Python just-in-time (JIT) compiler designed for numerical astrophysical applications. HOPE focuses on a subset of the language and is able to translate Python code into C++ while performing numerical optimisation on mathematical expressions at runtime. To enable the JIT compilation, the user only needs to add a decorator to the function definition. We assess the performance of HOPE by performing a series of benchmarks and compare its execution speed with that of plain Python, C++ and the other existing frameworks. We find that HOPE improves the performance compared to plain Python by a factor of 2 to 120, achieves speeds comparable to that of C++, and often exceeds the speed of the existing solutions.
    [Show full text]