How it works
Performance Database

The GitHub for performance engineering.

We reinvented performance engineering, scalable for everyone. Every new model feature or chip you adopt breaks yesterday's optimizations, so keeping your software fast means redoing the same work by hand, over and over. We make it automatic, so your performance never falls behind.

Continuous benchmarkingWeb IDEPerformance Database
Continuous benchmarking

Measure performance on every commit.

Every push carries your workloads straight from GitHub into the performance dashboard of our Cloud Console. We run them on real hardware, surface the hotspots, and place each part of your code on the roofline of the hardware, so you see where time goes and what limits it.

daisytuner/modelsmain · 6d6dbefPerformance dashboard2 workloads · todayLive
pytorch_models2 workloads
VariantRegionsRuntimeSpeedupΔ Base
torch—78.0 ms+3.0%
torch-cuda—17.9 ms−7.5%
docc-cuda93 regions11.2 ms1.60×+0.0%
docc-omp45 regions41.5 ms1.88×−1.8%
VariantRegionsRuntimeSpeedupΔ Base
torch-cuda—36.4 ms−3.4%
docc-cuda266 regions21.7 ms1.68×+0.6%
Roofline · segformer::docc-cudadraml2l1
0.010.11101001k10k1101001k10k100kfp64 · 411 GFLOP/sfp32 · 25.8k GFLOP/sDRAM · 465 GB/stensor_fp16 · 243k GFLOP/ssegformer.py · hot region48.4 GFLOP/s @ 0.227 FLOP/Bdram-bound · 46% of peak
From the DashboardHot region found on the roofline → opened in the Editor
The editor

Performance optimizations, reviewed like code.

Our compiler, docc, represents every code as a dataflow IR that makes data movement, parallelism and computation explicit. In the web IDE of our Cloud Console you compose optimization recipes yourself. The compiler checks each recipe for legality, and you're ready to open the result as a pull request.

Dataflow IRProvably legal transformationsChecks on real hardware
Cloud Console · Pull requests

[segformer] fused gemm and div

MergedServerCUDA
__docc_GraphModule:2398 · 4 loops · 3 maps · depth 4
Initial SDFG · 5 steps
map [SEQUENTIAL]: _b41 = 0; (_b41 < 16); _b41++
map [SEQUENTIAL]: _j55 = 0; (_j55 < 160); _j55++
map [SEQUENTIAL]: _i1857 = 0; (_i1857 < 256); _i1857++
for: _k93 = 0; (_k93 < 160); _k93++
_copy13_out = _a * _b + _c_sum55
_sum55_out = _in_tmp31
_tmp31_out = _a / _b_copy2
From the EditorPull request merged → recipe indexed as a performance embedding
The database

A live database, queried by docc.

Your performance database stores every optimization recipe, and docc matches them against your code automatically during compilation. Purpose-built performance embeddings find similar regions and the ideal optimization for yours. A RAG method for compilers.

Illustrative data · t-SNE of performance embeddings
Embedding mapPR · fused gemm and div
Pinned kernelPublished
kernelsegformer.fused_gemm_div
sourcepull request · merged
targetCUDA
scheduleinterchange ×2 · CUDA(32) · nested(8, 4)
legalitypolyhedral · proven
speedup2.14×
gap to I/O bound9%
neighbours3 · transfer-tunable
Kernels274in view
Tuned48%of kernels in view
Avg speedup2.01×tuned in view
Targets4in view
From the DatabaseNearest neighbours retrieved → handed to the agents as a starting point
The agents

Agents feed your database, day and night.

Let our agents tune your code for you. They search for optimizations around the clock, propose recipes, and the compiler proves each one correct before it joins the database. Every proven recipe makes the next search faster, so the database keeps improving on its own.

Fully automated searchEvery recipe proven correctImproving 24/7
RecipesAgents36RunsPull requestsSettings
Recipe lifecycle
Transitions · last 90 days · 1,480 eventsNewEmptyTunedFailedPublishedRetriedDead
275 tasks in queue · 36 agents working
StatusRegionTargetSpeedupUpdated
Runningattention.softmax_matmulServerCUDA2.6×2m ago
Runninggemm.bf16ServerRocm1.9×5m ago
Pendinglayernorm.fusedServerOpenMP—12m ago
Mergedconv2d.3x3ServerSequential1.4×31m ago
Compiler theoryMachine learning
Under the hood

PerformanceOptimization forthe Age of AI.