Stencil Computation at the Intersection of AI and HPC

I. INTRODUCTION

• Stencil optimization evolved from multicore cache tiling to accelerator data movement and GPU parallelism, alongside AI-driven investment in tensor programming abstractions.The paper describes cache-blocking and loop tiling, explicit local-store transfers, and GPU shared-memory and warp-level techniques.Source: §I · p. 1
• Tensor compilers such as TinyTC and Triton expose tiling abstractions for AI workloads, while stencils share regular tiling and memory-access patterns suited to evaluation.Triton is described as a low-barrier Python DSL with multiple GPU backends.Source: §I · p. 1
• The evaluation compares TinyTC with PT/Triton, analyzes memory behavior and B580 compression, and measures cross-vendor PT/Triton portability trade-offs.TinyTC is framed as the architecture-specialized path and PT/Triton as the portability baseline.Source: §I · pp. 1–2

II. RELATED WORK

• Prior CPU work uses cache blocking and time skewing to reduce traffic, while GPU approaches use 2.5D or 3.5D blocking, register allocation, and shared-memory staging.A prior study examined the 25-point 8th-order acoustic stencil with PML boundaries on NVIDIA GPUs.Source: §II · p. 2
• Earlier tile-architecture foundations focused on other workloads; this work targets high-order stencils with boundaries and evaluates compiler-managed L1 caching against programmer-managed staging.TinyTC targets Intel L1/LSC, which the paper describes as larger than SLM on Battlemage and GPU MAX 1550.Source: §II · pp. 2–3

A. Stencil Computation

• The solver targets the acoustic isotropic 3-D wave equation used in seismic depth imaging, with large grids and many time steps for realistic simulations.The base code comes from the Minimod proxy application developed by TotalEnergies.Source: A. Stencil Computation · p. 3
• An 8th-order star-shaped discretization yields a 25-point 3-D stencil, applied to the inner pressure field with a Gaussian-wavelet source and to the PML region.The PML is 27 cells wide, based on the stated dominant source frequency and grid spacing.Source: A. Stencil Computation · p. 3
• The PML shell occupies roughly 19% of the 800^3 domain, leaving a 746^3 inner region; the PML kernel becomes negligible for larger production grids.Figure 1 depicts the inner region within the outer domain.Source: A. Stencil Computation · p. 3, Figure 1 · p. 3
• Separate kernels process the inner region and six PML subregions to avoid boundary branch divergence, and concurrent PML dispatch did not improve B580 throughput.The inner kernel alone saturates the available execution resources on that GPU.Source: A. Stencil Computation · p. 3
• Zero-initialized buffers can benefit from lossless B580 memory compression, but their compressibility declines as propagated information fills the grid; random data is incompressible from the start.Figure 2 tracks floating-point value distributions over time steps for a zero constant initialization.Source: A. Stencil Computation · pp. 3–4, Figure 2 · p. 4

B. TinyTC Tile Compiler

• TinyTC is an Intel-GPU tensor DSL/compiler whose hand-authored SSA IR is lowered to SPIR-V and follows an SPMD execution model.Its finer control over generated code comes with greater verbosity and a steeper learning curve than Triton.Source: B. TinyTC Tile Compiler · p. 4
• TinyTC cooperative tile operations specify shape, stride, and type, enabling 2D block loads that transfer rectangular regions to the LSC more efficiently than scalar or 1D-vectorized accesses.The 2D block-load instructions can clamp accesses to declared buffer extents, avoiding explicit mask logic.Source: B. TinyTC Tile Compiler · p. 4
• TinyTC kernels can be packaged as standard SYCL kernel bundles and dispatched through parallel_for within existing SYCL host code.The compiler parses the IR string, compiles it to SPIR-V, and creates the bundle.Source: B. TinyTC Tile Compiler · p. 4

C. Triton

• Triton launches a grid of program instances over tiles, using masked tl.load and tl.store operations to handle domain boundaries.Invalid masked loads use a supplied fill value rather than accessing out-of-bounds memory.Source: C. Triton · p. 4
• Triton expresses dimension iteration with tl.range, leaving scheduling, register allocation, and supported-backend software pipelining to the compiler.Although Triton can generate 2D block loads with tensor descriptors, the examined assembly did not show their use.Source: C. Triton · p. 5

IV. IMPLEMENTATION

• Work-groups sweep TX × TY × TZ tiles along X, with each tile’s TY × TZ extent treated as a 2D matrix in the LSC.A typical tile uses TX = 32, TY = 16, and TZ = 16.Source: §IV · p. 5
• Nine TY × TZ planes at x0 −4 through x0 +4 are kept in the register queue, letting the X Laplacian use those values without memory traffic.After each update, the oldest plane is dropped and the plane at k+5 is loaded.Source: §IV · p. 5
• Each step fetches eight Y- and eight Z-direction neighbor planes from global memory, with the LSC providing reuse across adjacent tiles.The Y/Z planes include ±1 through ±4 offsets; TinyTC loads them with halos, while Triton loads tile-sized planes and handles halos separately.Source: §IV · p. 5

A. TinyTC Kernel

• shape_gcd and stride_gcd annotations let TinyTC prove alignment requirements for 2D block loads, while foreach_tile assigns TZ × TY sub-tiles to subgroups.The excerpt specifies 4-, 16-, and 64-byte alignment requirements.Source: A. TinyTC Kernel · p. 5
• Checked cooperative matrix loads fetch the Z- and Y-direction neighbors, whose contributions are scaled and added to assemble the stencil.The result tile is written with cooperative_matrix_store.both_checked.Source: A. TinyTC Kernel · pp. 5–6
• The X-direction Laplacian is computed from a pre-filled register queue, which shifts by one plane per iteration without extra loads.The queue is initialized with planes around the current X position before the loop.Source: A. TinyTC Kernel · pp. 5–6

B. PT/Triton Kernel

• Triton’s per-element masked loads add instruction pressure across 2D tiles, especially when only the final tile along an axis is partially out of bounds.The adopted alternative shifts boundary checking to the store side and makes loads safe by construction.Source: B. PT/Triton Kernel · p. 6
• One extra tile of zeroed padding lets stencil-halo and X-queue loads land in allocated memory without masks, even when the final launched tile extends beyond the valid domain.The padding is at least one full tile wide.Source: B. PT/Triton Kernel · p. 6
• A validity mask is applied only at stores so computed values do not overwrite padding that later time steps may load.This “load wide, store narrow” strategy uses one extra BLOCK_Y × BLOCK_Z slice, negligible for the evaluated 800^3 grids; Fig. 4 depicts the approach used in PT/Triton.Source: B. PT/Triton Kernel · p. 6, Figure 4 · p. 6

C. SYCL Shared-Memory Kernel

• The SYCL reference uses shared-memory tiling for the inner kernel, while its damping kernel streams directly from main memory without tiling or data-reuse optimization.The inner-kernel tile is loaded into local_accessor shared memory and synchronized before a per-thread X-direction register window; accesses use scalar loads without inline 2D block-load assembly.Source: C. SYCL Shared-Memory Kernel · p. 6

D. OpenMP Offload Kernel

• The OpenMP target baseline offloads the nested-loop 25-point kernel with minimal code changes and no explicit shared-memory or register-queue optimization.It represents a low-effort GPU port and a lower bound for throughput against the specialized kernels.Source: D. OpenMP Offload Kernel · p. 6

V. EXPERIMENTAL SETUP

• The Intel Arc B580 is the primary evaluation target, with theoretical peak memory bandwidth of 450 GB/s.The passage identifies it as the only publicly available host for TinyTC at the time of writing.Source: §V · pp. 6–7
• Evaluation extends to Intel B70 and GPU MAX 1550, NVIDIA A100, RTX6000 Blackwell and H100, and AMD MI325x; TinyTC runs only on Intel GPUs, while PT/Triton runs on all GPUs.The GPU MAX 1550 platform result is in 1-tile mode, with 64 rather than 128 Xe cores active.Source: §V · p. 7, Table I · p. 7
• B580 lossless memory compression can raise effective bandwidth for repetitive data: the modified STREAM Triad reaches ≈840 GB/s at 1/128 random fill and ≈400 GB/s at full random fill.Compression was enabled on B580 and B70, disabled on GPU MAX 1550, and not characterized on NVIDIA or AMD GPUs.Source: §V · p. 7

A. Benchmark Results

• 35.8 vs 15.6 Gpts/s for TinyTC and 32.5 vs 13.5 Gpts/s for Triton (zero vs random initialization) show compression-sensitive throughput.SYCL falls from 20.2 to 12.2 Gpts/s and OMP from 8.9 to 7.8 Gpts/s; zero-initialized arrays compress more, while random data is incompressible.Source: Table III · p. 7, A. Benchmark Results · p. 7
• With random initialization, throughput is nearly steady across 1,000–4,000 steps; with zero initialization, TinyTC, Triton, and SYCL throughput declines as wave patterns emerge.For zero initialization, TinyTC drops from 35.8 to 23.8 Gpts/s, Triton from 32.5 to 21.5 Gpts/s, and SYCL from 20.2 to 16.1 Gpts/s; the strategies converge over many iterations.Source: A. Benchmark Results · p. 7

B. Connecting Roofline to End-to-End Performance

• All implementations are bandwidth-limited in Figure 5, making reduced memory traffic and efficient caching the primary paths to higher throughput.The plot compares arithmetic intensity with performance for inner and damping kernels against memory-bandwidth and peak-compute limits.Source: Figure 5 · p. 8, B. Connecting Roofline to End-to-End… · p. 8
• TinyTC and Triton sustain about 390 GB/s for the inner kernel and 360 GB/s for damping, near the 405 GB/s STREAM bandwidth.Triton reaches 393.4 GB/s for the inner kernel; the roofline measurements cover steady-state kernels under optimal initialization conditions.Source: Table IV · p. 8, B. Connecting Roofline to End-to-End… · p. 8
• TinyTC records 5.9 GB DRAM traffic and a 73.5% L3 hit rate, while Triton records 7.4 GB and a 70.0% LSC hit rate.The authors attribute the difference to TinyTC’s 2D block loads; Triton’s implementation omits tensor descriptors needed to emit these loads and runs 14% slower.Source: Table V · p. 8, B. Connecting Roofline to End-to-End… · p. 8
• The roofline analysis covers only 10 iterations, and the authors note that additional manual tuning could improve the SYCL results.Source: B. Connecting Roofline to End-to-End… · pp. 8–9
• The OMP kernel generates 16.7 GB of DRAM traffic and takes 46 ms, versus TinyTC’s 20 ms, serving as the lower-bound performance case.Source: B. Connecting Roofline to End-to-End… · p. 9

• At 1,000 steps under zero initialization, TinyTC reached 46.2 Gpts/s on B70 and 35.8 Gpts/s on B580; B580 PT/Triton was about 8% slower.Figure 6 plots zero-initialization throughput and replots B580/B70 results with random initialization in its inset.Source: C. Intel B70/GPUMAX 1550, NVIDIA… · p. 9, Figure 6 · p. 9
• Under zero initialization, B70 PT/Triton falls below the B580 result, and the authors could not identify the cause.Source: C. Intel B70/GPUMAX 1550, NVIDIA… · p. 9
• Under random initialization, GM1550/B70/B580 relative throughput ratios were 1.0/1.9/2.2, tracking measured bandwidth ratios within about 10%.The GM1550/B580 throughput ratios were 2.44 for PT/Triton (32.9/13.5) and 2.17 for TinyTC (33.8/15.6).Source: C. Intel B70/GPUMAX 1550, NVIDIA… · p. 9
• NVIDIA/AMD comparisons use PT/Triton only; their zero- and random-initialization results are identical because these platforms lack memory compression.Source: C. Intel B70/GPUMAX 1550, NVIDIA… · p. 9
• Relative to B580, NVIDIA/AMD performance ratios were (1.1/1.3/1.3/1.9) for zero-initialization and (2.5/3.0/2.9/4.4) for random-initialization.The ratios are ordered A100, H100, RTX 6000, and MI325X.Source: C. Intel B70/GPUMAX 1550, NVIDIA… · p. 9
• For zero initialization, the gap between B580 and server-class GPUs remains limited because memory compression accelerates Intel results.The NVIDIA/AMD performance ratios relative to B580 rise from (1.1/1.3/1.3/1.9) for zero initialization to (2.5/3.0/2.9/4.4) for random initialization.Source: C. Intel B70/GPUMAX 1550, NVIDIA… · p. 9
• The cache-first approach may be suboptimal on NVIDIA/AMD; explicit shared memory or LDS and NVIDIA TMA are proposed options, pending further architectural investigation.Source: C. Intel B70/GPUMAX 1550, NVIDIA… · p. 10
• Peak performance requires architecture-specific adaptations, and generic kernels can sacrifice performance for portability.Source: C. Intel B70/GPUMAX 1550, NVIDIA… · p. 10

• OpenMP offload is the lowest-effort route for moving existing CPU stencil code to GPUs, but it delivers the lowest throughput in this study.Source: D. Programming model · p. 10
• SYCL provides explicit memory and execution control, outperforming OpenMP while remaining less intrusive than a full DSL rewrite.Source: D. Programming model · p. 10
• PT/Triton offers a portable, Python-based tile abstraction and a productivity–performance compromise that is substantially faster than directive-only offload.Source: D. Programming model · p. 10
• TinyTC delivers the highest performance on Intel hardware through fine-grained tile-shape and 2D block-load control, but is the most demanding model evaluated.Source: D. Programming model · p. 10
• TinyTC can be applied selectively to critical kernels in an existing SYCL application while retaining its SYCL host framework.Source: D. Programming model · p. 10
• Invest in a lower-level model when dominant kernels control end-to-end runtime; otherwise, Triton or OpenMP may offer better time-to-solution.OpenMP, SYCL, and TinyTC can also be mixed within one codebase.Source: D. Programming model · p. 10

• Tensor compilers are practical tools for high-order HPC stencils beyond their original AI focus; TinyTC performs best on Intel hardware through low-level tiling and memory-operation control.Source: §VII · p. 10
• Specialization maximizes peak performance, while generalist frameworks maximize portability and development velocity; the authors frame these paths as complementary.Source: §VII · p. 10
• Future work includes extending memory-traffic analysis beyond steady-state inner kernels, optimizing boundary kernels, and investigating architecture-specific Triton performance.The authors also propose exploring tighter integration of Triton into production code.Source: §VII · p. 10