1. Pin the workload
Use the same composition, frame range, resolution, frame rate, codec intent, and input bytes. Name the suite so a later run can be compared.
Benchmark methodology · updated 2026-07-23
A benchmark is useful only when the workload, host, measurement, and claim boundary are visible. RenderMac publishes the same composition or source through each available path, reports wall-clock first, and separates measured results from projections, rate-card estimates, and package-power samples.
powermetrics runs in research/apple-silicon-idle-render-network/benchmarks/results/. The benchmark pages are evidence summaries, not invoices or a promise that every cloud shape behaves the same way.Use the same composition, frame range, resolution, frame rate, codec intent, and input bytes. Name the suite so a later run can be compared.
Include the render and encode path that a buyer waits for. Call out cold-start, scaffolding, or transfer steps instead of hiding them.
Publish chip family, memory, OS/runtime, runner version, container CPU/memory shape, and whether the path was local, live cloud, or a projection.
Label package watts or watt-hours as on-device SoC estimates. Do not present them as wall-outlet measurements or idle-subtracted energy when the idle sample is missing.
A single Mac and a massively sharded Lambda fleet answer different questions. We compare the tested shape and explicitly say when a fan-out path was not run.
Same compositions on M2 Max, M1 Air, live Containers, and a Docker-matched shape.
Fleet wall-clock comparison across LightMotion, MediumMotion, HeavyMotion, and a long kinetic check.
A 20-minute 1080p30 encode showing Mac-native VideoToolbox and software x264 beside the cloud-shaped run.
M2 Max package watts, watt-hours, and the practical thermal implications for hosts.