nCPU replaces the ALU with a trained network and asks whether that is a computer

One repository, one thesis, five subsystems

nCPU states its argument in the README banner: every layer, arithmetic, operating system, compiler and display, is either a trained neural network or runs entirely on GPU, and the model does not run on the computer, the model is the computer.

That claim is the reason the repository exists, and it explains why it contains so many unrelated looking directories. The README says nCPU pursues one thesis from five directions, that a computer can be built out of learned components, and that once the whole execution stack is differentiable, programs stop being things you write and become things you can search for by gradient descent.

The five subsystems are the neural computer, the GPU computer, the nSynth synthesis engine, the differentiable coprocessor, and a fifth direction the truncated README does not show in full. What they share is the differentiable-execution premise. The coprocessor injects the neural ALU into a transformer's forward pass, the GPU computer runs an operating system and a compiler without a CPU in the loop, and nSynth searches for programs instead of compiling them.

The repository layout is large enough to see the scope: ncpu/ for the Python package, nsynth/ for the synthesis engine, kernels/, models/, training/, training_results/, benchmarks/, experiments/, programs/, egdc/, tools/, demos/, paper/, docs/ and artifacts/. There is a MASTER_ROADMAP.md, a REPRODUCIBILITY.md, a CHANGELOG.md and both AGENTS.md and CLAUDE.md, which suggests the work is organised as a research programme with published artefacts rather than as a library.

The honest framing: this is a research repository that contains working subsystems, not a product. The performance and accuracy figures quoted in the README are the authors' own measurements, and there is no independent verification here.

The neural ALU is a set of trained nets, and multiplication beats addition

The first subsystem replaces the arithmetic unit. The README says every ALU operation, including addition, subtraction, multiplication, bitwise logic, shifts and division, is a trained neural network, and that the neural OS, called neurOS, manages memory, schedules processes and compiles code through 11 trained models with no hand written fallbacks. A neural display renders characters through character to glyph multilayer perceptrons and a convolutional network.

The pipeline is described as source code to neural compiler to neural assembler to neural CPU to neural display, differentiable end to end. That is the load bearing claim, because differentiability is what makes gradient descent meaningful over the whole stack.

The accuracy result is narrow and strong. The README states the neural ALU reaches 100 percent accuracy on 32-bit integer arithmetic, verified exhaustively over every possible input. That verification method matters: exhaustively means every input pair, not a sample.

The counterintuitive result is the one the project highlights. Multiplication is reported as 12 times faster than addition, because addition needs an eight pass carry chain while multiplication decomposes into parallel byte pair table lookups. The README's own table gives addition at 248 microseconds and multiplication at 21, with bitwise logic also at 21 and shifts at 434. The claim is that the learned implementation inverts the usual hardware hierarchy, where multiplication is the expensive operation.

The component accuracy table is less uniform: the MMU, assembler codegen and watchdog are listed at 100 percent, while the compiler optimizer sits at 95.2 percent and prefetch at 97.8. Those numbers matter if you intend to run real programs rather than arithmetic tests.

A UNIX OS and a self-hosting C compiler on the GPU

The second subsystem is the one with the broadest surface. The README describes a self sufficient computer on a single GPU where the CPU is involved only at bootstrap. The Rust and Metal kernel executes about 200 ARM64 instructions at roughly 1.9 million instructions per second, with zero copy shared memory and zero cycle count variance across runs.

On top of that kernel the README lists what runs. There is a multi process UNIX operating system with fork, pipe and wait, a 25 command shell, 28 syscalls and up to 15 concurrent processes. There is a self hosting C compiler of about 4,200 lines that compiles itself and then compiles and runs other programs entirely on the GPU. Real Linux binaries load through an ELF64 loader, with BusyBox at 264KB and more than 34 commands, and Alpine Linux v3.20.

The application list includes 13 or more compiled C programs, among them SHA-256, AES-128, Tetris, Snake, a Brainfuck interpreter, a Forth REPL, a CHIP-8 emulator, an HTTP server and an MNIST classifier.

The debugger is the part with a stated theoretical reason behind it. It is described as a 26 command deterministic debugger with instruction tracing, breakpoints, watchpoints, time travel debugging, a memory sanitizer, automated fuzzing, reverse data flow analysis and constant time verification. The README gives the argument for why determinism matters: conventional CPUs, with cache and speculation induced timing noise, cannot offer the same guarantees for exact replay. On a GPU where the execution is deterministic by construction, time travel is a property of the system rather than a feature you have to bolt on.

That is a coherent research argument. It is also a small scale computer, with 200 instructions and 1.9 million instructions per second, which is worth keeping in mind before treating the word computer as a general claim.

nSynth searches for programs from examples, and reports 420 out of 420

The third subsystem is a program synthesis engine. The README describes nSynth as a Rust based system that discovers executable programs from input and output examples using gradient descent, enumeration and search, and says it can synthesise algorithms such as arithmetic, bitwise operations and data structures, machine learning models ranging from CNNs and RNNs to Transformers, GNNs, diffusion models and reinforcement learning agents, and full stack web applications.

The coverage claim is the number that needs context. The README states coverage of 420 out of 420 synthesis problems, broken down as Mog at 315 out of 315 and nSynth at 105 out of 105, with the core pillar solving 105 out of 105 via gradient based search, enumerative synthesis, template matching and search families.

Those are the project's own problem sets. Whether a solver that clears its own benchmark transfers to an unfamiliar problem is exactly the question the benchmark cannot answer, so treat the figure as a statement about the evaluation harness rather than about general synthesis ability.

The three pillars are the synthesis core, an ML and tensor engine described as having more than 1000 APIs with automatic differentiation, and a web stack of more than 500 APIs covering HTTP, WebSocket, SSL, frameworks such as React, Vue, Svelte, Solid, Next.js and Remix, modern platform features such as WASM, WebGPU, WebAuthn, WebRTC and PWA, plus GraphQL, gRPC, tRPC and OpenAPI, styling, and bundlers.

The point of the tensor engine is to make the search space differentiable. The list of architectures it claims to be able to synthesise, from MAML and DARTS to NeRF volume rendering and FlashAttention, is long enough that you should treat it as a menu rather than a guarantee.

The coprocessor routes tokens through the neural ALU

The fourth subsystem takes the ALU out of the research setting and puts it inside a language model. The README describes the neural ALU injected into a transformer's forward pass as a routed expert, where a learned per token gate decides whether each token flows through the original multilayer perceptron or through the neural ALU.

The pieces that make that differentiable are named: bilinear soft truth tables for differentiable logic, tensor operations for differentiable arithmetic, and gating modulated by model confidence.

The results come from an 11 model sweep across the Qwen 2.5, 3 and 3.5 families on arithmetic tasks. The README's table reports the largest model at 2B with instruct tuning moving from 14.5 percent to 71.0 percent arithmetic accuracy, a gain of 56.5 percentage points, and the base 2B model moving from 15.5 to 63.0 percent with 100 percent on addition, subtraction, multiplication and division. A 4B model shows a 51.0 point gain, listed as the largest base model gain tied, and a 9B row is cut off in the visible portion of the README.

The honest reading of these numbers is that this is a small, specific intervention on arithmetic ability in models that were already weak at arithmetic. The gains are large because the baseline is low. That is a legitimate research result and it is not evidence that a neural ALU improves reasoning in general.

The repository carries this area in the egdc/ directory, and the coprocessor is also the reason the model training stack with transformers, peft, datasets and accelerate is an optional dependency group rather than a core one.

Installing the Python package and the two console entry points

The Python side of nCPU is packaged with setuptools, and the packaging metadata is unusually explicit about the optional dependency groups, which is worth reading before you install.

[project.scripts]
ncpu = "ncpu.__main__:main"
ncpu-lab = "ncpu.lab:main"

Two console scripts are installed. ncpu is the main entry point and ncpu-lab is the laboratory surface, and the repository's examples directory contains demo_model_cpu.py, demo_neural_cpu.py and demo_tensor_cpu.py plus a go_client subdirectory, so those are the scripts to look at first.

The install guidance is in requirements.txt, which describes itself as convenience requirements for a broad local development environment and gives two editable install paths.

#   pip install -e ".[demo,model,train,dev]"

The lighter alternative for the flagship demo surface is the same form with the demo and dev groups only, and the groups themselves are the real decision. The demo and neural groups carry torch, torchvision, numpy and tqdm. The model and train groups add transformers, peft, and, for training, datasets and accelerate. The tensor group is torch with numpy. The base package itself declares no dependencies at all, and the project name is ncpu at version 0.2.0 with Python 3.9 or newer required.

So a user who only wants the synthesis engine, which is Rust based, does not need the Python training stack at all, and a user who wants to reproduce the coprocessor sweep needs the model and train groups.

Running a synthesis job from the command line

The README gives one concrete command for nSynth, and it is the fastest way to see whether the synthesis engine does anything on your machine. You move into the nsynth directory and run the codegen binary with a language flag and a JSON payload of examples.

cd nsynth
cargo run --release --bin nsynth_codegen --lang python --examples '{
  "name":"reverse","signature":"fn reverse(arr: List<i64>) -> List<i64>",
  "examples":[{"inputs":[[1,2,3]],"expected":[3,2,1]}]
}'

The payload names the target program, gives its signature, and provides input and expected output pairs. The README shows the expected result as a one line Python function that returns the reversed list.

Two practical observations. The command is a cargo run in release mode, so the first invocation compiles the Rust engine and will be slow. And the payload is a JSON object with a Rust typed signature inside it, which means the synthesis target is expressed in a language whose type system the engine has to honour. A function taking a list of i64 is a different problem from one taking a string, and the README does not describe how the search handles a harder signature.

The engine also has a documented breadth of output languages, since the flag is set to python in the example, and the surrounding text mentions synthesising full stack web applications among others.

The licence needs checking, and the numbers need reproducing

Two things should be checked before you build anything on this repository.

The first is the licence, and the sources disagree in a way that only the LICENSE file can settle. The project is recorded under a custom licence that GitHub cannot classify, while pyproject.toml declares the package licence as MIT, and the README badge also says MIT. The LICENSE file at the top of the repository is the document that matters, and if you intend to use the code in a product rather than read it, that file is the first thing to open.

The second is the numbers. The ALU accuracy claim is specific and checkable, since it says 100 percent on 32-bit integer arithmetic verified exhaustively over every possible input. The latency figures, the instruction throughput on the GPU, the synthesis coverage of 420 out of 420 and the coprocessor accuracy gains are all measurements produced by the project about itself. The repository does include a REPRODUCIBILITY.md and a benchmarks/ directory, which are the right places to check whether you can get the same numbers on your own hardware.

On maintenance, the repository is not archived and the last push was on 2026-07-30, so work is still landing on the main branch, but there are no GitHub releases at all. There is no version to pin to beyond the CHANGELOG.md and the 0.2.0 version string in pyproject.toml. For a project whose pitch is that you can train and rebuild its components, a moving main branch with no tagged releases is a genuine constraint on reproducible work.

Editorial conclusion

Adopt nCPU if you are researching differentiable program execution, learned hardware primitives, or program synthesis from input and output examples, and you are comfortable running the training stack yourself. Do not adopt it as a production runtime or as a general program synthesis tool, because the synthesis coverage is measured against the project's own problem sets and the ALU latency figures come from the authors' own measurements. Before you build on it, reconcile the licence question, since the repository records a custom licence while pyproject.toml declares MIT, and reproduce the neural ALU accuracy claim on your own hardware before you rely on it.

Frequently asked questions

Official sources

1. Issues
2. README
3. robertcprice/nCPU on GitHub