Skip to content

bench: add the GPU benchmark and fold its findings into the docs - #55

Merged
wenh06 merged 2 commits into
masterfrom
gpu-benchmark
Oct 26, 2026
Merged

wenh06 merged 2 commits into
masterfrom
gpu-benchmark

Conversation

@wenh06

@wenh06 wenh06 commented Oct 25, 2026

Copy link
Copy Markdown
Owner

What

Adds the GPU leg of the executor benchmark that the parallel-execution docs page left open (larger-model and GPU tiers to be answered by the benchmark), and folds its findings into that page.

Configuration: FedAvg on FedSynthetic with the 1.19M-parameter mlp_d3 candidate model (dimension=512), 64 clients, 3 iterations, 5 local epochs, batch 256, best of 3, on a 12-core host with one consumer GPU.

Findings (now in the docs page)

device sequential threads at 8 workers speedup
CPU 14.9 s 10.3-10.6 s 1.40-1.45x
GPU (single) 5.1 s 4.9-5.1 s 1.01-1.04x (none)
  • CPU with a compute-heavier model: the speedup grows over the tiny-model configuration (about 1.2x) - the torch kernels release the GIL, so the benefit tracks the compute share of each client task.
  • Single GPU: no benefit from the threads backend. All clients submit kernels to the same device, where they execute serially regardless of the submitting thread; the sequential loop already saturates one card (the measured GPU run was itself about 3x faster than the CPU run for this workload). Scaling beyond one GPU comes from multi-GPU client placement (ServerConfig.visiable_gpus) or CUDA streams - not from concurrent submission to a single device.

The docs page now states these as observations on the measured configurations (not ceilings), and keeps the pointer to the planned process-based backend for GIL-bound CPU workloads.

Verification

  • the script was executed end-to-end twice (once from the working copy, once from the committed path) with consistent numbers;
  • pre-commit (black / isort / flake8) green.

Adds test-files/benchmark_gpu.py: sequential vs threads on CPU and GPU
for a compute-heavier workload (FedAvg, FedSynthetic with a 1.19M-parameter
MLP, 64 clients, 3 iterations, 5 local epochs, batch 256, best of 3).

Findings folded into the parallel-execution docs page:
- CPU with the compute-heavier model: 1.40x at 8 workers (the torch
  kernels release the GIL; the benefit grows with the compute share),
  vs about 1.2x on the tiny-model configuration;
- single GPU: no benefit from the threads backend — all clients submit
  to the same device where kernels execute serially, so the sequential
  loop already saturates one card; scaling beyond that comes from
  multi-GPU client placement or CUDA streams, not from concurrent
  submission to a single device.
The tests picked their JSON-log fixture with glob('*.json')[0], which
grabbed whatever file sorted first; adding any other JSON file to
test-files/ silently broke five tests (already bitten once by the
benchmark results file). Pin the actual log file name instead.
@codecov

codecov Bot commented Oct 25, 2026

Copy link
Copy Markdown

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.30%. Comparing base (967b45b) to head (0ee7476).

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##           master      #55      +/-   ##
==========================================
+ Coverage   82.28%   82.30%   +0.01%     
==========================================
  Files          55       55              
  Lines        5640     5640              
==========================================
+ Hits         4641     4642       +1     
+ Misses        999      998       -1     

see 2 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@wenh06
wenh06 merged commit a21cbb4 into master Oct 26, 2026
28 checks passed
@wenh06
wenh06 deleted the gpu-benchmark branch October 26, 2026 04:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant