{"id":"126b163e-63e6-4d18-a64f-84dd5a4bec67","arxiv_id":"2507.20063","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":3.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"An empirical measurement on one consumer laptop finds the discrete GPU used about 2% of the CPU's energy on a 4096x4096 matrix multiply, demonstrating the race-to-idle effect.","lead":"This paper measures how much time and energy a CPU, a discrete GPU, and an integrated GPU inside one laptop use to multiply two 4096 by 4096 matrices. The discrete GPU finishes fastest and uses the least total energy, while the CPU is the slowest and consumes the most energy overall.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The CPU baseline in Appendix A.1 is a cache-hostile, unvectorized OpenMP loop; a tuned BLAS run would likely erase most of the reported 93.5x time and 50x energy ratios.","rationale":"Reader's weakest_assumption identifies the naive-kernel issue, and I agree; it is the most load-bearing concern. The claimed numbers are central: the abstract quantifies 93.5x, 50x, and 2% energy, and Section 5.2 frames them as practical validation of race to idle. Appendix A.1 shows the CPU code is a naive i-j-k loop with a strided B access; the observed 2.4 GFLOPS is far below the machine's capability. Replacing the CPU kernel with OpenBLAS/MKL is a single concrete check that would settle whether the ratios survive. The secondary measurement issues (single run, 10 Hz NVML sampling) affect precision but not the order-of-magnitude conclusion; the kernel-representativeness issue can change the order of magnitude. The qualitative direction (dGPU faster, likely more efficient) is plausible and consistent with prior work, so I do not reject the paper; I keep the conditional verdict pending this check. Thus no adjustment to the reader's verdict is needed.","tokens_in":12511,"tokens_out":6180,"duration_ms":66107,"concrete_test":"Reproduce Table 1 with a tuned CPU SGEMM: link the same 4096x4096 single-precision multiply against OpenBLAS or Intel MKL (or use Eigen with -O3 -march=native), measure time and RAPL energy-pkg over at least 10 runs, and separately run cuBLAS SGEMM on the GTX 1650 with NVML power capture. If the OpenBLAS/MKL run completes in less than about 2 s and uses less than about 100 J (instead of 57.34 s and 1417.89 J), the abstract's ratios fail and Section 5.2's energy comparison must be rewritten. If the tuned CPU run remains above about 30 s, the concern does not land.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 4's central quantitative claim is an architectural comparison, but the CPU side of the comparison (Appendix A.1, Listing 1, lines 16–25) is not representative of what the Ryzen 7 5800H can do. The inner loop reads B column-wise with stride N from row-major storage, has no tiling or register blocking, is not vectorized, and is compiled without -march=native. At 57.34 s, the 137.4 GFLOP workload achieves only about 2.4 GFLOPS. A tuned OpenBLAS/MKL SGEMM on the same CPU can plausibly run hundreds of GFLOPS and finish in well under a second, with package energy on the order of tens of joules rather than 1417.89 J. Thus the 'race to idle' result is not yet established as an architectural property: it may be an artifact of comparing an unoptimized CPU loop against GPU kernels. If the CPU were tuned, the 93.5x and 50x headline ratios and the 'dGPU consumes 2% of the CPU energy' statement would change materially; the dGPU could even lose the energy comparison. The paper's own appendix therefore undermines the strongest claim until a tuned CPU baseline is run.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper reports a direct empirical comparison of execution time and energy-to-solution for a 4096x4096 single-precision dense matrix multiplication on three compute units in one consumer laptop: an AMD Ryzen 7 5800H CPU running OpenMP, an NVIDIA GTX 1650 dGPU running CUDA, and an AMD Radeon Vega iGPU running OpenCL. The authors report a 93.5x speedup and a 50x energy-efficiency improvement for the dGPU over the CPU (28.33 J vs. 1417.89 J), a 27.3x speedup for the iGPU, and interpret the results as a practical validation of the 'race to idle' principle. CPU energy is measured with RAPL via perf, dGPU energy by integrating nvidia-smi power samples, and iGPU energy from whole-package RAPL during an iGPU-offloaded run. The paper concludes that GPU offloading is an energy-conservation strategy for data-parallel workloads and that the discrete GPU is the optimal component on this platform for this workload.","tokens_in":12734,"tokens_out":5037,"duration_ms":49832,"significance":"The paper has a clear, reproducible experimental design with complete source code in Appendix A, uses standard tools (perf/RAPL, NVML), and directly measures time and energy rather than relying on models. The qualitative observation that a high-power but fast device can have lower energy-to-solution than a low-power but slow device is arithmetically sound and is a useful illustration of the 'race to idle' principle. However, the paper's headline quantitative claims—the 93.5x speedup and 50x energy advantage—are not established as architectural properties because the CPU baseline is a cache-hostile, unvectorized OpenMP loop that is not representative of the Ryzen 7 5800H's achievable SGEMM performance. The measurement protocol also has important gaps (low-rate dGPU power sampling with mismatched time bases, whole-package iGPU energy without idle subtraction, and no repeat runs). If the CPU baseline were replaced by a tuned BLAS implementation, the reported ratios would change materially and the energy ranking could even be affected. The paper is therefore a useful case study of naive implementations, but not yet a valid architecture-level comparison.","major_comments":[{"comment":"The CPU baseline is not representative of what the Ryzen 7 5800H can achieve for this workload. The inner loop reads element b[k*size + j] with a fixed column j, so the access pattern strides through memory with a stride of N elements; there is no tiling, register blocking, or vectorization beyond what -O3 provides, and the code is compiled without -march=native. At 57.34 s for 137.4 GFLOP, this is about 2.4 GFLOPS, whereas a tuned OpenBLAS or MKL SGEMM on the same CPU can plausibly sustain hundreds of GFLOPS and finish in well under a second. Because the abstract and Sections 4 and 5 present the 93.5x speedup and 50x energy-efficiency ratio as architectural findings, this single unoptimized implementation is load-bearing. The paper needs to rerun the CPU side with an optimized BLAS routine (or at least a properly cache-blocked and vectorized kernel) and report the resulting time and package energy, or explicitly reframe all quantitative claims as comparisons of the specific naive code versions rather than of the architectures. Until this is done, the central claim is not supported.","section":"Appendix A.1, Listing 1, lines 16-25"},{"comment":"The dGPU power measurement uses nvidia-smi polling at 10 Hz, but the kernel runs for only 0.613 s, so the energy integral is based on at most about six power samples. The uncertainty of trapezoidal integration over such a short interval is not quantified. In addition, the 0.613 s time is measured with CUDA events and covers only the kernel, while the energy is presumably integrated over the wall-clock time of the surrounding shell-script invocation, which includes memory transfers and launch overhead. The paper should specify the exact sampling window, use a higher-rate NVML sampling loop (or measure device energy directly with CUDA/NVML APIs), and ensure that the time basis for the energy integral matches the reported execution time.","section":"Section 3.4, dGPU Measurement"},{"comment":"Both the CPU and iGPU energy values are obtained from the RAPL energy-pkg event, which measures the entire APU package, not the individual compute unit. For the iGPU run, the paper reports 30.05 J as the 'energy-to-solution' of the Radeon Vega, but this includes the CPU cores and uncore, which are described as 'largely idle' but are not measured or subtracted. The same issue affects the CPU measurement, which includes the iGPU and memory controller. The paper should report idle package power over the relevant interval and subtract it, or report the values as whole-package energy and discuss the implications for the dGPU comparison. Without this, the small energy margin between the dGPU (28.33 J) and iGPU (30.05 J) is not a reliable component-level comparison.","section":"Section 3.4, iGPU Measurement and CPU Measurement"},{"comment":"All results are single runs with no repeat measurements or error bars. The difference between the dGPU and iGPU energy-to-solution is only 1.72 J (28.33 vs. 30.05 J, about 6%), while the dGPU and iGPU times differ by 1.49 s. Run-to-run variance from thermal state, frequency scaling, and background activity could easily exceed this margin. The paper should report multiple repetitions with mean and standard deviation (or min/median) for time and energy, and state whether the observed dGPU/iGPU ranking is stable across runs.","section":"Section 4, Table 1"}],"minor_comments":[{"comment":"The compiler version is reported as g++ 12.4.0, but the kernel version and driver versions are listed; please also report the exact OpenMP runtime version and whether CPU frequency scaling (governor) was set to 'performance' or left at its default, since this affects both time and energy.","section":"Section 3.1"},{"comment":"The code listings have numerous spacing artifacts (e.g., 'co ll aps e' in Listing 1, 'D u ra ti on' in Listing 1, and 'd ur ati on' in Listing 3) that appear to be formatting artifacts but would prevent direct copy-paste compilation. The authors should host the exact source files in a public repository and reference it in the paper.","section":"Appendix A"},{"comment":"The statement 'Energy-to-solution is the product of average power and execution time (Energy = Power × Time)' is correct, but the paper should note that this identity is definitional rather than an empirical finding; the 'race to idle' explanation is a post-hoc interpretation, not a mechanism established by the measurements.","section":"Section 5.2"},{"comment":"The text says 'the dGPU consumed only 2% of the energy used by the CPU', but the table shows 28.33 J / 1417.89 J = 2.00%, so the claim is exact; please include the ratio in the table or a footnote for clarity.","section":"Section 4.2"}],"recommendation":"major_revision","confidential_remarks":"The manuscript is a straightforward empirical study with a serious fairness problem in the CPU baseline. The authors should be asked to rerun with an optimized CPU BLAS implementation and to tighten the power-measurement protocol before any claim about architectural energy efficiency is made. The paper's contribution is otherwise modest but could be useful as a reproducible case study if the comparisons are reframed as implementation-level rather than architecture-level. I would not reject it, but the current text overstates the conclusions."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Colleague,\n\nQuick take: the qualitative finding — a discrete GPU beats the CPU on both time and energy for a dense SGEMM on a consumer laptop — is almost certainly correct and consistent with prior work. But the specific ratios in the abstract (93.5x speedup, 50x energy saving, dGPU at 2% of CPU energy) are not supported by the measurement protocol. The CPU side of the comparison is a hand-written OpenMP triple loop that reads B column-wise with stride N, has no tiling, no vectorization, and was compiled without -march=native. It achieves about 2.4 GFLOPS on a Ryzen 7 5800H. A tuned OpenBLAS or MKL SGEMM would plausibly finish in well under a second and use tens of joules rather than 1417.89 J. So the headline ratios are a comparison of an unoptimized CPU against GPU kernels, not an architectural property.\n\nWhat the paper does well: it gives a clean three-way CPU/dGPU/iGPU comparison on one system, uses standard power measurement tools, reports the whole-package iGPU limitation honestly, and ships complete source code in the appendix. That transparency is real and useful, and it's why the flaw is even visible. The race-to-idle explanation itself is sound as a mechanism, and the qualitative ordering (dGPU most efficient, iGPU close behind, CPU far worse) would probably survive a tuned CPU baseline — though the margin could shrink a lot, and the dGPU could even lose the energy comparison against a well-tuned CPU if the CPU finishes fast enough.\n\nOther soft spots, in ascending order: no repeat runs or error bars; nvidia-smi polling at 10 Hz over a 0.613 s kernel gives only a handful of samples for the energy integration; the iGPU energy is whole-package with no idle baseline subtracted; and there's no check that the result matrices are actually correct. The last one is minor. The CPU baseline is the load-bearing issue.\n\nWho's this for? Energy-aware software developers and systems folks who want a reproducible data point on common hardware. As it stands, I'd tell the authors to rerun with a tuned CPU BLAS, add repetitions and error bars, and then the paper becomes a solid brief empirical note. It's worth one round of serious referee attention, not a desk reject, because the methodology is transparent and the fix is straightforward. If you're tempted to cite the 93.5x and 50x numbers, don't cite them yet.","headline":"Qualitative GPU-beats-CPU finding is almost certainly right, but the specific 93.5x/50x ratios rest on a deliberately unoptimized CPU baseline that a tuned BLAS would erase.","tokens_in":13364,"tokens_out":2825,"would_cite":false,"duration_ms":26707,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":["68W10","65Y05","68M20"],"pacs":[],"model":"deepseek-v4-flash","headline":"On one consumer laptop, the discrete GPU multiplied two 4096x4096 matrices 93.5x faster than the CPU and consumed 50x less energy, demonstrating the race-to-idle principle.","keywords":["High-Performance Computing","GPU","CUDA","OpenMP","Matrix Multiplication","Parallel Computing","Energy Efficiency","Heterogeneous Systems"],"falsifier":"Run the same 4096x4096 single-precision multiplication on the CPU with a cache-blocked kernel or a vendor-tuned GEMM library; if the CPU's time falls far below 57.34 s and its energy below 1417.89 J, the reported speedup and energy ratios no longer describe the architectures' true capabilities.","tokens_in":12319,"feed_emoji":"⚡","tokens_out":10296,"duration_ms":86818,"temperature":0.7,"pith_summary":"This paper measures the time and energy a single consumer laptop needs to multiply two 4096x4096 single-precision matrices on its three compute units: an 8-core AMD CPU, a discrete NVIDIA GPU, and an integrated AMD GPU. The central claim is that the discrete GPU wins on both metrics, finishing in 0.613 seconds versus 57.34 seconds for the CPU (a 93.5x speedup) and consuming 28.33 joules versus 1417.89 joules (roughly a 50x energy-efficiency advantage). The explanation offered is the 'race to idle' principle: the dGPU draws the most power while active (46.22 W) but returns to idle so quickly that its total energy is the lowest. The practical point is that for a compute-bound kernel like matrix multiplication, hardware choice can move energy use by about two orders of magnitude.","feed_headline":"GPU races to idle: 93.5x faster, 50x less energy than CPU","feed_subtitle":"A consumer laptop shows the fastest GPU also uses 50x less energy than the CPU for matrix multiply.","key_machinery":"The central object is the dense 4096x4096 single-precision GEMM kernel, used as a canonical compute-bound workload. The mechanism that carries the argument is the energy-to-solution identity $E = P \\times t$ applied through the 'race to idle' principle: the architecture that finishes first and drops quickly to a low-power idle state minimizes total energy even when its active power draw is the highest. The supporting machinery is the measurement setup—Linux perf with the RAPL package-energy counter for CPU and iGPU, nvidia-smi polling for the dGPU, and event-based timing inside each benchmark.","core_discovery":"In a head-to-head run of a 4096x4096 single-precision dense matrix-matrix multiplication (GEMM) on one laptop, the paper's measurements give the discrete NVIDIA GPU the win on both axes: 0.613 s and 28.33 J versus the CPU's 57.34 s and 1417.89 J, a 93.5x speedup and roughly 50x lower energy-to-solution. The integrated AMD GPU lands between at 2.10 s and 30.05 J. Average power tells the opposite story: the dGPU draws the most (46.22 W), the iGPU the least (14.31 W), with the CPU at 24.73 W. The authors interpret this as a demonstration that energy is the product of power and time, so a high-power unit that finishes fast and returns to idle can beat a low-power unit that keeps grinding.","pith_inferences":["Beyond the paper's single matrix size, the race-to-idle logic suggests the energy ranking could shift for smaller matrices, where kernel launch and data-transfer overhead make the dGPU's fast execution less dominant.","Because the iGPU's energy was measured as whole-APU package energy while the CPU cores sat mostly idle, a direct iGPU power sensor would likely assign the iGPU even less energy, making its 30.05 J a conservative upper bound.","An untested corollary is that splitting the matrix between the CPU and dGPU could beat the dGPU alone on energy for some sizes, trading a little runtime to keep the CPU cores useful rather than idle.","The authors' data imply an easy extension: sweep matrix sizes and arithmetic intensities to find the crossover point where the CPU's moderate power or the iGPU's low power starts to beat the dGPU's race-to-idle."],"forward_implications":["For compute-bound dense linear algebra on consumer-class hardware, offloading to a discrete GPU is an energy-saving move, not just a speed-saving one.","The highest-power component can be the most energy-efficient when it finishes first, so energy-aware scheduling should minimize time-to-idle rather than simply minimize wattage.","The integrated GPU's low average power (14.31 W) does not make it the energy winner, because its longer runtime (2.10 s versus 0.613 s) raises its total energy above the dGPU's.","The paper's 93.5x and 50x ratios are platform- and workload-specific; the authors explicitly note that integer-heavy or memory-bound tasks could change which architecture wins."],"supporting_citations":[{"why":"Validates RAPL-based energy measurement as accurate and low-overhead, the method behind the CPU and iGPU energy numbers.","marker":"[2]"},{"why":"Frames dense linear algebra as a canonical high-performance computing kernel and motivates the choice of GEMM as the workload.","marker":"[4]"},{"why":"Supplies the power-characterization approach for comparing CPU and GPU nodes that this study adapts to a single laptop.","marker":"[5]"},{"why":"Shows an integer-heavy workload where the GPU is least efficient, bounding how far the dGPU advantage generalizes.","marker":"[6]"},{"why":"Demonstrates a different matrix-multiply energy-efficiency result on a specialized system-on-chip, providing a contrast case.","marker":"[11]"},{"why":"Offers the analytical heterogeneous energy model that the paper says its empirical results validate.","marker":"[14]"}],"fun_headline_variants":["Fastest GPU also most energy-efficient for matrix multiply","93.5x speedup, 50x less energy: GPU wins both metrics","Race to idle: fast GPU saves energy despite higher power draw","For matrix multiply, fastest GPU uses 50x less energy than CPU","Discrete GPU wins speed and energy in laptop GEMM"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The paper assumes the three hand-written kernels in the appendix are representative of each processor's capability for this workload; the CPU baseline in particular is a naive loop with poor cache behavior, so the headline ratios depend on that choice.","fun_headline_variants_meta":{"raw":{"variants":["Fastest GPU also most energy-efficient for matrix multiply","93.5x speedup, 50x less energy: GPU wins both metrics","Race to idle: fast GPU saves energy despite higher power draw","For matrix multiply, fastest GPU uses 50x less energy than CPU","Discrete GPU wins speed and energy in laptop GEMM"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.001238,"raw_usage":{"total_tokens":5110,"prompt_tokens":1003,"completion_tokens":4107,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":619,"completion_tokens_details":{"reasoning_tokens":4017}},"tokens_in":619,"tokens_out":4107,"duration_ms":24694,"temperature":1.0,"reasoning_tokens":4017,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-15T17:50:37.568174+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the same 4096x4096 single-precision multiplication on the CPU with a cache-blocked kernel or a vendor-tuned GEMM library; if the CPU's time falls far below 57.34 s and its energy below 1417.89 J, the reported speedup and energy ratios no longer describe the architectures' true capabilities.","supporting_citations":[{"cited_title":"Rapl in action: Experiences in using rapl for power measurements","cited_arxiv_id":null,"evidence_quote":"Validates RAPL-based energy measurement as accurate and low-overhead, the method behind the CPU and iGPU energy numbers."},{"cited_title":"The landscape of parallel computing research: A view from berkeley, 2006","cited_arxiv_id":null,"evidence_quote":"Frames dense linear algebra as a canonical high-performance computing kernel and motivates the choice of GEMM as the workload."},{"cited_title":"Performance and power analysis of hpc workloads on heterogeneous multi-node clusters","cited_arxiv_id":null,"evidence_quote":"Supplies the power-characterization approach for comparing CPU and GPU nodes that this study adapts to a single laptop."},{"cited_title":"Evaluating the efficiency of cpus, gpus and fpgas on a near-duplicate document detection via opencl","cited_arxiv_id":null,"evidence_quote":"Shows an integer-heavy workload where the GPU is least efficient, bounding how far the dGPU advantage generalizes."},{"cited_title":"Analytical modeling of energy efficiency in heterogeneous processors.Computers & Electrical Engineering, 39(8):2566–2578, 2013","cited_arxiv_id":null,"evidence_quote":"Offers the analytical heterogeneous energy model that the paper says its empirical results validate."}],"review_version":1}