You may want to build a sandbox if one or more of these sound familiar:
- You want to build recognizable, representative binaries instead of toy programs for experimentation, but you also don't want the overhead of the actual SPEC CPU2017 benchmark suite, nor a script to manage the binaries' execution.
- You want to modify the source code of the benchmarks without corrupting the SPEC CPU2017 source tree. Modifying the source code is allowed if you use the
strict_rundir_verify=nooption in your configuration file, or if you create a modified installation of the benchmark using theconvert_to_developmentutility. But an easier option is to create sandboxes for each benchmark program you wish to investigate, and it doesn't corrupt the source tree if you're reusing it with other experiments. - You want to modify the options or inputs provided to the benchmarks to investigate how the benchmark binaries respond.
