DataMill: a distributed heterogeneous infrastructure forrobust experimentation

Abstract

SUMMARYEmpirical systems research is facing a dilemma. Minor aspects of an experimental setup can have a significant impact on its associated performance measurements and potentially invalidate conclusions drawn from them. Examples of such influences, often called hidden factors, include binary link order, process environment size, compiler generated randomized symbol names, or group scheduler assignments. The growth in complexity and size of modern systems will further aggravate this dilemma, especially with the given time pressure of producing results. How can one trust any reported empirical analysis of a new idea or concept in computer science? DataMill is a community-based services-oriented open benchmarking infrastructure for rigorous performance evaluation. DataMill facilitates producing robust, reliable, and reproducible results. The infrastructure incorporates the latest results on hidden factors and automates the variation of these factors. DataMill is also of interest for research on performance evaluation. The infrastructure supports quantifying the effect of hidden factors, disseminating the research results beyond mere reporting. It provides a platform for investigating interactions and composition of hidden factors. This paper discusses experience earned through creating and using an open benchmarking infrastructure. Multiple research groups participate and have used DataMill. Furthermore, DataMill has been used for a performance competition at the International Conference on Runtime Verification (RV) 2014 and is currently hosting the RV 2015 competition. This paper includes a summary of our experience hosting the first RV competition.

Reliable benchmarking: requirements and solutions

“…-a set of input files, -the name of the tool to use, -command-line arguments for the tool (e.g., to specify a tool configuration), -the limits for CPU time, memory, and number of CPU cores, and -the number of runs that should be executed in parallel. This benchmark definition is given in XML format; an example is available in the tool documentation 25 and in Listing 2 of Appendix B. Additionally, a tool-info module (a tool-specific Python module) needs to be written that con-tains functions for creating a command-line string for a run (including input file and user-defined command-line arguments) and for determining the result from the exit code and the output of the tool. Such a tool-info module typically has under 50 lines of Python code, and needs to be written only once per tool.…”

“…The authors of DataMill [25] propose to make benchmarking more reliable by explicitly varying as many hardware and software factors as possible in a controlled manner while benchmarking, e.g., the hardware architecture, CPU model, memory size, link order, etc. To do so, they rely on a diverse set of worker machines, which are rebooted for each benchmark run into a specific OS installation.…”

“…https://github.com/sosy-lab/benchexec/blob/master/doc/ run-results.md25 https://github.com/sosy-lab/benchexec/blob/master/doc/ benchexec.md…”

International Competition on Runtime Verification (CRV)

“…This facilitated the communication and ensured transparency. To run the experiments, we used DataMill [30], to ensure robust and reproducible experiments. We selected the most powerful and generalpurpose machine and evaluated all submissions on this machine.…”

Empirical Formal Methods: Guidelines for Performing Empirical Studies on Formal Methods

“…Many different competitions exist in which tools are evaluated in terms of performance (evaluation of their usability is rare). Experiments are typically conducted on a representative set of benchmark problems and executed by benchmarking environments like BenchExec [16], BenchKit [17], DataMill [18], or StarExec [19]. The oldest competitions concern Boolean satisfiability (SAT) solvers [20], initiated three decades ago, and Automated Theorem Provers (ATP) [21].…”