are-we-fast-yet

Are We Fast Yet? Comparing Language Implementations with Objects, Closures, and Arrays

https://github.com/smarr/are-we-fast-yet

Science Score: 44.0%

This score indicates how likely this project is to be science-related based on various indicators:

  • CITATION.cff file
    Found CITATION.cff file
  • codemeta.json file
    Found codemeta.json file
  • .zenodo.json file
  • DOI references
    Found 11 DOI reference(s) in README
  • Academic publication links
  • Committers with academic emails
  • Institutional organization owner
  • JOSS paper metadata
  • Scientific vocabulary similarity
    Low similarity (12.9%) to scientific vocabulary

Keywords

benchmark benchmarking comparison dynamic-languages language language-implementations performance

Keywords from Contributors

continuous-benchmarking continuous-testing performance-tracking reproducibility research-tool
Last synced: 6 months ago · JSON representation ·

Repository

Are We Fast Yet? Comparing Language Implementations with Objects, Closures, and Arrays

Basic Info
  • Host: GitHub
  • Owner: smarr
  • License: other
  • Language: Java
  • Default Branch: master
  • Homepage:
  • Size: 3.75 MB
Statistics
  • Stars: 350
  • Watchers: 16
  • Forks: 39
  • Open Issues: 19
  • Releases: 2
Topics
benchmark benchmarking comparison dynamic-languages language language-implementations performance
Created about 10 years ago · Last pushed 12 months ago
Metadata Files
Readme Changelog License Citation

README.md

Are We Fast Yet? Comparing Language Implementations with Objects, Closures, Arrays, and Strings

Build Status

Goal

The goal of this project is to assess whether a language implementation is highly optimizing and thus able to remove the overhead of programming abstractions and frameworks. We are interested in comparing language implementations (not languages!) with each other and optimize their compilers as well as the run-time representation of objects, closures, arrays, and strings.

This is in contrast to other projects such as the Computer Language Benchmark game, which encourage finding the smartest possible way to express a problem in a language to achieve best performance, an equally interesting but different problem.

Approach

To allow us to compare the degree of optimization done by the implementations as well as the absolute performance achieved, we set the following basic rules:

  1. The benchmark is 'identical' for all languages.
    This is achieved by relying only on a widely available and commonly used subset of language features and data types.

  2. The benchmarks should use language 'idiomatically'.
    This means, they should be realized as much as possible with idiomatic code in each language, while relying only on the core set of abstractions.

For the detailed set of rules see the guidelines document. For a description of the set of common language abstractions see the core language document.

The initial publication describing the project is Cross-Language Compiler Benchmarking: Are We Fast Yet? and can be cited as (bib file):

Stefan Marr, Benoit Daloze, Hanspeter Mössenböck. 2016. Cross-Language Compiler Benchmarking: Are We Fast Yet? In Proceedings of the 12th Symposium on Dynamic Languages (DLS '16). ACM.

Disclaimer: This is an Academic Project to Facilitate Research on Languages

To facilitate our research, we want to be able assess the effectiveness of compiler and runtime optimizations for a common set of abstractions between languages. As such, many other relevant aspects such as GC, standard libraries, and language-specific abstractions are not included here. However, by focusing on this one aspect, we know exactly what is compared.

Current Status

Currently, we have 14 benchmarks ported to ten different languages, including C++, Crystal, Java, JavaScript, Lua, Python, Ruby, SOM Smalltalk, SOMns (a Newspeak implementation), and Smalltalk (Squeak/Pharo).

The graph below shows some older results for different implementations after warmup, to ensure peak performance is reported:

Peak Performance of Java, Node.js, JRuby, JRuby+Truffle, MRI, and SOMns,
last update 2016-06-20

A detailed overview of the results is in docs/performance.md.

The benchmarks are listed below. A detailed analysis including metrics for the benchmarks is in docs/metrics.md.

Macro Benchmarks

  • CD is a simulation of an airplane collision detector. Based on WebKit's JavaScript CDjs. Originally, CD was designed to evaluate real-time JVMs.

  • DeltaBlue is a classic VM benchmark used to tune, e.g., Smalltalk, Java, and JavaScript VMs. It implements a constraint solver.

  • Havlak implements a loop recognition algorithm. It has been used to compare C++, Java, Go, and Scala performance.

  • Json is a JSON string parsing benchmark derived from the minimal-json Java library.

  • Richards is a classic benchmark simulating an operating system kernel. The used code is based on Wolczko's Smalltalk version.

Micro Benchmarks

Micro benchmarks are based on SOM Smalltalk benchmarks unless noted otherwise.

  • Bounce simulates a ball bouncing within a box.

  • List recursively creates and traverses lists.

  • Mandelbrot calculates the classic fractal. It is derived from the Computer Languages Benchmark Game.

  • NBody simulates the movement of planets in the solar system. It is derived from the Computer Languages Benchmark Game.

  • Permute generates permutations of an array.

  • Queens solves the eight queens problem.

  • Sieve finds prime numbers based on the sieve of Eratosthenes.

  • Storage creates and verifies a tree of arrays to stress the garbage collector.

  • Towers solves the Towers of Hanoi game.

Contributing

Considering the large number of languages out there, we are open to contributions of benchmark ports to new languages. We would also be interested in new benchmarks that are in the range of 300 to 1000 lines of code.

When porting to a new language, please carefully consider the guidelines and description of the core language to ensure that we can compare results.

A list of languages we would definitely be interested in is on the issues tracker.

This includes languages like Dart, Scala, and Go. Other interesting ports could be for Racket, Clojure, or CLOS, but might require more carefully thought-out rules for porting. Similarly, a port to Rust need additional care to account for the absence of a garbage collector and should be guided by our C++ port.

Getting the Code and Running Benchmarks

Quick Start

To obtain the code, benchmarks, and documentation, checkout the git repository:

bash git clone --depth 1 https://github.com/smarr/are-we-fast-yet.git

Run Benchmarks for a Specific Language

The benchmarks are sorted by language in the benchmarks folder. Each language has its own harness. For JavaScript and Ruby, the benchmarks are executed like this:

bash cd benchmarks/JavaScript node harness.js Richards 5 10 cd ../Ruby ruby harness.rb Queens 5 20

The harness takes three parameters: benchmark name, number of iterations, and problem size. The benchmark name corresponds to a class or file of a benchmark. The number of iterations defines how often a benchmark should be executed. The problem size can be used to influence how long a benchmark takes. Note that some benchmarks rely on magic numbers to verify their results. Those might not be included for all possible problem sizes.

The rebench.conf file specifies the supported problem sizes for each benchmark.

Using the Full Benchmark Setup

Each port of the benchmarks comes with a build.sh file, which either runs any build steps needed, or with ./build.sh style runs code style checks. Though, the repository does not contain setup steps for the various languages anymore. We abandoned the idea of maintaining a full setup, since it took too much work.

Benchmark are configured and executed with the ReBench tool.

ReBench can be installed via the Python package manager pip:

pip install ReBench

The benchmarks can be executed with the following command in the root folder, assuming they have be previously built:

rebench -d --without-nice rebench.conf all

The -d gives more output during execution, and --without-nice means that the nice tool enforcing high process priority is not used. We don't use it here to avoid requiring root rights.

Note: The rebench.conf file specifies how and which benchmarks to execute. It also defines the arguments to be passed to the benchmarks.

Academic Work using this benchmark suite

Owner

  • Name: Stefan Marr
  • Login: smarr
  • Kind: user
  • Location: Canterbury, UK
  • Company: University of Kent

Investigating concurrency, language implementation, and VM technology.

Citation (CITATION.bib)

@inproceedings{Marr:2016:AWFY,
  abstract = {Comparing the performance of programming languages is difficult because they differ in many aspects including preferred programming abstractions, available frameworks, and their runtime systems. Nonetheless, the question about relative performance comes up repeatedly in the research community, industry, and wider audience of enthusiasts.
  This paper presents 14 benchmarks and a novel methodology to assess the compiler effectiveness across language implementations. Using a set of common language abstractions, the benchmarks are implemented in Java, JavaScript, Ruby, Crystal, Newspeak, and Smalltalk. We show that the benchmarks exhibit a wide range of characteristics using language-agnostic metrics. Using four different languages on top of the same compiler, we show that the benchmarks perform similarly and therefore allow for a comparison of compiler effectiveness across languages. Based on anecdotes, we argue that these benchmarks help language implementers to identify performance bugs and optimization potential by comparing to other language implementations.},
  appendix = {https://github.com/smarr/are-we-fast-yet#readme},
  author = {Marr, Stefan and Daloze, Benoit and Mössenböck, Hanspeter},
  blog = {https://stefan-marr.de/2016/10/cross-language-compiler-benchmarking-are-we-fast-yet/},
  booktitle = {Proceedings of the 12th Symposium on Dynamic Languages},
  day = {1},
  doi = {10.1145/2989225.2989232},
  html = {https://stefan-marr.de/papers/dls-marr-et-al-cross-language-compiler-benchmarking-are-we-fast-yet/},
  isbn = {978-1-4503-4445-6},
  keywords = {Benchmark Compiler Crystal Graal Java JavaScript Metrics Newspeak NodeJS Performance Ruby Smalltalk Truffle},
  location = {Amsterdam, Netherlands},
  month = nov,
  numpages = {12},
  pages = {120--131},
  pdf = {https://stefan-marr.de/downloads/dls16-marr-et-al-cross-language-compiler-benchmarking-are-we-fast-yet.pdf},
  publisher = {ACM},
  series = {DLS'16},
  title = {{Cross-Language Compiler Benchmarking---Are We Fast Yet?}},
  year = {2016},
  month_numeric = {11}
}

GitHub Events

Total
  • Issues event: 4
  • Watch event: 21
  • Delete event: 1
  • Issue comment event: 14
  • Push event: 12
  • Pull request review event: 4
  • Pull request event: 6
  • Fork event: 2
  • Create event: 3
Last Year
  • Issues event: 4
  • Watch event: 21
  • Delete event: 1
  • Issue comment event: 14
  • Push event: 12
  • Pull request review event: 4
  • Pull request event: 6
  • Fork event: 2
  • Create event: 3

Committers

Last synced: 9 months ago

All Time
  • Total Commits: 965
  • Total Committers: 10
  • Avg Commits per committer: 96.5
  • Development Distribution Score (DDS): 0.054
Past Year
  • Commits: 14
  • Committers: 3
  • Avg Commits per committer: 4.667
  • Development Distribution Score (DDS): 0.214
Top Committers
Name Email Commits
Stefan Marr g****t@s****e 913
Francois Perrad f****d@g****g 15
Benoit Daloze e****p@g****m 15
Fabio Niephaus c****e@f****m 13
Tim Felgentreff t****f@g****m 4
rvigee c****t@r****m 1
Tobias Pape t****s@n****e 1
Guido Chari c****g@g****m 1
Edd Barrett v****1@g****m 1
Chris Seaton c****s@c****m 1
Committer Domains (Top 20 + Academic)

Issues and Pull Requests

Last synced: 6 months ago

All Time
  • Total issues: 36
  • Total pull requests: 64
  • Average time to close issues: over 1 year
  • Average time to close pull requests: 6 months
  • Total issue authors: 7
  • Total pull request authors: 12
  • Average comments per issue: 1.5
  • Average comments per pull request: 3.2
  • Merged pull requests: 54
  • Bot issues: 0
  • Bot pull requests: 0
Past Year
  • Issues: 2
  • Pull requests: 5
  • Average time to close issues: N/A
  • Average time to close pull requests: 5 days
  • Issue authors: 2
  • Pull request authors: 3
  • Average comments per issue: 0.0
  • Average comments per pull request: 4.4
  • Merged pull requests: 4
  • Bot issues: 0
  • Bot pull requests: 0
Top Authors
Issue Authors
  • smarr (28)
  • rochus-keller (3)
  • eregon (2)
  • fniephaus (1)
  • yuppox (1)
  • vext01 (1)
  • JensLincke (1)
  • ltratt (1)
  • q3cpma (1)
Pull Request Authors
  • smarr (37)
  • eregon (10)
  • fniephaus (10)
  • fperrad (7)
  • timfel (2)
  • vext01 (2)
  • vchuravy (1)
  • charig (1)
  • OvermindDL1 (1)
  • krono (1)
  • jfheins (1)
  • ExtReMLapin (1)
Top Labels
Issue Labels
enhancement (10) contribution request (9) bug (4) question (1) help wanted (1)
Pull Request Labels
enhancement (16) bug (12) help wanted (4) maintenance (4)

Dependencies

.github/workflows/ci.yml actions
  • actions/checkout v3 composite
  • actions/setup-python v4 composite
  • hpi-swa/setup-smalltalkCI v1 composite
  • leafo/gh-actions-lua v8 composite
  • leafo/gh-actions-luarocks v4 composite
  • oprypin/install-crystal v1 composite
  • psf/black stable composite
benchmarks/JavaScript/package.json npm
  • @babel/core ^7.19.6 development
  • @babel/preset-env ^7.19.4 development
  • babel-loader ^8.2.5 development
  • eslint ^8.23.1 development
  • eslint-config-airbnb-base ^15.0.0 development
  • eslint-plugin-import ^2.26.0 development
  • eslint-plugin-n ^15.2.5 development
  • eslint-plugin-promise ^6.0.1 development
  • webpack ^5.74.0 development
  • webpack-cli 4.10.0 development