Turning Old Hardware into a Supercomputer
On the 10th of January 2026, I had the pleasure of discussing a solution to a dilemma many of us face: having big aspirations but a limited budget. It begins with a simple question: “Do you aspire to anything?”. We often look at our existing hardware and feel it isn’t up to the task, believing we are “too poor” or that we need to spend our entire salary on expensive GPUs to do anything interesting. However, your code might not shine yet, but that shouldn’t stop you from having fun. You don’t need massive cloud budgets to do something interesting.
The “Fudgable” Problem Pattern
The strategy relies on identifying problems that follow a specific, surprisingly common pattern: small input, large compute, and small output. While this might sound niche, you would be surprised how many different computational problems can be “fudged” into this category.
We aren’t talking about massive server-farm style Machine Learning, but rather processes that need to run on a CPU for a long time. This covers a broad spectrum: from genetic algorithms—like finding the best way to train a virtual ant to walk —to Monte Carlo simulations for determining the best way to invest your stocks. It even applies to artistic endeavours like ray tracing or security tasks like cryptography, where you might brute-force a hash by sending it to thousands of CPUs across the country.
The Python Philosophy: Don’t Relearn, Recycle
The inspiration for this approach came from a very real problem during my thesis. I was faced with experiments that were projected to take 10 years to finish unless I drastically changed my approach. I am not a fan of buying Cloud credits, so I looked for a cheaper way using the language I already knew: Python.
I firmly believe that doing something new shouldn’t require relearning a whole new language. Do our favourite authors learn a new language every time they write in a different genre? No. Python is what I knew, so that is what I used to recycle the old technology I had lying around. The goal isn’t “hyper-optimization” where latency is zero; I just needed a system reliable enough to restart from a saved state if it crashed.
Conquering the Single Thread
The first step was conquering the single-threaded nature of standard Python. To demonstrate this, consider the example of finding prime numbers—a task that is notoriously easy to understand but hard to do with very large numbers.
When I tried running a prime-finding script live for numbers between 10 million and 10,010,000, it took nearly 3 minutes and 46 seconds on a single thread. This is due to the Global Interpreter Lock (GIL), which restricts Python to one thread. However, Python has a built-in “Goldilocks” solution: multiprocessing.
By using a Pool to spin up multiple processes that share the workload, we can bypass the GIL. However, this comes with dangers. Memory isn’t easily shared, objects must be “pickled” (serialized) to be sent between processes, and you have to manage deadlocks and “zombie processes”. Despite these hurdles, when I ran the experiment using all available cores, that nearly 4-minute task finished in just 5 seconds.
Scaling Up: The Master/Worker Architecture
The real magic happens when you distribute this workload beyond a single machine. We all have old hardware lying around—an old PC or a mother’s laptop—and letting them “languish” is a waste. To utilise this gear, I utilize a Master/Worker architecture. In this setup, the Master controls the queue and collects results, while the Worker picks up tasks and utilises the local CPU cores (minus one to keep the OS stable). My workflow is simple: I keep code in a single Git repository, pull it onto every computer I have, and spin up the Workers.
In a live demo, I calculated a complex Mandelbrot set in just 27 seconds using my 32-core home PC and a laptop connected over a 5G network. The system is incredibly flexible; you can turn on a basement PC mid-process, and it will immediately start helping with the queue. However, a crucial safety note is required: if connecting computers over a network, do not open your router to the internet—use a VPN to stay safe.
The Future: Browser-Based Compute
We can even push this further using Pyodide and WebAssembly (WASM) to run CPython directly in a browser. Since standard multiprocessing is blocked in browsers for security, we use Web Workers to spin up independent Pyodide interpreters. This allows you to utilise friends’ laptops or even mobile phones. While you might get 2–3x less performance per machine compared to native Python, the ability to scale to ten devices results in a significant net gain. I even demonstrated this with my phone, contributing its 9 cores to the calculation simply by opening a URL. While mobile browsers can be a bit “shoddy” due to battery throttling, it works.
This system needs more “plumbing” to be truly enterprise-reliable, but it proves that you can perform heavy computing on a budget. If you are interested in the technical details, you can find me on LinkedIn
The code for this talk can be found on Github.
Happy Clustering