Skip to main content

Interactive learning

Illustrative figures, including the cases where the answer is “don’t”.

Three demos

Pick one, or scroll. They are all on this page.

Performance & optimization

Speedup explorer

Watch speedup diverge from ideal-linear scaling as worker count grows, and see where adding workers stops paying. Illustrative figures, not measurements.

GPU & acceleration

CPU vs GPU on the same machine

Compare the same operation on one machine's CPU and on its GPU, including the small workloads where the transfer costs more than the GPU saves. Illustrative figures, not measurements.

Performance & optimization

Cluster sizer

Describe the shape of your workload and get a worker count, an estimated runtime, and the point where scaling stops helping.

The first two panels are illustrative: no capture backs their figures, and they may not be quoted as performance claims. What they are for is the boundary — where a technique stops paying: a GPU that loses to the CPU beside it, a worker count that buys nothing. Knowing the boundary is more useful than knowing the best case. The cluster sizer is a model of Amdahl’s law and says so on its own face. Each panel has a table view if you would rather read the numbers directly.

Speedup explorer

Illustrative speedup against worker count for three workload shapes, with ideal-linear scaling for reference. Where a curve flattens is where adding workers stops paying. The shape is the lesson; the figures are not measurements.

Figures pending verification — not measured. No capture backs these curves. They were written to show the shape of the effect, and they are not timings of Eugo hardware, so nothing here may be quoted as a performance claim. Eugo publishes a performance figure only when a named capture backs it and the benefit is above 10%; these meet neither test.
ideal1248163264Workers1×8×16×24×32×40×38.2×15.8×4.7×
  • Compute-bound
    Numeric work over data already in memory. Scales close to linear until scheduling overhead becomes visible.
  • Mixed compute and I/O
    A typical dataframe pipeline: read a partition, transform it, write results. Scales well, then tapers.
  • I/O-bound
    Most time spent waiting on object storage. Plateaus early: past this point extra workers add cost, not speed.
Not measured on Eugo clusters, or anywhere else: these curves have no capture behind them. Ideal-linear assumes speedup equals worker count, which no real workload achieves; it leaves the top of the scale at 40 workers and is not drawn beyond there.

CPU vs GPU on the same machine

Every row shows one operation twice on the same machine: once on its CPU, once on its GPU, with the host-to-device transfer counted inside the GPU bar. The last two rows run slower on that machine's GPU than on its own CPU, because the transfer costs more than the computation saves. The figures are illustrative, not measured.

Figures pending verification — not measured. No capture backs these timings. They were written to show when offloading pays and when the transfer eats the gain, and they are not timings of Eugo hardware, so nothing here may be quoted as a performance claim. Eugo publishes a performance figure only when a named capture backs it and the benefit is above 10%; these meet neither test.
0.11ms10ms100ms1sRuntime (log scale)Matrix multiply8192 × 8192, `float32`50.2×Elementwise transform512M element array13.2×FFT2D, 4096 × 409614.3×Reduction (sum)512M elements1.8×Matrix multiply256 × 256, `float32`2.7× slower than CPUElementwise transform10K element array17.3× slower than CPU
  • CPU
  • GPU, faster than CPU
  • GPU, slower than CPU
  • transfer portion of GPU time
Illustrative figures, with no capture behind them. Both bars in a row are one machine's own processors: its CPU against its GPU, on the same operation. Log scale, because runtimes span four orders of magnitude. GPU bars include host-to-device transfer and back. The inset shows what share of each GPU bar is transfer, drawn as a proportion of the bar rather than measured against the logarithmic axis.

Cluster sizer

Describe the shape of your workload and get a worker count, an estimated runtime, and the point where adding workers stops paying for itself.

Recommended workers
32
where returns flatten
Estimated runtime
4 min
from 33 min serial
Speedup
7.8×
ceiling 10.0× at any size
GPU nodes
Unlikely to help
Partition, transform, concatenate. The combine step is the serial remainder.

Partition, transform, concatenate. The combine step is the serial remainder. This shape is about 90% parallelizable, so its speedup cannot exceed 10.0× no matter how many workers you add.

12481632641284 minWorkers34 min0
Modeled with Amdahl’s law plus per-task scheduling overhead. An estimate for planning, not a guarantee. Measure your own workload, and see measuring the gain honestly.