Your compiler targets every machine.
We target yours.
Velobyte builds compiler infrastructure that discovers optimizations for one workload on one machine, checks them against the obligations they claim, measures them where the code will actually run, and keeps what survives.
representative example — a fused matrix–vector epilogue, shown to illustrate the pipeline, not a recorded run
- 01program
- 02input IR
- 03evolve · verify · measure
- 04targeted IR
- 05hardware
for (i = 0; i < m; i++) {acc = 0;for (j = 0; j < n; j++)acc += w[i][j] * x[j];y[i] = act(acc + b[i]);}
- fuse epilogue into MMA loopchecking obligations…
- stage operands via async copyqueued
- reassociate reduction across kqueued
- skip bounds check on tailqueued
- warp-shuffle reduce, 32 lanesqueued
models search inside this box and never leave it — what exits is a pass with its preconditions attached
- → tiled 128×64, k-loop double buffered
- → operands staged through shared memory
- → reduction folded into warp shuffles
- → bias + activation fused into the epilogue
ld.global.nc.v4 %rd4, [x + off]cp.async.bulk %shared, %global, 16384mma.sync.m16n8k16.bf16.f32 %acc, %a, %b, %accredux.sync.add.f32 %sum, %acc, 0xfffffffffma.rn.f32 %y, %sum, %scale, %bias
General compilers optimize for everyone. Your machine does not run everyone's workload.
A general-purpose stack has to be correct for every program on every supported target, so it keeps the choices that are safe in the widest case. Name the workload and the machine and most of that generality is dead weight.
schematic — the narrowing, not a measurement
Add what you know about the deployment. Every constraint is a fact a general compiler is not allowed to assume, and each one removes choices it had to keep.
Nothing named yet — every lowering that is legal somewhere is still on the table.
A compiler that keeps what it learns.
Hand-tuning ends when the engagement does. Evo is built so a win found once becomes something the compiler can apply again: a pass, with the conditions it depends on written down.
read the full Evo thesis- 01
Discover
Agents and search engines read the hot code, the target description and the surrounding constraints, then propose rewrites: layouts, tilings, schedules, fusions, instruction choices, algorithm substitutions.
inputhot code + target descriptionoutputcandidate transformationsstatusspeculative by construction - 02
Prove
A candidate arrives with the preconditions it assumes and the equivalence it claims. Those obligations are checked mechanically, at the scope the transformation actually applies to. Anything that cannot be discharged is dropped — a model never gets to assert that its own rewrite is correct.
checkspreconditions, equivalence obligationsscopethe region the rewrite applies toon failurediscarded, with the reason kept - 03
Measure
Survivors are benchmarked in the target environment, repeated until the distribution is stable, and held against a regression gate. A transformation that is correct but not faster on the machine in front of it is not admitted.
environmentthe target you deploy onreporteddistribution, not a single rungateregression rejects the candidate - 04
Admit
An admitted transformation stops being a suggestion. It enters the library as a pass with its preconditions attached, applied by the compiler when those preconditions hold. No model sits in the build path.
formpass + preconditionsappliedwhen preconditions holdbuild pathdeterministic, model-free - 05
Reuse
The library is the point. Optimizations discovered for one program and machine are available to the next program that satisfies the same preconditions, which is what makes the search worth paying for more than once.
unitreusable pass, not a patchconditionpreconditions must hold againeffectsearch cost amortizes
note — what can be checked, and how completely, depends on the transformation and the region it applies to. Evo's position is narrower than “all programs are proven equivalent”: a candidate states the preconditions it assumes and the equivalence it claims, those obligations are discharged mechanically, and anything left open is rejected rather than shipped.
Search can be probabilistic.
Compilation cannot.
A frontier model is a good source of ideas and a bad source of authority. Evo keeps those roles apart: models sit outside the boundary and propose; a deterministic checker and a clock on the target decide what crosses it.
✕ trip count not established · fault path differs · reassociation outside declared tolerance · accumulator overflow open
representative candidates — rejection is the common case, and the reason is kept
- models
Propose, never decide
A candidate is an input to the pipeline, not a conclusion. Confidence is not evidence.
- checker
Deterministic and repeatable
The same candidate produces the same verdict. Nothing is promoted because a review looked fine.
- clock
Measured on the target
Correct but not faster on the machine in front of it is still a rejection.
- output
A pass, not a suggestion
What crosses the boundary is compiler capability with its preconditions attached. No model in the build path.
One computation, all the way down.
The same matrix–vector kernel at every level Evo works at, with the record that travels beside it: what a general pipeline emits, what the transformation actually claims, what it had to discharge, and what a measurement report contains.
region @gemv_relu {
contract {
shapes W:[m,n] x:[n] b:[m] y:[m]
layout W row-major, unit stride in j
aliasing W, x, b, y pairwise disjoint # from restrict
numerics f32; reassociation NOT permitted # no tolerance declared
effects pure, except store to y
}
reduce %acc[i] = sum_j ( W[i,j] * x[j] ) assoc = declared_order
map %y[i] = max(%acc[i] + b[i], 0)
reuse x is loop-invariant in i # available to any lowering
hot j-loop: n iterations, m times
}stage-and-fuse — one admitted candidate
- rewrites
- tiled j-loop, staged W, resident x, fused epilogue
- assumes
- W, x, b, y pairwise disjoint
- assumes
- x invariant across the i-loop
- assumes
- staging budget ≥ tile footprint
- preserves
- declared reduction order
- preserves
- observable behaviour on the tail path
- applies when
- the assumptions above hold at the call site
A transformation is not the diff. It is the diff plus the conditions under which the diff is allowed.
representative example, written for this page — the IR dialects are illustrative and the measurement view intentionally carries no figures
The compiler should not stop at the hardware boundary.
Compiler design and architecture design are usually separate disciplines with separate deadlines, which is how a machine ends up carrying hardware to cover software that could have been better, and software written around hardware nobody explained to it.
- program
- compiler
- architecture
- silicon
workload structure travels down the stack
Take the program as given and specialize everything below it: algorithm choice, kernels, data layout, scheduling, lowering, data movement — against one machine instead of a class of them.
- 01
Hot-path optimization
Kernels, inference serving, HPC, DSP, control and signal paths driven through the loop until the wins are checked and measured on your target.
- 02
Compiler and runtime work
Custom passes, lowering, scheduling and memory movement written against the machine you deploy on, not a generic target triple.
- 03
Portability across parts
Re-run the loop against a new accelerator or a new node and get an artifact specialized for it without rewriting your source.
- 04
Performance under a record
Every change arrives with the obligations it discharged and the measurement behind it. Regressions are gated, not explained afterwards.
Seven layers decide how fast your program is.
A speedup can come from any of them, and the interesting ones come from the interaction between two. Velobyte works the whole span rather than optimizing one layer against assumptions about the next.
Transformation and scheduling
Where the specialization happens: tiling, fusion, layout, instruction selection, scheduling — against one machine rather than a class of machines.
- Custom passes and lowering
- Discovered transformation library
- Proof-gated promotion
hover or focus a layer — “core” marks where the compiler and the hardware contract meet, which is the part we think is under-worked
Open questions we are working on.
These are problems, not results. We would rather show the questions we are attacking than publish a number nobody can reproduce.
01Verified compiler transformations
What obligation a proposed rewrite has to discharge before a compiler is entitled to apply it, and how much of that can be checked mechanically at the scope the rewrite touches.
02Reusable optimization discovery
Turning a one-off win into a pass with explicit preconditions, so the next program that satisfies them inherits it instead of paying for the search again.
03Cross-IR equivalence
Keeping the correspondence between representations intact as a program descends from source to a target-specific form, so a claim proven at one level still means something at the next.
04Hardware-aware compilation
Compiling against a specific machine description — memory hierarchy, available operations, numerical behaviour — rather than a generic target triple.
05Workload-aware architecture
Using the structure a compiler discovers in a workload as evidence about which hardware generality is earning its area and power.
06Automated performance engineering
Benchmark methodology strong enough to promote on: stable distributions, regression gates, and results that hold up on the machine that will run the code.
The boundary is where the performance goes.
Velobyte designs custom software, custom silicon, and the compiler layer between them as one system. The distance between what a program means and what a machine actually does is one of the largest and least examined sources of waste in computing.
- 01
Generality is expensive
A general-purpose compiler has to be right for every program on every supported target, so it is rarely great for yours. What it leaves behind is large, repeatable and mostly invisible.
- 02
The people who can close it are scarce
Performance engineers who work at this level are rare, and their wins usually stay locked inside the one project that paid for them.
- 03
Search changed the economics
Proposing candidate transformations is now cheap. What was missing is infrastructure willing to reject almost all of them and keep the rest.
- based in
- Lexington, MA
- product
- Evo
- span
- workload → silicon
- output
- deterministic artifact
Have a workload that should be faster?
Three things tell us whether we can help: what you are running, where you are running it, and which constraint you are actually up against. A paragraph is enough to start.
- jkc.cassidy@gmail.com
- based in
- Lexington, Massachusetts
- good first step
- one kernel, one machine, one number that matters