A published CUDA-versus-OpenCL percentage is a measurement of one kernel, on one device, at one tuning budget. It is not a property of the API, and it is not a decision input until you know what was held constant.
The naive reading goes: CUDA is 20–30% faster, therefore CUDA wins. The expert reading asks a different question — what was equalised? Kernel tuning hours, memory access pattern, occupancy target, driver version, and, most importantly, whether the OpenCL kernel was written for the target device or transliterated line-by-line from CUDA source.
Where does the gap actually come from?
The usual divergence point is the memory model. A kernel built around CUDA-specific shared-memory tiling and coalescing assumptions will underperform when the same logic is moved to OpenCL on the same silicon, because the assumptions no longer hold in the same way. That penalty is real, but it belongs to the port, not to the API. Attributing it to OpenCL is a category error that then gets quoted in a procurement discussion.
Two consequences follow. First, most of a transliteration-driven gap is recoverable by rewriting the kernel against the target device’s memory hierarchy rather than translating it. Second, because published comparisons rarely disclose the tuning budget spent on each side, the reported number is uninterpretable — you cannot tell whether you are reading an API difference, a compiler difference, or an effort difference.
Workload class matters too. Kernels that are straightforwardly bandwidth-bound with simple, streaming access patterns tend to show the smallest difference, because there is little room for either API to be cleverer than the memory system. Kernels that lean hard on vendor-specific primitives, tuned library calls, or intricate shared-memory staging show the largest — and there the gap is at least partly a library ecosystem gap rather than a language one.e.e.
What to measure before you commit
Replace the cited percentage with three numbers from your own hardware, per kernel, with the same engineering hours spent on each candidate:
| Measure | Why it matters | What “good” looks like |
|---|---|---|
| Kernel wall-clock time | The only number the business actually feels | Compared per kernel, not per app |
| Achieved memory bandwidth as % of theoretical peak | Separates a memory-model problem from an API problem | Bandwidth-bound kernels near peak on both sides |
| Occupancy | Shows whether the port respected the device’s execution model | Comparable occupancy targets on both APIs |
| Tuning hours spent per API | Makes the comparison honest | Equal, and recorded |
A published benchmark is usable as evidence only if it discloses hardware and driver version, compiler and toolkit version, whether the OpenCL kernel was rewritten or transliterated, and the optimisation effort on each side. Missing any of those, treat it as an anecdote about someone else’s kernel.
We see the cost asymmetry regularly in porting work: measuring this before the commitment costs a benchmark run, whereas discovering a 2–3× shortfall after the port costs a rewrite (an observed pattern in GPU porting engagements, not a published figure). Getting the measurement discipline right — bandwidth utilisation and occupancy per kernel, equal tuning effort per candidate — is the same discipline our GPU engineering and performance work applies when a client arrives holding a third-party percentage.
Turning the residual into a number the business can weigh
Once tuning effort is equalised, whatever difference remains is the real one. Express it as a cost: extra GPU-hours per month at your utilisation, or extra devices needed to hit the same throughput. That converts “CUDA is faster” into a quantified lock-in premium, which can be weighed against the value of running on hardware from more than one vendor. Sometimes the premium is worth paying. Sometimes it turns out to be smaller than the cost of being unable to switch silicon.
The open question on most projects is not which API is faster, but how much of the measured gap you are willing to spend engineering hours reclaiming — and whether anyone has checked that the number came from a fair fight.
