Pith. sign in

REVIEW 4 major objections 5 minor 48 references

MMStencil: Optimizing High-order Stencils on Multicore CPU using Matrix Unit

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

Pith's one-line read MMStencil shows a RISC multicore CPU's outer-product matrix unit can outperform an Nvidia A100 GPGPU by up to 2.1x on 3D high-order stencils and speed up reverse-time-migration imaging by 1.8x.

desk verdict The matrix-unit mapping for 3D high-order stencils is real and worth engaging; the CPU-vs-GPU speedups are not yet established because the comparisons mix precision and grid sizes. read the letter →

arxiv 2507.11067 v1 pith:NPZBV2NC submitted 2025-07-15 cs.DC

classification cs.DC
keywords stencilcomputationmatrixunitouterproductmulticoreCPUhigh-orderReverseTimeMigrationNUMASDMA
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

MMStencil claims that a RISC multicore CPU's outer-product matrix unit can make 3D high-order stencil computations—the kind that dominate seismic imaging and other PDE solvers—run faster than they do on an Nvidia A100 GPGPU. By recasting each stencil axis as a sequence of outer products, reorganizing the grid into bricks to keep memory streams contiguous, serving halo data from neighboring cores' private caches instead of main memory, and using the chip's DMA engine for cross-NUMA halo exchange, the paper reports up to 2.1x speedup over state-of-the-art GPU libraries on stencil kernels and a 1.8x speedup in an end-to-end Reverse Time Migration workload. If true, this would mean CPUs with matrix units can rival or beat GPGPUs on an important memory-bound HPC kernel class, without giving up CPU programmability. The paper also reports that the same techniques hold up when scaling from one NUMA node to a full two-socket server.

What carries the argument

The load-bearing mechanism is the outer-product mapping of a stencil onto the matrix unit: a one-dimensional stencil of radius r is computed by loading input vectors and outer-producting them with coefficient columns into a [VL x VL] matrix tile accumulator, with the axes composed in sequence for 3D. Around it, the paper stacks four supporting mechanisms: tile-based instruction-level parallelism that interleaves outer products across matrix tiles; a tile-assisted vector transpose that uses horizontal loads and vertical stores to avoid gather penalties along the x-axis; a brick memory layout (with brick sizes chosen to match the vector length and stencil radius) that reduces the number of concurrent memory streams; and a cache-snoop scheme where adjacent tiles are assigned to adjacent cores so halo regions are served from peer L2 caches, plus gather-based software prefetch and SDMA-based asynchronous halo exchange for multi-NUMA scaling.

What would settle it

Run the 3D radius-4 star stencil in the same precision (single or double) on the same grid size ($512^{3}$) on both the disclosed RISC CPU with MMStencil and an NVIDIA A100 with the best available CUDA stencil library, using the same halo-exchange and tiling constraints; if the CPU fails to beat the GPU, or the RTM speedup disappears when both run $512^{3}$ grids, the central claim is not established.

Watch

Extended reading notes

Core claim

The paper's central discovery is that high-order 3D stencils, which degrade SIMD and CUDA implementations, map naturally onto outer-product matrix units: each axis of the stencil becomes a series of outer products between a vector loaded from the input and a coefficient vector, accumulated in matrix tiles. With 512-bit SIMD registers and a 16x16 matrix tile, the instruction count grows as (VL + 2r) outer products instead of VL x (2r+1) SIMD FMAs, which flips the balance in favor of the matrix unit as soon as the stencil radius exceeds one. The paper combines this mapping with a brick memory layout borrowed from prior blocked-stencil work, cache-snoop-based halo sharing between cores that lack a shared last-level cache, and SDMA-engine-based asynchronous halo exchange to replace MPI, and reports that the combination sustains high hardware utilization across stencil shapes and scales to outperform an A100 GPGPU by up to 2.1x on kernels and 1.8x on an industrial reverse-time-migration application.

Load-bearing premise

The headline speedups assume the CPU and GPU runs are fairly comparable: the CPU runs single precision on an undisclosed RISC chip, the GPU baselines mostly run double precision, the RTM workload uses a smaller grid on the CPU, and one flagship CPU baseline library could not be run at all; if those imbalances were corrected, the claimed margins might shrink.

Editorial extensions

If this is right

  • If the mapping is right, high-order stencil kernels—the hard case for SIMD and CUDA—become the sweet spot for CPU matrix units, with speedups growing as stencil radius increases.
  • The brick layout plus cache-snooping could let stencil codes run at near-peak on-package memory bandwidth on multicore CPUs without a shared last-level cache.
  • SDMA-based halo exchange, with pipeline overlap, removes MPI's shared-memory locking bottleneck and makes hybrid MPI+OpenMP scaling practical on multi-die CPUs.
  • CPU-based RTM and similar seismic imaging workloads could reach or exceed GPU throughput on CPU-only servers, simplifying deployment of industrial HPC codes.
  • The paper's performance model suggests the technique carries over to any matrix unit with sufficiently low outer-product latency, not just the specific chip used.

Reading between the lines

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

  • The same outer-product decomposition should transfer to other matrix-unit CPUs or future tensor-core hardware; the paper's own performance model gives a quick formula for predicting where it wins.
  • The cache-snoop halo scheme suggests a general principle for multicore SoCs without shared last-level caches: assign adjacent tiles to adjacent cores and let the coherence protocol serve halo data, which could extend to other halo-exchange PDE solvers.
  • A natural extension is to exercise the matrix unit's full-precision path—the paper runs single precision—by benchmarking double-precision stencils, and to combine the brick layout with temporal blocking.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 5 minor

Summary. The paper presents MMStencil, a framework for accelerating 3D high-order stencil computations on a RISC multicore CPU with an outer-product matrix unit. The contributions are: a mapping of 1D stencils to outer-product matrix operations; microarchitectural techniques such as tile-based ILP, tile-assisted vector transpose, cache-pollution-avoiding intermediate placement, and a redundant-access-zeroing box-stencil scheme; memory optimizations consisting of a SIMD-friendly brick layout and gather-based software prefetch; a cache-snoop-based data-sharing scheme for cores without a shared LLC; and SDMA-based halo exchange for multi-NUMA and MPI settings. The authors integrate the kernels into RTM applications and report speedups over SIMD baselines on the CPU and, as headline claims, up to 2.1x over state-of-the-art GPU libraries on an NVIDIA A100 and a 1.8x speedup over an industrial A100 RTM implementation.

Significance. If the headline claims are substantiated, the paper would demonstrate that CPU matrix units combined with on-package memory can beat GPGPUs on an important memory-bound kernel class, which would be a meaningful result for the HPC community. The paper also provides useful algorithmic ideas, particularly the outer-product stencil mapping and the cache-snoop/SDMA parallelization techniques, and it includes a performance breakdown (Fig. 12) that gives insight into which optimizations matter. However, the headline CPU-versus-GPU speedups rest on comparisons that are not apples-to-apples, and the CPU platform is undisclosed, so the quantitative claims are not yet established.

major comments (4)
  1. [Sec. V-C, V-E3; Sec. III-B.d] The headline 2.1x speedup over GPU libraries is based on a precision mismatch that is load-bearing for a memory-bound kernel. Sec. III-B.d states that all GPU libraries run in double precision (except TCStencil in half precision) while CPU libraries run in single precision, and the main comparisons in Fig. 11 and the weak-scaling result in Sec. V-E3 report wall-clock or speedup ratios without normalizing for datatype width. For a memory-bound stencil, DRAM traffic scales with the datatype size, so an FP32 CPU kernel moves half the bytes of an FP64 GPU kernel. The Bandwidth Utilization metric defined in Sec. III-B.d normalizes by sizeof(datatype), but the claimed 2.1x is a raw wall-clock ratio. The authors should rerun the GPU baselines in single precision at the same grid size (or otherwise provide a precision-normalized comparison) before claiming a CPU-over-GPU speedup.
  2. [Sec. V-F] The RTM comparison is not workload-normalized. Sec. V-F sets the CPU grid to (512, 512, 256) 'due to on-package memory capacity limitations' while the GPU grid is (512, 512, 512), so the GPU executes twice as many grid points. The abstract's 1.8x speedup and the Sec. V-F scaling claim of up to 3.5x speedup over the CUDA implementation therefore conflate workload reduction with performance advantage. The authors should either run the same problem size on both platforms or report per-point or per-unit-work throughput (e.g., stencils per second per grid point).
  3. [Sec. V-A; Sec. II-B footnote 1] The CPU platform is undisclosed, and the CPU baseline set is incomplete, which weakens the 'outperforms state-of-the-art libraries' claim. Footnote 1 in Sec. II-B states that hardware specifications cannot be disclosed, and Sec. V-A footnote 2 says BrickLib's CPU implementation could not run and that the authors instead implemented their own SIMD baseline. The paper cites Yask [18] and Devito [20] but does not compare against them. While the kernel techniques may be sound, the absence of a disclosed platform and the lack of well-established CPU stencil baselines make it impossible to assess whether the reported CPU performance is a property of the algorithm or of an unusual, unreproducible platform. At minimum, the authors should provide a detailed enough description (or a known equivalent) and add at least one independently maintained CPU stencil baseline.
  4. [Sec. IV-B; Sec. V-D] The performance model in Sec. IV-B is not used as a predictive tool, and its discrepancy with the measured results is not explained quantitatively. The model predicts a theoretical 1.5x speedup for r=4, but Sec. V-D attributes the larger measured gains to qualitative factors such as instruction-scheduling overhead. The paper would be stronger if the experiments tested the model's predictions across a range of radii and precisions, or if the model were revised to account for the scheduling effects. As written, the model is an incentive device rather than evidence for the central claim, though this is not a fatal flaw on its own.
minor comments (5)
  1. [Abstract and throughout] There are several typographical errors, including 'Nividia' (Abstract), 'absense' (Sec. I and II-A), and 'Intermedian' (Sec. IV-C heading). The paper would benefit from a careful proofread.
  2. [Sec. V-A] The classification in Table I labels 3DBoxR2 as 'Computation Bound,' but Sec. V-B says the kernel is 'compute-bound' and Sec. V-C reports 85% of the 3.75 TFLOPS theoretical peak. This is consistent, but the table does not state the peak FLOPS or memory bandwidth used for the Roofline classification; adding those numbers would improve interpretability.
  3. [Sec. V-E2] The sentence 'MMStencil matches the CUDA performance' in Sec. V-E2 compares against BrickLib running the 3DStarR4 stencil in single precision on the A100. This is a more controlled comparison than the rest of the paper, but the result is reported without a timing table or precision statement for MMStencil; please clarify that the comparison is single-precision on both sides and report the actual runtimes.
  4. [Fig. 14 and Fig. 15] The captions for Fig. 14 and Fig. 15 do not define the axes or the baseline curves. In particular, Fig. 15 is described as 'RTM Scaling Experiments' but the caption does not state whether the y-axis is elapsed time or speedup, or what the 'CUDA' curve represents. Please make the captions self-contained.
  5. [Sec. IV-B] The notation 'CPI Matrix = 2in single precision' in Sec. IV-B should read '2 in single precision' to avoid confusion. Also, the derivation of Cycles_Matrix = (VL + 2r) * CPI_Matrix assumes one outer product per stencil offset; this should be stated explicitly.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the central performance claims are direct measurements against external baselines; the only self-citations are domain background or non-load-bearing.

full rationale

The paper's derivation chain is not circular. The stencil-to-matrix-unit mapping (Sec. IV-A) is a constructive algorithm, and the performance model (Sec. IV-B) is an analytic instruction-count/CPI estimate: it uses stated hardware constants (CPI_SIMD=0.5, CPI_Matrix=2) and is not fitted to the later speedups. The headline CPU-vs-GPU results (Sec. V-C, V-E, V-F) are measured wall-clock comparisons against external baselines (BrickLib, EBISU, TCStencil, LoRAStencil, ConvStencil, compiler and hand-tuned SIMD code), not predictions derived from the model. The only same-author citations are [7] and [9]: [7] is domain background on earthquake simulation, and [9] is cited in Sec. IV-F for a pipeline-overlap scheme alongside the independent Pencil reference [45]; neither is used to establish the central claim or to exclude alternatives. No uniqueness theorem is imported, no fitted parameter is renamed as a prediction, and no known result is merely relabeled. The principal weaknesses—undisclosed CPU platform details (Sec. II-B footnote), the unavailable BrickLib CPU port (Sec. V-A footnote), and unequal precision/grid sizes in some GPU comparisons (Sec. V-F)—are experimental-fairness and transparency issues, not circular derivation.

Assumptions & free parameters 2 free parameters · 4 assumptions · 0 invented entities

The paper introduces no new physical entities; the free parameters are engineering choices (tile sizes) and hardware CPI values. The load-bearing assumptions are about the undisclosed platform's microarchitecture and about the fairness of cross-precision, cross-size benchmarks. The count of assumptions is small, but their unverifiability is the main obstacle to accepting the claims.

free parameters (2)
  • Block and brick tile sizes (VX, VY, VZ; BX, BY, BZ) = VX=VY=16, VZ=4 or multiples; BX=VL, BY=BZ=4
    Chosen by hand in Sec IV-D and Table I to balance contiguous access, halo traffic, and matrix-tile ILP; the choices directly affect the measured performance and are not derived from the stencil equations.
  • Matrix unit CPI and SIMD CPI = CPI_Matrix=2, CPI_SIMD=0.5 (single precision)
    Hardware measurements quoted in Sec IV-B and used in the theoretical speedup model; they are inputs, not fit to the results, but they are unverifiable without platform disclosure.
assumptions (4)
  • domain assumption The experimental CPU's Matrix unit executes outer products at CPI=2 with 4-cycle latency and saturates with interleaved tiles.
    Used in Sec IV-B performance model and Sec V-D to explain why Matrix unit beats SIMD; cannot be checked without platform details.
  • domain assumption The CPU cores have private data caches but no shared last-level cache; coherence snooping can serve halo data from neighboring cores.
    Motivates the cache-snoop data-sharing scheme in Sec IV-E; if a shared LLC exists on the platform, the scheme's benefit and the premise are false.
  • ad hoc to paper Normalizing by sizeof(datatype) in the bandwidth-utilization metric makes single-precision CPU and double-precision GPU comparisons fair.
    Introduced in Sec III-B; the metric does not account for precision-dependent arithmetic throughput on GPUs, so the fairness of cross-precision comparisons rests on this assumption.
  • domain assumption Single precision is the appropriate working precision for RTM, so CPU single-precision results are directly comparable to the industrial GPU implementation.
    Sec II-B states RTM relies on single precision; if the industrial GPU code uses higher precision or a different algorithm, the RTM speedup comparison is invalid.

how reviews work

0 comments
Cite this review

Pith. "Pith review of MMStencil: Optimizing High-order Stencils on Multicore CPU using Matrix Unit." pith.science (2026). https://pith.science/paper/NPZBV2NC

@misc{pith2026250711067,
  author       = {Pith},
  title        = {Pith review of: MMStencil: Optimizing High-order Stencils on Multicore CPU using Matrix Unit},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/NPZBV2NC}},
  note         = {Machine review of arXiv:2507.11067}
}
read the original abstract

Matrix-accelerated stencil computation is a hot research topic, yet its application to three-dimensional (3D) high-order stencils and HPC remains underexplored. With the emergence of matrix units on multicore CPUs, we analyze matrix-based acceleration strategies and tailor an optimal approach for 3D high-order stencils. We introduce algorithmic optimizations based on SIMD and matrix units to address strided memory accesses, alignment conflicts, and redundant accesses. We propose memory optimizations to boost on-package memory efficiency, and a novel multi-thread parallelism paradigm to overcome data-sharing challenges caused by the absence of shared data caches. MMStencil sustains consistently high hardware utilization across diverse stencil shapes and dimensions. Our DMA-based inter-NUMA communication further mitigates NUMA effects and MPI limitations in hybrid parallelism. Combining all the innovations, MMStencil outperforms state-of-the-art libraries on Nvidia A100 GPGPU by up to 2.1x. Moreover, the performance improvements translate directly to real-world HPC applications and enable RTM applications to yield 1.8x speedup versus a highly optimized industrial Nvidia A100 GPGPU version.

Figures

Figures reproduced from arXiv: 2507.11067 by the authors.

Figure 1
Figure 1. Two Stencil Examples: Box and Star high-order stencils form a particularly crucial subclass, un￾derpinning many real-world high-performance computing ap￾plications [4], [7]–[9]. For instance, Reverse Time Migration (RTM), a pivotal supercomputing application for earth mod￾eling, employs finite difference methods for approximating spatial derivatives. To balance computational efficiency and storage demands, geophysic… view at source ↗
Figure 2
Figure 2. Outer-Product Based Matrix Compute Mechanism. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Bandwidth Utilization of State-of-the-arts [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (12 more)
Figure 4
Figure 4. Figure 4: Mapping Stencil to Matrix Unit As shown in [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]
Figure 5
Figure 5. Figure 5: Tile-Assisted Vector Transpose b) Tile-Assisted Vector Transpose: When computing the x-axis stencil, accessing each (1, VY , 1) column vector incurs non-contiguous memory accesses. As most modern CPUs perform 2 loads and 1 store per cycle, on a 512- bit SIMD platform, …
Figure 6
Figure 6. Figure 6: Redundant-Access Zeroing Box Stencil computational efficiency without incurring extra arithmetic overhead or imposing restrictions on the stencil properties. D. Memory Optimizations Stencil computations demand both high computational power and bandwidth. With our micro…
Figure 7
Figure 7. Figure 7: SIMD-Friendly Memory Reorder and Gather-Based [PITH_FULL_IMAGE:figures/full_fig_p007_7.png]
Figure 8
Figure 8. Figure 8: Cache-snoop based Data Sharing To address this limitation, we exploit the data cache coher￾ence protocol. Whenever a core accesses an address missing in its private caches, it checks the NUMA’s root directory. If the data resides in another core’s cache, it is retrieve…
Figure 9
Figure 9. Figure 9: Pipeline Overlapping Scheme Another advantage of the SDMA engine is its non-intrusive nature: it does not occupy CPU cores or pollute caches. This allows efficient computation–communication overlap. Specifically, we apply a pipeline-overlap scheme [9], [45] by partitio…
Figure 10
Figure 10. Figure 10: Computing partial derivatives c) Benchmarks: We selected eight stencil benchmarks with varying shapes and dimensions, as detailed in Tab. I. This set includes four star stencils (2DStarR2, 2DStarR4, 3DStarR2, 3DStarR4) and four box stencils (2DBoxR2, 2DBoxR3, 3DBoxR1,…
Figure 11
Figure 11. Figure 11: Performance Comparisons with Baselines [PITH_FULL_IMAGE:figures/full_fig_p010_11.png]
Figure 12
Figure 12. Figure 12: Performance Breakdown of MMStencil thereby validating our “Redundant Access Zeroing Box Stencil Optimization” scheme. In the case of 3D stencils, the SIMD intrinsic version surprisingly delivers the best performance for the 3DStarR2 kernel. Although 3DStarR2 exhibits …
Figure 13
Figure 13. Figure 13: Scaling Experiments of MMStencil 1) SDMA Communication Bandwidth Test: We first assess the data exchange bandwidth across NUMA nodes using both SDMA and MPI. The global grid size is set to 512×512×512, and two processes are placed on the same DDR die to perform the ha…
Figure 14
Figure 14. Figure 14: RTM Performance using MMStencil F. Performance in HPC Applications In this subsection, we evaluate the performance gains achieved by integrating MMStencil into complex HPC appli￾cations. Leveraging our expertise in earth modeling, we target RTM in both VTI and TTI med…
Figure 15
Figure 15. Figure 15: RTM Scaling Experiments industrially optimized RTM implementations for both CPU and GPU, as provided by Bureau of Geophysical Prospecting INC. China National Petroleum Corporation. The CPU version runs on the experimental platform, while the GPU version is executed on…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

48 extracted references · 38 canonical work pages

  1. [33]

    Can tensor cores benefit memory-bound kernels? (no!),

    L. Zhang, J. Huang, S. Di, S. Matsuoka, and M. Wahib, “Can tensor cores benefit memory-bound kernels? (no!),” in Proceedings of the 17th Workshop on General Purpose Processing Using GPU, ser. GPGPU ’25. New York, NY , USA: Association for Computing Machinery, 2025, p. 28–34. [Online]. Available: https://doi.org/10.1145/3725798.3725803

  2. [18]

    Yask—yet another stencil kernel: A framework for hpc stencil code-generation and tuning,

    C. Yount, J. Tobin, A. Breuer, and A. Duran, “Yask—yet another stencil kernel: A framework for hpc stencil code-generation and tuning,” 11 2016, pp. 30–39

  3. [20]

    Devito: Automated fast finite difference computation,

    N. Kukreja, M. Louboutin, F. Vieira, F. Luporini, M. Lange, and G. Gorman, “Devito: Automated fast finite difference computation,” in 2016 Sixth International Workshop on Domain-Specific Languages and High-Level Frameworks for High Performance Computing (WOLFHPC), 2016, pp. 11–19

  4. [1]

    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, S. Williams, and K. Yelick, “The landscape of parallel computing research: A view from berkeley,” EECS Department, University of California, Berkeley, vol. EECS-2006-183, 12 2006

  5. [2]

    A view of the parallel computing landscape,

    K. Asanovic, R. Bodik, J. Demmel, T. Keaveny, K. Keutzer, J. Kubiatowicz, N. Morgan, D. Patterson, K. Sen, J. Wawrzynek, D. Wessel, and K. Yelick, “A view of the parallel computing landscape,” Commun. ACM , vol. 52, no. 10, p. 56–67, Oct. 2009. [Online]. Available: https://doi.org/10.1145/1562764.1562783

  6. [3]

    Global shallow water models based on multi-moment constrained finite volume method and three quasi-uniform spherical grids,

    C. Chen, X. Li, X. Shen, and F. Xiao, “Global shallow water models based on multi-moment constrained finite volume method and three quasi-uniform spherical grids,” Journal of Computational Physics , vol. 271, pp. 191–223, 2014

  7. [4]

    High-order finite- volume methods for the shallow-water equations on the sphere,

    P. A. Ullrich, C. Jablonowski, and B. Van Leer, “High-order finite- volume methods for the shallow-water equations on the sphere,” Journal of Computational Physics , vol. 229, no. 17, pp. 6104–6134, 2010

  8. [5]

    High-order methods for computa- tional fluid dynamics: A brief review of compact differential formulation on unstructured grids,

    H. Huynh, Z. Wang, and P. Vincent, “High-order methods for computa- tional fluid dynamics: A brief review of compact differential formulation on unstructured grids,” Computers & Fluids , vol. 98, 06 2013

Show all 48 references
  1. [6]

    Opensbli: Automated code- generation for heterogeneous computing architectures applied to com- pressible fluid dynamics on structured grids,

    D. Lusher, S. Jammy, and N. Sandham, “Opensbli: Automated code- generation for heterogeneous computing architectures applied to com- pressible fluid dynamics on structured grids,” Computer Physics Com- munications, vol. 267, p. 108063, 06 2021

  2. [7]

    Simulating the wenchuan earthquake with accurate surface topography on sunway taihulight,

    B. Chen, H. Fu, Y . Wei, C. He, W. Zhang, Y . Li, W. Wan, W. Zhang, L. Gan, W. Zhang, Z. Zhang, G. Yang, and X. Chen, “Simulating the wenchuan earthquake with accurate surface topography on sunway taihulight,” ser. SC ’18. IEEE Press, 2018. 13

  3. [8]

    Three-dimensional curved grid finite-difference modelling for non-planar rupture dynamics,

    Z. Zhang, W. Zhang, and X. Chen, “Three-dimensional curved grid finite-difference modelling for non-planar rupture dynamics,” Geophys- ical Journal International , vol. 199, no. 2, pp. 860–879, 2014

  4. [9]

    69.7-pflops extreme scale earthquake simulation with crossing multi-faults and topography on sunway,

    W. Wan, L. Gan, W. Wang, Z. Yin, H. Tian, Z. Zhang, Y . Wang, M. Hua, X. Liu, S. Xiang, Z. He, Z. Wang, P. Gao, X. Duan, W. Liu, W. Xue, H. Fu, G. Yang, X. Chen, Z. Song, Y . Chen, X. Liu, and W. Zhang, “69.7-pflops extreme scale earthquake simulation with crossing multi-fault...

  5. [10]

    Reverse time migration: A prospect of seismic imaging methodology,

    H.-W. Zhou, H. Hu, Z. Zou, Y . Wo, and O. Youn, “Reverse time migration: A prospect of seismic imaging methodology,” Earth- Science Reviews , vol. 179, pp. 207–227, 2018. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S0012825217306256

  6. [11]

    A practical implementation of 3d tti reverse time migration with multi-gpus,

    C. Li, G. Liu, and Y . Li, “A practical implementation of 3d tti reverse time migration with multi-gpus,” Comput. Geosci. , vol. 102, no. C, p. 68–78, May 2017. [Online]. Available: https://doi.org/10.1016/j.cageo.2017.02.011

  7. [12]

    Data layout transformation for stencil computations on short-vector simd architectures,

    T. Henretty, K. Stock, L.-N. Pouchet, F. Franchetti, J. Ramanujam, and P. Sadayappan, “Data layout transformation for stencil computations on short-vector simd architectures,” in Compiler Construction , J. Knoop, Ed. Berlin, Heidelberg: Springer Berlin Heidelberg, 2011, pp. 225– 245

  8. [13]

    A stencil compiler for short-vector simd architectures,

    T. Henretty, R. Veras, F. Franchetti, L.-N. Pouchet, J. Ramanujam, and P. Sadayappan, “A stencil compiler for short-vector simd architectures,” in Proceedings of the 27th International ACM Conference on International Conference on Supercomputing, ser. ICS ’13. New York, NY , U...

  9. [14]

    Reducing redundancy in data organization and arithmetic calculation for stencil computations,

    K. Li, L. Yuan, Y . Zhang, and Y . Yue, “Reducing redundancy in data organization and arithmetic calculation for stencil computations,” in SC21: International Conference for High Performance Computing, Networking, Storage and Analysis , 2021, pp. 01–15

  10. [15]

    An efficient vectorization scheme for stencil computation,

    K. Li, L. Yuan, Y . Zhang, Y . Yue, and H. Cao, “An efficient vectorization scheme for stencil computation,” in 2022 IEEE International Parallel and Distributed Processing Symposium (IPDPS) , 2022, pp. 650–660

  11. [16]

    Compiler-directed transformation for higher-order stencils,

    P. Basu, M. Hall, S. Williams, B. Van Straalen, L. Oliker, and P. Colella, “Compiler-directed transformation for higher-order stencils,” in 2015 IEEE International Parallel and Distributed Processing Symposium , 2015, pp. 313–323

  12. [17]

    Associative instruction reordering to alleviate register pressure,

    P. S. Rawat, A. Sukumaran-Rajam, A. Rountev, F. Rastello, L.-N. Pouchet, and P. Sadayappan, “Associative instruction reordering to alleviate register pressure,” in SC18: International Conference for High Performance Computing, Networking, Storage and Analysis , 2018, pp. 590–602

  13. [19]

    Yasksite: Stencil optimization techniques applied to explicit ode methods on modern architectures,

    C. L. Alappat, J. Seiferth, G. Hager, M. Korch, T. Rauber, and G. Wellein, “Yasksite: Stencil optimization techniques applied to explicit ode methods on modern architectures,” in 2021 IEEE/ACM International Symposium on Code Generation and Optimization (CGO) , 2021, pp. 174–186

  14. [21]

    3.5-d blocking optimization for stencil computations on modern cpus and gpus,

    A. Nguyen, N. Satish, J. Chhugani, C. Kim, and P. Dubey, “3.5-d blocking optimization for stencil computations on modern cpus and gpus,” in SC ’10: Proceedings of the 2010 ACM/IEEE International Conference for High Performance Computing, Networking, Storage and Analysis, 2010,...

  15. [22]

    Dhts: A dynamic hybrid tiling strategy for optimizing stencil computation on gpus,

    S. Liu, Z. Zhang, and W. Wu, “Dhts: A dynamic hybrid tiling strategy for optimizing stencil computation on gpus,” IEEE Transactions on Computers, vol. 72, no. 10, pp. 2795–2807, 2023

  16. [23]

    Comparison of the effectiveness of shared memory optimizations for stencil computations on nvidia gpu architectures,

    G. J. W. Verweij, “Comparison of the effectiveness of shared memory optimizations for stencil computations on nvidia gpu architectures,”

  17. [24]

    Optimized three-dimensional stencil computation on fermi and kepler gpus,

    A. Vizitiu, L. Itu, C. Nit ¸ ˘a, and C. Suciu, “Optimized three-dimensional stencil computation on fermi and kepler gpus,” in 2014 IEEE High Performance Extreme Computing Conference (HPEC) , 2014, pp. 1–6

  18. [25]

    Register caching for stencil computations on gpus,

    T. L. Falch and A. C. Elster, “Register caching for stencil computations on gpus,” in 2014 16th International Symposium on Symbolic and Numeric Algorithms for Scientific Computing , 2014, pp. 479–486

  19. [26]

    On optimizing complex stencils on gpus,

    P. S. Rawat, M. Vaidya, A. Sukumaran-Rajam, A. Rountev, L.-N. Pouchet, and P. Sadayappan, “On optimizing complex stencils on gpus,” in 2019 IEEE International Parallel and Distributed Processing Symposium (IPDPS), 2019, pp. 641–652

  20. [27]

    Delivering performance-portable stencil computations on cpus and gpus using bricks,

    T. Zhao, S. Williams, M. Hall, and H. Johansen, “Delivering performance-portable stencil computations on cpus and gpus using bricks,” in 2018 IEEE/ACM International Workshop on Performance, Portability and Productivity in HPC (P3HPC) , 2018, pp. 59–70

  21. [28]

    Exploiting reuse and vectorization in blocked stencil computations on cpus and gpus,

    T. Zhao, P. Basu, S. Williams, M. Hall, and H. Johansen, “Exploiting reuse and vectorization in blocked stencil computations on cpus and gpus,” 11 2019, pp. 1–44

  22. [29]

    Improving communication by optimizing on-node data movement with data layout,

    T. Zhao, M. Hall, H. Johansen, and S. Williams, “Improving communication by optimizing on-node data movement with data layout,” in Proceedings of the 26th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming , ser. PPoPP ’21. New York, NY , USA: Association...

  23. [30]

    Toward accelerated stencil computation by adapting tensor core unit on gpu,

    X. Liu, Y . Liu, H. Yang, J. Liao, M. Li, Z. Luan, and D. Qian, “Toward accelerated stencil computation by adapting tensor core unit on gpu,” in Proceedings of the 36th ACM International Conference on Supercomputing , ser. ICS ’22. New York, NY , USA: Association for Computing...

  24. [31]

    Convstencil: Transform stencil computation to matrix multiplication on tensor cores,

    Y . Chen, K. Li, Y . Wang, D. Bai, L. Wang, L. Ma, L. Yuan, Y . Zhang, T. Cao, and M. Yang, “Convstencil: Transform stencil computation to matrix multiplication on tensor cores,” in Proceedings of the 29th ACM SIGPLAN Annual Symposium on Principles and Practice of Parallel Pro...

  25. [32]

    Lorastencil: Low-rank adaptation of stencil computation on tensor cores,

    Y . Zhang, K. Li, L. Yuan, J. Cheng, Y . Zhang, T. Cao, and M. Yang, “Lorastencil: Low-rank adaptation of stencil computation on tensor cores,” in Proceedings of the International Conference for High Performance Computing, Networking, Storage, and Analysis , ser. SC ’24. IEEE ...

  26. [34]

    Scalable distributed high- order stencil computations,

    M. Jacquelin, M. Araya-Polo, and J. Meng, “Scalable distributed high- order stencil computations,” in Proceedings of the International Con- ference on High Performance Computing, Networking, Storage and Analysis, ser. SC ’22. IEEE Press, 2022

  27. [35]

    Dispersion analysis of finite difference and discontinuous galerkin schemes for maxwell’s equations in linear lorentz media,

    Y . Jiang, P. Sakkaplangkul, V . A. Bokil, Y . Cheng, and F. Li, “Dispersion analysis of finite difference and discontinuous galerkin schemes for maxwell’s equations in linear lorentz media,” Journal of Computational Physics, vol. 394, pp. 100–135, 2019. [Online]. Available: h...

  28. [36]

    Numerical dispersion relation for fdtd method in general curvilinear coordinates,

    F. Xiao and H. Yabe, “Numerical dispersion relation for fdtd method in general curvilinear coordinates,” IEEE Microwave and Guided Wave Letters, vol. 7, no. 2, pp. 48–50, 1997

  29. [37]

    High order schemes for resolving waves: Number of points per wavelength,

    L. Jameson, “High order schemes for resolving waves: Number of points per wavelength,” Journal of Scientific Computing 15, 417–439 (2000) , vol. 15, p. 417–439, 2000

  30. [38]

    Y . E. Li, P. Shen, and C. Perkins, VTI migration velocity analysis using RTM , 2012, pp. 1–6. [Online]. Available: https: //library.seg.org/doi/abs/10.1190/segam2012-0128.1

  31. [39]

    Analysis of rtm extended images for vti media,

    V . Li, I. Tsvankin, and T. Alkhalifah, “Analysis of rtm extended images for vti media,” GEOPHYSICS, vol. 81, no. 3, pp. S139–S150, 2016. [Online]. Available: https://doi.org/10.1190/geo2015-0384.1

  32. [40]

    Optimization and performance modeling of stencil computations on modern microprocessors,

    K. Datta, S. Kamil, S. Williams, L. Oliker, J. Shalf, and K. Yelick, “Optimization and performance modeling of stencil computations on modern microprocessors,” SIAM Review , vol. 51, no. 1, pp. 129–159,

  33. [41]

    Physis: an implicitly parallel programming model for stencil computations on large-scale gpu-accelerated supercomputers,

    N. Maruyama, T. Nomura, K. Sato, and S. Matsuoka, “Physis: an implicitly parallel programming model for stencil computations on large-scale gpu-accelerated supercomputers,” in Proceedings of 2011 International Conference for High Performance Computing, Networking, Storage and ...

  34. [42]

    High performance stencil code generation with lift,

    B. Hagedorn, L. Stoltzfus, M. Steuwer, S. Gorlatch, and C. Dubach, “High performance stencil code generation with lift,” in Proceedings of the 2018 International Symposium on Code Generation and Optimization, ser. CGO ’18. New York, NY , USA: Association for Computing Machiner...

  35. [43]

    An5d: automated stencil framework for high-degree temporal blocking on gpus,

    K. Matsumura, H. R. Zohouri, M. Wahib, T. Endo, and S. Matsuoka, “An5d: automated stencil framework for high-degree temporal blocking on gpus,” in Proceedings of the 18th ACM/IEEE International Symposium on Code Generation and Optimization , ser. CGO ’20. New York, NY , USA: A...

  36. [44]

    Revisiting temporal blocking stencil optimizations,

    L. Zhang, M. Wahib, P. Chen, J. Meng, X. Wang, T. Endo, and S. Matsuoka, “Revisiting temporal blocking stencil optimizations,” in Proceedings of the 37th International Conference on Supercomputing , ser. ICS ’23. ACM, Jun. 2023, p. 251–263. [Online]. Available: http://dx.doi.o...

  37. [45]

    Pencil: A pipelined algorithm for distributed stencils,

    H. Wang and A. Chandramowlishwaran, “Pencil: A pipelined algorithm for distributed stencils,” in SC20: International Conference for High Performance Computing, Networking, Storage and Analysis , 2020, pp. 1–16

  38. [46]

    Roofline: an insightful visual performance model for multicore architectures,

    S. Williams, A. Waterman, and D. Patterson, “Roofline: an insightful visual performance model for multicore architectures,” Commun. ACM, vol. 52, no. 4, p. 65–76, Apr. 2009. [Online]. Available: https://doi.org/10.1145/1498765.1498785 Yinuo Wang is a master candidate in the De...

  39. [2009]

    Available: https://doi.org/10.1137/070693199

    [Online]. Available: https://doi.org/10.1137/070693199

  40. [2017]

    Available: https://api.semanticscholar.org/CorpusID: 69273299

    [Online]. Available: https://api.semanticscholar.org/CorpusID: 69273299

Pith tools

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