Accelerating Matrix Multiplication: A Performance Comparison Between Multi-Core CPU and GPU

(2) Lamar University; Beaumont; Mudabir Qamar Ansari (2) ((1) The University of Toledo; Mufakir Qamar Ansari (1); OH; Toledo; TX; USA; USA)

REVIEW 3 major objections 3 minor 14 references

Accelerating Matrix Multiplication: A Performance Comparison Between Multi-Core CPU and GPU

T0 review · 3 major / 3 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A mobile GPU multiplies 4096x4096 matrices 45x faster than a 16-thread CPU.

desk verdict A readable replication of a well-known GPU-vs-CPU result whose headline numbers are not reproducible from the printed source; the shared-memory kernel described in the text is not the kernel in Appendix A. read the letter →

arxiv 2507.19723 v1 pith:CMM56JPM submitted 2025-07-26 cs.DC

Mufakir Qamar Ansari (1) , Mudabir Qamar Ansari (2) ((1) The University of Toledo , Toledo , OH , USA , (2) Lamar University , Beaumont , TX

show 1 more author

USA)

This is my paper · ORCID

classification cs.DC MSC 68W1065Y0568M20

keywords matrixmultiplicationGPUaccelerationCUDAOpenMPheterogeneouscomputingperformancebenchmarkinghigh-performancespeedupmeasurement

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper tries to establish, by direct measurement on a consumer laptop, that a discrete GPU executes dense matrix multiplication far faster than either a single CPU core or a 16-thread multi-core CPU, and that the advantage grows with matrix size. It reports that for a 4096x4096 matrix of 32-bit floats, a CUDA implementation on a GTX 1650 Mobile took about 663 ms, versus about 393 s for a sequential C++ loop and about 30 s for an OpenMP loop, giving speedups of roughly 593x and 45x, respectively. The paper also documents a small-matrix regime where OpenMP overhead makes the parallel CPU slower than the sequential baseline. If the measurements are right, they quantify how much of the parallel-computing gap is accessible to ordinary hardware for a foundational scientific kernel.

What carries the argument

The mechanism is the choice of parallel execution model. The sequential baseline is a plain nested loop; the CPU parallel version adds `#pragma omp parallel for collapse(2)` to fuse the two outer loops across 16 threads; the GPU version is a CUDA kernel that the text describes as cooperatively loading tiles of A and B into shared memory to cut global-memory traffic, though the code listing in Appendix A contains no shared memory and directly reads global memory in the inner loop. The performance metric that carries the argument is the speedup ratio S = T_seq / T_parallel, and the reported scaling of this ratio with matrix size is what the paper uses to conclude that GPU advantage grows with workload.

What would settle it

Recompile and run the printed code on the same laptop (Ryzen 7 5800H, GTX 1650 Mobile, CUDA 12.2, -O3) and compare the measured 4096x4096 GPU time to the reported 663.24 ms; also inspect whether the kernel allocates any `__shared__` memory. A zero-shared-memory kernel or a large time difference would indicate that the printed code is not the code that was benchmarked, or that the shared-memory description is inaccurate.

Watch

Extended reading notes

Core claim

The central claim is that on the tested heterogeneous system, the GPU's many-core throughput dominates as problem size grows. The authors implement three versions of the same triple-nested loop and measure wall-clock time including GPU memory transfers. Their data show the GPU speedup over the sequential CPU climbing monotonically from about 8x at 128x128 to about 593x at 4096x4096, while the OpenMP speedup plateaus near 12-14x. They interpret the 45x GPU-over-OpenMP figure as the fairer comparison between optimized implementations, and read it as consistent with earlier results that narrowed the '100x GPU vs CPU' gap when both sides are tuned.

Load-bearing premise

The entire experimental result rests on the assumption that the source code printed in Appendix A is exactly the code that produced Table 1, since the printed CUDA kernel does not use shared memory despite the paper's description of a shared-memory tiled kernel.

Editorial extensions

If this is right

For large dense matrix multiplication on consumer hardware, a GPU can deliver hundreds-fold speedup over a single-threaded CPU and tens-fold over a 16-thread CPU, making GPU offload worthwhile even on a laptop.
The GPU advantage is workload-dependent: it grows super-linearly with matrix size, so small kernels may run faster on the CPU despite the presence of a GPU.
End-to-end GPU time, including host-device copies, remains far below CPU time at scale, so the transfer overhead is not a disqualifier for large matrices.
Using an optimized parallel CPU as the baseline, rather than a sequential loop, changes the headline from roughly 593x to roughly 45x, a more realistic framing for the architectural comparison.
The same measurement protocol can be applied to other basic kernels to map which computations benefit from GPU offload on commodity systems.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

Editorial: If the printed kernel is authoritative, the reported GPU timings were produced by a straightforward global-memory kernel, not the shared-memory tiled kernel described in the methodology; a properly tiled kernel would likely be faster, so the paper may understate the GTX 1650's ceiling.
Editorial: The sequential baseline's 393 s for 4096x4096 suggests the C++ loop did not exploit cache blocking or SIMD; a tuned BLAS library on the same CPU would shrink the denominator and could reduce the headline speedup considerably.
Editorial: The claimed monotonic scaling of GPU speedup implies that for even larger matrices (8192x8192 and beyond, within VRAM limits) the GTX 1650 would continue to widen its lead, a prediction the paper does not test.
Editorial: A reader wanting to extend the work could rerun the benchmark with cublasSgemm as the GPU baseline to see how close the hand-written kernel comes to the vendor-optimized library.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Short version: this is a clear, honest-in-intent benchmark of matrix multiplication on a consumer laptop, confirming the well-established result that a discrete GPU beats a multi-core CPU on dense matmul and that the gap grows with size. The numbers in Table 1 are internally plausible for a naive CUDA kernel. The paper even handles the small-matrix case well, noting the OpenMP overhead at 128x128.

What the paper does well: it frames itself as a contemporary validation of Lee et al. (2010) rather than claiming a new phenomenon. The writing is straightforward, the experimental setup is described in enough detail to identify the hardware and toolchain, and the reported scaling trends match what the literature would predict.

The soft spots are not minor. The abstract, Section 3.1.3, and Section 5.3 all say the CUDA kernel uses shared-memory tiling. Appendix A, explicitly labeled 'complete source code used to generate all performance data,' contains a plain element-per-thread kernel with no __shared__ memory, no __syncthreads(), and a simple k-loop over global memory. If that code was run, the described algorithm was not benchmarked. If a different, tiled kernel was run, the printed code cannot reproduce the timings. Either way the central empirical claim is unverifiable from the paper as submitted. This is not a stylistic quibble; it is a contradiction between the method description and the artifact.

Two more issues amplify this. The benchmarking protocol says GPU time includes device memory allocation, but the code calls cudaMalloc before start_gpu, so allocation is excluded. That is a smaller error, but it shows the timings need scrutiny. And the 'optimized parallel CPU' baseline is a naive OpenMP loop with no tiling, no SIMD, and no BLAS-level optimization, so the headline 45x GPU-vs-CPU figure is against a weak baseline. There are also no repeated trials or error bars, so the single-run wall-clock numbers carry unknown variance.

Bottom line: the field conclusion the paper reaches is almost certainly correct, but this manuscript cannot support it because the evidence is not reproducible. The fixes are straightforward — supply the actual kernel, correct the timing description, strengthen the CPU baseline, and run repeated trials — but they are not minor edits. As submitted, I would not send this to a referee; I would desk reject with an invitation to resubmit after major revision. A corrected version would be a modest but usable data point for practitioners comparing consumer hardware, though it would still be low-novelty.

Referee Report

3 major / 3 minor

Summary. This manuscript reports an empirical benchmark of three square matrix multiplication implementations—a sequential C++ loop, an OpenMP-parallel version using collapse(2), and a CUDA kernel—on a Lenovo IdeaPad Gaming 3 with an 8-core Ryzen 7 5800H and a GTX 1650 Mobile. Execution times for N = 128 to 4096 are tabulated, and speedups are computed as ratios of wall-clock times. The headline results are approximately 593x GPU speedup over the sequential baseline and 45x over the parallel CPU at N=4096. The paper interprets these as evidence of GPU dominance for data-parallel workloads on consumer hardware and states that the CUDA kernel uses shared-memory tiling.

Significance. The contribution is purely empirical and would be a modest but useful data point if internally consistent: it uses a clear speedup metric, supplies a benchmark harness, and reports a hardware/software configuration that is easy to replicate. The paper also connects its CPU-vs-GPU comparison to the earlier caveat by Lee et al. about CPU-side optimization. However, the manuscript's central claim is not independently verifiable because the printed source code contradicts the described algorithm. Since the entire conclusion rests on the measured timings, this inconsistency is disqualifying for the submitted version.

major comments (3)

[Appendix A, Listing 1 (lines 58-69); §3.1.3; Abstract] The paper claims the CUDA implementation 'makes extensive use of on-chip shared memory' and that the measured GPU time corresponds to this optimized kernel. The complete source in Appendix A contains no __shared__ declarations, no __syncthreads(), and each thread computes one output element by looping over k with global accesses A[row*size+k] and B[k*size+col]. Because the appendix says this is 'the complete C++/CUDA source code used to generate all performance data,' the reported Table 1 cannot be reproduced from the described tiled kernel. If the actual benchmark used a different tiled kernel, the appendix is not the code that was run; if it used this kernel, the shared-memory claims in the abstract and §5.3 are false. Either way the central empirical result is unverifiable.
[§3.2 vs Appendix A lines 105-119] The methodology states that the GPU time is comprehensive and includes device memory allocation. In the supplied code, the three cudaMalloc calls appear before 'auto start_gpu', and the timed region covers only the two host-device transfers and the kernel launch. The timing convention therefore excludes allocation, contrary to the text. The reported GPU wall-clock times should be recomputed with a uniform convention (including or explicitly excluding allocation) so that the speedup ratios have a well-defined meaning.
[Abstract; §3.1.2; §5.1] The abstract and §5.1 describe the OpenMP version as an 'optimized parallel CPU' implementation, but the printed source is the same naive triple loop with a collapse(2) pragma. It does not use SIMD vectorization, cache blocking, or a vendor-tuned BLAS routine. Consequently, the 45.73x 'GPU vs. optimized parallel CPU' speedup at N=4096 is a comparison against a naive OpenMP loop, and the wording overstates what the experiment demonstrates. The paper should either replace the CPU baseline with a genuinely optimized implementation (e.g., an optimized BLAS library) or reword the claims to say naive OpenMP.

minor comments (3)

[§3.2 / Table 1] The table reports single timings without repetitions, standard deviations, or a statement that values are medians. On a laptop with thermal and frequency variation, at least three to five runs per size should be reported to support the speedup ratios.
[Appendix A] The listing appears corrupted in the preprint (identifiers such as 'c u d a _ r u n t i m e .h', 'co ll aps e (2)', and 'bl ock Id x' contain spurious spaces). If this is not simply a text-extraction artifact, the actual source code in the final version must be verbatim compilable.
[§5.2] The comparison with Lee et al. would be more informative if the manuscript also measured a vendor-optimized CPU BLAS (e.g., OpenBLAS or Intel MKL) and possibly cuBLAS, since these are the standard reference points for 'optimized' performance.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: measured timings and ratio-based speedups are purely empirical; the appendix kernel mismatch is a reproducibility defect, not circularity.

full rationale

This paper reports a direct empirical benchmark: execution times are measured wall-clock durations, and speedups are computed by the stated formula S = Tseq/Tpar (Section 3.3). No parameter is fitted to the reported outputs, no model is calibrated to the data, and the claimed 593x/45x figures are arithmetic ratios of the measured timings in Table 1, not quantities that reduce to the inputs by construction. The claims therefore have independent empirical content and are falsifiable by rerunning the benchmark. The apparent mismatch between the shared-memory algorithm described in Section 3.1.3 and the naive kernel printed in Appendix A (Listing 1, lines 58-69), combined with the exclusion of cudaMalloc from the GPU timing despite the Section 3.2 statement that allocation is included, is a serious reproducibility and methodology defect; it is a correctness concern, not a form of circularity, because it does not make the result equivalent to its own inputs. No step in the paper's chain is self-definitional, fitted-input-called-prediction, or uniquely justified by a self-citation, so the circularity burden is zero.

Assumptions & free parameters 0 free parameters · 3 assumptions · 0 invented entities

The paper introduces no new free parameters, no mathematical axioms beyond standard arithmetic, and no invented entities. It relies on domain assumptions about the stability of the benchmark environment and, critically, on the assumption that the printed source code matches both the described methodology and the code that produced the reported timings. That assumption is contradicted by the text, which is the main source of uncertainty.

assumptions (3)

domain assumption The benchmark environment is quiet and consistent across the single run per size, so the reported wall-clock times are representative.
Section 3.2 describes a single execution per matrix size with no repetition, so the protocol assumes no thermal throttling, background load, or timing jitter affects the results.
domain assumption The compiler flags (-O3 for g++, default CUDA flags) and the naive loop structures produce implementations that can fairly be labeled 'optimized' for the comparison.
The 'optimized parallel CPU' label is applied to a collapse(2) triple loop with no cache tiling, vectorization, or BLAS, and the GPU kernel is described as shared memory optimized despite containing no shared memory, in Section 3.1.3 and Appendix A.
domain assumption The printed source code in Appendix A is the exact code that generated Table 1.
The paper claims in Section 3.1.3 that the kernel uses shared memory, but Listing 1 shows a naive kernel. The identity of the benchmark code is a precondition for the reported numbers to be reproducible.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Accelerating Matrix Multiplication: A Performance Comparison Between Multi-Core CPU and GPU." pith.science (2026). https://pith.science/paper/CMM56JPM

@misc{pith2026250719723,
  author       = {Pith},
  title        = {Pith review of: Accelerating Matrix Multiplication: A Performance Comparison Between Multi-Core CPU and GPU},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/CMM56JPM}},
  note         = {Machine review of arXiv:2507.19723}
}

read the original abstract

Matrix multiplication is a foundational operation in scientific computing and machine learning, yet its computational complexity makes it a significant bottleneck for large-scale applications. The shift to parallel architectures, primarily multi-core CPUs and many-core GPUs, is the established solution, and these systems are now ubiquitous from datacenters to consumer laptops. This paper presents a direct, empirical performance analysis of matrix multiplication on a modern, consumer-grade heterogeneous platform. We implemented and benchmarked three versions of the algorithm: a baseline sequential C++ implementation, a parallel version for its multi-core CPU using OpenMP, and a massively parallel version for its discrete GPU using CUDA with shared memory optimizations. The implementations were evaluated with square matrices of varying dimensions, from 128x128 to 4096x4096. Our results show that while the parallel CPU provides a consistent speedup of 12-14x over the sequential version, the GPU's performance scales dramatically with problem size. For a 4096x4096 matrix, the GPU implementation achieved a speedup of approximately 593x over the sequential baseline and 45x over the optimized parallel CPU version. These findings quantitatively demonstrate the profound impact of many-core GPU architectures on accelerating data-parallel workloads, underscoring that significant performance gains are readily accessible even on consumer-level hardware.

Figures

Figures reproduced from arXiv: 2507.19723 by the authors.

**Figure 1.** A comparison of execution times for sequential CPU, parallel CPU (OpenMP), and parallel GPU (CUDA) implementations across varying matrix sizes. The logarithmic Y-axis is used to accommodate the wide range of execution times. performance gains offered by both parallel approaches as the problem size increases, with the GPU demonstrating a significantly higher rate of improvement. Finally, [PITH_FULL_IMAGE:figures/fu… view at source ↗

**Figure 2.** Speedup of the parallel CPU (OpenMP) and parallel GPU (CUDA) implementations relative to the sequential CPU baseline. Note that the Y-axis is on a logarithmic scale to clearly display the vast difference in speedup factors. thread creation, management, and synchronization on the CPU, which for a computationally trivial workload, consumes more time than is saved by parallel execution. Second, as the matrix dimensions… view at source ↗

**Figure 3.** The performance advantage of the parallel GPU implementation relative to the parallel CPU implementation. The plot shows that the GPU’s lead grows as the computational workload increases. advantage, claims of 100–1000x speedups often result from comparing an optimized GPU implementation against unoptimized sequential CPU code. Our results affirm this perspective; the speedup of the GPU is a formidable ∼45x when com… view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

14 extracted references · 13 canonical work pages

[1]

Eijkhout, Introduction to high performance scientific computing

V. Eijkhout, Introduction to high performance scientific computing . Lulu. com, 2010

work page 2010
[2]

GPU computing performance analysis on matrix multiplication,

Z. Huang, N. Ma, S. Wang, and Y. Peng, “GPU computing performance analysis on matrix multiplication,” The Journal of Engineering , vol. 2019, no. 23, pp. 9043–9048, 2019

work page 2019
[3]

Neuromorphic computing and beyond,

K. S. Mohamed, “Neuromorphic computing and beyond,” (No Title) , 2020

work page 2020
[4]

The landscape of parallel computing research: A view from berkeley,

K. Asanovic, R. Bodik, B. Catanzaro, J. Gebis, P. Husbands, K. Keutzer, D. Patterson, W. Plishker, J. Shalf, and S. W. Williams, “The landscape of parallel computing research: A view from berkeley,” 2006

work page 2006
[5]

Optimization principles and application performance evaluation of a multithreaded gpu using cuda,

S. Ryoo, C. I. Rodrigues, S. S. Baghsorkhi, S. S. Stone, D. B. Kirk, and W.-m. W. Hwu, “Optimization principles and application performance evaluation of a multithreaded gpu using cuda,” in Proceedings of the 13th ACM SIGPLAN Symposium on Principles and practice of parallel programming , 2008, pp. 73–82

work page 2008
[6]

A survey of cpu-gpu heterogeneous computing techniques,

S. Mittal and J. S. Vetter, “A survey of cpu-gpu heterogeneous computing techniques,” ACM Computing Surveys (CSUR) , vol. 47, no. 4, pp. 1–35, 2015

work page 2015
[7]

Openmp: an industry standard api for shared-memory programming,

L. Dagum and R. Menon, “Openmp: an industry standard api for shared-memory programming,” IEEE computational science and engineering , vol. 5, no. 1, pp. 46–55, 1998. 10 M. Q. ANSARI AND M. Q. ANSARI

work page 1998
[8]

CUDA C Programming Guide,

NVIDIA Corporation, “CUDA C Programming Guide,” 2024, version retrieved in July 2025. [Online]. Available: https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html

work page 2024

Show all 14 references

[9]

Debunking the 100x gpu vs. cpu myth: an evaluation of throughput computing on cpu and gpu,

V. W. Lee, C. Kim, J. Chhugani, M. Deisher, D. Kim, A. D. Nguyen, N. Satish, M. Smelyanskiy, S. Chen- nupaty, P. Hammarlund et al. , “Debunking the 100x gpu vs. cpu myth: an evaluation of throughput computing on cpu and gpu,” in Proceedings of the 37th annual international sym...

2010
[10]

Performance analysis and efficient execution on systems with multi-core cpus, gpus and mics,

G. Teodoro, T. Kurc, G. Andrade, J. Kong, R. Ferreira, and J. Saltz, “Performance analysis and efficient execution on systems with multi-core cpus, gpus and mics,” arXiv preprint arXiv:1505.03819 , 2015

2015 arXiv
[11]

Understanding the efficiency of gpu algorithms for matrix- matrix multiplication,

K. Fatahalian, J. Sugerman, and P. Hanrahan, “Understanding the efficiency of gpu algorithms for matrix- matrix multiplication,” in Proceedings of the ACM SIGGRAPH/EUROGRAPHICS conference on Graph- ics hardware, 2004, pp. 133–137

2004
[12]

Tsm2: optimizing tall-and-skinny matrix-matrix multiplication on gpus,

J. Chen, N. Xiong, X. Liang, D. Tao, S. Li, K. Ouyang, K. Zhao, N. DeBardeleben, Q. Guan, and Z. Chen, “Tsm2: optimizing tall-and-skinny matrix-matrix multiplication on gpus,” in Proceedings of the ACM International Conference on Supercomputing, 2019, pp. 106–116

2019
[13]

Automatically tuning sparse matrix-vector multiplication for gpu architectures,

A. Monakov, A. Lokhmotov, and A. Avetisyan, “Automatically tuning sparse matrix-vector multiplication for gpu architectures,” in International Conference on High-Performance Embedded Architectures and Compilers. Springer, 2010, pp. 111–125

2010
[14]

A performance comparison of cuda and opencl,

K. Karimi, N. G. Dickson, and F. Hamze, “A performance comparison of cuda and opencl,” arXiv preprint arXiv:1005.2581, 2010. Appendix A. Benchmark Source Code The complete C++/CUDA source code used to generate all performance data in this paper is provided below for reproducib...

2010 arXiv

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.

[1] [1]

Eijkhout, Introduction to high performance scientific computing

V. Eijkhout, Introduction to high performance scientific computing . Lulu. com, 2010

work page 2010

[2] [2]

GPU computing performance analysis on matrix multiplication,

Z. Huang, N. Ma, S. Wang, and Y. Peng, “GPU computing performance analysis on matrix multiplication,” The Journal of Engineering , vol. 2019, no. 23, pp. 9043–9048, 2019

work page 2019

[3] [3]

Neuromorphic computing and beyond,

K. S. Mohamed, “Neuromorphic computing and beyond,” (No Title) , 2020

work page 2020

[4] [4]

The landscape of parallel computing research: A view from berkeley,

K. Asanovic, R. Bodik, B. Catanzaro, J. Gebis, P. Husbands, K. Keutzer, D. Patterson, W. Plishker, J. Shalf, and S. W. Williams, “The landscape of parallel computing research: A view from berkeley,” 2006

work page 2006

[5] [5]

Optimization principles and application performance evaluation of a multithreaded gpu using cuda,

S. Ryoo, C. I. Rodrigues, S. S. Baghsorkhi, S. S. Stone, D. B. Kirk, and W.-m. W. Hwu, “Optimization principles and application performance evaluation of a multithreaded gpu using cuda,” in Proceedings of the 13th ACM SIGPLAN Symposium on Principles and practice of parallel programming , 2008, pp. 73–82

work page 2008

[6] [6]

A survey of cpu-gpu heterogeneous computing techniques,

S. Mittal and J. S. Vetter, “A survey of cpu-gpu heterogeneous computing techniques,” ACM Computing Surveys (CSUR) , vol. 47, no. 4, pp. 1–35, 2015

work page 2015

[7] [7]

Openmp: an industry standard api for shared-memory programming,

L. Dagum and R. Menon, “Openmp: an industry standard api for shared-memory programming,” IEEE computational science and engineering , vol. 5, no. 1, pp. 46–55, 1998. 10 M. Q. ANSARI AND M. Q. ANSARI

work page 1998

[8] [8]

CUDA C Programming Guide,

NVIDIA Corporation, “CUDA C Programming Guide,” 2024, version retrieved in July 2025. [Online]. Available: https://docs.nvidia.com/cuda/cuda-c-programming-guide/index.html

work page 2024