119 research outputs found
Simple and Effective Type Check Removal through Lazy Basic Block Versioning
Dynamically typed programming languages such as JavaScript and Python defer
type checking to run time. In order to maximize performance, dynamic language
VM implementations must attempt to eliminate redundant dynamic type checks.
However, type inference analyses are often costly and involve tradeoffs between
compilation time and resulting precision. This has lead to the creation of
increasingly complex multi-tiered VM architectures.
This paper introduces lazy basic block versioning, a simple JIT compilation
technique which effectively removes redundant type checks from critical code
paths. This novel approach lazily generates type-specialized versions of basic
blocks on-the-fly while propagating context-dependent type information. This
does not require the use of costly program analyses, is not restricted by the
precision limitations of traditional type analyses and avoids the
implementation complexity of speculative optimization techniques.
We have implemented intraprocedural lazy basic block versioning in a
JavaScript JIT compiler. This approach is compared with a classical flow-based
type analysis. Lazy basic block versioning performs as well or better on all
benchmarks. On average, 71% of type tests are eliminated, yielding speedups of
up to 50%. We also show that our implementation generates more efficient
machine code than TraceMonkey, a tracing JIT compiler for JavaScript, on
several benchmarks. The combination of implementation simplicity, low
algorithmic complexity and good run time performance makes basic block
versioning attractive for baseline JIT compilers
Interprocedural Type Specialization of JavaScript Programs Without Type Analysis
Dynamically typed programming languages such as Python and JavaScript defer
type checking to run time. VM implementations can improve performance by
eliminating redundant dynamic type checks. However, type inference analyses are
often costly and involve tradeoffs between compilation time and resulting
precision. This has lead to the creation of increasingly complex multi-tiered
VM architectures.
Lazy basic block versioning is a simple JIT compilation technique which
effectively removes redundant type checks from critical code paths. This novel
approach lazily generates type-specialized versions of basic blocks on-the-fly
while propagating context-dependent type information. This approach does not
require the use of costly program analyses, is not restricted by the precision
limitations of traditional type analyses.
This paper extends lazy basic block versioning to propagate type information
interprocedurally, across function call boundaries. Our implementation in a
JavaScript JIT compiler shows that across 26 benchmarks, interprocedural basic
block versioning eliminates more type tag tests on average than what is
achievable with static type analysis without resorting to code transformations.
On average, 94.3% of type tag tests are eliminated, yielding speedups of up to
56%. We also show that our implementation is able to outperform Truffle/JS on
several benchmarks, both in terms of execution time and compilation time.Comment: 10 pages, 10 figures, submitted to CGO 201
Interprocedural Specialization of Higher-Order Dynamic Languages Without Static Analysis
Function duplication is widely used by JIT compilers to efficiently implement dynamic languages. When the source language supports higher order functions, the called function\u27s identity is not generally known when compiling a call site, thus limiting the use of function duplication. This paper presents a JIT compilation technique enabling function duplication in the presence of higher order functions. Unlike existing techniques, our approach uses dynamic dispatch at call sites instead of relying on a conservative analysis to discover function identity. We have implemented the technique in a JIT compiler for Scheme.
Experiments show that it is efficient at removing type checks, allowing the removal of almost all the run time type checks for several benchmarks.
This allows the compiler to generate code up to 50% faster. We show that the technique can be used to duplicate functions using other run time information opening up new applications such as register allocation based duplication and aggressive inlining
Return to Play Following Shoulder Stabilization: A Systematic Review and Meta-analysis.
BackgroundAnterior shoulder instability can be a disabling condition for the young athlete; however, the best surgical treatment remains controversial. Traditionally, anterior shoulder instability was treated with open stabilization. More recently, arthroscopic repair of the Bankart injury with suture anchor fixation has become an accepted technique.HypothesisNo systematic reviews have compared the rate of return to play following arthroscopic Bankart repair with suture anchor fixation with the Bristow-Latarjet procedure and open stabilization. We hypothesized that the rate of return to play will be similar regardless of surgical technique.Study designSystematic review; Level of evidence, 4.MethodsWe performed a systematic review and meta-analysis focused on return to play following shoulder stabilization. Inclusion criteria included studies in English that reported on rate of return to play and clinical outcomes following primary arthroscopic Bankart repair with suture anchors, the Latarjet procedure, or open stabilization. Statistical analyses included Student t tests and analyses of variance.ResultsSixteen papers reporting on 1036 patients were included. A total of 545 patients underwent arthroscopic Bankart repair with suture anchors, 353 with the Latarjet procedure, and 138 with open repair. No significant difference was found in patient demographic data among the studies. Patients returned to sport at the same level of play (preinjury level) more consistently following arthroscopic Bankart repair (71%) or the Latarjet procedure (73%) than open stabilization (66%) (P < .05). Return to play at any level and postoperative Rowe scores were not significantly different among studies. Recurrent dislocation was significantly less following the Latarjet procedure (3.5%) than after arthroscopic Bankart repair (6.6%) or open stabilization (6.7%) (P < .05).ConclusionThis systematic review demonstrates a greater rate of return to play at the preinjury level following arthroscopic Bankart repair and the Latarjet procedure than open stabilization. Despite this difference, >65% of all treated athletes returned to sport at their preinjury levels, with other outcome measures being similar among the treatment groups. Therefore, arthroscopic Bankart repair, the Latarjet procedure, and open stabilization remain good surgical options in the treatment of the athlete with anterior shoulder instability
A R4RS Compliant REPL in 7 KB
The Ribbit system is a compact Scheme implementation running on the Ribbit
Virtual Machine (RVM) that has been ported to a dozen host languages. It
supports a simple Foreign Function Interface (FFI) allowing extensions to the
RVM directly from the program's source code. We have extended the system to
offer conformance to the R4RS standard while staying as compact as possible.
This leads to a R4RS compliant REPL that fits in an 7 KB Linux executable. This
paper explains the various issues encountered and our solutions to make,
arguably, the smallest R4RS conformant Scheme implementation of all time.Comment: Presented at The 2023 Scheme and Functional Programming Workshop
(arXiv:cs/0101200
Benchmarking implementations of functional languages with ‘Pseudoknot', a float-intensive benchmark
Over 25 implementations of different functional languages are benchmarked using the same program, a floating-point intensive application taken from molecular biology. The principal aspects studied are compile time and execution time for the various implementations that were benchmarked. An important consideration is how the program can be modified and tuned to obtain maximal performance on each language implementation. With few exceptions, the compilers take a significant amount of time to compile this program, though most compilers were faster than the then current GNU C compiler (GCC version 2.5.8). Compilers that generate C or Lisp are often slower than those that generate native code directly: the cost of compiling the intermediate form is normally a large fraction of the total compilation time. There is no clear distinction between the runtime performance of eager and lazy implementations when appropriate annotations are used: lazy implementations have clearly come of age when it comes to implementing largely strict applications, such as the Pseudoknot program. The speed of C can be approached by some implementations, but to achieve this performance, special measures such as strictness annotations are required by non-strict implementations. The benchmark results have to be interpreted with care. Firstly, a benchmark based on a single program cannot cover a wide spectrum of ‘typical' applications. Secondly, the compilers vary in the kind and level of optimisations offered, so the effort required to obtain an optimal version of the program is similarly varie
Benchmarking implementations of functional languages with ‘Pseudoknot’, a float-intensive benchmark
- …