Tag: systems programming

Mitchell Hashimoto gives SIMD the right entry point: recognize the common shape before reaching for cleverness. Broadcast a constant, process a vector-width chunk, reduce the result, and retain the scalar loop for the tail and unsupported hardware. The Zig examples are approachable, but the bigger lesson travels: performance work begins by understanding the data path, not by memorizing intrinsics.

The Hacker News pushback improves the thesis. Manual SIMD is not simply a more verbose for loop, and it is not the first move for every hot path. The durable skill is knowing when vectorization did not happen, checking optimized compiler output and benchmarks, then deciding whether the extra code, portability surface, and memory behavior justify taking control.

Serge Zaitsev builds a compact tensor library in C from the representation upward: contiguous data, shapes and strides, broadcasting, kernels, SIMD, then enough layers and manual backward passes to train small models. It is not a PyTorch replacement, which is exactly why it works so well as a teaching artifact. Once the runtime is small enough to read, "tensor operations" stop feeling like API magic and become memory layout, indexing, and carefully composed loops.

The Hacker News discussion catches an important boundary: a tensor in a numerical library is a useful computational representation, but that is not the full mathematical object, with its coordinate-independent transformation behavior. That is not a reason to reject the simplification. It is a reason to label it clearly. Good systems explanations earn their clarity by saying which layer they are describing, and this post is strongest when read as a tour of the engineering layer beneath modern ML tools.

This is a wonderful tiny-hardware project: a Swift-flavored language environment for the Apple II, implemented through a bytecode VM instead of pretending full modern Swift can fit on a 1 MHz 6502 with tens of kilobytes of RAM. The constraints make the engineering visible: disks, keyboard quirks, memory banking, integer-only tradeoffs, and separate tool families instead of one universal binary.

The part I want to keep near the agent-workflow notes is the process. The project worked because the AI had a human boundary around it: numbered phases, design docs, acceptance tests, and manual architectural calls. That is the healthy version of agent leverage: not autonomous magic, but fast iteration inside a context the builder keeps sharpening.

A full account of building Fame Boy — a working Game Boy emulator in F# — covering CPU, PPU, and APU implementation, optimization decisions, and what the project revealed about how computers actually work.

The F# angle is useful: it shows where functional programming fits naturally in low-level emulation work and where it requires deliberate workarounds.