Subscribe to the gold package and get unlimited access to Shamra Academy
Register a new userTransient Typechecks are (Almost) Free
117
0
0.0
(
0
)
Added by
Stefan Marr
Publication date
2018
fields
Informatics Engineering
and research's language is
English
Ask ChatGPT about the research
No Arabic abstract
Transient gradual typing imposes run-time type tests that typically cause a linear slowdown in programs performance. This performance impact discourages the use of type annotations because adding types to a program makes the program slower. A virtual machine can employ standard just-in-time optimizations to reduce the overhead of transient checks to near zero. These optimizations can give gradually-typed languages performance comparable to state-of-the-art dynamic languages, so programmers can add types to their code without affecting their programs performance.
rate research
Read More
One form of type checking used in gradually typed language is transient type checking: whenever an object flows through code with a type annotation, the object is dynamically checked to ensure it has the methods required by the annotation. Just-in-time compilation and optimisation in virtual machines can eliminate much of the overhead of run-time transient type checks. Unfortunately this optimisation is not uniform: some type checks will significantly decrease, or even increase, a programs performance. In this paper, we refine the so called Takikawa protocol, and use it to identify which type annotations have the greatest effects on performance. In particular, we show how graphing the performance of such benchmarks when varying which type annotations are present in the source code can be used to discern potential patterns in performance. We demonstrate our approach by testing the Moth virtual machine: for many of the benchmarks where Moths transient type checking impacts performance, we have been able to identify one or two specific type annotations that are the likely cause. Without these type annotations, the performance impact of transient type checking becomes negligible. Using our technique programmers can optimise programs by removing expensive type checks, and VM engineers can identify new opportunities for compiler optimisation.
Context: Computational notebooks are a contemporary style of literate programming, in which users can communicate and transfer knowledge by interleaving executable code, output, and prose in a single rich document. A Domain-Specific Language (DSL) is an artificial software language tailored for a particular application domain. Usually, DSL users are domain experts that may not have a software engineering background. As a consequence, they might not be familiar with Integrated Development Environments (IDEs). Thus, the development of tools that offer different interfaces for interacting with a DSL is relevant. Inquiry: However, resources available to DSL designers are limited. We would like to leverage tools used to interact with general purpose languages in the context of DSLs. Computational notebooks are an example of such tools. Then, our main question is: What is an efficient and effective method of designing and implementing notebook interfaces for DSLs? By addressing this question we might be able to speed up the development of DSL tools, and ease the interaction between end-users and DSLs. Approach: In this paper, we present Bacata, a mechanism for generating notebook interfaces for DSLs in a language parametric fashion. We designed this mechanism in a way in which language engineers can reuse as many language components (e.g., language processors, type checkers, code generators) as possible. Knowledge: Our results show that notebook interfaces generated by Bacata can be automatically generated with little manual configuration. There are few considerations and caveats that should be addressed by language engineers that rely on language design aspects. The creation of a notebook for a DSL with Bacata becomes a matter of writing the code that wires existing language components in the Rascal language workbench with the Jupyter platform. Grounding: We evaluate Bacata by generating functional computational notebook interfaces for three different non-trivial DSLs, namely: a small subset of Halide (a DSL for digital image processing), SweeterJS (an extended version of JavaScript), and QL (a DSL for questionnaires). Additionally, it is relevant to generate notebook implementations rather than implementing them manually. We measured and compared the number of Source Lines of Code (SLOCs) that we reused from existing implementations of those languages. Importance: The adoption of notebooks by novice-programmers and end-users has made them very popular in several domains such as exploratory programming, data science, data journalism, and machine learning. Why are they popular? In (data) science, it is essential to make results reproducible as well as understandable. However, notebooks are only available for GPLs. This paper opens up the notebook metaphor for DSLs to improve the end-user experience when interacting with code and to increase DSLs adoption.
A proof that almost all quantum systems have trap free (that is, free from local optima) landscapes is presented for a large and physically general class of quantum system. This result offers an explanation for why gradient methods succeed so frequently in quantum control in both theory and practice. The role of singular controls is analyzed using geometric tools in the case of the control of the propagator of closed finite dimension systems. This type of control field has been implicated as a source of landscape traps. The conditions under which singular controls can introduce traps, and thus interrupt the progress of a control optimization, are discussed and a geometrical characterization of the issue is presented. It is shown that a control being singular is not sufficient to cause a control optimization progress to halt and sufficient conditions for a trap free landscape are presented. It is further shown that the local surjectivity axiom of landscape analysis can be refined to the condition that the end-point map is transverse to each of the level sets of the fidelity function. This novel condition is shown to be sufficient for a quantum systems landscape to be trap free. The control landscape for a quantum system is shown to be trap free for all but a null set of Hamiltonians using a novel geometric technique based on the parametric transversality theorem. Numerical evidence confirming this is also presented. This result is the analogue of the work of Altifini, wherein it is shown that controllability holds for all but a null set of quantum systems in the dipole approximation. The presented results indicate that by-and-large limited control resources are the most physically relevant source of landscape traps.
Free algebras are always free as modules over the base ring in classical algebra. In equivariant algebra, free incomplete Tambara functors play the role of free algebras and Mackey functors play the role of modules. Surprisingly, free incomplete Tambara functors often fail to be free as Mackey functors. In this paper, we determine for all finite groups conditions under which a free incomplete Tambara functor is free as a Mackey functor. For solvable groups, we show that a free incomplete Tambara functor is flat as a Mackey functor precisely when these conditions hold. Our results imply that free incomplete Tambara functors are almost never flat as Mackey functors. However, we show that after suitable localizations, free incomplete Tambara functors are always free as Mackey functors.
By using the Szemeredi Regularity Lemma, Alon and Sudakov recently extended the classical Andrasfai-Erd~os-Sos theorem to cover general graphs. We prove, without using the Regularity Lemma, that the following stronger statement is true. Given any (r-1)-partite graph H whose smallest part has t vertices, and any fixed c>0, there exists a constant C such that whenever G is an n-vertex graph with minimum degree at least ((3r-4)/(3r-1)+c)n, either G contains H, or we can delete at most Cn^(2-1/t) edges from G to yield an r-partite graph.
Log in to be able to interact and post comments
comments
Fetching comments
Sign in to be able to follow your search criteria
