Renaissance 0.13 Released

We are pleased to announce a new release of the Renaissance benchmark suite. This release is primarily a JDK compatibility update, introducing support for the newly released JDK17. The Renaissance suite now supports the complete set of LTS releases of the JDK (JDK8, JDK11, and JDK17) on Linux, MacOS X, and Windows. A few benchmarks have dependencies that limit their compatibility to a particular range of JDK versions and these are automatically excluded when running the suite on an unsupported JDK.

The changes in this release are minimal. The most important one just brings the Scala 2.12 benchmarks over to Scala 2.12.15, which now properly supports JDK17 – we merely pass on the compatibility improvements provided by the Scala community! This change affects the following benchmarks, which were previously using Scala 2.12.14:

  • finagle-chirper, finagle-http
  • neo4j-analytics
  • philosophers, scala-stm-bench7
  • reactors
  • all apache-spark workloads

Here we just want to note that no benchmark code has been changed in this release, only project documentation and parts of the harness responsible for plugin loading (plugin main class can be now specified in its manifest).

We welcome any comments and contributions.

Happy benchmarking!

Renaissance 0.12 Released

We are pleased to announce a new release of the Renaissance benchmark suite. Apart from a number of internal cleanups, most changes in this release focused on improving compatibility with modern platforms. Most notably, we have moved away from Scala 2.11, Scala 2.12, and Spark 2 towards Scala 2.12, Scala 2.13 and Spark 3. Some benchmarks were unaffected, some needed just dependency updates, and some needed a bit more work.

The workloads, as implemented by the benchmarks, are largely unchanged, but the code being executed as a result of the benchmark workload may differ substantially from previous version of Renaissance, mainly due to substantial dependency updates in some of the benchmarks. See the sections below for more details.

On the platform compatibility front, the suite supports JDK8 and JDK11 on Linux, MacOS X, and Windows. While most benchmarks also run on more recent JDK versions, some of them have dependencies that limit their compatibility to a particular range of JDK versions.

We welcome any comments and contributions.

Happy benchmarking!

Harness changes

The harness now automatically excludes benchmarks that are known to be incompatible with the JVM on which it executes. This can be disabled using the --no-jvm-check option on the command line.

The harness now allows using a specific base directory for scratch files. The current directory is still the default, but it can be changed using the --scratch-base option on the command line. For debugging purposes, the --keep-scratch option disables deleting the scratch directories when the harness terminates.

Finally, to make experimentation with benchmarks a bit easier, the harness allows overriding benchmark parameters using the --override command line option.

Spark benchmark changes

The Spark benchmarks moved from Spark 2.0.0 on Scala 2.11.8 to Spark 3.1.2 on Scala 2.12.14, which is a major change in the underlying libraries. In addition to various cleanups and compatibility fixes for Windows, there have been several changes that may influence the overall performance.

  • The number of threads used by the Spark local executor is now limited to reflect the parallelism of a particular workload, which prevents scalability issues on huge machines with tens of cores. The limit is configured using the spark_thread_limit parameter. - All workloads use the default partitioning of input data and limit the storage level of input data to memory only.
  • als and movie-lens also limit the storage level of intermediate data sets to memory only to avoid benchmarking storage IO.
  • log-regression now avoids repeated conversion from an RDD to DataFrame.
  • naive-bayes now uses ML classes from the package because classes from the org.apache.spark.mllib package only served as wrappers, introducing unnecessary conversion from RDD to DataFrame.

Benchmarks using Scala 2.13.6

The following lists Java bencharks with a simple Scala wrapper or Scala benchmarks that have been updated to use Scala 2.13.6, along with notable changes in some of them:

  • akka-uct (previously Scala 2.11.8)
    • Updated akka-actor dependency (2.3.11 -> 2.6.12)
    • Very minor benchmark update for the 2.6.x API.
  • db-shootout (Java)
    • Maximum supported JVM version set to 11.
  • dotty (previously Scala 2.12.8)
    • Updated Dotty compiler (0.12.0 -> 3.0.0)
    • Compiles scalap sources instead of “type-system puzzles”.
    • Adds hash-based validation of generated Tasty files.
  • fj-kmeans, future-genetic (Java)
  • mnemonics, par-mnemonics, scrabble (Java)
  • rx-scrabble (Java)
  • scala-kmeans (previously Scala 2.12.8)
  • scala-doku (previously Scala 2.11.7)
    • Bundled cafesat dependency updated (0.01 -> 0.01-28-gd0edeaa) and cleaned up for Scala 2.13
    • Bundled scala-smtlib dependency updated (0.1 -> 0.2.1-52-ga71d6b0) and cleaned up for Scala 2.13

Benchmarks using Scala 2.12.14

The following lists benchmarks that use Scala 2.12.14, along with notable changes in some them:

  • finagle-chirper, finagle-http (previously Scala 2.11.8)
  • neo4j-analytics (previously Scala 2.12.8)
    • Benchmark ported to Neo4J 4.x API
    • Updated org.neo4j.neo4j dependency (3.5.12 -> 4.2.4)
    • Updated net.liftweb.lift-json dependency (3.2.0 -> 3.4.3)
    • Requires JVM versions between 11 and 15, inclusive (Neo4J requirements).
  • philosophers, scala-stm-bench7 (previously Scala 2.12.3)
  • reactors (previously Scala 2.11.8)
  • Spark workloads (previously Scala 2.11.8)

Renaissance 0.11 Released

A new release of the Renaissance benchmark suite includes several changes to the workloads:

  • movie-lens bug fix, where part of the setup was moved out of the core benchmark iteration,
  • log-regression bug fix, where input features are cached to avoid parsing the input during each benchmark iteration,
  • neo4j-analytics improvement that adds indices and uses placeholder for queries (contributed by Michael Hunger from Neo4J), and
  • dotty fix for Windows compatibility.

The Renaissance harness now forces a garbage collection run before each iteration. This changes especially the behavior of Spark based workloads, which would otherwise retain weakly referenced objects until Spark controlled cleanup once every 30 minutes. The garbage collection forced by the harness can be disabled with the --no-forced-gc flag.

The harness also includes two plugins, jmx-timers for collecting the JIT compilation times, and ubench-agent for collecting the values of arbitrary hardware performance counters.

The JSON result format now also includes OS and system metadata, which help capture the benchmark execution conditions across experiments.

We also note that Renaissance helped tune the OpenJDK HotSpot inlining settings.

Special thanks go to:

  • Michael Hunger from Neo4J for his contribution on the neo4j-analytics benchmark,
  • Guillaumes Martres from EPFL for his input on fixing the dotty benchmark for Windows, and
  • Tom Rodriguez from Oracle Labs for spotting a bug in log-regression.

Renaissance 0.10 Released

Two months after the announcement of the Renaissance benchmark suite, we are pleased to release version 0.10.0 that includes a new benchmark, several improvements and bug fixes.

Most importantly, we added the scala-doku benchmark which is a Sudoku solver written in Scala. Other changes include making finagle-http more parallel, addressing an important bug in finagle-chirper and removing the native libraries dependencies of db-shootout. Moreover, the compatibility with different architectures has been improved and JDK11 is now also supported. All changes are listed in the GitHub release.

The numerous reports and positive feedback from the community are very encouraging and show a quick adoption of the suite across the industry. It helps companies like Oracle, IBM or SAP track performance and/or fix bugs. For instance, this OpenJ9 bug running Apache Spark has been spotted thanks to the Renaissance suite.

We address special thanks to:

  • tkrodriguez from Oracle for the in-depth analysis of the finagle-chirper bug
  • vkostyukov from Twitter, for his feedback on the Finagle benchmarks
  • MBaesken and the SAP Machine team for compatibility testing on less common infrastructures

Renaissance 0.9 Released

We are pleased to announce the release of the Renaissance benchmark suite for the Java Virtual Machine. The suite is primarily focused on parallelism and concurrency, and provides workloads that exercise the modern parallel programming abstractions and primitives provided by the JVM and the Java Class Library. Through these workloads, the suite aims to aid in understanding of how modern applications and data processing frameworks use the concurrency features of the JVM, and to foster development of new optimizations that enable more efficient execution of such workloads.

The Renaissance benchmark suite is intended to provide workloads that are not available elsewhere, and thus complement the workloads found in the existing, commonly used benchmark suites for the JVM, such as DaCapo, ScalaBench, and SPECjvm2008, which we gratefully acknowledge. We have found a great deal of inspiration in these suites, and strive to match and, where possible, exceed, the level of quality and usability established by these suites.

We realize that keeping a benchmarking suite alive (so that it evolves along with the platform and applications) requires a tremendous amount of work. We therefore aim to make the Renaissance development process as open as possible, and invite the community to participate in the process. The code is open-source and the contribution mechanism is open. The suite will be regularly updated through minor releases, while new benchmarks will be introduced or retired in major releases.

Version 0.9 marks the first public open-source release of the Renaissance suite and is considered a major-release candidate with respect to the selection of workloads included in the suite. The initial selection is based on the upcoming PLDI’19 paper, which also provides additional details on motivation behind the suite as well as detailed analysis of individual benchmarks and initial performance results. We are currently stabilizing the internal design of the harness and its public APIs, and work on a number of features that need to be included in version 1.0, the first major release of the suite which should be ready in few weeks.

We welcome any comments and contributions.

Happy benchmarking!