Pith. sign in

REVIEW 3 major objections 1 minor 23 references

nomp: A Framework for Building Domain Specific Compilers

T0 review · 3 major / 1 minor · reviewed 2026-06-27 · grok-4.3

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

Pith's one-line read nomp is a pragma-based framework where user metadata drives a runtime to transform code using domain-specific optimization patterns.

desk verdict nomp is a high-level proposal for a pragma-plus-metadata framework to build domain-specific compilers, but it stays at the outline stage with no implementation, examples, or results. read the letter →

arxiv 2606.12650 v1 pith:KVRQ4CFM submitted 2026-06-10 cs.PL cs.PF

Thilina Ratnayaka , Kaushik Kulkarni , Nipuna Fernando , Pubudu Hewavitharana , Hirumal Priyashan , Poorna Gunathilaka , Nagitha Abeywickrema , Ravindu Hirimuthugoda
show 3 more authors
Tarun Prabhu Kirshanthan Sundararajah Sanath Jayasena
This is my paper · ORCID
classification cs.PLcs.PF
keywords domainspecificcompilerspragmabasedprogrammingGPUcodegenerationmetadatadriventransformationperformanceportabilityprogrammerproductivityruntime
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

The paper argues that low-level GPU models deliver performance at the cost of productivity while high-level models do the reverse, and that domain-specific reuse of optimization patterns can reduce this trade-off. nomp supplies a pragma programming model plus a runtime that reads user metadata to perform the transformations and code generation needed for those patterns. A sympathetic reader would care because the approach targets the middle ground where experts encode reusable patterns once and others obtain close-to-metal results without writing the low-level details themselves.

What carries the argument

The nomp runtime that interprets structured user metadata to drive code transformations and generation for domain-specific optimizations.

What would settle it

A side-by-side benchmark in which nomp-generated code for a concrete domain task runs within a few percent of equivalent hand-written CUDA or HIP code while the source remains only pragmas and metadata.

Watch

Extended reading notes

Core claim

nomp consists of a pragma based programming model and a runtime capable of code transformation and generation based on user provided metadata, enabling reuse of optimization patterns specific to a given domain without sacrificing performance or portability.

Load-bearing premise

User-provided metadata can be structured and interpreted by the runtime so that the resulting code transformations reliably achieve performance on par with hand-written low-level models across domains.

Editorial extensions

If this is right

  • Domain experts encode optimization patterns once as metadata and the runtime applies them to multiple programs.
  • Programmers write at the pragma level yet obtain transformations that target specific GPU execution plans.
  • The same metadata-driven process supports portability across low-level backends such as CUDA, HIP, and OpenCL.
  • Productivity rises because the low-level details are generated rather than written by each developer.

Reading between the lines

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

  • If metadata schemas prove stable, the same runtime could host multiple domain-specific compilers without rewriting the transformation engine each time.
  • The approach could be tested by measuring how much less code a developer must write to reach a target performance level compared with direct use of CUDA.
  • Extending the metadata format to capture data-layout decisions or kernel-fusion rules would be a natural next step the paper leaves open.
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, simulated authors' rebuttal, and a circularity audit.

Referee Report

3 major / 1 minor

Summary. The manuscript proposes nomp, a framework for building domain-specific compilers. It consists of a pragma-based programming model and a runtime for code transformation and generation driven by user-provided metadata. The goal is to improve programmer productivity for GPU programming (relative to CUDA/HIP/OpenCL) without sacrificing performance or portability, by reusing domain-specific optimization patterns that high-level models like OpenMP/OpenACC have not yet achieved.

Significance. If the framework could be realized such that metadata reliably drives transformations matching hand-tuned performance across domains, the work would address a long-standing tension in heterogeneous computing between productivity and performance. The proposal itself, however, supplies only a high-level outline with no concrete metadata schema, transformation rules, implementation, or evaluation, so any significance remains prospective.

major comments (3)
  1. [Abstract] Abstract (paragraph beginning 'However, we believe there is room...'): The central claim that user-provided metadata can be structured and interpreted by the runtime to achieve performance on par with hand-written low-level models is stated as the motivating assumption, yet the manuscript supplies no metadata format, no transformation rules, and no code-generation mechanism, rendering the claim untestable from the given text.
  2. [Abstract] Abstract: No implementation details, transformation examples, or experimental results are presented to support the assertion that the runtime can deliver performance and portability comparable to low-level models while improving productivity; this absence is load-bearing because the entire contribution is framed as a practical framework rather than a purely conceptual sketch.
  3. [Abstract] Abstract: The paper does not indicate how domain-specific optimization patterns are identified, encoded in metadata, or reused across applications, nor does it address integration with existing pragma models (OpenMP, OpenACC) or handling of portability across GPU vendors; these omissions prevent assessment of whether the proposed design can actually close the stated productivity-performance gap.
minor comments (1)
  1. [Abstract] The abstract uses the term 'user provided metadata' without defining its structure or scope; a brief illustrative example would clarify the intended interface.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for the detailed review and constructive feedback on our manuscript. We acknowledge that the current version presents nomp primarily as a high-level conceptual proposal rather than a fully specified and evaluated implementation. We will revise the abstract and add clarifying text to better align reader expectations with the scope of the work.

read point-by-point responses

  1. Referee: [Abstract] Abstract (paragraph beginning 'However, we believe there is room...'): The central claim that user-provided metadata can be structured and interpreted by the runtime to achieve performance on par with hand-written low-level models is stated as the motivating assumption, yet the manuscript supplies no metadata format, no transformation rules, and no code-generation mechanism, rendering the claim untestable from the given text.

    Authors: We agree that the manuscript does not supply a concrete metadata format, transformation rules, or code-generation mechanism. The work is framed as a proposal for a framework that reuses domain-specific optimization patterns via metadata, rather than a complete specification or implementation. We will revise the abstract to explicitly characterize the contribution as a high-level design proposal, with the detailed schema and rules reserved for future development. This will make the claim's prospective nature clear. revision: yes

  2. Referee: [Abstract] Abstract: No implementation details, transformation examples, or experimental results are presented to support the assertion that the runtime can deliver performance and portability comparable to low-level models while improving productivity; this absence is load-bearing because the entire contribution is framed as a practical framework rather than a purely conceptual sketch.

    Authors: The referee is correct that no implementation details, examples, or results appear in the manuscript. The paper is positioned as a proposal for the nomp framework and runtime concept, not as an evaluation of a deployed system. We will revise the abstract and introduction to state this scope explicitly and to frame the contribution as a conceptual outline rather than a practical, evaluated framework. This addresses the framing concern directly. revision: yes

  3. Referee: [Abstract] Abstract: The paper does not indicate how domain-specific optimization patterns are identified, encoded in metadata, or reused across applications, nor does it address integration with existing pragma models (OpenMP, OpenACC) or handling of portability across GPU vendors; these omissions prevent assessment of whether the proposed design can actually close the stated productivity-performance gap.

    Authors: We acknowledge that the manuscript provides only a high-level description and does not detail how patterns would be identified, encoded, reused, integrated with OpenMP/OpenACC, or made portable across vendors. As this is a proposal, we will add a dedicated section outlining possible approaches to metadata encoding, pattern reuse, and compatibility considerations. This will allow readers to assess the design direction without requiring a full implementation at this stage. revision: partial

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity identified

full rationale

The manuscript is a high-level design proposal for the nomp framework (pragma-based model plus metadata-driven runtime) with no equations, fitted parameters, predictions, or derivation chain. The central claim—that domain-specific metadata can enable performance-competitive transformations—rests on future implementation and evaluation rather than any self-referential reduction or self-citation load-bearing step. No load-bearing premise reduces to its own inputs by construction, making the argument self-contained as an outline of intended work.

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

The proposal rests on one domain assumption about the existence and reusability of domain-specific optimization patterns via metadata; it introduces the nomp framework itself as the central new entity. No free parameters are visible. Assessment is limited because only the abstract is available.

assumptions (1)
  • domain assumption Domain-specific optimization patterns exist that can be captured by user-supplied metadata and applied by a runtime to reach performance parity with low-level models
    This premise is required for the claim that productivity can be improved without sacrificing performance or portability.
invented entities (1)
  • nomp framework
    purpose: Provide a pragma model and runtime for constructing domain-specific compilers
    The framework is the central artifact proposed in the abstract.

how reviews work

0 comments
Cite this review

Pith. "Pith review of nomp: A Framework for Building Domain Specific Compilers." pith.science (2026). https://pith.science/paper/KVRQ4CFM

@misc{pith2026260612650,
  author       = {Pith},
  title        = {Pith review of: nomp: A Framework for Building Domain Specific Compilers},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/KVRQ4CFM}},
  note         = {Machine review of arXiv:2606.12650}
}
read the original abstract

The low-level GPU programming models (CUDA, HIP, OpenCL, etc.) provide detailed control of the data flow and execution plan of a program in order to extract close-to-metal performance. However, these have a steep learning curve due to the intricacies of their syntax and semantics. This reduces programmer productivity. On the other hand, high-level models (OpenMP, OpenACC, etc.) that serve as abstractions over the low-level models are aimed at improving programmer productivity but achieving performance on-par with the low-level models is a challenge. There are inherent trade-offs between productivity, portability and performance in both approaches and there is no one-size-fits-all solution which achieves all three simultaneously. However, we believe there is room to improve programmer productivity without sacrificing performance and portability by reusing optimization patterns specific to a given domain. To this end, we propose nomp: a framework for building domain specific compilers. nomp consists of a pragma based programming model and a runtime capable of code transformation and generation based on user provided metadata.

Figures

Figures reproduced from arXiv: 2606.12650 by the authors.

Figure 1
Figure 1. A vector scaling program written for CPUs with C (left) and for GPUs with CUDA (right). [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Syntax of the nomp directives and clauses sup [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. A domain specific transformation script for the [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (9 more)
Figure 4
Figure 4. Figure 4: A kernel specific transformation function for the [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]
Figure 5
Figure 5. Figure 5: illustrates the nomp workflow, beginning with the user annotating the C source with nomp directives and clauses followed by compilation of the C program using nompcc. nompcc links libnomp library during the linking phase of the user program. At runtime, libnomp uses lo…
Figure 6
Figure 6. Figure 6: Mandelbrot C implementation on GPUs with [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]
Figure 7
Figure 7. Figure 7: HIP-variable vs. nomp Nekbone performance for N = 4 on a single GCD of AMD MI250X GPU on Frontier supercomputer at OLCF. 2 2 2 4 2 6 2 8 2 10 2 12 2 14 Number of elements 0.0 0.2 0.4 0.6 0.8 1.0 1.2 1.4 1.6 Residual ×10−6 Residual: HIP-variable vs nomp, N = 6 HIP-varia…
Figure 8
Figure 8. Figure 8: HIP-variable vs. nomp Nekbone performance for N = 6 on a single GCD of AMD MI250X GPU on Frontier supercomputer at OLCF. 2 2 2 4 2 6 2 8 2 10 2 12 2 14 Number of elements 0.0 0.5 1.0 1.5 2.0 2.5 3.0 3.5 Residual ×10−7 Residual: HIP-variable vs nomp, N = 8 HIP-variable …
Figure 9
Figure 9. Figure 9: HIP-variable vs. nomp Nekbone performance for N = 8 on a single GCD of AMD MI250X GPU on Frontier supercomputer at OLCF [PITH_FULL_IMAGE:figures/full_fig_p009_9.png]
Figure 10
Figure 10. Figure 10: HIP-fixed vs. nomp Nekbone performance for N = 4 on a single GCD of AMD MI250X GPU on Frontier supercomputer at OLCF. 2 2 2 4 2 6 2 8 2 10 2 12 2 14 Number of elements 0.0 0.2 0.4 0.6 0.8 1.0 1.2 1.4 1.6 Residual ×10−6 Residual: HIP-fixed vs nomp, N = 6 HIP-fixed nomp…
Figure 11
Figure 11. Figure 11: HIP-fixed vs. nomp Nekbone performance for N = 6 on a single GCD of AMD MI250X GPU on Frontier supercomputer at OLCF. 2 2 2 4 2 6 2 8 2 10 2 12 2 14 Number of elements 0.0 0.5 1.0 1.5 2.0 2.5 3.0 3.5 Residual ×10−7 Residual: HIP-fixed vs nomp, N = 8 HIP-fixed nomp (a)…
Figure 12
Figure 12. Figure 12: HIP-fixed vs. nomp Nekbone performance for N = 8 on a single GCD of AMD MI250X GPU on Frontier supercomputer at OLCF [PITH_FULL_IMAGE:figures/full_fig_p010_12.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

23 extracted references · 1 canonical work pages

  1. [1]

    TOP500 List - June 2024,

    TOP500.org, “TOP500 List - June 2024,” 2024, accessed: 2024-06-04. [Online]. Available: https://top500.org/lists/top500/ 2024/06/

    2024

  2. [2]

    Exascale computing project,

    Exascale Computing Project, “Exascale computing project,” 2024, accessed: 2024-10-10. [Online]. Available: https://www. exascaleproject.org

    2024

  3. [3]

    Cuda c programming guide,

    NVIDIA Corporation, “Cuda c programming guide,” 2024, accessed: 2024-06-15. [Online]. Available: https://docs.nvidia. com/cuda/cuda-c-programming-guide/

    2024

  4. [4]

    Hip documentation,

    AMD, “Hip documentation,” 2024, accessed: 2024-06-15. [Online]. Available: https://rocm.docs.amd.com/projects/HIP/en/ latest/

    2024

  5. [5]

    Opencl registry,

    Khronos Group, “Opencl registry,” 2024, accessed: 2024-06-15. [Online]. Available: https://registry.khronos.org/OpenCL/

    2024

  6. [6]

    Openmp api specification 5.2,

    OpenMP Architecture Review Board, “Openmp api specification 5.2,” 2020. [Online]. Available: https://www.openmp.org/ wp-content/uploads/OpenMP-API-Specification-5-2.pdf

    2020

  7. [7]

    OpenACC 3.2 specification,

    OpenACC, “OpenACC 3.2 specification,” Tech. Rep., Sep. 2020. [Online]. Available: https://www.openacc.org/sites/default/files/ inline-images/Specification/OpenACC-3.2-final.pdf

    2020

  8. [8]

    User-directed loop-transformations in clang,

    M. Kruse and H. Finkel, “User-directed loop-transformations in clang,” in 2018 IEEE/ACM 5th Workshop on the LLVM Compiler Infrastructure in HPC (LLVM-HPC) . IEEE, 2018, pp. 49–58

    2018

Show all 23 references
  1. [9]

    Polly-polyhedral optimization in llvm,

    T. Grosser, H. Zheng, R. Aloor, A. Simb ¨urger, A. Gr ¨oßlinger, and L.-N. Pouchet, “Polly-polyhedral optimization in llvm,” in Proceedings of the First International Workshop on Polyhedral Compilation Techniques (IMPACT), vol. 2011, 2011, p. 1

    2011

  2. [10]

    A language for the compact representation of multiple program versions,

    S. Donadio, J. Brodman, T. Roeder, K. Yotov, D. Barthou, A. Cohen, M. J. Garzar ´an, D. Padua, and K. Pingali, “A language for the compact representation of multiple program versions,” in Languages and Compilers for Parallel Computing: 18th Inter- national Workshop, LCPC 2005,...

    2005

  3. [11]

    Nekrs, a gpu-accelerated spectral element navier-stokes solver,

    P. Fischer, S. Kerkemeier, M. Min, Y .-H. Lan, M. Phillips, T. Rathnayake, E. Merzari, A. Tomboulides, A. Karakus, N. Chalmers et al. , “Nekrs, a gpu-accelerated spectral element navier-stokes solver,” arXiv preprint arXiv:2104.05829 , 2021

    2021

  4. [12]

    libparanumal: a performance portable high-order finite element library,

    N. Chalmers, A. Karakus, A. Austin, K. Swirydowicz, and T. Warburton, “libparanumal: a performance portable high-order finite element library,” Release 0.4. 0 , 2020

    2020

  5. [13]

    Loo.py: transformation-based code generation for gpus and cpus,

    A. Kl ¨ockner, “Loo.py: transformation-based code generation for gpus and cpus,” in Proceedings of ACM SIGPLAN international workshop on libraries, languages, and compilers for array pro- gramming, 2014, pp. 82–87

    2014

  6. [14]

    Openmp: an industry standard api for shared-memory programming,

    L. Dagum and R. Menon, “Openmp: an industry standard api for shared-memory programming,” IEEE Computational Science and Engineering, vol. 5, no. 1, pp. 46–55, 1998

    1998

  7. [15]

    Llvm and clang: Next generation compiler technol- ogy,

    C. Lattner, “Llvm and clang: Next generation compiler technol- ogy,” in The BSD conference , vol. 5, 2008, pp. 1–20

    2008

  8. [16]

    Kl ¨ockner

    A. Kl ¨ockner. (2016) Loopy documentation - reference: Kernels. Accessed: 2023-12-23. [Online]. Available: https://documen. tician.de/loopy/ref kernel.html

    2016

  9. [17]

    libclang: C interface to clang,

    LLVM Project, “libclang: C interface to clang,” 2024, accessed: 2024-06-15. [Online]. Available: https://clang.llvm.org/doxygen/ group CINDEX.html

    2024

  10. [18]

    Hipbone: A performance-portable graphics processing unit- accelerated c++ version of the nekbone benchmark,

    N. Chalmers, A. Mishra, D. McDougall, and T. Warburton, “Hipbone: A performance-portable graphics processing unit- accelerated c++ version of the nekbone benchmark,” The Inter- national Journal of High Performance Computing Applications , vol. 37, no. 5, pp. 560–577, 2023

    2023

  11. [19]

    Nekbone performance on gpus with openacc and cuda fortran implementations,

    J. Gong, S. Markidis, E. Laure, M. Otten, P. Fischer, and M. Min, “Nekbone performance on gpus with openacc and cuda fortran implementations,” The Journal of Supercomputing , vol. 72, pp. 4160–4180, 2016

    2016

  12. [20]

    Nek5000: Open source spectral element CFD solver. http://nek5000.mcs.anl.gov and https://github.com/nek5000/nek5000,

    P. Fischer, J. Lottes, and S. Kerkemeier, “Nek5000: Open source spectral element CFD solver. http://nek5000.mcs.anl.gov and https://github.com/nek5000/nek5000,” 2008

    2008

  13. [21]

    OLCF Frontier,

    “OLCF Frontier,” https://www.olcf.ornl.gov/frontier/

  14. [22]

    Gropp, E

    W. Gropp, E. Lusk, and A. Skjellum, Using MPI: Portable Parallel Programming with the Message-Passing Interface, 2nd edition. Cambridge, MA: MIT Press, 1999

    1999

  15. [23]

    Hip runtime compilation user guide,

    AMD, “Hip runtime compilation user guide,” https://rocm.docs. amd.com/projects/HIP/en/docs-6.0.0/user guide/hip rtc.html, 2024, accessed: 2024-07-01

    2024

Pith tools

Reviewed June 27, 2026 · model on record in the stance chip above.