The phrase linear tensor projection usually exists in the sterile environment of academic papers or deep-learning documentation. But for a developer sitting in front of a MacBook this week, it became a tangible wall. The scene is familiar to anyone who has attempted to run a local model without a massive GPU cluster: the agonizing wait as tokens trickle out one by one, the CPU fans spinning into a crescendo, and the realization that the software is barely scratching the surface of the hardware's potential. To break this bottleneck, a new experiment has emerged, attempting to train a Large Language Model (LLM) using nothing but the Swift programming language on Apple Silicon, stripped of all third-party frameworks.
The Architecture of llm.c and the Scale of Computation
This experimental journey takes its architectural cues from llm.c, a project by AI researcher Andrej Karpathy. The llm.c implementation is a GPT-2 compatible model written in roughly 1,000 lines of pure C, designed specifically to make the internal mechanics of a transformer model transparent. By using this as a baseline, the developer could map out the exact computational requirements of the model. The model in question utilizes 124,439,808 weights, and a single training iteration requires approximately 0.2 trillion floating point operations. The raw math breaks down to a calculation of 6 x 124,439,808 x 256.
When running the C implementation with the -O3 optimization flag, the results were a sobering reminder of the gap between proof-of-concept and usability. A single training iteration took 7 seconds, and inference speeds dropped below one token per second. While this confirms that the logic works, it is effectively ten times slower than what is required for a fluid experience. The objective shifted from mere implementation to extreme optimization. The goal was to move the performance metric from Gflop/s (billions of operations per second) into the realm of Tflop/s (trillions of operations per second) by rewriting the matrix multiplication kernels directly in Swift.
Beyond Frameworks: The War for Memory and Metal
Most modern AI development relies on the comfort of PyTorch or TensorFlow. These frameworks act as conductors, providing a high-level Python interface that orchestrates complex operations happening in a hidden C++ or CUDA backend. This abstraction is convenient, but it introduces a layer of separation between the developer and the silicon. The Swift experiment rejects this conductor model entirely. Instead of using a pre-packaged library, the developer wrote the operation kernels from scratch, treating the process less like using a meal kit and more like sourcing and prepping every single ingredient by hand to control the final flavor.
At its core, LLM training is a relentless cycle of forward passes, where weights are applied to input data to produce a result, and backward passes, where errors are calculated to refine those weights. Both processes rely on a singular, repetitive operation: matrix multiplication. In the simplest terms, this is the repeated execution of `z += x * y` trillions of times. To optimize this, the developer had to look beyond the standard CPU and tap into the specialized engines of Apple Silicon: SIMD (Single Instruction, Multiple Data), AMX (Apple Matrix Coprocessor), and the GPU.
The critical tension here is the trade-off between safety and speed. Swift is designed as a memory-safe language, meaning it constantly performs bounds checking on arrays to prevent crashes and security vulnerabilities. However, in the world of Tflop/s performance, these safety checks are overhead that the hardware cannot afford. By employing the `-remarks-unsafe` option, the developer effectively stripped away these guardrails, allowing Swift to access memory with the same raw, unchecked speed as C. This shift reveals a fundamental truth about high-performance computing: the limitation is rarely the language itself, but rather the abstractions that shield the programmer from the hardware.
This pursuit of efficiency demonstrates that the ceiling for AI performance is not always found in a more complex algorithm, but in the ability to squeeze every possible cycle out of the physical silicon.
