Intel oneAPI GEMM Benchmark: 2× NumPy on Iris Xe
See how Intel oneAPI GEMM reached 2× NumPy/OpenBLAS performance on Iris Xe, what the benchmark proves, and how to validate GPU gains on your workload.
Intel oneAPI GEMM on Iris Xe: A 2× Result, With Caveats
A GPU benchmark can look decisive at first glance: if one implementation takes half the time, it's tempting to call the winner and move on. But a single GEMM timing only helps if you know what was actually measured, what was left out, and whether the same setup matches your workload.
One reported test of Intel oneAPI 2026.1 compared a DPC++ GEMM implementation on an Intel Iris Xe GPU with NumPy using OpenBLAS on an Intel Core i7-1195G7. The reported times were 0.062 seconds for oneAPI and 0.124 seconds for NumPy/OpenBLAS. A version labeled "oneAPI + cache" took 0.048 seconds.
In the tested setup, that's a pretty clear win: the DPC++ result was about 2× faster than the NumPy baseline, and the cached result was about 2.58× faster. Still, this doesn't mean oneAPI will automatically deliver a 2× speedup for every matrix workload. This article walks through what the numbers do (and don't) tell you, and how to sanity-check GPU GEMM for your own application.
What the benchmark measured
GEMM stands for general matrix-matrix multiplication. In its common form, it computes a matrix product and combines it with an existing output matrix:
C = αAB + βC
It's a core building block for scientific computing, image processing, simulation, and machine learning. But "how fast" GEMM runs depends on more than the processor's theoretical compute rate. Matrix dimensions, data type, memory traffic, library implementation, and the cost of moving data all matter.
The published comparison used this hardware and software configuration:
| Component | Reported configuration |
|---|---|
| CPU | Intel Core i7-1195G7 |
| GPU | Intel Iris Xe, Gen11 Xe-LP |
| oneAPI version | 2026.1 |
| CPU implementation | NumPy/OpenBLAS |
| GPU implementation | oneAPI DPC++ |
The reported timing table is:
| Implementation | Time | Relative to NumPy/OpenBLAS |
|---|---|---|
| NumPy/OpenBLAS | 0.124 s | 1.00× |
| oneAPI DPC++ | 0.062 s | 2.00× |
| oneAPI + cache | 0.048 s | 2.58× |
The math checks out. Dividing the NumPy time by the DPC++ time gives 0.124 / 0.062 = 2. For the cached result, 0.124 / 0.048 is about 2.58. So the claim is based on the reported elapsed times, not on theory.
What is not specified
This result is useful as a signal, but the benchmark summary leaves out details you'd want for a fully reproducible comparison:
- Matrix dimensions and whether the matrices were square
- Data type and numerical precision
- Whether the timing includes memory allocation and host-to-device transfers
- Whether GPU compilation or initialization was included
- Warm-up count, repeat count, and timing method
- How many CPU threads were used, and how OpenBLAS was configured
- What "cache" means in the oneAPI + cache result
- Whether outputs were verified for equivalent numerical correctness
Those missing pieces don't automatically invalidate the measurements. They just limit how far you can generalize. A 2× speedup for one matrix shape isn't a blanket promise, and a "cached" result isn't a fair comparison against a non-cached run unless the benchmark boundaries are clearly defined.
The original report is available at the benchmark source. Use it as a starting point, then rerun with your own matrix sizes and the same kind of application flow you actually use.
How to interpret the performance numbers
The strongest takeaway is specific: in the reported test, oneAPI DPC++ finished the measured GEMM in about half the time of NumPy/OpenBLAS on that system. If GEMM is a recurring cost in your app, it's worth investigating.
The more interesting question is why a GPU implementation might win on an integrated GPU. Iris Xe shares system memory with the CPU, so you can sometimes reduce transfer overhead compared with a discrete GPU. But transfers and synchronization still exist, and the result still depends on where the benchmark starts and stops timing.
GEMM speed is not the same thing as application speed
A kernel timing answers one narrow question: how long did that operation take under that measurement setup? It doesn't automatically tell you how much faster your whole program runs.
For example, imagine an application that:
- Reads and prepares inputs on the CPU.
- Copies (or maps) the input for GPU use.
- Runs one matrix multiplication.
- Transfers the result back to the CPU.
- Continues with CPU-only processing.
If the multiplication is short, then setup, synchronization, and data movement can dominate. Even if the GPU kernel is twice as fast, the end-to-end job might only improve a little - or sometimes not at all. On the other hand, if the workload does many large matrix operations while keeping data on the GPU, a kernel-level advantage has a better chance of showing up as real end-to-end speed.
That's why it helps to think in two layers:
- Kernel-level measurement: Is the GEMM operation itself faster?
- End-to-end measurement: Does your whole workflow finish sooner once you include setup, transfers, and synchronization?
Both matter. Optimizing only the kernel can be "correct" in a benchmark sense but irrelevant in a product sense.
What the cache result may mean
The source reports a third result as "oneAPI + cache," with a time of 0.048 seconds. That's roughly 22.6% faster than the 0.062-second DPC++ run, and about 2.58× faster than NumPy/OpenBLAS.
But "cache" by itself doesn't explain the mechanism. It could mean reusing compiled kernels, keeping data around between runs, improving memory access patterns, or something else entirely. Those are not interchangeable, and they imply different behavior in real applications. Until the report defines what's cached and when, you should treat it as a separate configuration rather than a general oneAPI speedup.
If you try a cache in your own benchmark, document exactly what's cached, when it gets populated, and whether your application can reuse it. A warm repeated operation and a first-time operation answer different questions.
Keep unrelated performance claims separate
The source summary also mentions a 9.83× result for sparse data and a 584× error reduction using RK4. Those are tied to different workload characteristics and algorithms, and the provided details don't explain their test conditions. They shouldn't be used as evidence for dense GEMM performance. Sparse operations and numerical integration need their own baselines, metrics, and validation.
How to test oneAPI GEMM on your workload
You don't need a huge benchmarking framework to get a useful answer. You need a clear question and controlled conditions. The goal isn't to chase the biggest speedup number - it's to figure out whether switching to the GPU path reduces the time your users actually care about.
1. Start with the real matrix shapes
Write down the dimensions and layouts your application uses. If production mixes small and large matrices, test representative cases rather than only the largest one. GEMM performance can shift a lot with problem size: small matrices may be dominated by launch and setup costs, while larger matrices can generate enough work to keep the GPU busy.
Also note the data type. A comparison only makes sense if both implementations are doing equivalent work at an acceptable precision. If one path uses lower precision, you'll want to measure accuracy impact instead of assuming the timings are directly comparable.
2. Define the timing boundary
Decide what you're timing: just the operation, or the full application path.
For an isolated kernel test, be explicit about what's excluded - allocation, initialization, compilation, and transfers. For an end-to-end test, include the costs your production workflow actually pays.
Neither boundary is "more correct" by default. The real mistake is comparing numbers collected under different boundaries and treating them as if they meant the same thing.
3. Control warm-up and repetition
The first GPU operation can include initialization or compilation overhead that later calls avoid. If your users experience both cold-start and steady-state behavior, measure both. Run multiple trials, report something like the median, and don't hang your conclusion on a single timing.
Also keep the machine reasonably steady while testing. Background CPU activity, power settings, thermal limits, and other GPU work can all affect results. On a laptop, sustained performance may differ from a quick burst because of power and heat.
4. Compare equivalent implementations
Use the same input values, dimensions, and output requirements. Confirm numerical results are acceptable before comparing speed. Record the CPU library's thread configuration too - an under-tuned CPU baseline can make the GPU look better than it would against a properly configured CPU path.
For implementation details, see the Intel oneAPI documentation, and review the NumPy documentation for how the Python-side code behaves. Versions and library behavior are part of the environment, not incidental details.
5. Record enough information to repeat the test
A useful results log includes:
- Hardware model and operating system
- Library, compiler, and runtime versions
- Matrix sizes, layouts, and data types
- CPU thread settings and GPU device selection
- Warm-up and repeat counts
- Whether transfers and allocations are included in the timing
- Correctness tolerance and validation method
- Cold-start and steady-state timings, when relevant
That's what turns a headline number into something you can debug later when a driver, runtime, or library update changes performance.
When GPU GEMM is worth using
Whether the GPU is faster in isolation is only half the story. The real question is whether it lowers the total cost of your system. A practical way to decide is to check four conditions.
The workload is large or repeated
GPU execution is more compelling when each operation has enough work to amortize setup, or when the same process runs many operations. If your app only does one small multiplication occasionally, the extra complexity may cost more than the milliseconds you save.
Data can stay close to the computation
If intermediate matrices remain available to GPU operations, you can avoid repeatedly moving data between execution contexts. If each operation requires a round trip through CPU code, you'll need to measure those transitions carefully. Integrated graphics change the mechanics, but they don't eliminate synchronization and memory behavior - you still have to account for it.
The deployment environment is controlled
A benchmark on one Iris Xe laptop doesn't automatically generalize across every Intel GPU, driver version, operating system, or power profile. If you deploy to different machines, validate representative configurations and plan what happens when a supported GPU or runtime isn't available.
A CPU fallback can make sense operationally even if it's not the fastest path on your benchmark machine. Keeping two execution paths increases testing and debugging effort, so the expected user benefit needs to justify it.
The speedup survives end-to-end measurement
Set a threshold before you commit. For instance, require a meaningful improvement in total job time or throughput - not just a faster isolated kernel. Include correctness, memory use, initialization behavior, and maintenance overhead in the decision.
A compact rule of thumb:
- Use the GPU path when representative workloads show a stable end-to-end gain and the runtime cost is acceptable.
- Stick with the CPU path when operations are small, infrequent, or transfer-heavy.
- Benchmark both when workload sizes vary or performance depends strongly on deployment hardware.
The reported 2× result is a solid reason to test oneAPI on similar hardware. It's not a reason to rewrite a working CPU solution without measuring the real application as a whole.
Conclusion
This Intel oneAPI benchmark is encouraging: on an Intel Core i7-1195G7 with Iris Xe graphics, DPC++ GEMM ran in half the time of the NumPy/OpenBLAS baseline. The cached configuration was faster again, though the mechanism isn't described in the supplied results.
The real takeaway isn't "move everything to the GPU." It's that integrated graphics can offer a meaningful acceleration path when matrix operations are large or repeated, data movement is limited, and the improvement holds up in an end-to-end test.
If GEMM is a real bottleneck in your application, reproduce the benchmark with your matrix sizes and your deployment conditions. Measure both the operation and the full workflow, validate output correctness, and keep the CPU path if the GPU advantage doesn't survive those checks.