Pith. sign in

REVIEW 4 major objections 4 minor 37 references

A Priori Loop Nest Normalization: Automatic Loop Scheduling in Complex Applications

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

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

Pith's one-line read Normalizing loop nests before optimization maps semantically equivalent code variants to one canonical form, so a single optimization recipe serves every implementation.

desk verdict A genuinely useful idea—normalize loop nests before tuning—with solid out-of-sample evidence across C and Python, though the tested loop variations are narrower than the abstract suggests. read the letter →

arxiv 2412.20179 v1 pith:PHQBKMST submitted 2024-12-28 cs.PF

Lukas Trümper , Philipp Schaad , Berke Ates , Alexandru Calotoiu , Marcin Copik , Torsten Hoefler This is my paper · ORCID
classification cs.PF
keywords loopnormalizationoptimizationpolyhedralanalysisauto-schedulingfissionstrideminimizationperformanceportabilitycompiler
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

Loop-based code that computes the same thing can look very different depending on how the developer ordered and composed the loops, and automatic optimizers often need a separate optimization recipe for each variant. This paper proposes normalizing the loop nest before scheduling: split it into the smallest independent loops, then rearrange those loops so memory accesses are as contiguous as possible. The result is a canonical form, and the paper shows that one optimization recipe learned on it applies to many variants of the same kernel, across C, Python, and Fortran. If the approach holds, automatic optimizers would no longer need to search over all loop permutations and compositions; they would need one recipe per computation, making them more stable on large scientific code.

What carries the argument

The load-bearing object is the normalization pipeline applied before scheduling. It first performs maximal loop fission: any two independent computations sharing a loop are split into separate atomic loop nests until no further split is possible. It then performs stride minimization: for each resulting nest, it enumerates legal loop permutations and picks the one whose array accesses are closest together in memory. The normalized nests are then matched by similarity to a database of optimization recipes built from reference implementations, so that one recipe transfers to every code variant that normalizes to the same shape.

What would settle it

A concrete test: take a kernel whose loop nest cannot be lifted to the affine single-entry-single-exit form, for instance one with data-dependent control flow, produce a semantically equivalent but differently ordered variant, and check whether the scheduler still matches the two runtimes; a large mismatch would falsify the canonicalization claim.

Watch

Extended reading notes

Core claim

The paper argues that two normalization criteria, maximal loop fission and stride minimization, define a canonical form for loop nests, so that different implementations of the same computation, even in different programming languages, exhibit the same memory-access shape and can be optimized by the same recipe. The claim is tested with a scheduler that first lifts loop nests from an intermediate representation, fissions each nest into atomic loops, permutes loops to minimal stride, and then looks up optimization recipes in a database built from normalized reference implementations. On pairs of semantically equivalent benchmark variants, the scheduler keeps the performance difference between variants near measurement noise, with a mean difference of 5 percent, while the compared baselines vary by up to orders of magnitude; an ablation shows that both normalization and the recipe-transfer mechanism are needed. The paper further reports that applying the same pipeline to a production cloud-microphysics Fortran code yields roughly a 10 percent speedup over the hand-tuned original.

Load-bearing premise

The central assumption is that every relevant loop nest can be lifted into the affine, single-entry-single-exit representation the normalization operates on; when lifting fails, the loop nest is left unoptimized, and the paper's correlation and covariance results show that this can make the scheduler fall behind a baseline.

Editorial extensions

If this is right

  • An optimization recipe learned on one implementation of a kernel can be reused on every semantically equivalent implementation, so automatic schedulers stop paying for loop-order variation.
  • Because normalization is applied before scheduling, the search space an automatic scheduler must explore shrinks to one canonical instance per computation instead of one per code variant.
  • Idiom detection becomes more reliable: once loop nests are canonicalized, recognizing a matrix-multiply or other library-call kernel no longer depends on the exact loop structure in the source.
  • Large applications that group computations according to formulas rather than memory-access patterns can be reshaped automatically, which is how the paper obtains speedups in a heavily tuned Fortran weather model.

Reading between the lines

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

  • The two normalization criteria are only a first cut; other data-locality objectives, such as minimizing reuse distance or preparing tiling-friendly shapes, could define additional canonical forms and broaden the class of loop nests covered.
  • The paper's own correlation and covariance results show that liftability is the bottleneck; widening the lifting step to non-affine or partially detected loop nests would be the natural next test of the general claim.
  • Because the normalization is language-independent once a dataflow graph is built, the same recipes could transfer across accelerator backends, so a kernel tuned once for a CPU might be retargeted to a GPU by reusing the canonical form.
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 / 4 minor

Summary. The paper proposes a priori loop nest normalization, consisting of maximal loop fission and stride minimization, to canonicalize loop nests before automatic scheduling. The authors implement this normalization on LLVM IR using a Polly-based lifting workflow and integrate it into a scheduler, daisy, which queries a database of optimization recipes via similarity-based transfer tuning. The evaluation covers 15 PolyBench benchmarks in C with A and B implementations, NPBench Python implementations, and the CLOUDSC Fortran scheme, reporting speedups over icc, Polly, Tiramisu, NumPy, Numba, and DaCe, as well as a 10% speedup over CLOUDSC Fortran. The central claim is that normalized semantically equivalent loop nests can share a single optimization recipe, improving auto-scheduler robustness across implementations and languages.

Significance. The idea of normalizing loop nests before scheduling is timely and potentially valuable: it could reduce the auto-scheduler's search space and enable transfer of optimization recipes across implementations and languages. The B-variant experiments provide an out-of-sample test of the core transfer claim, and the ablation study in Section 4.2 supports the conclusion that both normalization and transfer tuning are needed. The CLOUDSC case study is a strength because it targets a real, highly tuned production code. However, the headline performance comparisons are weakened by in-sample database tuning on the A variants and by a modified Tiramisu baseline, so the quantitative claims need to be reframed. The paper is honest about the correlation/covariance failures and the Tiramisu adapter, but those limitations are load-bearing for the generality claim.

major comments (4)
  1. [Section 4, 'Seeding a Scheduling Database' and Section 4.1] The optimization recipes are evolved and refined using runtime measurements on the A variants, and the speedups over Polly, Tiramisu, and icc in Section 4.1 and the abstract are reported on those same A variants. Because the baseline schedulers are not given comparable per-benchmark tuning, the A-variant speedups are in-sample estimates and should not be presented as a head-to-head comparison. Please separate in-sample (A) from out-of-sample (B) results in the abstract and figures, or construct the database using a training/test split such that the A variants used for evolutionary search are not the same A variants used for the reported speedups.
  2. [Section 4, 'Baselines'] The comparison against Tiramisu is not against the released Tiramisu auto-scheduler: the authors state that the original could not be built, so they run the search as a standalone component and implement an adapter that applies maximal loop fission and restricts the conversion to perfectly nested parallel loops. Since maximal loop fission is one of the two proposed normalization criteria, the adapter itself may be responsible for part of the reported improvement over Tiramisu. Please quantify the effect of the adapter (for example, by running the Tiramisu search on the original loop nests without fission) or clearly label this as a modified baseline and soften the claim of outperforming the Tiramisu auto-scheduler.
  3. [Section 4.1, 'Robustness' and abstract] The A/B variants are generated only by different permutations and compositions, as stated in the benchmark description: 'randomly generate an alternative B variant for each benchmark based on different permutations and compositions.' The two normalization criteria, maximal fission and stride minimization, act within a fixed loop structure and cannot canonicalize variants that introduce or remove loops, such as tiling, strip-mining, or skewing. The experiments therefore demonstrate transfer over a restricted variant class, not the 'many different loop nest variants' claimed in the abstract. Please either extend the variant generation to include loop-structure-changing transformations or explicitly scope the transfer claim to permutation and composition variants.
  4. [Section 4.1, correlation and covariance results] The paper reports that normalization fails to lift specific loop nests for correlation and covariance, causing daisy to underperform Polly on those benchmarks. This is an important limitation for the stated target of complex applications, but the paper does not quantify how many loop nests across the 15 benchmarks fail to lift or discuss how representative the CLOUDSC success is in light of those failures. Please report the number and fraction of loop nests successfully lifted in each benchmark and discuss the implications for the generality of the normalization approach.
minor comments (4)
  1. [Section 5.2 and abstract/conclusion] The CLOUDSC sequential result is reported as a 1.08x speedup (about 8%) in Figure 11, while the abstract and conclusion state a 10% speedup; the 10% figure appears to correspond to a weak-scaling configuration in Figure 12b. Please state explicitly which measurement supports the headline number and reconcile the abstract with the sequential result.
  2. [Section 2.2] The definition of the stride criterion is informal: 'the sum of all distances between two subsequent accesses to all arrays over all computations' needs a precise definition for multi-dimensional arrays and non-affine access functions, and the legality condition for the considered permutations should be stated explicitly.
  3. [Section 3.1] There is a typo in 'This AST consists of a a tree of loops and computations nodes'; the duplicated article should be removed.
  4. [General] No artifact or code availability link is provided, which makes the reported speedups and the daisy implementation difficult to reproduce; please add a repository or detailed experimental scripts.

Circularity Check

1 steps flagged · score 6.0 of 10

The A/B transfer result is partially circular: B variants are generated by exactly the transformations the normalization removes, so the 'predicted' B performance is the A-fitted recipe replayed on identical normalized code.

  1. fitted input called prediction [Section 4 'The daisy scheduler', Optimization Algorithm; Section 4.1 'Robustness']
    "The database is seeded from normalized loop nests of the A variants and then applied to the normalized B variants. If a B loop nest is not reduced to an A loop nest, the transformation sequence cannot be applied."

    The optimization recipes are fitted by evolutionary search to runtimes of normalized A variants. The B variants are generated only by 'different permutations and compositions', which are exactly the variations that the two normalization criteria (maximal loop fission and stride minimization) are defined to remove. Hence any B variant that successfully 'is reduced to an A loop nest' compiles to the same normalized code as A and receives the identical fitted recipe. The reported robustness (A/B runtime ratio near 1) and the B-variant speedups over Polly/icc/Tiramisu are therefore the A-fitted recipe replayed on identical code, not an independent prediction.

full rationale

The paper's normalization criteria are defined independently of the benchmarks and are standard compiler transformations; no load-bearing self-citation chain was found. The CLOUDSC case study (Section 5) uses an external, highly tuned Fortran code not generated by the authors, and the Python/NPBench transfer (Section 4.3) uses existing external implementations, so those results provide independent support for the transfer claim. The admitted failures on correlation and covariance (Section 4.1) are honest and show the experiment is falsifiable. The circularity is localized to the A/B robustness test: the B variants are constructed from the same transformations that normalization removes, so the B-variant 'prediction' is a definitional consequence rather than an out-of-sample test. This is a partial circularity in the central evaluation, but not a total one because of the independent case studies. Broader concerns about the limited scope of the generated B variants (e.g., not exercising tiling or strip-mining) are correctness and generality risks, not circularity, and are therefore not counted in the score beyond the described step.

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

The central claim rests on the affine lifting coverage of Polly, the semantics-preservation of fission and permutation, the assumption that memory access pattern dominates performance, and the transferability of performance embeddings. The optimization recipe database and stride objective are hand-chosen or fitted quantities; NPROMA=128 is hand-tuned for the case study.

free parameters (4)
  • Optimization recipe database (per-kernel transformation sequences) = unknown; selected by evolutionary search on A variant runtime
    The scheduler does not derive recipes from the canonical form; it searches transformation sequences using runtime fitness on the very A variants used for evaluation (Section 4, Seeding a Scheduling Database). The 2.31x/2.89x speedups over Polly and Tiramisu are therefore partly fitted values.
  • stride(loop) objective = sum of strides of all array accesses
    Hand-chosen definition of the normalization criterion (Section 4, Optimization Algorithm); different definitions would change the canonical form and the results.
  • NPROMA tiling size = 128
    Chosen because it offers the best results on our hardware (Section 5.1); the CLOUDSC speedup depends on this hand-set parameter.
  • Evolutionary search budget = 3 epochs, 3 refinement iterations, top-3 Tiramisu candidates
    Hand-chosen search budget; the quality of the optimization recipes and hence the reported speedups depend on it.
assumptions (4)
  • domain assumption Polly detects all relevant loop nests as maximal SESE regions with affine accesses.
    Section 3.1 says the lifting workflow is based on Polly; Section 4.1 reports correlation and covariance loop nests are not lifted, so this is a real coverage assumption.
  • domain assumption Maximal loop fission and legal loop permutations preserve semantics.
    Sections 2.1 and 2.2 define the criteria using known compiler transformations, but the paper does not prove legality conditions for all cases.
  • domain assumption Memory access pattern and reuse distance dominate loop nest performance.
    Section 2 opens with this claim to justify normalization; if memory behavior is not dominant, the method may not help.
  • domain assumption Performance embeddings from prior work provide transferable similarity between loop nests.
    Section 4 Optimization Algorithm uses Euclidean distance of performance embeddings to find similar loop nests; this is assumed to select beneficial recipes.

how reviews work

0 comments
Cite this review

Pith. "Pith review of A Priori Loop Nest Normalization: Automatic Loop Scheduling in Complex Applications." pith.science (2026). https://pith.science/paper/PHQBKMST

@misc{pith2026241220179,
  author       = {Pith},
  title        = {Pith review of: A Priori Loop Nest Normalization: Automatic Loop Scheduling in Complex Applications},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/PHQBKMST}},
  note         = {Machine review of arXiv:2412.20179}
}
abstract

The same computations are often expressed differently across software projects and programming languages. In particular, how computations involving loops are expressed varies due to the many possibilities to permute and compose loops. Since each variant may have unique performance properties, automatic approaches to loop scheduling must support many different optimization recipes. In this paper, we propose a priori loop nest normalization to align loop nests and reduce the variation before the optimization. Specifically, we define and apply normalization criteria, mapping loop nests with different memory access patterns to the same canonical form. Since the memory access pattern is susceptible to loop variations and critical for performance, this normalization allows many loop nests to be optimized by the same optimization recipe. To evaluate our approach, we apply the normalization with optimizations designed for only the canonical form, improving the performance of many different loop nest variants. Across multiple implementations of 15 benchmarks using different languages, we outperform a baseline compiler in C on average by a factor of $21.13$, state-of-the-art auto-schedulers such as Polly and the Tiramisu auto-scheduler by $2.31$ and $2.89$, as well as performance-oriented Python-based frameworks such as NumPy, Numba, and DaCe by $9.04$, $3.92$, and $1.47$. Furthermore, we apply the concept to the CLOUDSC cloud microphysics scheme, an actively used component of the Integrated Forecasting System, achieving a 10% speedup over the highly-tuned Fortran code.

Figures

Figures reproduced from arXiv: 2412.20179 by the authors.

Figure 1
Figure 1. Structurally different General Matrix-Matrix Multiply (GEMM) kernels yield significantly different performance. Abstract The same computations are often expressed differently across software projects and programming languages. In particu￾lar, how computations involving loops are expressed varies due to the many possibilities to permute and compose loops. Since each variant may have unique performance properties, aut… view at source ↗
Figure 2
Figure 2. Characterization of loop nests. Computation. We define a computation as a unit of work composed of one or more instructions, where exactly one of the instructions is a write of a scalar value to a data container. Loop. A loop comprises an iterator with its initial values and update criterion, a termination condition, and a loop body composed of a sequence of computations. Loop nest. A loop nest is a loop where the l… view at source ↗
Figure 3
Figure 3. Loop nest code samples subject to normalization. 2.1 Maximal Loop Fission Fusing computations into shared loops is a common tech￾nique to improve performance [25]. However, the combi￾nation of computations usually increases the complexity of memory accesses. An example, shown in Figure 3a, combines two computations with contiguous and strided memory ac￾cesses. Since the developer may apply such compositions manually… view at source ↗
Figures from the paper (9 more)
Figure 4
Figure 4. Figure 4: Lifting a symbolic representation of loop nests with high-level information from source code translated to LLVM IR. 3 Normalization on Intermediate Representations We implement the normalization on LLVM IR to apply to as many codes as possible. In LLVM IR, loops and me…
Figure 5
Figure 5. Figure 5: The normalization pipeline in two steps: Maximal loop fission and stride minimization. Optimization Algorithm. We define a new auto sched￾uler, which applies our normalization passes and then queries optimizations from a database using similarity-based transfer tuning …
Figure 6
Figure 6. Figure 6: Comparison of our model with state-of-the-art auto-scheduling methods and the icc compiler. The runtime is expressed relative to the runtime of the A variant of the benchmarks using daisy. Hence, a lower value is better. The implementation of the Tiramisu scheduler cou…
Figure 7
Figure 7. Figure 7: Comparison of clang and our model with and without normalization. The runtime is expressed relative to A variants of the benchmarks using clang. Hence, a lower value is better. the database queried by the transfer tuning algorithm would need to explicitly enumerate all…
Figure 8
Figure 8. Figure 8: The SYRK kernel implemented in C and NumPy. Baselines. We consider three baselines: NumPy 1.25.2 [19], Numba 0.58.0 [23], and DaCe 0.14.2 [5]. All frameworks use custom operators to call optimized BLAS libraries for specific operations. Besides the operators, Numba and…
Figure 9
Figure 9. Figure 9: Comparison of our model with NumPy-based frameworks implementing custom operators and optimizations for different applications. The runtime is expressed relative to the runtime of daisy . Hence, a lower value is better. compiler that can automatically parallelize and v…
Figure 10
Figure 10. Figure 10: A loop nest taken from from the vertical loop of CLOUDSC before and after normalization and fusion. An important characteristic of the code is the way it ac￾cesses data. The simulated volume is divided into vertical columns, each computed independently. When iterating…
Figure 11
Figure 11. Figure 11: CLOUDSC runtime for sequential execution of the Fortran, C, DaCe, and daisy versions from left to right. The runtime is normalized by the Fortran version. Hence, a lower value is better. Results. We measure the performance of the two versions for a single iteration an…
Figure 12
Figure 12. Figure 12: b. With an optimization of the application’s crit￾ical path, the performance improvements also translate to the parallel execution. We also measure the FLOP/s for For￾tran and daisy and compare it to the peak FLOP/s of the machine. The peak FLOP/s of the machine is me…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

37 extracted references · 22 canonical work pages

  1. [1]

    Aravind Acharya and Uday Bondhugula. 2015. PLUTO+: Near- Complete Modeling of Affine Transformations for Parallelism and Locality. SIGPLAN Not. 50, 8 (jan 2015), 54–64. https://doi.org/10. 1145/2858788.2688512

    arXiv 2015

  2. [2]

    Andrew Adams, Karima Ma, Luke Anderson, Riyadh Baghdadi, Tzu- Mao Li, Michaël Gharbi, Benoit Steiner, Steven Johnson, Kayvon Fa- tahalian, Frédo Durand, and Jonathan Ragan-Kelley. 2019. Learn- ing to Optimize Halide with Tree Search and Random Programs. ACM Trans. Graph. 38, 4, Article 121 (jul 2019), 12 pages. https: //doi.org/10.1145/3306346.3322967

    arXiv 2019

  3. [3]

    Ama- rasinghe

    Riyadh Baghdadi, Massinissa Merouani, Mohamed-Hicham Leghettas, Kamel Abdous, Taha Arbaoui, Karima Benatchba, and Saman P. Ama- rasinghe. 2021. A Deep Learning Based Cost Model for Automatic CGO ’25, March 01–05, 2025, Las Vegas, NV, USA Lukas Trümper, Philipp Schaad, Berke Ates, Alexandru Calotoiu, Marcin Copik, and Torsten Hoefler Code Optimization. In ...

    work page 2021

  4. [4]

    Riyadh Baghdadi, Jessica Ray, Malek Ben Romdhane, Emanuele Del Sozzo, Abdurrahman Akkas, Yunming Zhang, Patricia Suriana, Shoaib Kamil, and Saman Amarasinghe. 2019. Tiramisu: A Polyhedral Compiler for Expressing Fast and Portable Code. In Proceedings of the 2019 IEEE/ACM International Symposium on Code Generation and Optimization (Washington, DC, USA)(CGO...

    work page 2019

  5. [5]

    Ziogas, Timo Schneider, and Torsten Hoefler

    Tal Ben-Nun, Johannes de Fine Licht, Alexandros N. Ziogas, Timo Schneider, and Torsten Hoefler. 2019. Stateful Dataflow Multigraphs: A Data-Centric Model for Performance Portability on Heterogeneous Architectures. In Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis (Denver, Colorado) (SC ’19). As...

    arXiv 2019

  6. [6]

    D’Hollander

    Kristof Beyls and Erik H. D’Hollander. 2001. Reuse Distance as a Metric for Cache Behavior. In In Proceedings of the IASTED Conference on Parallel and Distributed Computing and Systems . 617–662

    work page 2001

  7. [7]

    Ra- manujam, Atanas Rountev, and P

    Uday Bondhugula, Muthu Baskaran, Sriram Krishnamoorthy, J. Ra- manujam, Atanas Rountev, and P. Sadayappan. 2008. Automatic Trans- formations for Communication-Minimized Parallelization and Local- ity Optimization in the Polyhedral Model. In Compiler Construction, Laurie Hendren (Ed.). Springer Berlin Heidelberg, Berlin, Heidelberg, 132–146

    work page 2008

  8. [8]

    Ramanujam, and P

    Uday Bondhugula, Albert Hartono, J. Ramanujam, and P. Sadayap- pan. 2008. A Practical Automatic Polyhedral Parallelizer and Lo- cality Optimizer. SIGPLAN Not. 43, 6 (jun 2008), 101–113. https: //doi.org/10.1145/1379022.1375595

    arXiv 2008

Show all 37 references
  1. [9]

    Callahan

    D. Callahan. 1992. Recognizing and parallelizing bounded recurrences. In Languages and Compilers for Parallel Computing , Utpal Banerjee, David Gelernter, Alex Nicolau, and David Padua (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 169–185

    1992

  2. [10]

    Alexandru Calotoiu, Tal Ben-Nun, Grzegorz Kwasniewski, Johannes de Fine Licht, Timo Schneider, Philipp Schaad, and Torsten Hoefler

  3. [11]

    Lorenzo Chelini, Tobias Gysi, Tobias Grosser, Martin Kong, and Henk Corporaal. 2020. Automatic Generation of Multi-Objective Polyhe- dral Compiler Transformations. In Proceedings of the ACM Interna- tional Conference on Parallel Architectures and Compilation Techniques (Virtua...

    2020 doi

  4. [12]

    Lorenzo Chelini, Oleksandr Zinenko, Tobias Grosser, and Henk Corpo- raal. 2019. Declarative Loop Tactics for Domain-Specific Optimization. ACM Trans. Archit. Code Optim. 16, 4, Article 55 (dec 2019), 25 pages. https://doi.org/10.1145/3372266

    2019 doi

  5. [13]

    Tianqi Chen, Thierry Moreau, Ziheng Jiang, Lianmin Zheng, Eddie Yan, Meghan Cowan, Haichen Shen, Leyuan Wang, Yuwei Hu, Luis Ceze, Carlos Guestrin, and Arvind Krishnamurthy. 2018. TVM: An Automated End-to-End Optimizing Compiler for Deep Learning. In Proceedings of the 13th US...

    2018

  6. [14]

    Edward Grady Coffman and Peter J Denning. 1973. Operating systems theory. Vol. 973. prentice-Hall Englewood Cliffs, NJ

    1973

  7. [15]

    João P. L. De Carvalho, Braedy Kuzma, Ivan Korostelev, José Nelson Amaral, Christopher Barton, José Moreira, and Guido Araujo. 2021. KernelFaRer: Replacing Native-Code Idioms with High-Performance Library Calls. ACM Trans. Archit. Code Optim. 18, 3, Article 38 (jun 2021), 22 p...

    2021 doi

  8. [16]

    Philip Ginsbach, Bruce Collie, and Michael F. P. O’Boyle. 2020. Auto- matically Harnessing Sparse Acceleration. In Proceedings of the 29th International Conference on Compiler Construction (San Diego, CA, USA) (CC 2020). Association for Computing Machinery, New York, NY, USA, ...

    2020

  9. [17]

    Tobias Grosser, Sven Verdoolaege, and Albert Cohen. 2015. Poly- hedral AST Generation Is More Than Scanning Polyhedra. ACM Trans. Program. Lang. Syst. 37, 4, Article 12 (jul 2015), 50 pages. https://doi.org/10.1145/2743016

    2015 doi

  10. [18]

    Tobias Grosser, Hongbin Zheng, Raghesh Aloor, Andreas Simbürger, Armin Größlinger, and Louis-Noël Pouchet. 2011. Polly - Polyhedral optimization in LLVM. http://impact2011.inrialpes.fr/en/index.html First International Workshop on Polyhedral Compilation Techniques, IPACT 2011 ...

    2011

  11. [19]

    Harris, K

    Charles R. Harris, K. Jarrod Millman, St’efan J. van der Walt, Ralf Gommers, Pauli Virtanen, David Cournapeau, Eric Wieser, Julian Taylor, Sebastian Berg, Nathaniel J. Smith, Robert Kern, Matti Picus, Stephan Hoyer, Marten H. van Kerkwijk, Matthew Brett, Allan Hal- dane, Jaime...

    2020

  12. [20]

    Torsten Hoefler and Roberto Belli. 2015. Scientific Benchmarking of Parallel Computing Systems: Twelve Ways to Tell the Masses When Reporting Performance Results. In Proceedings of the Interna- tional Conference for High Performance Computing, Networking, Stor- age and Analysi...

    2015

  13. [21]

    Richard Johnson, David Pearson, and Keshav Pingali. 1994. The Pro- gram Structure Tree: Computing Control Regions in Linear Time. SIG- PLAN Not. 29, 6 (jun 1994), 171–185. https://doi.org/10.1145/773473. 178258

    1994 doi

  14. [22]

    Martin Kong and Louis-Noël Pouchet. 2019. Model-Driven Trans- formations for Multi- and Many-Core CPUs. In Proceedings of the 40th ACM SIGPLAN Conference on Programming Language Design and Implementation (Phoenix, AZ, USA) (PLDI 2019) . Association for Computing Machinery, New...

    2019

  15. [23]

    Siu Kwan Lam, Antoine Pitrou, and Stanley Seibert. 2015. Numba: A LLVM-Based Python JIT Compiler. In Proceedings of the Second Workshop on the LLVM Compiler Infrastructure in HPC (Austin, Texas) (LLVM ’15). Association for Computing Machinery, New York, NY, USA, Article 7, 6 p...

    2015

  16. [24]

    Lim, Gerald I

    Amy W. Lim, Gerald I. Cheong, and Monica S. Lam. 1999. An Affine Partitioning Algorithm to Maximize Parallelism and Mini- mize Communication. In Proceedings of the 13th International Con- ference on Supercomputing (Rhodes, Greece) (ICS ’99) . Association for Computing Machiner...

    1999

  17. [25]

    Sanyam Mehta, Pei-Hung Lin, and Pen-Chung Yew. 2014. Revisit- ing Loop Fusion in the Polyhedral Framework. In Proceedings of the 19th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming (PPoPP) (PPoPP ’14) . http://www-users.cs.umn.edu/ ~sanyam/publication...

    2014

  18. [26]

    Lina Mezdour, Khadidja Kadem, Massinissa Merouani, Amina Selma Haichour, Saman Amarasinghe, and Riyadh Baghdadi. 2023. A Deep Learning Model for Loop Interchange. In Proceedings of the 32nd ACM SIGPLAN International Conference on Compiler Construction (Montréal, QC, Canada) (C...

    2023

  19. [27]

    Julian Miller, Lukas Trümper, Christian Terboven, and Matthias S. Müller. 2021. A Theoretical Model for Global Optimization of Par- allel Algorithms. Mathematics 9, 14 (2021). https://doi.org/10.3390/ math9141685

    2021

  20. [28]

    Pinter and Ron Y

    Shlomit S. Pinter and Ron Y. Pinter. 1994. Program Optimization and Parallelization Using Idioms. ACM Trans. Program. Lang. Syst. 16, 3 (may 1994), 305–327. https://doi.org/10.1145/177492.177494

    1994

  21. [29]

    Louis-Noël Pouchet and Tomofumi Yuki. 2017. PolyBench: The poly- hedral benchmark suite (version 4.2)

    2017

  22. [30]

    Philipp Schaad, Tal Ben-Nun, and Torsten Hoefler. 2022. Boosting Performance Optimization with Interactive Data Movement Visualiza- tion. In Proceedings of the International Conference on High Performance Computing, Networking, Storage and Analysis (Dallas, Texas) (SC ’22). IE...

    2022

  23. [31]

    Shikhar Singh, James Hegarty, Hugh Leather, and Benoit Steiner. 2022. A Graph Neural Network-Based Performance Model for Deep Learning Applications. In Proceedings of the 6th ACM SIGPLAN International Symposium on Machine Programming (San Diego, CA, USA) (MAPS 2022). Associati...

    2022

  24. [32]

    Benoit Steiner, Chris Cummins, Horace He, and Hugh Leather. 2021. Value Learning for Throughput Optimization of Deep Learning Work- loads. In Proceedings of Machine Learning and Systems , A. Smola, A. Di- makis, and I. Stoica (Eds.), Vol. 3. 323–334. https://proceedings.mlsys....

    2021

  25. [33]

    Lukas Trümper, Tal Ben-Nun, Philipp Schaad, Alexandru Calotoiu, and Torsten Hoefler. 2023. Performance Embeddings: A Similarity- Based Transfer Tuning Approach to Performance Optimization. In Proceedings of the 37th International Conference on Supercomputing (Orlando, FL, USA)...

    2023

  26. [34]

    Chamberlain, Romain Cledat, H

    Didem Unat, Anshu Dubey, Torsten Hoefler, John Shalf, Mark Abraham, Mauro Bianco, Bradford L. Chamberlain, Romain Cledat, H. Carter Edwards, Hal Finkel, Karl Fuerlinger, Frank Hannig, Em- manuel Jeannot, Amir Kamil, Jeff Keasler, Paul H J Kelly, Vitus Leung, Hatem Ltaief, Naoy...

    2017

  27. [35]

    Sven Verdoolaege. 2010. isl: An Integer Set Library for the Polyhe- dral Model. In Mathematical Software – ICMS 2010 , Komei Fukuda, Joris van der Hoeven, Michael Joswig, and Nobuki Takayama (Eds.). Springer Berlin Heidelberg, Berlin, Heidelberg, 299–302

    2010

  28. [36]

    Alexandros Nikolaos Ziogas, Tal Ben-Nun, Timo Schneider, and Torsten Hoefler. 2021. NPBench: A Benchmarking Suite for High- Performance NumPy. In Proceedings of the ACM International Con- ference on Supercomputing (Virtual Event, USA) (ICS ’21) . Associa- tion for Computing Ma...

    2021

  29. [2022]

    In Proceedings of the 36th ACM International Conference on Supercomputing (Virtual Event) (ICS ’22)

    Lifting C Semantics for Dataflow Optimization. In Proceedings of the 36th ACM International Conference on Supercomputing (Virtual Event) (ICS ’22). Association for Computing Machinery, New York, NY, USA, Article 17, 13 pages. https://doi.org/10.1145/3524059.3532389

Pith tools

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