A CUDA core and an AMD stream processor are not the same unit of compute, so 4,096 of one does not equal 4,096 of the other. Both are marketing labels applied to lanes inside different SIMD organisations: NVIDIA schedules work as warps across streaming multiprocessors, AMD schedules wavefronts across compute units. The scheduling granularity, register file limits, and occupancy ceilings differ, which means the same kernel can leave very different fractions of each device’s theoretical throughput unreachable.
That matters most at two moments: sizing hardware before purchase, and porting a kernel from one vendor to another. A team that shortlisted parts on core counts alone tends to discover the deficit only after the kernel is written and profiled — by which point the budget is committed.
Why can’t CUDA core and stream processor counts be compared directly?
Because the count tells you how many lanes exist, not how many of them your instruction stream can keep fed. Occupancy is bounded by registers per thread, shared memory or LDS usage per block, and the scheduler’s issue rules — all of which are architecture-specific. A bandwidth-bound kernel saturates memory long before it saturates lanes, so adding lanes adds nothing measurable.
Specialised units complicate the label further. Tensor Cores on NVIDIA, matrix cores on AMD CDNA parts, and Intel’s Xe vector and matrix engines sit alongside the general-purpose lanes and are not included in the headline core figure. A transformer inference workload running through TensorRT may spend most of its time on units the core count never mentioned.
Run your workload on real silicon
| Signal | Why it correlates with throughput |
|---|---|
| Achieved FLOPs or frames/tokens per second on a representative kernel | Direct measurement of the workload you actually run |
| Memory bandwidth and achieved bandwidth utilisation | Decides the ceiling for bandwidth-bound kernels |
| Cache and shared-memory/LDS capacity per compute block | Determines tiling strategy and re-use |
| Sustained clocks under thermal load | Boost figures rarely hold across a full run |
| Occupancy limits at your register and block-size choices | Sets how much of the lane count is reachable |
| Presence and reachability of matrix/tensor units via your stack | Often dominates mixed-precision inference |
| Core count | A shortlist filter only — never a performance model |
Pick a kernel that mirrors your production code, compile it with the vendor’s native toolchain, and profile memory bandwidth alongside compute occupancy on both GPUs. That single measurement replaces the whole core-count argument. It is also the fastest way to expose an unbudgeted second porting cycle before it happens rather than after.
Does this change your compute API choice between CUDA, OpenCL, and SYCL? Mostly no — that decision is driven by portability requirements, toolchain maturity, and library coverage, not by lane counts. What the counts do affect is how much re-tuning each target needs once the API is chosen: block sizes, unroll factors, and tiling written for a 32-lane warp rarely land optimally on a 64-lane wavefront without adjustment.
We see this pattern regularly in porting work — the kernel compiles, runs, and returns correct results, then delivers a fraction of the expected rate because the launch geometry was inherited from the other vendor. Our GPU acceleration and optimisation work starts from measured bottleneck class per kernel for exactly this reason: knowing whether you are bandwidth-, occupancy-, or instruction-bound tells you which specification to negotiate on, and the core count tells you none of the three.
The open question on any given shortlist is not which part has more lanes. It is how much of either part’s theoretical throughput your kernel, as written today, can actually reach.
