A CUDA core and a stream processor are not the same unit of hardware, so the two numbers on the two spec sheets are not comparable. Both are vendor labels for a lane inside a SIMD execution group, and the groups differ: NVIDIA schedules work in 32-wide warps, AMD in wavefronts that have been 64-wide and, on RDNA parts, 32-wide. A 4,096-lane AMD part does not automatically beat a 3,584-lane NVIDIA part, because lane count says nothing about how many of those lanes are kept fed.
What does CUDA core vs stream processor mean in practice?
Operationally, it means you are reading two different marketing denominators. Around each cluster of lanes sits the machinery that decides whether they do useful work: the number of warp or wavefront schedulers, the register file size that caps how many thread groups can be resident, the L1/shared-memory allocation, and the memory bandwidth available per lane. Two devices with similar advertised lane counts can differ by a wide margin in achieved occupancy and delivered bandwidth, and it is those two properties — not lane count — that track measured throughput on real kernels.
That is why we treat core counts as descriptive rather than predictive. They tell you roughly what class of device you are looking at. They do not tell you what your workload will get.
| Spec-sheet number | What it actually describes | What it does not tell you |
|---|---|---|
| CUDA cores (NVIDIA) | FP32 lanes grouped into 32-wide warps per SM | Occupancy achieved by your kernel; bandwidth per lane |
| Stream processors (AMD) | Lanes grouped into wavefronts (32 or 64 wide by architecture) | Scheduler throughput; register pressure limits |
| Compute units / SMs | How many independent schedulers exist | Whether your block size maps cleanly onto them |
| Tensor cores / matrix cores | Separate matrix-math units, counted separately | Anything about FP32 lane performance |
| Memory bandwidth (GB/s) | Peak, not sustained | Achieved utilisation under your access pattern |
The divergence usually shows up at procurement and porting at the same time. A team sizes hardware on lane count, buys the nominally larger device, ports the kernel, and finds the CUDA-specific memory access patterns — coalescing tuned to a 32-lane warp, shared-memory tiling tuned to one register budget — do not transfer performantly to a machine organised differently. The lost performance was never in the core count. It was in occupancy and bandwidth headroom, which are measurable before purchase and are the properties our GPU engineering work is usually pointed at.t.
Benchmark instead of comparing
- Pick one representative kernel per workload class you actually run, not a synthetic peak-FLOPS test.
- Measure achieved occupancy and memory-bandwidth utilisation on each candidate device, not just wall-clock time.
- Record samples per second (or frames per second) per device, then price it against the multi-year hardware plan.
- Treat the compute API decision — CUDA, HIP, SYCL, OpenCL, or a graph compiler such as TensorRT or ONNX Runtime — as a separate decision with its own portability cost. Lane counts do not inform it.
Teams that run this measurement typically find that achieved utilisation, not advertised lane count, explains the gap between expected and delivered throughput (a pattern we see across GPU audit work rather than a published benchmark figure).
Vendors will keep inventing new denominators — Intel counts Xe-cores, NVIDIA counts tensor cores separately from CUDA cores, AMD counts matrix cores. The useful question is not which label is larger, but whether your kernel keeps the lanes it is given busy.
