sweet: update README.md Just fix a bunch of stale information. Change-Id: I0acefe2daec6c4c7d450e185bfc4206693499f7a Reviewed-on: https://go-review.googlesource.com/c/benchmarks/+/615576 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
diff --git a/sweet/README.md b/sweet/README.md index 5f350b9..b4aeac4 100644 --- a/sweet/README.md +++ b/sweet/README.md
@@ -21,9 +21,13 @@ Some benchmarks, however, have various requirements for building. Notably they are: -* `make` (tile38) +* `make` (esbuild, tile38) * `bash` (tile38) -* `binutils` (tile38) +* `binutils` (esbuild, tile38) + +The CockroachDB benchmark also requires a myriad of additional tools commonly +available in most Linux distributions. A full list is not available yet; try +running it and see what happens (sorry!). Please ensure your system has these tools installed and available in your system's PATH. @@ -47,7 +51,7 @@ $ go build ./cmd/sweet ``` -### Getting Assets +### Getting assets ```sh $ ./sweet get @@ -82,30 +86,14 @@ To execute it from somewhere else, point `-bench-dir` at `/path/to/x/benchmarks/sweet/benchmarks`. -## Tips and Rules of Thumb - -* If you're not confident if your experimental Go toolchain will work with all - the benchmarks, try the `-short` flag to run to get much faster feedback on - whether each benchmark builds and runs. -* You can expect the benchmarks to take a few hours to run with the default - settings on a somewhat sizable Linux box. -* If a benchmark fails to build, run with `-shell` and copy and re-run the - last command to get full output. - TODO(mknyszek): Dump the output to the terminal. -* If a benchmark fails to run, the output should have been captured in the - corresponding results file (e.g. if biogo-igor failed, check - `/path/to/results/biogo-igor/myconfig.results`) which is really just the - stderr (and usually stdout too) of the benchmark. You can also try to re-run - it yourself with the output of `-shell`. - -## Memory Requirements +## Memory requirements These benchmarks generally try to stress the Go runtime in interesting ways, and some may end up with very large heaps. Therefore, it's recommended to run the suite on a system with at least 16 GiB of RAM available to minimize the chance that results are lost due to an out-of-memory error. -## Configuration Format +## Configuration format The configuration is TOML-based and a more detailed description of fields may be found in the help docs for the `run` subcommand: @@ -114,7 +102,7 @@ $ ./sweet help run ``` -## Results Format +## Results format Results are produced into a single directory containing each benchmark as a sub-directory. Within each sub-directory is one file per configuration @@ -135,6 +123,15 @@ $ benchstat config1.results config2.results ``` +## Logs + +If you encounter an error when running Sweet, the most helpful thing for +debugging will be to look at the "log" output for each benchmark. This data can +found next to the [results file](#results-format) in a file named after the +Sweet configuration that produced it with the file extension `.log`. For +example, the log for `etcd` for `config1` can be found at +`results/etcd/config1.log` assuming the default results directory is used. + ## Noise This benchmark suite tries to keep noise low in measurements where possible. @@ -147,7 +144,18 @@ of its co-tenancy with the benchmark and throttles itself when the benchmarks are running). -### Tips for Reducing Noise +## General tips and rules of thumb + +* If you're not confident if your experimental Go toolchain will work with all + the benchmarks, try the `-short` flag to run to get much faster feedback on + whether each benchmark builds and runs. +* You can expect the benchmarks to take a few hours to run with the default + settings. +* If a benchmark fails to build or run, run with `-shell` and copy and re-run + the last command to get full output. + TODO(mknyszek): Dump the output to the terminal. + +### Tips for reducing noise * Sweet should be run on a dedicated machine where a [perflock daemon](https://github.com/aclements/perflock) is running (to avoid noise due