HackerPapers

arXiv:1604.01290cs.PL

Implementation of the Programming Language Dino -- A Case Study in Dynamic Language Performance

Vladimir N. Makarov

Early discovery. Linked by one identifiable commenter. This paper is outside the main ranking; a mention is not an endorsement.

Abstract

The article gives a brief overview of the current state of programming language Dino in order to see where its stands between other dynamic programming languages. Then it describes the current implementation, used tools and major implementation decisions including how to implement a stable, portable and simple JIT compiler. We study the effect of major implementation decisions on the performance of Dino on x86-64, AARCH64, and Powerpc64. In brief, the performance of some model benchmark on x86-64 was improved by $\textbf{3.1}$ times after moving from a stack based virtual machine to a register-transfer architecture, a further $\textbf{1.5}$ times by adding byte code combining, a further $\textbf{2.3}$ times through the use of JIT, and a further $\textbf{4.4}$ times by performing type inference with byte code specialization, with a resulting overall performance improvement of about $\textbf{47}$ times. To put these results in context, we include performance comparisons of Dino with widely used implementations of Ruby, Python 3, PyPy and JavaScript on the three platforms mentioned above. The goal of this article is to share the experience of Dino implementation with other dynamic language implementors in hope that it can help them to improve implementation of popular dynamic languages to make them probably faster and more portable, using less developer resources, and may be to avoid some mistakes and wrong directions which were experienced during Dino development.

arXiv comments
10 pages, 1 figure, 4 tables
Journal reference
DOI
Subjects
cs.PLProgramming Languages

On Hacker News

Linked by 1 identifiable commenter in 1 comment across 1 thread, from Jun 2018 to Jun 2018.

Comments linking this paper, per year.

Discussed in comments1 thread

    • This is simply not true. You're massively underestimating the overhead of a bytecode VM. Even the most optimal bytecode VMs are easily beaten by the simplest of JITs in 100 lines of C: https://arxiv.org/pdf/1604.01290.pdf Code doesn't even need to be "hot" to make it worth it.…

      jashmatthewsView on HNParent context

Submitted to Hacker News

Connected through shared HN threads, not inferred similarity or a recommendation.