DOCSLIB.ORG

Code Optimization Based on Source to Source Transformations Using Profile Guided Metrics Youenn Lebras

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Code Optimization Based on Source to Source Transformations Using Profile Guided Metrics Youenn Lebras Code optimization based on source to source transformations using profile guided metrics Youenn Lebras To cite this version: Youenn Lebras. Code optimization based on source to source transformations using profile guided met- rics. Automatic Control Engineering. Université Paris-Saclay, 2019. English. NNT : 2019SACLV037. tel-02443231 HAL Id: tel-02443231 https://tel.archives-ouvertes.fr/tel-02443231 Submitted on 17 Jan 2020 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. s Code optimization based on source to source transformations using profile guided metrics Thèse de doctorat de l’Université Paris-Saclay préparée à l’Université de Versailles-Saint-Quentin-en-Yvelines Ecole doctorale n◦580 Sciences et technologies de l’information et de la NNT : 2019SACLV037 communication (STIC) Spécialité de doctorat: "Programmation : modèles, algorithmes, langages, architecture" Thèse présentée et soutenue à Versailles, le 3 Juillet 2019, par YOUENN LEBRAS Composition du Jury : Anthony Scemama IR CNRS, HdR, Université de Toulouse Rapporteur Angelo Steffenel ) McF HdR, Université de Reims Champagne-Ardenne Rapporteur Michel Masella CEA DRF, HdR, Saclay Examinateur Denis Barthou PR. Université de Bordeaux Président Sophie Robert McF, Université d’Orleans Examinateur William Jalby PR, Univesité de Versailles Saint-Quentin Directeur de thèse Andres S. Charif-Rubial PhD., PeXL Co-encadrant Romain Dolbeau PhD ATOS BULL Invité iii Declaration of Authorship I, Youenn LEBRAS, declare that this thesis titled, “Code optimization based on source to source transformations using profile guided metrics” and the work presented in it are my own. I confirm that: • This work was done wholly or mainly while in candidature for a research degree at this University. • Where any part of this thesis has previously been submitted for a degree or any other qualification at this University or any other institution, this has been clearly stated. • Where I have consulted the published work of others, this is always clearly attributed. • Where I have quoted from the work of others, the source is always given. With the exception of such quotations, this thesis is entirely my own work. • I have acknowledged all main sources of help. • Where the thesis is based on work done by myself jointly with others, I have made clear exactly what was done by others and what I have contributed myself. Signed: Youenn LEBRAS Date: 07/03/2019 v UVSQ Abstract Paris-Saclay UVSQ - Li-Parad PhD. Student in Computer Science Code optimization based on source to source transformations using profile guided metrics by Youenn Lebras Modern high performance processor architectures tackle performance issues by heavily relying on increased vector lengths and advanced memory hierarchies to deliver high performance. Manual optimization of production HPC codes became a difficult task when having to man- age multiple architecture dependent transformations. Developers usually trust compilers to automatically address these performance issues, but they deploy static performance models and heuristics which, must remain conservative or even fail in the worst case. Compiler optimization choices can be refines by using feedback data from dynamic profiling. But, it does not always consider some metrics and is rarely aggressive enough regarding metric data collection. On the other hand, performance analysis tools are pretty good at detecting specific performance issues, but only return observations on the quality and on the execution of the code. Our goal is to develop a framework will allow to perform of source code trans- formations based on performance analysis tools metrics. This framework will be integrated into the MAQAO tool suite. We present an FDO tool with a set of source-to-source transfor- mations guided by metrics coming from the various MAQAO tools and open to user advices. This framework can also be used to simplify the development by automatically perform- ing some simple, but time-consuming and error-prone transformations (e.g. loop/function specialization). vii Acknowledgements Avant toute chose, je voudrais remercier M. William Jalby, pour m’avoir acceuilli au sein du laboratoire et pour m’avoir suivi, orienté et soutenu durant cette thèse. Je voudrais aussi remercier Andrès S. Charif-Rubial pour son encadrement. Je suis reconnaissant envers mes rapporteurs, Anthony Scemama et Angelo Steffenel pour avoir eu la patience de lire ce manuscrit et m’avoir fait des retours pour l’améliorer et sur mes travaux. Mes années de thèses n’ont pas été de tout repos, mais grâce aux membres de ce labo- ratoire, elles m’ont paru plus facile à vivre. C’est pourquoi j’adresse un grand merci chacun d’entre eux, pour m’avoir aidé et soutenu que ce soit au travail ou en dehors via les team building au Montbauront et autres occasions. Cédric, pour avoir le courage d’agréger nos MPR pas toujours palpitant chaque mois, pour les soirées graphes avant les reviews et pour les tournées payées. Emmanuel, pour ces longues discussions durant nos trajets pour Teratec. Hugo, mon coéquipier breton de l’équipe, pour nos discussions au montbauront. Jasper, pour tes médecines douces et techniques de relaxation. Mathieu, pour avoir eu la patience (oui, la patience) de m’avoir eu en voisin de bureau et de m’aider à régler de nombreux problèmes d’interface chaise-clavier (que ce soit avec maqao ou pas) ainsi que pour tes citations toujours très inspirées et ton humour noir. A tous, un grand merci ! Je remercie bien évidemment tous les autres membres du laboratoire avec qui j’ai passé moins de temps, mais avec qui j’ai tout autant apprécié travailler/discuter/etc. Kevin, notre stagiaire qui un jour écrira son rapport ; Pablo pour m’avoir aidé dans de nombreuses dé- marches et avec qui j’ai apprécié travailler et donner des cours ; Yohan, doctorant et com- pagnon de galère de thèse (adum et formations), Nathalie et sylvain sans qui mon parcours n’aurait peut-être pas été le même, Clément, Marie, Sebastien, pour les différentes discus- sions et moments qui ont fait que ces années de thèse sont passées si vite. Evidemment, merci à mes parents et ma soeur, pour leur soutien et pour leur patience lorsqu’ils tentaient de comprendre quel était exactement mon sujet de thèse et en quoi con- sistait mes travaux. Un merci plus personnel et tout particulier à Chloé qui m’a soutenue autant (et aussi longtemps) que possible durant cette thèse et ce malgré ce qu’elle vivait. J’espère t’avoir autant soutenu et rendu le bonheur que tu as pu m’apporter. Pour tout ça, je lui dédicace cette thèse. viii Un autre remerciement personnel, à mes amis qui sont là pour moi depuis de nombreuses années, Romain et MP, Julien, Jaunathan, Gaetan et Pierre (surtout pour les bières après le travail), Xavier, Jeremy, Zac, Anthony, Cassandre, etc. Il me faudrait encore quelques pages pour citer tout le monde donc je m’arrête là, mais vous pouvez toujours mettre votre nom dans la partie laissée en blanc qui suit. Merci, ! And finally, after all these thanks, I would like to thank you random citizen! Yes you, who gonna read this thesis (or at least a brief part). Thank you for thinking that there is something interesting in this manuscript. ix Contents Declaration of Authorship iii Abstract v Acknowledgements vii 1 Background1 1.1 Evolution of HPC Processor Architectures...................1 1.1.1 Uni-core Design Details..........................2 1.1.2 Memory Technology...........................5 1.2 With Great Evolution Comes Great Difficulties................8 1.2.1 Vectorization Evolution..........................8 1.2.2 Memory Organization.......................... 10 1.3 Compilers..................................... 12 1.3.1 Introduction................................ 12 1.3.2 Limitations................................ 13 1.4 Performance Analysis Tools........................... 14 1.4.1 Static Analysis.............................. 14 1.4.2 Dynamic Analysis............................. 16 Using Sampling.............................. 16 Using Tracing............................... 18 1.4.3 Global view using both.......................... 19 1.5 Optimization Tools & Techniques........................ 21 1.5.1 Compiler Optimization Techniques................... 21 1.5.2 Flag Research............................... 22 1.5.3 Profile Guided Optimization (PGO)................... 22 1.5.4 Libraries.................................. 23 1.5.5 Directives................................. 24 1.5.6 Domain Specific Language........................ 24 1.5.7 Source-to-Source............................. 25 1.5.8 Auto-tuning................................ 26 x 1.6 Conclusion..................................... 26 2 ASSIST 29 2.1 Background.................................... 29 2.1.1 Specifications / Context......................... 29 2.1.2 Existing Tools for Source-to-Source Transformation.......... 30 Cetus................................... 30 Par4All & PIPS.............................. 31 OpenC++................................. 31 DMS Software Re-engineering Toolkit.................. 31 LLVM (Clang
Load more

Recommended publications
  • Source-To-Source Translation and Software Engineering
    Journal of Software Engineering and Applications, 2013, 6, 30-40 http://dx.doi.org/10.4236/jsea.2013.64A005 Published Online April 2013 (http://www.scirp.org/journal/jsea) Source-to-Source Translation and Software Engineering David A. Plaisted Department of Computer Science, University of North Carolina at Chapel Hill, Chapel Hill, USA. Email: [email protected] Received February 5th, 2013; revised March 7th, 2013; accepted March 15th, 2013 Copyright © 2013 David A. Plaisted. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. ABSTRACT Source-to-source translation of programs from one high level language to another has been shown to be an effective aid to programming in many cases. By the use of this approach, it is sometimes possible to produce software more cheaply and reliably. However, the full potential of this technique has not yet been realized. It is proposed to make source- to-source translation more effective by the use of abstract languages, which are imperative languages with a simple syntax and semantics that facilitate their translation into many different languages. By the use of such abstract lan- guages and by translating only often-used fragments of programs rather than whole programs, the need to avoid writing the same program or algorithm over and over again in different languages can be reduced. It is further proposed that programmers be encouraged to write often-used algorithms and program fragments in such abstract languages. Libraries of such abstract programs and program fragments can then be constructed, and programmers can be encouraged to make use of such libraries by translating their abstract programs into application languages and adding code to join things together when coding in various application languages.
    [Show full text]
  • Redundancy Elimination Common Subexpression Elimination
    Redundancy Elimination Aim: Eliminate redundant operations in dynamic execution Why occur? Loop-invariant code: Ex: constant assignment in loop Same expression computed Ex: addressing Value numbering is an example Requires dataflow analysis Other optimizations: Constant subexpression elimination Loop-invariant code motion Partial redundancy elimination Common Subexpression Elimination Replace recomputation of expression by use of temp which holds value Ex. (s1) y := a + b Ex. (s1) temp := a + b (s1') y := temp (s2) z := a + b (s2) z := temp Illegal? How different from value numbering? Ex. (s1) read(i) (s2) j := i + 1 (s3) k := i i + 1, k+1 (s4) l := k + 1 no cse, same value number Why need temp? Local and Global ¡ Local CSE (BB) Ex. (s1) c := a + b (s1) t1 := a + b (s2) d := m&n (s1') c := t1 (s3) e := a + b (s2) d := m&n (s4) m := 5 (s5) if( m&n) ... (s3) e := t1 (s4) m := 5 (s5) if( m&n) ... 5 instr, 4 ops, 7 vars 6 instr, 3 ops, 8 vars Always better? Method: keep track of expressions computed in block whose operands have not changed value CSE Hash Table (+, a, b) (&,m, n) Global CSE example i := j i := j a := 4*i t := 4*i i := i + 1 i := i + 1 b := 4*i t := 4*i b := t c := 4*i c := t Assumes b is used later ¡ Global CSE An expression e is available at entry to B if on every path p from Entry to B, there is an evaluation of e at B' on p whose values are not redefined between B' and B.
    [Show full text]
  • A Methodology for Assessing Javascript Software Protections
    A methodology for Assessing JavaScript Software Protections Pedro Fortuna A methodology for Assessing JavaScript Software Protections Pedro Fortuna About me Pedro Fortuna Co-Founder & CTO @ JSCRAMBLER OWASP Member SECURITY, JAVASCRIPT @pedrofortuna 2 A methodology for Assessing JavaScript Software Protections Pedro Fortuna Agenda 1 4 7 What is Code Protection? Testing Resilience 2 5 Code Obfuscation Metrics Conclusions 3 6 JS Software Protections Q & A Checklist 3 What is Code Protection Part 1 A methodology for Assessing JavaScript Software Protections Pedro Fortuna Intellectual Property Protection Legal or Technical Protection? Alice Bob Software Developer Reverse Engineer Sells her software over the Internet Wants algorithms and data structures Does not need to revert back to original source code 5 A methodology for Assessing JavaScript Software Protections Pedro Fortuna Intellectual Property IP Protection Protection Legal Technical Encryption ? Trusted Computing Server-Side Execution Obfuscation 6 A methodology for Assessing JavaScript Software Protections Pedro Fortuna Code Obfuscation Obfuscation “transforms a program into a form that is more difficult for an adversary to understand or change than the original code” [1] More Difficult “requires more human time, more money, or more computing power to analyze than the original program.” [1] in Collberg, C., and Nagra, J., “Surreptitious software: obfuscation, watermarking, and tamperproofing for software protection.”, Addison- Wesley Professional, 2010. 7 A methodology for Assessing
    [Show full text]
  • Polyhedral Compilation As a Design Pattern for Compiler Construction
    Polyhedral Compilation as a Design Pattern for Compiler Construction PLISS, May 19-24, 2019 [email protected] Polyhedra? Example: Tiles Polyhedra? Example: Tiles How many of you read “Design Pattern”? → Tiles Everywhere 1. Hardware Example: Google Cloud TPU Architectural Scalability With Tiling Tiles Everywhere 1. Hardware Google Edge TPU Edge computing zoo Tiles Everywhere 1. Hardware 2. Data Layout Example: XLA compiler, Tiled data layout Repeated/Hierarchical Tiling e.g., BF16 (bfloat16) on Cloud TPU (should be 8x128 then 2x1) Tiles Everywhere Tiling in Halide 1. Hardware 2. Data Layout Tiled schedule: strip-mine (a.k.a. split) 3. Control Flow permute (a.k.a. reorder) 4. Data Flow 5. Data Parallelism Vectorized schedule: strip-mine Example: Halide for image processing pipelines vectorize inner loop https://halide-lang.org Meta-programming API and domain-specific language (DSL) for loop transformations, numerical computing kernels Non-divisible bounds/extent: strip-mine shift left/up redundant computation (also forward substitute/inline operand) Tiles Everywhere TVM example: scan cell (RNN) m = tvm.var("m") n = tvm.var("n") 1. Hardware X = tvm.placeholder((m,n), name="X") s_state = tvm.placeholder((m,n)) 2. Data Layout s_init = tvm.compute((1,n), lambda _,i: X[0,i]) s_do = tvm.compute((m,n), lambda t,i: s_state[t-1,i] + X[t,i]) 3. Control Flow s_scan = tvm.scan(s_init, s_do, s_state, inputs=[X]) s = tvm.create_schedule(s_scan.op) 4. Data Flow // Schedule to run the scan cell on a CUDA device block_x = tvm.thread_axis("blockIdx.x") 5. Data Parallelism thread_x = tvm.thread_axis("threadIdx.x") xo,xi = s[s_init].split(s_init.op.axis[1], factor=num_thread) s[s_init].bind(xo, block_x) Example: Halide for image processing pipelines s[s_init].bind(xi, thread_x) xo,xi = s[s_do].split(s_do.op.axis[1], factor=num_thread) https://halide-lang.org s[s_do].bind(xo, block_x) s[s_do].bind(xi, thread_x) print(tvm.lower(s, [X, s_scan], simple_mode=True)) And also TVM for neural networks https://tvm.ai Tiling and Beyond 1.
    [Show full text]
  • Attacking Client-Side JIT Compilers.Key
    Attacking Client-Side JIT Compilers Samuel Groß (@5aelo) !1 A JavaScript Engine Parser JIT Compiler Interpreter Runtime Garbage Collector !2 A JavaScript Engine • Parser: entrypoint for script execution, usually emits custom Parser bytecode JIT Compiler • Bytecode then consumed by interpreter or JIT compiler • Executing code interacts with the Interpreter runtime which defines the Runtime representation of various data structures, provides builtin functions and objects, etc. Garbage • Garbage collector required to Collector deallocate memory !3 A JavaScript Engine • Parser: entrypoint for script execution, usually emits custom Parser bytecode JIT Compiler • Bytecode then consumed by interpreter or JIT compiler • Executing code interacts with the Interpreter runtime which defines the Runtime representation of various data structures, provides builtin functions and objects, etc. Garbage • Garbage collector required to Collector deallocate memory !4 A JavaScript Engine • Parser: entrypoint for script execution, usually emits custom Parser bytecode JIT Compiler • Bytecode then consumed by interpreter or JIT compiler • Executing code interacts with the Interpreter runtime which defines the Runtime representation of various data structures, provides builtin functions and objects, etc. Garbage • Garbage collector required to Collector deallocate memory !5 A JavaScript Engine • Parser: entrypoint for script execution, usually emits custom Parser bytecode JIT Compiler • Bytecode then consumed by interpreter or JIT compiler • Executing code interacts with the Interpreter runtime which defines the Runtime representation of various data structures, provides builtin functions and objects, etc. Garbage • Garbage collector required to Collector deallocate memory !6 Agenda 1. Background: Runtime Parser • Object representation and Builtins JIT Compiler 2. JIT Compiler Internals • Problem: missing type information • Solution: "speculative" JIT Interpreter 3.
    [Show full text]
  • Extending Fortran with Meta-Programming
    OpenFortran: Extending Fortran with Meta-programming Songqing Yue and Jeff Gray Department of Computer Science University of Alabama Tuscaloosa, AL, USA {syue, gray}@cs.ua.edu Abstract—Meta-programming has shown much promise for manipulated [1]. MOPs add the ability of meta-programming improving the quality of software by offering programming to programming languages by providing users with standard language techniques to address issues of modularity, reusability, interfaces to modify the internal implementation of the maintainability, and extensibility. A system that supports meta- program. Through the interface, programmers can programming is able to generate or manipulate other programs incrementally change the implementation and the behavior of a to extend their behavior. This paper describes OpenFortran, a program to better suit their needs. Furthermore, a metaprogram Meta-Object Protocol (MOP) that is able to bring the power of can capture the needs of a commonly needed feature and be meta-programming to Fortran, one of the most widely used applied to several different base programs. languages in the area of High Performance Computing (HPC). OpenFortran provides a framework that allows library A MOP may perform the underling adaptation of the base developers to build arbitrary source-to-source program program at either run-time or compile-time. Run-time MOPs transformation libraries for Fortran programs. To relieve the function while a program is executing and can be used to burden of learning the details about how the underlying perform real-time adaptation, for example the Common Lisp transformations are performed, a domain-specific language Object System (CLOS) [13] that allows the mechanisms of named SPOT has been created that allows developers to specify inheritance, method dispatching, and class instantiation to be direct manipulation of programs.
    [Show full text]
  • ROSE Tutorial: a Tool for Building Source-To-Source Translators Draft Tutorial (Version 0.9.11.115)
    ROSE Tutorial: A Tool for Building Source-to-Source Translators Draft Tutorial (version 0.9.11.115) Daniel Quinlan, Markus Schordan, Richard Vuduc, Qing Yi Thomas Panas, Chunhua Liao, and Jeremiah J. Willcock Lawrence Livermore National Laboratory Livermore, CA 94550 925-423-2668 (office) 925-422-6278 (fax) fdquinlan,panas2,[email protected] [email protected] [email protected] [email protected] [email protected] Project Web Page: www.rosecompiler.org UCRL Number for ROSE User Manual: UCRL-SM-210137-DRAFT UCRL Number for ROSE Tutorial: UCRL-SM-210032-DRAFT UCRL Number for ROSE Source Code: UCRL-CODE-155962 ROSE User Manual (pdf) ROSE Tutorial (pdf) ROSE HTML Reference (html only) September 12, 2019 ii September 12, 2019 Contents 1 Introduction 1 1.1 What is ROSE.....................................1 1.2 Why you should be interested in ROSE.......................2 1.3 Problems that ROSE can address...........................2 1.4 Examples in this ROSE Tutorial...........................3 1.5 ROSE Documentation and Where To Find It.................... 10 1.6 Using the Tutorial................................... 11 1.7 Required Makefile for Tutorial Examples....................... 11 I Working with the ROSE AST 13 2 Identity Translator 15 3 Simple AST Graph Generator 19 4 AST Whole Graph Generator 23 5 Advanced AST Graph Generation 29 6 AST PDF Generator 31 7 Introduction to AST Traversals 35 7.1 Input For Example Traversals............................. 35 7.2 Traversals of the AST Structure............................ 36 7.2.1 Classic Object-Oriented Visitor Pattern for the AST............ 37 7.2.2 Simple Traversal (no attributes)....................... 37 7.2.3 Simple Pre- and Postorder Traversal....................
    [Show full text]
  • Towards Large-Scale Refactoring for Ocaml
    Towards Large-scale Refactoring for OCaml REUBEN N. S. ROWE, University of Kent, UK SIMON J. THOMPSON, University of Kent, UK Refactoring is the process of changing the way a program works without changing its overall behaviour. The functional programming paradigm presents its own unique challenges to refactoring. For the OCaml language in particular, the expressiveness of its module system makes this a highly non-trivial task. The use of PPX preprocessors, other language extensions, and idiosyncratic build systems complicates matters further. We begin to address the question of how to refactor large OCaml programs by looking at a particular refactoring—value binding renaming—and implementing a prototype tool to carry it out. Our tool, Rotor, is developed in OCaml itself and combines several features to manage the complexities of refactoring OCaml code. Firstly it defines a rich, hierarchical way of identifying bindings which distinguishes between structures and functors and their associated module types, and is able to refer directly to functor parameters. Secondly it makes use of the recently developed visitors library to perform generic traversals of abstract syntax trees. Lastly it implements a notion of ‘dependency’ between renamings, allowing refactorings to be computed in a modular fashion. We evaluate Rotor using a snapshot of Jane Street’s core library and its dependencies, comprising some 900 source files across 80 libraries, and a test suite of around 3000 renamings. We propose that the notion of dependency is a general one for refactoring, distinct from a refactoring ‘precondition’. Dependencies may actually be mutual, in that all must be applied together for each one individually to be correct, and serve as declarative specifications of refactorings.
    [Show full text]
  • CS153: Compilers Lecture 19: Optimization
    CS153: Compilers Lecture 19: Optimization Stephen Chong https://www.seas.harvard.edu/courses/cs153 Contains content from lecture notes by Steve Zdancewic and Greg Morrisett Announcements •HW5: Oat v.2 out •Due in 2 weeks •HW6 will be released next week •Implementing optimizations! (and more) Stephen Chong, Harvard University 2 Today •Optimizations •Safety •Constant folding •Algebraic simplification • Strength reduction •Constant propagation •Copy propagation •Dead code elimination •Inlining and specialization • Recursive function inlining •Tail call elimination •Common subexpression elimination Stephen Chong, Harvard University 3 Optimizations •The code generated by our OAT compiler so far is pretty inefficient. •Lots of redundant moves. •Lots of unnecessary arithmetic instructions. •Consider this OAT program: int foo(int w) { var x = 3 + 5; var y = x * w; var z = y - 0; return z * 4; } Stephen Chong, Harvard University 4 Unoptimized vs. Optimized Output .globl _foo _foo: •Hand optimized code: pushl %ebp movl %esp, %ebp _foo: subl $64, %esp shlq $5, %rdi __fresh2: movq %rdi, %rax leal -64(%ebp), %eax ret movl %eax, -48(%ebp) movl 8(%ebp), %eax •Function foo may be movl %eax, %ecx movl -48(%ebp), %eax inlined by the compiler, movl %ecx, (%eax) movl $3, %eax so it can be implemented movl %eax, -44(%ebp) movl $5, %eax by just one instruction! movl %eax, %ecx addl %ecx, -44(%ebp) leal -60(%ebp), %eax movl %eax, -40(%ebp) movl -44(%ebp), %eax Stephen Chong,movl Harvard %eax,University %ecx 5 Why do we need optimizations? •To help programmers… •They write modular, clean, high-level programs •Compiler generates efficient, high-performance assembly •Programmers don’t write optimal code •High-level languages make avoiding redundant computation inconvenient or impossible •e.g.
    [Show full text]
  • Quaxe, Infinity and Beyond
    Quaxe, infinity and beyond Daniel Glazman — WWX 2015 /usr/bin/whoami Primary architect and developer of the leading Web and Ebook editors Nvu and BlueGriffon Former member of the Netscape CSS and Editor engineering teams Involved in Internet and Web Standards since 1990 Currently co-chair of CSS Working Group at W3C New-comer in the Haxe ecosystem Desktop Frameworks Visual Studio (Windows only) Xcode (OS X only) Qt wxWidgets XUL Adobe Air Mobile Frameworks Adobe PhoneGap/Air Xcode (iOS only) Qt Mobile AppCelerator Visual Studio Two solutions but many issues Fragmentation desktop/mobile Heavy runtimes Can’t easily reuse existing c++ libraries Complex to have native-like UI Qt/QtMobile still require c++ Qt’s QML is a weak and convoluted UI language Haxe 9 years success of Multiplatform OSS language Strong affinity to gaming Wide and vibrant community Some press recognition Dead code elimination Compiles to native on all But no native GUI… platforms through c++ and java Best of all worlds Haxe + Qt/QtMobile Multiplatform Native apps, native performance through c++/Java C++/Java lib reusability Introducing Quaxe Native apps w/o c++ complexity Highly dynamic applications on desktop and mobile Native-like UI through Qt HTML5-based UI, CSS-based styling Benefits from Haxe and Qt communities Going from HTML5 to native GUI completeness DOM dynamism in native UI var b: Element = document.getElementById("thirdButton"); var t: Element = document.createElement("input"); t.setAttribute("type", "text"); t.setAttribute("value", "a text field"); b.parentNode.insertBefore(t,
    [Show full text]
  • Combining Source and Target Level Cost Analyses for Ocaml Programs
    Combining Source and Target Level Cost Analyses for OCaml Programs Stefan K. Muller Jan Hoffmann Carnegie Mellon University Carnegie Mellon University Abstract bounding gas usage in smart contracts [24]. More generally, Deriving resource bounds for programs is a well-studied it is an appealing idea to provide programmers with imme- problem in the programming languages community. For com- diate feedback about the efficiency of their code at design piled languages, there is a tradeoff in deciding when during time. compilation to perform such a resource analysis. Analyses at When designing a resource analysis for a compiled higher- the level of machine code can precisely bound the wall-clock level language, there is a tension between working on the execution time of programs, but often require manual anno- source code, the target code, or an intermediate represen- tations describing loop bounds and memory access patterns. tation. Advantages of analyzing the source code include Analyses that run on source code can more effectively derive more effective interaction with the programmer and more such information from types and other source-level features, opportunities for automation since the control flow and type but produce abstract bounds that do not directly reflect the information are readily available. The advantage of analyz- execution time of the compiled machine code. ing the target code is that analysis results apply to the code This paper proposes and compares different techniques for that is eventually executed. Many of the tools developed combining source-level and target-level resource analyses in in the programming languages community operate on the the context of the functional programming language OCaml.
    [Show full text]
  • Dead Code Elimination for Web Applications Written in Dynamic Languages
    Dead code elimination for web applications written in dynamic languages Master’s Thesis Hidde Boomsma Dead code elimination for web applications written in dynamic languages THESIS submitted in partial fulfillment of the requirements for the degree of MASTER OF SCIENCE in COMPUTER ENGINEERING by Hidde Boomsma born in Naarden 1984, the Netherlands Software Engineering Research Group Department of Software Technology Department of Software Engineering Faculty EEMCS, Delft University of Technology Hostnet B.V. Delft, the Netherlands Amsterdam, the Netherlands www.ewi.tudelft.nl www.hostnet.nl © 2012 Hidde Boomsma. All rights reserved Cover picture: Hoster the Hostnet mascot Dead code elimination for web applications written in dynamic languages Author: Hidde Boomsma Student id: 1174371 Email: [email protected] Abstract Dead code is source code that is not necessary for the correct execution of an application. Dead code is a result of software ageing. It is a threat for maintainability and should therefore be removed. Many organizations in the web domain have the problem that their software grows and de- mands increasingly more effort to maintain, test, check out and deploy. Old features often remain in the software, because their dependencies are not obvious from the software documentation. Dead code can be found by collecting the set of code that is used and subtract this set from the set of all code. Collecting the set can be done statically or dynamically. Web applications are often written in dynamic languages. For dynamic languages dynamic analysis suits best. From the maintainability perspective a dynamic analysis is preferred over static analysis because it is able to detect reachable but unused code.
    [Show full text]