# How Eugo compares to other HPC options

If you have run [high-performance computing](/glossary/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](/glossary/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](/glossary/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](/lesson/distributed-python-with-eugo-hpc/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](/lesson/how-automatic-optimizations-work/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](/glossary/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:

1. **No queue.** You are not sharing a fixed pool, so there is nothing to wait behind. Compute is
   requested per run.
2. **No rewrite.** [Distributing](/glossary/distributed-computing) work is a decorator on a
   function, not a port to a new framework or a new language.
3. **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](/glossary/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.

---

**Next:** [Open your first interactive session](./04-first-session.mdx).

---

Source: https://university.eugo.io/lesson/getting-started-with-eugo/how-eugo-compares