Da capo con scala

Abstract

Originally conceived as the target platform for Java alone, the Java Virtual Machine (JVM) has since been targeted by other languages, one of which is Scala. This trend, however, is not yet reflected by the benchmark suites commonly used in JVM research. In this paper, we thus present the design and analysis of the first full-fledged benchmark suite for Scala. We furthermore compare the benchmarks contained therein with those from the well-known DaCapo 9.12 benchmark suite and show where the differences are between Scala and Java code-and where not.

Cross-language compiler benchmarking: are we fast yet?

“…Furthermore, we select metrics that are designed to be language agnostic, i.e., that lead to similar results across languages. This is similar to the approach of Dufour et al [3] and Sewe et al [13] that select metrics that are independent for instance of the underlying execution envi-ronment. The following sections detail the selected metrics and discuss their cross-language properties.…”

“…1 SPECjvm2008, https://www.spec.org/jvm2008/ 2 Introducing the JetStream Benchmark Suite, Apple Inc., access date: 2016-02-14, https://webkit.org/blog/3418/introducing-the-j etstream-benchmark-suite/ 3 Octane, Google, https://developers.google.com/octane/ 4 Kraken, Mozilla Foundation, https://wiki.mozilla.org/Kraken 5 The Computer Language Benchmarks Game, Isaac Gouy, http://benc hmarksgame.alioth.debian.org/ DaCapo con Scala The work of Sewe et al [13] uses a similar approach for a suite of application benchmarks for Scala, which also runs on the JVM. DaCapo con Scala aims at helping JVM engineers and researchers to optimize JVMs for languages besides Java.…”

“…Benchmark suites are typically built around specific languages or platforms. For the Java virtual machine (JVM), there exist commercial suites such as SPECjvm2008 1 and academic projects such as DaCapo [1] and DaCapo con Scala [13]. JavaScript has a set of competing projects with different goals including JetStream, 2 Octane, 3 and Kraken.…”

Haskell vs. f# vs. scala

“…We attribute this difference mainly to the Scala compiler and the memory management overhead imposed by it. It has been reported elsewhere [28] that Scala makes heavy use of boxed types, resulting in a fairly high memory footprint, as shown in Table 3 where the peak memory consumption of the strict Scala implementation (58 MB) is even higher than the lazy Haskell implementation (57 MB). On the Windows machine the smaller amount of main memory will cause this high memory consumption to have a stronger impact on total runtime.…”

Snippets

“…A significant new contribution of C1X is a clear separation between the VM and the compiler. XIR [Titzer et al 2010] enables the runtime to specify a high-level operation in a domain-specific language. XIR is close to assembly language and only exists as data structures inside the VM.…”