DEV Community: Michael Yang

I spent months building an exact incremental-computation library in C. I finally put the reproducible benchmarks on GitHub.

Michael Yang — Sat, 29 Aug 2026 18:29:54 +0000

I’ve been working on a performance project called HKD Kernel.

The premise is that a lot of large computations repeat work unnecessarily. If only a tiny portion of the input changed, you ideally want to recompute only the state affected by that change rather than rebuild everything.

HKD Kernel is a native C implementation of that idea with exact-result checks.

The most surprising result for me has been the size of the gap on highly sparse workloads. Across the benchmark configuration currently documented in the repository, the measured mean speedup is around 18,000x versus the full-recomputation path.

Huge caveat: that is not an “all software becomes 18,000x faster” claim. The gain comes specifically from workloads where most previously computed state remains valid.

I made the benchmark reproducible because I’d rather have people try to break the claim than just believe a graph.

GitHub:

https://github.com/yangofzeal/hkd-kernel

I’m particularly looking for:

adversarial benchmark ideas
real workloads with sparse state changes
feedback on the C API
cases where you think incremental recomputation would be the wrong architecture

There’s a free/community path and I’m also testing a $999/month production-node Business license, but right now I’m much more interested in whether developers can reproduce or invalidate the technical results.

I built a C library that avoids recomputing unchanged state — here are the reproducible benchmarks

Michael Yang — Sat, 29 Aug 2026 18:24:00 +0000

Most performance optimization focuses on making each operation faster.

HKD Kernel approaches a different question:

What if most of those operations did not need to execute at all?

I’ve been working on HKD Kernel, a native C library for exact sparse and incremental computation.

The target workload looks like this:

A large computation has already been evaluated.
Only a small subset of the inputs changes.
The dependency structure tells us which results can actually change.
HKD recomputes those affected regions instead of repeating the entire calculation.

The important word is exact. The optimized result must equal the result of full recomputation.

What the benchmark measures

The repository contains reproducible benchmarks comparing full recomputation with the HKD incremental path.

Across the benchmark suite currently documented in the repository, the measured mean speedup is roughly 18,000x.

That requires an important qualification:

This does not mean HKD makes arbitrary programs 18,000x faster.

It means that on workloads with sparse changes and reusable state, avoiding redundant computation can produce extremely large reductions in work.

That distinction is important enough that I built the repository around reproducibility rather than a black-box benchmark claim.

What HKD Kernel is not

HKD Kernel:

does not replace the macOS XNU kernel
does not modify CPU microcode
does not disable SIP
does not change processor ALU hardware

It is a user-space native computation library.

Where I think this model is useful

The workloads I’m most interested in include:

dependency graphs
incremental build systems
large simulations with sparse updates
optimization systems
financial/risk recomputation
logistics and scheduling
cached numerical pipelines

The real question is not “how fast is HKD?”

It is:

How much of your current computation is being repeated even though the inputs affecting it never changed?

I’d especially like developers to try to break the benchmark assumptions or suggest workloads where sparse incremental evaluation should fail.

Source, benchmarks and build instructions:

https://github.com/yangofzeal/hkd-kernel

There is a community edition, and a commercial Business option for production-node licensing.

Feedback on the C API and benchmark methodology is especially welcome.

40% Adam Optimizer Improvement: PyTorch Benchmarks

Michael Yang — Sun, 09 Aug 2026 16:06:29 +0000

40% Adam Optimizer Improvement

If you are training deep learning models in PyTorch, default optimizer implementations leave performance on the table.

Check out this project demonstrating up to a 40% Adam optimizer improvement:
https://github.com/yangofzeal/adam/

Highlights

40% faster step execution time in PyTorch.
Drop-in replacement for standard Adam.
Open-source implementation available on GitHub: https://github.com/yangofzeal/adam/