feat: New script to output table of benchmarks for README pasting.

[charlielye]

Benchmarks are cool man. They let you see how fast the thing goes.

This adds a tiny benchmark lib to barretenberg. Use it e.g.

    Timer proof_timer;
    auto proof = acir_composer.create_proof(constraint_system, witness, recursive);
    write_benchmark("proof_construction_time", proof_timer.milliseconds(), "acir_test", current_dir);

The write_benchmark function takes a name, value, and then an arbitrary number of label/value pairs.
The output data is very raw. The library will auto set the type to number/string/bool.
The output data is JSONL in the form e.g.

{"timestamp": "2023-10-10T22:17:10Z", "name": "pk_construction_time", "type": "number", "value": 234, "threads": 128, "acir_test": "1_mul"}
{"timestamp": "2023-10-10T22:17:10Z", "name": "proof_construction_time", "type": "number", "value": 173, "threads": 128, "acir_test": "1_mul"}
{"timestamp": "2023-10-10T22:17:10Z", "name": "vk_construction_time", "type": "number", "value": 74, "threads": 128, "acir_test": "1_mul"}

The labels are for ingesters to group/slice the data as they wish.

To enable benchmarking, set the env var e.g BENCHMARK_FD=3, then redirect the given file descriptor number to wherever you want the benchmarks, e.g.

BENCHMARK_FD=3 ./run_acir_tests.sh 1_mul 3>&1 > /dev/null

Sends them to FD1 (stdout) and sends stdout to /dev/null. Thus this just prints out the benchmarks like above. Or:

BENCHMARK_FD=3 ./run_acir_tests.sh 1_mul 3>>benchmarks.jsonl

Appends them to file benchmarks.jsonl

Longer term vision for benchmarks is that our TS code (or any other code), outputs benchmarks in the same style. The build-system will expect benchmarks, if enabled, to be have been written to a specific file in the container (or mounted volume), and will then upload the benchmarks to S3 for later, async processing (using e.g. glue -> athena -> quicksight/grafana).
Both the container itself could manipulate the JSONL to inject properties specific to the test run, and the build-system could inject properties prior to upload such as job-name or commit-hash (although structured file-naming might solve this better).

[ludamad]

How does it compare to our existing benchmarks?

[codygunton]

I tried this out in some of the honk tests and it worked like a charm. One minor annoyance was I had to include three headers: timer.hpp, benchmark.hpp and <filesystem>. Something to consider is that including <filesystem> is quite expensive according to https://github.com/s9w/cpp-lit.

[AztecBot]

Benchmark results

Metrics with a significant change:

• node_history_sync_time_in_ms (5): 14,278 (+17%)
• node_history_sync_time_in_ms (10): 27,394 (+25%)
• note_history_successful_decrypting_time_in_ms (5): 3,093 (+20%)
• note_history_successful_decrypting_time_in_ms (10): 6,111 (+27%)
• note_history_trial_decrypting_time_in_ms (10): 252 (+66%)

Detailed results

All benchmarks are run on txs on the Benchmarking contract on the repository. Each tx consists of a batch call to create_note and increment_balance, which guarantees that each tx has a private call, a nested private call, a public call, and a nested public call, as well as an emitted private note, an unencrypted log, and public storage read and write.

This benchmark source data is available in JSON format on S3 here.

Values are compared against data from master at commit db3fa62e and shown if the difference exceeds 1%.

L2 block published to L1

Each column represents the number of txs on an L2 block published to L1.

Metric	8 txs	32 txs	128 txs
l1_rollup_calldata_size_in_bytes	45,444	179,588	716,132
l1_rollup_calldata_gas	222,900	867,848	3,449,420
l1_rollup_execution_gas	841,987	3,594,956	22,204,789
l2_block_processing_time_in_ms	1,004 (-2%)	3,840 (-2%)	15,160 (-1%)
note_successful_decrypting_time_in_ms	329 (-2%)	1,018 (-2%)	3,705 (-6%)
note_trial_decrypting_time_in_ms	33.0 (-15%)	109 (+1%)	137
l2_block_building_time_in_ms	8,852	35,450 (-1%)	156,045 (-1%)
l2_block_rollup_simulation_time_in_ms	6,527	26,149	104,136 (-1%)
l2_block_public_tx_process_time_in_ms	2,283 (-1%)	9,179 (-1%)	51,270 (-1%)

L2 chain processing

Each column represents the number of blocks on the L2 chain where each block has 16 txs.

Metric	5 blocks	10 blocks
node_history_sync_time_in_ms	⚠️ 14,278 (+17%)	⚠️ 27,394 (+25%)
note_history_successful_decrypting_time_in_ms	⚠️ 3,093 (+20%)	⚠️ 6,111 (+27%)
note_history_trial_decrypting_time_in_ms	127 (+3%)	⚠️ 252 (+66%)
node_database_size_in_bytes	1,661,949	1,199,660
pxe_database_size_in_bytes	27,188	54,187

Circuits stats

Stats on running time and I/O sizes collected for every circuit run across all benchmarks.

Circuit	circuit_simulation_time_in_ms	circuit_input_size_in_bytes	circuit_output_size_in_bytes
private-kernel-init	52.1 (+9%)	61,697	18,841
private-kernel-ordering	25.9 (+8%)	24,233	8,089
base-rollup	939 (+10%)	639,797	811
root-rollup	42.3 (+11%)	4,072	1,097
private-kernel-inner	47.4 (+8%)	81,504	18,841
public-kernel-private-input	53.0 (+11%)	41,455	18,841
public-kernel-non-first-iteration	34.2 (+7%)	41,497	18,841
merge-rollup	1.00 (+23%)	2,592	873

Miscellaneous

Transaction sizes based on how many contracts are deployed in the tx.

Metric	0 deployed contracts	1 deployed contracts
tx_size_in_bytes	8,723	27,508

[codygunton]

This new benchmarking system taking 30 mins at the end of the pipeline is kind of painful though 😬

[charlielye]

This new benchmarking system taking 30 mins at the end of the pipeline is kind of painful though 😬

The 30m benchmark run was actually nothing to do with this PR, but I raised with Palla last week and I believe he's reduced it to 10m, so no longer than our worst case e2e test.

[charlielye]

I tried this out in some of the honk tests and it worked like a charm. One minor annoyance was I had to include three headers: timer.hpp, benchmark.hpp and <filesystem>. Something to consider is that including <filesystem> is quite expensive according to https://github.com/s9w/cpp-lit.

Unless I'm missing something, you only need to include timer.hpp if you're writing a benchmark that needed the timer (I guess we could include timer in the benchmark header as it's likely you'll have a time based benchmark, but it's not a given, and normal practice would not be for benchmark.hpp to import timer.hpp given that it doesn't use it).

And you only need filesystem if your doing filesystem stuff, which my example above does (it uses it to determine the name of the acir test), but there maybe ways of achieving the same without using filesystem.