Feature-Specific Profiling

St-Amour, Vincent; Andersen, Leif; Felleisen, Matthias

doi:10.1007/978-3-662-46663-6_3

Cited by 8 publications

(10 citation statements)

References 20 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The synth benchmark 5 is a sound synthesis example from St-Amour et al's work on feature-specific profiling [23]. The program consists of nine modules, half of which are from Typed Racket's array library.…”

Section: Synth (Vincent St-amour and Neil Toronto)mentioning

confidence: 99%

“…To analyze the cost of contract checks, we used the feature-specific profiler [23] on each benchmark's slowest configuration. 9 Figure 6 summarizes our findings.…”

Section: What Are the Bottlenecks?mentioning

confidence: 99%

“…Expanding this community will take the development of both guidelines on how to go about annotating a large system and performance measurement tools that help programmers discover how to identify those components of a gradually-typed configuration that yield the most benefit (per time investment). St-Amour's feature-specific profiler [23] and optimization coaches [24] look promising; we used both kinds of tools to find the reason for some of the most curious performance bottlenecks in our measurements.…”

Section: Long Live Sound Gradual Typingmentioning

confidence: 99%

See 2 more Smart Citations

Is sound gradual typing dead?

et al. 2016

Self Cite

View full text Add to dashboard Cite

Programmers have come to embrace dynamically-typed languages for prototyping and delivering large and complex systems. When it comes to maintaining and evolving these systems, the lack of explicit static typing becomes a bottleneck. In response, researchers have explored the idea of gradually-typed programming languages which allow the incremental addition of type annotations to software written in one of these untyped languages. Some of these new, hybrid languages insert run-time checks at the boundary between typed and untyped code to establish type soundness for the overall system. With sound gradual typing, programmers can rely on the language implementation to provide meaningful error messages when type invariants are violated. While most research on sound gradual typing remains theoretical, the few emerging implementations suffer from performance overheads due to these checks. None of the publications on this topic comes with a comprehensive performance evaluation. Worse, a few report disastrous numbers. In response, this paper proposes a method for evaluating the performance of gradually-typed programming languages. The method hinges on exploring the space of partial conversions from untyped to typed. For each benchmark, the performance of the different versions is reported in a synthetic metric that associates runtime overhead to conversion effort. The paper reports on the results of applying the method to Typed Racket, a mature implementation of sound gradual typing, using a suite of real-world programs of various sizes and complexities. Based on these results the paper concludes that, given the current state of implementation technologies, sound gradual typing faces significant challenges. Conversely, it raises the question of how implementations could reduce the overheads associated with soundness and how tools could be used to steer programmers clear from pathological cases.

show abstract

Section: Synth (Vincent St-amour and Neil Toronto)mentioning

confidence: 99%

“…To analyze the cost of contract checks, we used the feature-specific profiler [23] on each benchmark's slowest configuration. 9 Figure 6 summarizes our findings.…”

Section: What Are the Bottlenecks?mentioning

confidence: 99%

Section: Long Live Sound Gradual Typingmentioning

confidence: 99%

See 1 more Smart Citation

Is sound gradual typing dead?

et al. 2016

Self Cite

View full text Add to dashboard Cite

show abstract

“…We would like to point the work of St-Amour on optimization feedback [27] and feature-based profiling [28]. Profiling has existed for a long time at lower levels, such as at the Java Virtual Machine level, with profilers such as YourKit [8] or the Java VisualVM [7] or the x86 assembly, with processor hardware counters.…”

Section: Related Workmentioning

confidence: 99%

Improving the Interoperation between Generics Translations

Ureche

Stojanović

Beguet

et al. 2015

Proceedings of the Principles and Practices of Programming on the Java Platform

View full text Add to dashboard Cite

Generics on the Java platform are compiled using the erasure transformation, which only supports by-reference values. This causes slowdowns when generics operate on primitive types, such as integers, as they have to be transformed into reference-based objects.Project Valhalla is an effort to remedy this problem by specializing classes at load-time so they can efficiently handle primitive values. In its current early prototype 1 , the Valhalla compilation scheme limits the interaction between specialized and erased generics, thus preventing certain useful code patterns from being expressed.Scala has been using compile-time specialization for 6 years and has three generics compilation schemes working side by side. In Scala, programmers are allowed to write code that freely exercises the interaction between the different compilation schemes, at the expense of introducing subtle performance issues. Similar performance issues can affect Valhalla-enabled bytecode, whether the code was written in Java or translated from other JVM languages.In this context we explain how we help programmers avoid these performance regressions in the miniboxing transformation: (1) by issuing actionable performance advisories that steer programmers away from performance regressions and (2) by providing alternatives to the standard library constructs that use the miniboxing encoding, thus avoiding the conversion overhead.

show abstract

“…A technique that can help in this context is profiling, often used to detect performance "hot spots" and guide program optimization. Prior work on using profiling in the context of optimizing the performance of programs with run-time checks (Furr et al 2009;Mera et al 2011;St-Amour et al 2015) clearly demonstrates the benefits of this approach. Still, profiling infers information that is valid only for some particular input data values (and their execution traces).…”

mentioning

confidence: 95%

Static Performance Guarantees for Programs with Runtime Checks

Klemen

Stulova

López-García

et al. 2018

Proceedings of the 20th International Symposium on Principles and Practice of Declarative Programming

View full text Add to dashboard Cite

Instrumenting programs for performing run-time checking of properties, such as regular shapes, is a common and useful technique that helps programmers detect incorrect program behaviors. This is specially true in dynamic languages such as Prolog. However, such run-time checks inevitably introduce run-time overhead (in execution time, memory, energy, etc.). Several approaches have been proposed for reducing such overhead, such as eliminating the checks that can statically be proved to always succeed, and/or optimizing the way in which the (remaining) checks are performed. However, there are cases in which it is not possible to remove all checks statically (e.g., open libraries which must check their interfaces, complex properties, unknown code, etc.) and in which, even after optimizations, these remaining checks still may introduce an unacceptable level of overhead. It is thus important for programmers to be able to determine the additional cost due to the run-time checks and compare it to some notion of admissible cost. The common practice used for estimating run-time checking overhead is profiling, which is not exhaustive by nature. Instead, we propose a method that uses static analysis to estimate such overhead, with the advantage that the estimations are functions parameterized by input data sizes. Unlike profiling, this approach can provide guarantees for all possible execution traces, and allows assessing how the overhead grows as the size of the input grows. Our method also extends an existing assertion verification framework to express "admissible" overheads, and statically and automatically checks whether the instrumented program conforms with such specifications. Finally, we present an experimental evaluation of our approach that suggests that our method is feasible and promising.

show abstract

Feature-Specific Profiling

Cited by 8 publications

References 20 publications

Is sound gradual typing dead?

Is sound gradual typing dead?

Improving the Interoperation between Generics Translations

Static Performance Guarantees for Programs with Runtime Checks

Contact Info

Product

Resources

About