Split the work
A computation is divided into pieces that can each be done without waiting for the others. This is the whole precondition: if step two needs step one's answer, there is nothing to parallelize.
Independent workRunning one computation across many machines at once, so it finishes in hours rather than weeks.
High-performance computing (HPC) is the practice of splitting one large computation across many machines that work on it simultaneously, then combining the results. A job that would take a single computer three weeks can finish in an afternoon.
It is how weather is forecast, how genomes are compared, how aircraft are simulated before they are built, and how large models are trained. The technique is decades old. What has changed recently is not the computing. It is who can get at it.
For most of that history, HPC meant owning a supercomputer: a room of machines, a procurement cycle measured in months, a job scheduler arbitrating between everyone who wanted them, and a queue you waited in. Today the same computing is available as a service, requested for the length of one run and switched off after.
Three ideas, and everything else in HPC is a consequence of them.
A computation is divided into pieces that can each be done without waiting for the others. This is the whole precondition: if step two needs step one's answer, there is nothing to parallelize.
Independent workEach piece goes to a different worker on a different machine. Throughput rises roughly in proportion to the number of workers, until the pieces get too small to be worth dispatching.
Distributed computingThe pieces come back and are reassembled. A run finishes when its slowest piece finishes, which is why uneven division is the most common reason a scaled job disappoints.
StragglersNot every slow program does. The honest test is four questions, and a "no" to the first one means more hardware will not help:
The fourth question is the one that catches people out, and it is worth measuring rather than assuming. See when I/O is the bottleneck, not compute.
HPC as a service (HPCaaS) did not change the computing. It changed what you are responsible for, and that turns out to be most of the cost.
| Owning a cluster | HPC as a service | |
|---|---|---|
| Time to first run | Months | Minutes |
| Paying for idle capacity | Always | Only while it runs |
| Waiting behind other jobs | Yes, a shared queue | No shared pool |
| Who operates the scheduler | You | The provider |
| Scaling down | Not possible | Shut it down |
The trade runs the other way at sustained scale: if you can keep a large cluster genuinely busy year-round, owning it is cheaper. On-demand pricing is a good deal for variable demand and a worse one for a flat curve. See how Eugo compares to other HPC options for where each model wins.
Running one computation across many machines at once, so it finishes in hours rather than weeks. The work is split into pieces, each machine takes some, and the results are combined. It is the technique behind climate models, genome analysis, crash simulation, and training large neural networks.
Cloud computing is about who owns the machines; HPC is about how many of them work on one problem together. They are orthogonal. You can run HPC on your own hardware or in the cloud, and most cloud usage is not HPC at all. HPC as a service is the overlap: HPC delivered on demand rather than from a machine room you bought.
Probably not one you own. If a job takes longer than you can wait, runs out of memory, or you are batching work overnight that you would rather see in minutes, you need HPC. But that is now something you request for the length of a run rather than something you procure.
It depends almost entirely on whether the work divides. Work that splits cleanly scales close to linearly with the number of workers, so 32 machines can approach 30x. Work that is waiting on storage rather than computing barely improves at all, no matter how many machines you add. Diagnosing which case you are in comes before scaling anything.
High-performance computing consumed as a service: you request compute for one run and stop paying when it ends. No hardware procurement, no capacity planning, and no job queue to wait in, because you are not sharing a fixed pool of machines with other users.
Traditionally yes, and that is the historical barrier. Classic HPC meant a batch submission script and often MPI. On Eugo it is a decorator on a function you already wrote: the body is unchanged Python, and the call site returns a handle instead of a value.
No. The largest growth is commercial: financial modeling, geospatial pipelines, ML training and inference, and any data workload that outgrew a single machine are all HPC problems, whether or not the people running them use the term.
These courses teach HPC by running real workloads, in the order to take them.
All courses