PaperlayerView exact revision on arXiv

Source-linked AI summary

Closing the Prediction Gap: Completing Machine Shape So That Predicted Time, Power, Energy, and Mapping Match What Real Hardware Does

Lenore Mullin, Gaetan Hains

arXiv:2610.03197v1cs.DC

TL;DR

The companion paper’s real-hardware checks revealed missing machine-shape fields behind prediction gaps in precision-dependent performance and memory capacity. This paper indexes five additional fields and introduces reached(d) to capture whether compiled code dispatches to specialized hardware. It reports closing all five fields across the companion ensemble’s five devices.

  • Problem

    The companion paper’s hardware checks exposed missing machine-shape fields, including specialized-unit reachability and memory-reservation overhead that had not been indexed or measured.

    Source: §I · p. 1, B. The two real findings this paper… · p. 3

  • Method

    The paper adds five ψ-selectable machine-shape fields and separates hardware execution-unit capability from compiled-kernel reachability.

    Source: B. The two real findings this paper… · p. 3

  • Results

    All five fields are reported closed for the five devices in the companion ensemble, through direct measurement or stated construction and reachability evidence.

    Source: §XIV · pp. 20–21, §XVI · pp. 21–22

  • Takeaways & Limitations

    The paper gives the added quantities formal positions in machine shape and identifies the equations they complete, turning previously assumed or unindexed quantities into device-specific fields.

    Source: §XVI · p. 21

    Indexing reservation overhead does not determine its value for a device; the paper says that value requires real-hardware measurement.

    Source: E. Rd: memory-reservation overhead · p. 9

Abstract

from arXiv · show

A companion paper derives a weighted, communication free partition for heterogeneous, multi institution device ensembles from each device measured shape, rho_machine(d), validated on real hardware. Its experiments show rho_machine is incomplete: fp32 to fp16 speedup and power shifts are not fully indexed, and memory capacity predictions rely on an assumed, not measured, reservation overhead. This paper closes that gap, indexing five unmeasured fields in the psi selection vocabulary: memory capacity $M_i^{cap}$, power draw $P_i$, execution unit capability $X_d$, compiler directive configuration $C_d$, and memory reservation overhead $R_d$. We introduce reached(d), a Boolean for whether compiled code dispatches to specialized hardware, explaining the NVIDIA fp16 power shift that hardware availability alone cannot predict. MoA fixes a computation independently of its target, so compiler directives get a two part admissibility criterion: select a real hardware quantity without discretionary reordering, and be deterministic, not compiler overridable. Across Intel, AMD, NVIDIA, OpenMP, OpenACC, and Open MPI, this admits only cache placement controls, deterministic vector or tile widths, and occupancy caps; heuristics like autotuning are excluded and absorbed into a residual epsilon$(k)_d$. We validate on five devices: A100, H100, V100, MI100, and Max 1550, measuring or establishing all five fields on each. Reachability proves real but partial, occupancy limits are device specific, and reservation overhead ranges about 0.004 to 0.030. A residual of negative 9.8 percent for the excluded Triton autotuner shows an unvalidated heuristic can act opposite a presumed penalty. These results close all five fields for every device in the companion ensemble, converting assumed behavior into measured, target specific quantities.

I. INTRODUCTION

The companion paper’s hardware checks exposed missing machine-shape fields behind prediction errors; this paper formalizes those fields and extends the theory. MoA derives target-specific code from one target-independent specification, while the paper identifies specialized-hardware reachability as key to the observed precision-dependent results.

I. INTRODUCTION

  • The companion paper’s measured prediction errors show that machine shape lacks load-bearing fields, motivating this paper’s effort to close those gaps in the equations.The companion checked predicted time, memory ceiling, and energy against measured hardware; two checks were wrong.Source: §I · p. 1

A. MoA in Brief: From Array Data to Machine Shape

  • MoA expresses a computation once as a target-independent DNF and mechanically rewrites it into a device-specific ONF; kernels in this work use ONF code.The rewrite uses algebraic identities rather than hand tuning.Source: A. MoA in Brief: From Array Data to… · p. 2
  • The paper adds five ψ-selectable machine-shape fields, including memory capacity, power, execution-unit capability, compiler directives, and memory reservation overhead.It gives these quantities formal index positions and derives predictions from them, rather than leaving them folded into existing fields or unindexed assumptions.Source: A. MoA in Brief: From Array Data to… · pp. 2–3

B. The two real findings this paper closes

  • 14.7× NVIDIA fp32-to-fp16 speedup and a 36.3% power-draw increase contrast with 1.05× Intel speedup and power shifts below 1% on Intel and AMD.The reported difference is associated with NVIDIA’s kernel reaching tensor cores, while the portable OpenMP realizations on Intel and AMD did not reach specialized low-precision hardware.Source: B. The two real findings this paper… · p. 3
  • The new reached(d) quantity distinguishes hardware availability from whether a compiled kernel actually dispatches to that hardware, separating device capability from realization and compiler configuration.The companion paper’s fields did not identify whether the compiled kernel reached specialized units.Source: B. The two real findings this paper… · p. 3
  • Memory-reservation overhead was previously assumed, not measured; a corrected zero value on one device did not establish a general per-device value.The paper indexes overhead as a device-specific field rather than assuming a constant across devices.Source: B. The two real findings this paper… · p. 3

C. What this paper does and does not claim

The paper reports closing the five added machine-shape fields across the companion ensemble and contrasts its derivation-based account with search-based tuning and performance bounds. Its background explains how the additions extend, rather than replace, the companion paper’s original fields.

C. What this paper does and does not claim

  • All five added fields are closed for the five devices in the companion ensemble; the paper reports measuring or establishing them on real hardware.The devices are A100, MI100, H100, V100, and Intel Max 1550; the H100 and V100 experiments use a vendor-neutral OpenACC realization.Source: C. What this paper does and does not… · p. 3

II. RELATED WORK: WHY A FORMAL, DETERMINISTIC ACCOUNT OF MACHINE SHAPE

  • MoA derives admissible deterministic configurations rather than searching schedules as Halide, TVM, and Ansor do.The paper distinguishes fixed, documented settings from heuristic choices that compilers or autotuners may override.Source: §II · p. 4
  • The paper presents machine-shape measurements and compiled-kernel reachability as inputs to specific time, power, and memory-ceiling predictions that are checked against direct hardware measurements.This differs from Roofline’s performance bound, which does not establish whether a compiled kernel reaches the execution units assumed by peak figures.Source: §II · p. 4
  • The paper’s stated novelty is explaining compiled-kernel behavior from measured hardware facts without per-kernel search; reached(d) is read from profiling or disassembly.The discussion associates this account with a 36.3% power-draw shift and a 14.7× speedup where reachability is nonzero, and zero shift where it is measured zero.Source: §II · p. 5

III. BACKGROUND: THE FIVE-FIELD THEORY, AND WHERE IT WAS ALREADY SHOWN INCOMPLETE

  • The companion paper’s original machine shape indexes five fields and supports weighted partitioning, predicted finish time, memory ceiling, and energy.This paper adds five fields to the existing tuple rather than replacing it; the new fields include total memory capacity, power draw, execution-unit type, compiler directives, and memory-reservation overhead.Source: §III · pp. 5–6

IV. THE FIVE FIELDS, FORMULATED

The formulation adds five fields to machine shape and identifies the companion-paper equation each field completes. It distinguishes total device memory capacity from on-chip shared memory and makes the capacity value a device-indexed input.

IV. THE FIVE FIELDS, FORMULATED

  • M_i^cap is total device memory capacity, distinct from M_d, the much smaller per-block shared-memory quantity that governs occupancy.Indexing M_i^cap changes the provenance of the companion paper’s Equation 39 input, not its arithmetic: γ reads a device-specific field rather than a hand-substituted number.Source: §IV · p. 6
  • Table II pairs the five added machine-shape fields with the companion-paper equations each completes.The additions extend the existing tuple rather than replacing its original fields.Source: Table II · p. 6, §IV · p. 6

B. Pd: power draw, indexed by realization, not device alone

Measured power can differ by precision and compiled realization, so power predictions must account for which execution path the realization reaches. The compiler configuration is admissible only when it selects a real hardware quantity deterministically, rather than leaving the outcome to compiler discretion.

B. Pd: power draw, indexed by realization, not device alone

  • NVIDIA power rises from 143.30 W (fp32) to 195.30 W (fp16), while Intel and AMD power is flat across precision within measurement noise.The cited explanation attributes NVIDIA’s increase to its Triton realization engaging more tensor-core silicon per cycle at fp16.Source: B. Pd: power draw, indexed by… · p. 6
  • Power must be understood per compiled realization, not as a fixed device constant that can be assumed to transfer across kernels.The passage links power’s reliability to the measured realization, for the same reason as execution time.Source: B. Pd: power draw, indexed by… · p. 7
  • The device’s specialized execution units describe what hardware exists, but the compiled realization determines whether a kernel reaches those units.The paper distinguishes hardware capability from whether a particular kernel dispatches to it.Source: C. Xd: execution-unit capability · p. 7
  • Compiler configuration is admissible only when it selects a real hardware quantity without discretionary reordering and the written directive deterministically matches compiler behavior.Compiler heuristics that can be overridden or reinterpreted do not provide a known relationship between the setting and measured execution.Source: D. Cd: compiler-directive… · pp. 7–8

V. reached(d): THE INTERACTION Xd AND Cd ALONE CANNOT STATE

Hardware capability and compiler configuration alone do not say whether a compiled realization uses specialized execution units. The paper adds reached(d), which distinguishes available hardware from the execution path actually taken and makes time and power realization-specific.

V. reached(d): THE INTERACTION Xd AND Cd ALONE CANNOT STATE

  • Whether a realization reaches a specialized execution path is a joint fact about Xd and Cd that neither field predicts on its own.This interaction is identified as necessary to predict fp16 speedup and power-draw asymmetry.Source: §V · p. 9
  • reached(d) records whether compiled code dispatches to specialized hardware, as a Boolean or, for partial engagement, a degree in [0, 1].The paper says to read it from profilers rather than infer it from precision alone.Source: §V · p. 9
  • The time and energy equations keep their form, but ti and Pi depend on reached(di) and on which realization was measured.They are no longer treated as fixed per-device constants assumed to transfer to a new kernel.Source: §V · p. 9

VI. A SURVEY OF WHAT THREE REAL TOOLCHAINS EXPOSE, SCORED AGAINST THE ADMISSIBILITY CRITERION

The survey applies the paper’s two-part compiler-directive admissibility test to vendor toolchains and separates deterministic, shape-associated quantities from discretionary or heuristic settings. Its verdicts identify what is allowed, not which fields have been measured on the devices in the ensemble.

VI. A SURVEY OF WHAT THREE REAL TOOLCHAINS EXPOSE, SCORED AGAINST THE ADMISSIBILITY CRITERION

  • A directive is admissible only if it selects a real hardware quantity without discretionary reordering and deterministically specifies what the compiler does.The survey describes the test as shape association plus a deterministic directive, excluding compiler-overridable heuristic enables.Source: §VI · pp. 9, 11, Table III · p. 11
  • The survey checks Intel, AMD, and NVIDIA toolchains against their vendors’ documentation, applying the same criterion rather than inferring verdicts from observed behavior.The surveyed toolchains are those the companion experiments ran on real hardware.Source: §VI · pp. 9–10
  • ISA targeting is conditionally admissible when paired with an anti-contraction flag that independently pins rounding behavior.Without that pairing, FMA contraction can silently reassociate a reduction.Source: §VI · p. 10
  • A K verdict means admissible, not measured: only cache placement, vector/tile width, and occupancy cap were closed on real hardware in the companion ensemble.Other K rows surfaced by the survey remain outside the structured record for the devices measured in this ensemble.Source: §VI · pp. 9–10

A. Autotuning: admissible only over the restricted subset

The paper applies the same shape-associated and deterministic-directive test to autotuning and to OpenMP, OpenACC, and MPI. It admits fixed hardware choices while excluding settings whose realized behavior remains a compiler or runtime decision.

A. Autotuning: admissible only over the restricted subset

  • Autotuning may populate Cd only when its search fixes num_stages at its minimum and varies only tile shape and num_warps.The unrestricted search mixes admissible width quantities with software-pipelining depth, so it remains a diagnostic rather than a production configuration.Source: A. Autotuning: admissible only over… · pp. 11–12

VII. THE SAME CRITERION APPLIED BEYOND THE COMPILER: OPENMP, OPENACC, AND MPI

  • The same two-part criterion applies to source-level OpenMP, OpenACC, and MPI directives, not just compiler flags.The section carries the test from command-line settings to pragma APIs and communication-library choices.Source: §VII · p. 12, C. MPI: default collective selection… · p. 13
  • OpenMP admits fixed thread counts and static scheduling, while dynamic, guided, and auto scheduling leave work assignment adaptive or delegated.The SIMD construct is also excluded because its concurrent iteration count is implementation-defined and simdlen is only a preference.Source: A. OpenMP: thread count and static… · p. 12

B. OpenACC: parallel is a directive, kernels is not

  • OpenACC parallel clauses fix gang, worker, and vector configuration, but kernels may be split into differently configured accelerator kernels by the compiler.Thus the parallel construct with explicit clauses is admissible, while kernels is not.Source: B. OpenACC: parallel is a directive,… · p. 12

VII. THE SAME CRITERION APPLIED BEYOND THE COMPILER: OPENMP, OPENACC, AND MPI

  • MPI admits explicitly forced collective algorithms and fixed rank-to-core mappings, whereas default collective selection is heuristic.The companion partition is communication-free, so MPI is a next application of the criterion rather than a mechanism used by that ensemble.Source: C. MPI: default collective selection… · p. 12

D. What this confirms

The two-part directive test generalizes across toolchain classes, while excluded heuristics remain unknown and are measured as residuals against pinned baselines. The A100 experiment corrects measurement methods, finds precision-dependent reservation overhead, and shows tensor-core dispatch is real but partial.

D. What this confirms

  • The same two admissibility questions distinguish deterministic from heuristic directives across compiler flags, loop annotations, accelerator offload, and communication libraries.Excluded heuristic levers can still affect execution time; ε(k)_d measures their difference from a fully deterministic baseline with admissible fields pinned.Source: D. What this confirms · p. 13, E. ϵd: the residual once determinism… · pp. 13–14

VIII. REAL-HARDWARE VALIDATION: NCSA DELTA A100

  • 20-repeat windows over-measured A100 time by 20–25%: fp32 5.114 ms → 3.969 ms and fp16 0.346 ms → 0.265 ms at 2,000 repeats.At 20 repeats, the cumulative energy counter implied an impossible 1114 W; at 2,000 or more repeats, its average agreed with instantaneous readings within 1–2 W.Source: §VIII · p. 14
  • R_d was 0.500 at fp16 versus 0.250 at fp32, so the reservation-overhead fraction doubled rather than shrinking with the smaller dtype.The paper cautions that one device cannot establish whether this is general to reduced-precision execution or specific to this kernel and GPU generation.Source: §VIII · p. 14
  • Tensor-pipe active-cycle fractions of 20.73% and 20.74% confirm fp16 dispatch above the 0.55–0.56% noise floor, but leave the Boolean reached(d) formulation unresolved for partial use.The paper leaves open whether to retain a Boolean with a dispatch-fraction threshold or reformulate reached(d) as continuous.Source: §VIII · p. 14
  • Triton autotuning was repeatable across three paired runs and faster than the pinned baseline, opposite to an earlier differently conditioned measurement, so the residual’s sign is empirical.The paper treats this single A100 measurement as a proof of method, not completion; other excluded directive rows and devices remain unmeasured.Source: §VIII · pp. 14–15, E. ϵd: the residual once determinism… · p. 14

IX. REAL-HARDWARE VALIDATION: NCSA DELTA AMD MI100

The MI100 experiments establish that dispatch must be checked on live hardware and that occupancy settings must be re-derived for the chosen realization. They also replace an unusable energy-counter reading and directly bracket memory reservation overhead.

IX. REAL-HARDWARE VALIDATION: NCSA DELTA AMD MI100

  • Three MI100 allocations silently ran host code, producing a plausible 23.5 s timing; live GPU utilization at 0% exposed the fallback before reported timings were accepted.The architecture-mismatched code object did not dispatch, despite correctness passing and compilation succeeding; timings in Table VI were confirmed with live utilization above 0%.Source: §IX · p. 15

B. Occupancy-cap is realization-specific, not device-specific

  • At occupancy-cap 32, the admissible vector_size realization measured 446.377 ms fp32 (453.149 ms on rerun), versus 1432.250 ms at cap 10.The companion simdlen baseline at cap 10 reproduced within 1.3% for fp32 and 0.1% for fp64; the identical cap was wrong by a factor of three for vector_size on the same device.Source: B. Occupancy-cap is… · p. 15, §IX · p. 15

C. Pd: resolved via an independent-method substitution

  • The cumulative energy counter returned zero across nearly nine seconds of confirmed GPU load, so MI100 power was instead measured from instantaneous polling: 142.8 W fp32 and 136.2 W fp16.The independent readings were consistent across two runs and within the device’s approximately 300 W TDP.Source: C. Pd: resolved via an… · p. 15
  • MI100 memory capacity was read as 34,342,961,152 B, and the directly bracketed fp32 reservation overhead was approximately 0.013, below H100’s independently measured approximately 0.030.The MI100 boundary bracket placed correctness-pass cases through N = 33,100,000 and failures at N = 33,300,000 and 33,450,000.Source: C. Pd: resolved via an… · p. 16

E. The flat AMD fp16 result holds under the admissible realization

The admissible vector_size realization reproduces the companion paper’s flat AMD fp16 result after occupancy is retuned. H100 measurements show a different occupancy outcome, while direct profiling confirms no tensor-core dispatch in its fp64-only realization.

E. The flat AMD fp16 result holds under the admissible realization

  • At the tuned, dispatch-confirmed occupancy-cap, MI100 fp16 measured 447.357 ms against fp32’s 453.149 ms, a 1.3% difference within measurement noise.The admissible vector_size realization at its own re-derived occupancy-cap reproduces the companion paper’s flat AMD result, rather than making that result an artifact of simdlen.Source: E. The flat AMD fp16 result holds… · p. 16
  • MI100’s rocprofv3 tracing triggered a GPU memory-access fault, so the paper used disassembled device code to establish X_d = 0, with 169 ordinary FMA opcodes and no matrix-core opcodes.The fault was absent from unprofiled runs of the identical binary.Source: E. The flat AMD fp16 result holds… · p. 16

X. REAL-HARDWARE VALIDATION: PSC BRIDGES-2 H100

  • On H100, measured power was 135.05 W over utilization-confirmed active samples; direct Nsight Compute profiling found 0% tensor-pipe activity for the fp64-only realization.The H100 memory boundary gave R_d ≈ 0.030; its memory capacity was read directly from nvidia-smi rather than assumed from nominal specification.Source: §X · pp. 16–17, A. Occupancy-cap, checked rather than… · p. 17

A. Occupancy-cap, checked rather than assumed: flat on H100, unlike MI100

  • H100 timing varied by under 1% across the swept occupancy settings, unlike MI100: its carried-over setting was already at or statistically indistinguishable from saturation.The minimum tied at (16, 16) and the paper-cited baseline (16, 32); the (32, 64) combination was skipped because 2,048 threads per block exceeds the 1,024-thread limit.Source: A. Occupancy-cap, checked rather than… · p. 17

XI. REAL-HARDWARE VALIDATION: SDSC EXPANSE V100

The V100 measurements independently close its power, memory-capacity, occupancy, reservation-overhead, and execution-unit fields. The Max 1550 results then show that occupancy, vector width, and power readings depend on the particular device and configuration.

XI. REAL-HARDWARE VALIDATION: SDSC EXPANSE V100

  • V100 utilization reached 100%, with average power of 131.69 W and directly read memory capacity of 34,359,738,368 B (32,768 MiB).Live polling confirmed GPU activity before timing, power, or memory-boundary results were trusted.Source: §XI · p. 17

A. Occupancy-cap: flat, as on H100

  • V100 timings spanned 60.405–63.059 ms, a 4.4% spread; the (16, 32) baseline was statistically indistinguishable from the minimum at (8, 64).The (32, 64) configuration was skipped because it exceeded the 1024-thread/block limit.Source: A. Occupancy-cap: flat, as on H100 · p. 17

B. Rd: memory boundary, an independent NVIDIA measurement

  • V100’s reservation overhead is close to H100’s independently measured 0.030 and noticeably larger than MI100’s 0.013, consistent with R_d being device-dependent rather than a reusable guessed correction.A six-point bracket located the boundary in one round: N ∈ {15,900,000, 16,100,000, 16,300,000} passed correctness, while N ∈ {16,500,000, 16,650,000, 16,750,000} failed.Source: B. Rd: memory boundary, an independent… · pp. 17–18

C. Xd: confirmed directly, without the workaround MI100 needed

XII. REAL-HARDWARE VALIDATION: TACC STAMPEDE3 INTEL MAX 1550

  • On Max 1550, memory capacity was read as 63.98 GiB; its vector_size configuration compiled unmodified with Intel’s Clang-derived toolchain.Table IX summarizes the Max 1550 field measurements and occupancy-cap sweep.Source: §XII · p. 18, Table IX · p. 18

A. Occupancy-cap: a plateau at 16, and a real admissible-width ceiling at vector_length=64

The Max 1550 measurements expose device-specific limits in occupancy, vector width, and memory reservation while closing its measured fields. Its execution-unit capability is instead established from the kernel’s construction because direct binary inspection was unavailable.

A. Occupancy-cap: a plateau at 16, and a real admissible-width ceiling at vector_length=64

  • At vector_length=16, num_workers=16, 32, and 64 had statistically indistinguishable timings, while num_workers=8 was nearly twice as slow.At tied worker counts, vector_length=16 was 3.1× faster than 32, while 64 caused reproducible segmentation faults; the pinned configuration was (16, 16).Source: A. Occupancy-cap: a plateau at 16, and… · p. 18

B. Pd: consistent across four confirmatory runs, plausible against the device’s per-tile power budget

D. Xd: zero by construction, not by static disassembly

  • X_d = 0 follows from the fp64 kernel’s vector arithmetic, which contains no matrix-engine-targeting construct.The missing Intel Graphics Compiler backend prevented the static-disassembly workaround, so this field was established by construction rather than direct measurement.Source: D. Xd: zero by construction, not by… · p. 19

E. Rd: memory boundary, the smallest overhead measured on any device in this paper

  • The Max 1550’s reservation overhead was the smallest measured in the ensemble, below A100’s 0.250, MI100’s 0.013, H100’s 0.030, and V100’s 0.028.The boundary was located by a passing kernel call at N=33,400,000 and an allocation failure at N=33,545,166; a counter wraparound near capacity did not affect the R_d measurement.Source: E. Rd: memory boundary, the smallest… · p. 19
  • The Max 1550 is the fifth device whose fields are closed; M_i^cap, C_d, and R_d were measured, P_d was read consistently, and reached(d) was confirmed directly.X_d was established from the kernel’s construction rather than direct measurement.Source: E. Rd: memory boundary, the smallest… · p. 20

XIII. ALL FIVE DEVICES, EVERY FIELD, IN ONE VIEW

Table X presents the five newly indexed fields across devices, and the discussion connects them to completing the companion paper’s time, memory, and energy predictions. The section reports direct measurement closure for all five devices in the ensemble.

XIII. ALL FIVE DEVICES, EVERY FIELD, IN ONE VIEW

  • Table X treats each device column as a restriction of machine shape, so per-device data slices correspond to per-device machine-shape columns.Its memory-capacity and reservation-overhead rows are precision-independent and directly comparable across the five devices.Source: §XIII · p. 20

XIV. DISCUSSION: WHAT THIS CLOSES, AND WHAT THIS DOES NOT

  • The new fields make the companion paper’s time, memory-ceiling, and energy predictions functions of a machine shape complete with respect to its experimentally surfaced gaps.This gives reachability a formal place rather than leaving it implicit in measured time.Source: §XIV · p. 20

XIV. DISCUSSION: WHAT THIS CLOSES, AND WHAT IT DOES NOT

  • All five newly indexed fields are closed by direct measurement across the five devices in the companion ensemble.The discussion describes the A100, MI100, H100, V100, and Intel Max 1550 results as full empirical progress.Source: §XIV · pp. 20–21
  • MI100’s memory reservation overhead is about 0.013, and its execution-unit capability is zero, established through static disassembly after profiler faults.The profiler check found zero matrix-core opcodes and a nonzero ordinary-FMA sanity check.Source: §XIV · p. 20
  • H100’s occupancy cap was already at saturation, unlike MI100’s 3× discrepancy; V100 also showed a flat occupancy-cap result and zero execution-unit capability.H100’s reservation overhead was about 0.030; V100’s was about 0.028, with Nsight Compute confirming its zero capability.Source: §XIV · p. 20
  • Intel Max 1550’s reservation overhead is about 0.004, the smallest measured, and its specialized-unit reachability was confirmed at 99.88% busy.The discussion says all five fields were closed for this device, using a construction argument for zero execution-unit capability.Source: §XIV · p. 21

XV. FUTURE WORK

The conclusion reports full five-field measurement closure across all five devices, while future work proposes further tests of the extended predictions and excluded heuristic effects. It also identifies controlled experiments that could distinguish hardware limits from implementation effects.

XV. FUTURE WORK

  • Future work proposes rerunning the companion paper’s predicted-versus-measured checks with the extended equations to test whether reached(d) closes the reported gap.It would also test whether reached(d) should be Boolean or continuous across devices.Source: §XV · p. 21
  • A controlled same-device, same-precision comparison of kernel implementations is proposed to distinguish a hardware ceiling from a realization gap.The proposed experiment would replace generic OpenMP target-offload with hand-written intrinsics or a vendor-tuned library.Source: §XV · p. 21
  • Future work would measure excluded heuristic levers with admissible fields fixed; the A100 covers only Triton autotuning on one device so far.Testing the remaining excluded rows across devices would quantify their error contribution after the closed-form fields are accounted for.Source: §XV · p. 21

XVI. CONCLUSION

  • Occupancy-cap outcomes differ by device: MI100 was 3× off, while H100 was already near-optimal and V100 showed the same flat result.This contrast supports checking the field rather than assuming it transfers across devices.Source: §XVI · pp. 21–22
  • Full five-field measurement now closes on all five devices, with device-specific findings spanning A100, MI100, H100, V100, and Intel Max 1550.The conclusion reports the A100 gap narrowing, MI100 closure, H100 and V100 measurements, and Max 1550 closure.Source: §XVI · pp. 21–22
  • On Max 1550, vector_length=64 reproducibly segfaulted; a narrower, faster working width avoided the failure.The conclusion identifies this as an admissible-width ceiling not surfaced by earlier devices in the ensemble.Source: §XVI · p. 22

Related papers

Loading 2610.03197v1…