BENCHMARK(1)

πŸ“¦
version 7.44.0 Β· 2 versions
, in nixpkgs unstable

πŸ’… benchmark(1) Β· BRL-CAD Β· bestie edition πŸ¦‹

πŸŽ€ NAME πŸŽ€

benchmark β€” runs the BRL-CAD benchmark, periodt. πŸ’–

✨ SYNOPSIS ✨

[OPTION=value] benchmark [command] [OPTION=value] [RT_OPTIONS]

πŸ’– DESCRIPTION πŸ’–

Okay so the benchmark suite tests the performance of a given system by iteratively rendering several well-known datasets into 512x512 images where performance metrics are documented and fairly well understood. The local machine performance is compared to the base system (called VGR) and a numeric "VGR" multiplier of performance is computed. That number is a simplified metric from which one may qualitatively compare CPU and cache performance, versions of BRL-CAD, and different compiler characteristics. Iconic little number, honestly. πŸ”₯

Run without any arguments or variables set, and the benchmark suite will run a series of tests where it renders several image frames. By default, the benchmark suite will attempt to calibrate the intensity of the test frames with the performance characteristics of the machine running the tests. Very main-character energy. ✨

When the benchmark completes, output is saved to several log files including a summary file containing tabulated results, a benchmark.log file containing the output from a given run, and multiple log files for each test frame.

⚠️ The generated tabular summary file will not be removed automatically regardless of invocation command, and must always be manually deleted. No cap, bestie β€” that cleanup is on you πŸ’…

🌸 COMMANDS 🌸

There are various commands that may be given to the BRL-CAD benchmark to perform actions such as invoking computation tests or filesystem clean-up:

  • clean β€” Remove the test-specific .pix and .log files.
  • clobber β€” Same as clean, but also removes benchmark.log files and prompts the user before proceeding.
  • help (or h) β€” Display a brief usage statement.
  • instructions (or instruct) β€” Display more detailed usage instructions.
  • quiet β€” Quell printing output (output is still logged).
  • verbose β€” Turn on extra debug output.
  • run β€” Initiate the benchmark analysis.
  • start β€” Legacy compatibility alias (no operation).

πŸ¦‹ OPTIONS πŸ¦‹

There are several environment variables (passed as OPTION=value) that modify how the benchmark behaves, allowing it to be run in a stand-alone environment. Unrecognized options not containing = are appended to the raytracer invocation as RT_OPTIONS (e.g., -P1).

  • RT β€” The ray-trace binary (e.g., ../src/rt/rt or /usr/brlcad/bin/rt).
  • DB β€” The directory containing the reference geometry (e.g., ../db).
  • PIX β€” The directory containing the reference images (e.g., ../pix).
  • LOG β€” The directory containing the reference logs (e.g., ../pix).
  • CMP β€” The name of a pixel comparison tool (e.g., ./pixcmp or cmp).
  • ELP β€” The name of an elapsed time tool (e.g., ../sh/elapsed.sh).
  • TIMEFRAME β€” Minimum number of seconds each ray-trace frame should take.
  • MAXTIME β€” Maximum number of seconds to spend on any test.
  • DEVIATION β€” Minimum sufficient percentage deviation from the average.
  • AVERAGE β€” How many frames to average together.
  • VERBOSE β€” Turn on extra debug output (set to 1 or yes).
  • QUIET β€” Turn off all output (set to 1 or yes).

The TIMEFRAME, MAXTIME, DEVIATION, and AVERAGE options control how the benchmark will proceed and how long it should take. Each individual benchmark run will consume at least a minimum TIMEFRAME of wallclock time so that the results can stabilize. After consuming at least the minimum TIMEFRAME, additional frames may be computed until the standard deviation from the last AVERAGE count of frames is below the specified DEVIATION. When a test is run and it completes in less than TIMEFRAME, the raytrace is restarted using double the number of rays from the previous run. If the machine is fast enough, the benchmark may accelerate the number of rays being fired. These additional rays are hypersampled but without any jitter, so it is effectively performing a multiplier amount of work over the initial frame. Slay, but make it numerically stable πŸ’…βœ¨


πŸ”₯ REPORTING RESULTS πŸ”₯

Please send your BRL-CAD Benchmark results to the developers along with detailed system information to devs@brlcad.org. Include at least:

  1. Compiler name and version (e.g. gcc β€”version)
  2. CPU configuration (e.g. cat /proc/cpuinfo, hinv, or sysctl -a)
  3. Cache (data and/or instruction) details for L1/L2/L3 and system
  4. All generated log files (i.e. .log after benchmark completes)
  5. Anything else you think might be relevant to performance

🌈 EXAMPLES 🌈

  • benchmark run β€” Default run of the suite, taking approximately 10 minutes.
  • benchmark run TIMEFRAME=1 β€” Quick test run for testing functionality and performance ballpark.
  • benchmark run DEVIATION=1 TIMEFRAME=60 MAXTIME=600 β€” Excessive analysis, attempt to stabilize within 1 percent deviation with each frame taking at least 60 seconds but no more than 10 minutes per test (the entire analysis will probably take 30 to 60 minutes).
  • benchmark run QUIET=1 -P1 β€” Perform a benchmark analysis only using one CPU and only logging results to a file.
  • benchmark clean β€” Delete all of the log and pix image files generated during a benchmark analysis, leaving only the summary file and any *benchmark.log files.

⭐ SEE ALSO ⭐

Go peek at brlcad(1), rt(1), pix-fb(1), librt(3), and pix(5) β€” the whole little friend group πŸ’–

πŸ‘‘ AUTHOR πŸ‘‘

BRL-CAD Team

This software is Copyright (c) 2006-2026 United States Government as represented by the U.S. Army Research Laboratory.

πŸ“ BUG REPORTS πŸ“

Reports of bugs or problems should be submitted via electronic mail to devs@brlcad.org


Cute sign-off: source/version is BRL-CAD, the manual page is BENCHMARK(1), and the original footer didn't give a date to repeat β€” so no invented date here, bestie πŸ’‹βœ¨πŸ«Ά

πŸ“¦ where this page comes from