Build1 publisher2 min readPublished
Frost fits a deep learning framework in 1,400 lines by moving the hard parts into its own language
The Neve author has published Frost with a runnable ResNet-18 benchmark and three named complaints about PyTorch. The 1,400-line count covers the framework layer only; the compiler and SIMD backend underneath are separate code.
The Engineer · Build desk
What happened
- The author of the Neve language has released Frost, a deep learning framework he says expresses parallel dataloaders, GPU kernels and the language itself in 1,400 lines of code.
- He names three problems with the current stack: optimizers are hard to understand in PyTorch, high-level CUDA code is missing and interoperability is hard, and parallelism is absent.
- The only benchmark on offer is a ResNet-18 run in a separate repository readers are invited to clone, and the post itself publishes no timing or accuracy figures from it.
- The project started with the Sophia optimizer: he ran an unofficial implementation, got results that were quite bad with a lot of NaNs, and a later paper said such optimizers had overstated claims.
- He also claims Neve is competitive with NumPy and OpenBLAS on CPU matrix multiplication while using pure high-level SIMD code.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- capability If threads live in the language, a dataloader stops being a C extension bolted onto an interpreter, and the same person who writes the model can write the worker pool.
- constraint Anyone adopting Frost depends on a compiler, a SIMD backend and a GPU interface written by one person as a Master's project, and the framework's small line count says nothing about the size of that dependency.
- cost Verifying any of the performance claims falls on the reader, who has to build the toolchain and pick the baseline settings the post never specifies.
- decision A researcher testing a new optimizer now chooses between reading PyTorch's implementation and porting to a framework whose GPU interface is mid-rewrite and has no flash-attention yet.
Fourteen hundred lines is a count of Frost. Neve is a separate artifact, a language the author started a few months before finishing his Bachelor's and carried into his Master's project [8]. The compiler, the SIMD code the OpenBLAS comparison rests on, and the GPU kernel interface he says he is still rewriting toward flash-attention are not inside that number [7][1].
The most checkable evidence in the post is a setup.py. It builds a PyTorch C++ extension with `-DPy_LIMITED_API=0x03090000`, `-DTORCH_TARGET_VERSION=0x020a000000000000`, `py_limited_api=True`, and a `bdist_wheel` option pinning `cp39` [13]. The comments in his own snippet say what those flags buy: expose only the stable limited API subset of Python.h, expose only the stable API subset of torch, and build one wheel across multiple Python versions [13]. That is the price of handing a precompiled binary to strangers whose Python and torch versions you do not control. A framework compiled from source inside one toolchain never pays it. The hex spelling of torch 2.10 is a build system reading a version number.
He calls this problem 2, and his words for it are "lack of high-level CUDA code and hard interoperability" [14].
The parallelism complaint is the one where the diagnosis names a cause. He reports that EfficientZero has parallelism PyTorch does not handle, and that its implementation needed Cython packages to get threads, writing C and calling the C functions from Python [15]. He says PyTorch's own data worker threads are implemented in C for the same reason, as a workaround over the Global Interpreter Lock [16], and that BPE preprocessing implementations are written in C, C++ or Rust [17].
For the ResNet-18 repository to say anything to an outsider, it has to publish the GPU, the batch size, the precision, the dataloader worker count, and whether the PyTorch baseline was compiled. The CPU matmul claim needs matrix shapes and thread counts. None of that is in the post [2]. Until it is, the release is a claim about one author's workload on one machine.
The 2x that started the project came from flash attention, written in C++ CUDA [11]. Frost has yet to implement it, and the author says he is currently working on a better GPU programming interface to get there [7].
What to watch
- Whether the Neve_benchmarks repo publishes ResNet-18 configuration, GPU model and baseline settings next to any timings.
- Whether flash-attention lands in the new GPU programming interface the author says he is building.
- Whether Frost ever ships a precompiled wheel, at which point it inherits the same ABI pinning the post holds up as boilerplate.