Fonction anonyme | EPFL Graph Search

En programmation informatique, une fonction anonyme, aussi appelée lambda expression ou fonction lambda est une fonction n'ayant pas de nom. Les fonctions anonymes existent dans certains langages de programmation comme Python, JavaScript, OCaml ou C++. Certains langages, comme le C et Pascal (tout au moins les versions standards de ces langages), ne permettent pas d'écrire des fonctions anonymes. Parce que ces fonctions n'ont pas de nom, à l'endroit où l'on voudrait mettre leur nom, on trouve directement les instructions définissant la fonction introduites par une syntaxe particulière. Étymologie Dans les langages de programmation fonctionnelle, les fonctions anonymes sont souvent appelées fonctions lambda, en référence au lambda-calcul, outil théorique dans lequel on programme tout sous forme d'appel de fonction, alors même qu'aucune fonction de base n'est définie. Exemples JavaScript En JavaScript, la fonction suivante renvoie le carré de son a

Optimizing Higher-Order Functions in Scala

Iulian Dragos

Scala relies on libraries as the default mechanism for language extension. While this provides an elegant solution for growing the language, the performance penalty incurred by call-by-name parameters, boxing and anonymous functions is high. We show that inlining alone is not enough to remove this overhead, and present a solution based on decompilation of library code combined with inlining, dead code elimination, and copy propagation. We evaluate our approach on two language extensions, Java-like assert and C-like for-loops and show improvements of up to 45%.

2008

Compiling Scala for Performance

Iulian Dragos

Scala is a new programming language bringing together object-oriented and functional programming. Its defining features are uniformity and extensibility. Scala offers great flexibility for programmers, allowing them to grow the language through libraries. Oftentimes what seems like a language feature is in fact implemented in a library, effectively giving programmers the power of language designers. The downside of this flexibility is that familiar looking code may hide unexpected performance costs. It is important for Scala compilers to bring down this cost as much as possible. We identify several areas of impact for Scala performance: higher-order functions and closures, and generic containers used with primitive types. We present two complementary approaches for improving performance in these areas: optimizations and specialization. Compiler optimization can bring down the cost through a combination of aggressive inlining of higher-order functions, an extended version of copy-propagation and dead-code elimination. Both anonymous functions and boxing can be eliminated by this approach. We show on a number of benchmarks that these language features can be up to 5 times faster when properly optimized, on current day JVMs. We propose a new approach to compiling parametric polymorphism for performance at primitive types. We mix a homogeneous translation scheme with user-directed specialization for primitive types. Type parameters may be annotated to require specialization of code depending on them. We propose definition-site specialization for primitive types, achieving separate compilation and no boxing when both the definition and call site are specialized. Specialized classes are compatible with unspecialized code, and specialization agnostic code can work with specialized instances, meaning that specialization is opportunistic. We present a formalism of a small subset of Scala with specialization and prove that specialization preserves types. We implemented this translation in the Scala compiler and report on improvements on a set of benchmarks, showing that specialization can make programs more than two times faster.

EPFL2010

Making sbt Macro-Aware

Eugene Burmako, Martin Nicolas Duhem

Macros made their first appearance as a fork of the Scala compiler and then as an experimental feature in the version 2.10.0 of Scala. Since macros are normal Scala functions that are executed by the compiler during the compilation of their clients, they can introduce dependencies between compilation units in new and exciting ways. In which ways is post-macro dependency analysis different from its pre- macro days? How do we analyze all the code that’s involved in macro expansion, not just the end result? How can we know what parts of a program have been inspected by a given macro in order to produce a specific expansion? The goal of this report is to explain how macros affect incremental compilation and outline the techniques used to upgrade sbt to provide better support for macro-based programs.

2014

Compiling Scala for Performance

Iulian Dragos

EPFL2010