Add JSON output for benchmark results#8027
Draft
dantegd wants to merge 32 commits into
Draft
Conversation
|
Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
5 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Builds on top of #7980
This PR adds a structured JSON output path for cuML benchmarks. Benchmark runs can now write a single canonical JSON artifact containing grouped benchmark results and run metadata, including backend timings, accuracy metrics, benchmark shape, selected config/profile information, hardware metadata, package environment snapshots, and estimator parameters when available.
This PR also improves benchmark console output for long runs. Instead of repeated per-run DataFrame dumps, the runner now emits a concise aligned progress table with algorithm, shape, estimated data size, backend timings, and compact details like accuracy and speedup.
Why JSON Output
I think YAML remains the right format for benchmark configuration because it is human-authored, reviewable, and easy to maintain. JSON is the right format for benchmark output because it is machine-produced, schema-versioned, and easy for CI, dashboards, and future baseline comparison tooling to consume.
JSON Schema
The JSON artifact has two top-level fields:
{ "results": [], "metadata": {} }Each result represents one logical benchmark variation:
{ "benchmark_id": "logreg_fit_narrow_default", "algorithm": "LogisticRegression", "dataset": "classification", "operation": "fit", "shape": { "rows": 84000000, "features": 16, "estimated_input_size_bytes": 5376000000, "estimated_input_size_gb": 5.376 }, "data": { "input_type": "cupy", "dtype": "fp32", "n_reps": 1 }, "params": { "declared": {}, "effective": { "cpu": null, "gpu": {}, "accel": null } }, "backends": { "gpu": { "status": "success", "time_sec": 0.91, "accuracy": 0.995 } } }Run metadata includes schema version, command, Python/platform information, cuML/git identity, runtime availability, config/profile selection, hardware details, and a compact conda or pip package snapshot.
Backend records currently use:
status:successorskippedtime_sec: benchmark time in seconds for successful runsaccuracy: accuracy or score when availablereason: explanation for skipped backendsHighlights
--output results.jsonas the canonical benchmark artifact.resultsfollowed bymetadata.--csvas a legacy flat export.