How Eugo compares to other HPC options
If you have run high-performance computing work before, you arrive with a mental model. Some of it applies here and some of it does not, so this page says which is which. If you have not, it is the shortest tour of what the alternatives ask of you.
There are four broad ways to get a large computation done. They differ less in what the hardware does than in what you are responsible for.
The four options
| Approach | You operate | You wait for | Code changes |
|---|---|---|---|
| Own the cluster | Everything | Procurement, then a queue | Batch scripts |
| Managed batch service | Job definitions, images | A queue | Batch scripts, containers |
| Rent raw instances | The whole stack | Instance startup | Whatever you build |
| Eugo | Nothing | Cluster launch, ~1 minute | A decorator |
Owning a cluster
The traditional answer, and still the right one at sustained very large scale. You buy machines, they sit in a room, and a job scheduler arbitrates between everyone who wants them.
What it costs you is not only capital. Because the node pool is fixed and shared, work has to queue, which means describing your job in a submission script rather than running it. Capacity you are not using is capacity you already paid for, and capacity you need in a spike is capacity you do not have. Procurement cycles are measured in months.
Eugo is not a scheduler you submit jobs to and not a fixed pool you contend for. You launch a cluster when you need one and shut it down when the run finishes.
A managed batch service
Cloud providers offer services that run containerized jobs across machines they operate. This removes the hardware problem and leaves the packaging problem: you define a job, build an image, push it, and submit. The queue is still there, and so is the gap between "my code works locally" and "my code works in the job definition".
Eugo is not a batch service and does not need a container image or a job definition. The function you already wrote gets a decorator, and the call site stays ordinary Python. See your first task.
Renting raw instances
Maximum control, and the option where the most engineering time disappears. You choose instance types, install a toolchain, configure networking and shared storage, size the cluster, and keep all of it working. Every hour of that is an hour not spent on the analysis.
The subtler cost is performance you never see. Getting numeric Python to actually use the hardware underneath it takes compiler work most teams reasonably decline to do, so the machine runs your code correctly and slowly.
Eugo is not a set of instances you configure. The optimization pass is applied for you.
A hosted notebook
Notebook services give you a browser environment with a Python kernel, which is genuinely the right tool for exploratory work, right up until the dataset stops fitting in one machine's memory. At that point a notebook service gives you a bigger machine, and eventually runs out of bigger machines.
Eugo is not a single-machine notebook. EugoIDE is a notebook whose kernel can dispatch work to a cluster, so the same document scales past one machine rather than hitting a ceiling.
What actually differs
Three things:
- No queue. You are not sharing a fixed pool, so there is nothing to wait behind. Compute is requested per run.
- No rewrite. Distributing work is a decorator on a function, not a port to a new framework or a new language.
- No tuning pass. Vectorization and compilation happen without being asked. That is usually where the difference between "it runs" and "it runs fast" lives.
Where Eugo is the wrong choice
A comparison that finds no downsides is not a comparison, so here are the cases that go the other way.
- Sustained, predictable, very large load. If you can keep a large cluster genuinely busy year-round, owning it can be cheaper. On-demand pricing is a good deal for variable demand, and a worse one for a flat curve.
- Work that is not divisible. If each step needs the previous step's answer, there is no independent work to spread, and no amount of hardware helps.
- Frameworks Eugo does not support. PyTorch is supported; TensorFlow, spaCy and JAX are not. If your stack depends on one of those, that is a real constraint rather than a preference.