Pith. sign in

REVIEW 4 major objections 6 minor 17 references

OMP4Py: a pure Python implementation of OpenMP

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

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

Pith's one-line read OMP4Py is a pure Python implementation of OpenMP 3.0 that brings directive-based shared-memory parallelism to Python and demonstrates strong scaling on non-numerical and hybrid MPI workloads.

desk verdict A genuinely useful pure-Python OpenMP layer; the real problem is the unverified 'complete OpenMP 3.0' claim, which should be either demonstrated or trimmed. read the letter →

arxiv 2411.14887 v2 pith:MM5HUB72 submitted 2024-11-22 cs.DC cs.PL

César Piñeiro , Juan C. Pichel This is my paper · ORCID
classification cs.DCcs.PL
keywords OpenMPPythonmultithreadingfree-threadeddirective-basedparallelismASTtransformationmpi4pyhybridscalability
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

OMP4Py claims to be the first pure Python implementation of the OpenMP parallel programming model, covering the complete OpenMP 3.0 specification. It brings directive-style parallelism to Python through an @omp decorator and with omp("...") blocks, which are rewritten at module load time into threaded Python code. The paper reports that this works with the same control as OpenMP in C, C++, or Fortran, and shows measurable gains: 25.5x speedup at 48 threads for a non-numerical word-count benchmark, and hybrid MPI+OpenMP scaling. For numerical applications, current speedups are modest, which the authors attribute to the still-experimental free-threaded interpreter in Python 3.13 rather than to OMP4Py itself.

What carries the argument

The load-bearing mechanism is source-to-source transformation driven by the @omp decorator and the with omp("directive") syntax. At import time the decorator reads the function's source, builds an abstract syntax tree with Python's ast module, rewrites each directive into nested functions and calls to OMP4Py's runtime (omp_parallel_run, omp_range, omp_section, omp_task_submit, omp_copyprivate_set/get), and compiles the result back to bytecode. The runtime then manages threads, context stacks stored in threading.local, barriers, mutexes, and shared task queues entirely with Python's standard library.

What would settle it

Port an OpenMP 3.0 conformance suite or the specification's own examples to OMP4Py and compare outputs against a C OpenMP implementation; any mis-scoped private variable, missing lastprivate update, or failed taskwait in a public construct would refute the completeness claim. A second check: rerun the pi-style numerical benchmark on a future stable free-threaded Python release; if pure-Python numerical loops still fail to scale with thread count, the paper's attribution of the bottleneck to interpreter immaturity is wrong.

Watch

Extended reading notes

Core claim

The central claim is that OpenMP's directive-based model can be transplanted into Python without a compiler: OMP4Py parses the source of @omp-decorated functions, rewrites the abstract syntax tree, and replaces each directive with a nested function plus runtime calls that create and coordinate Python threads. The paper asserts full support for the OpenMP 3.0 API, including parallel regions, worksharing constructs, tasking, synchronization, scheduling clauses, data-environment clauses, and runtime functions. On that basis it argues that Python developers can write parallel code with the same level of control as in compiled OpenMP languages. The experimental section shows that non-numerical workloads scale well, that OMP4Py's own overhead is below 0.2%, and that numerical scaling is currently capped by issues in Python 3.13's free-threading support, a limitation the paper expects to disappear as the interpreter matures.

Load-bearing premise

The whole case rests on the rewrite step behaving exactly like a C OpenMP compiler for every directive; the paper only shows a few examples and offers no conformance tests.

Editorial extensions

If this is right

  • Non-numerical Python applications that use dictionaries, strings, and external libraries such as NetworkX can be parallelized with OpenMP-style directives and scale to tens of threads, reaching 25.5x speedup at 48 threads.
  • Existing mpi4py programs can add OMP4Py within each MPI rank to exploit shared memory, producing hybrid parallel codes that scale across nodes.
  • The negligible single-thread overhead, under 0.2%, means adding @omp and with omp blocks does not penalize sequential runs.
  • As Python's free-threaded interpreter stabilizes, numerical OMP4Py applications are expected by the authors to regain scalability without changes to OMP4Py itself.
  • OMP4Py covers a broader range of Python code than JIT-based OpenMP prototypes, which cannot compile external libraries or Python objects inside parallel regions.

Reading between the lines

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

  • If free-threaded Python matures, source-level directive rewriting could become a standard way to add shared-memory parallelism to existing Python codebases without rewriting them in C.
  • The paper's completeness claim is undertested: a public conformance suite for OpenMP 3.0 constructs in Python would be the natural next deliverable, and until it exists the 'full 3.0' statement should be read as a design goal with representative demonstrations.
  • The same AST-rewrite approach would likely stop at shared-memory OpenMP features; target offload and task dependencies require data-movement and memory semantics that pure Python threads cannot directly supply.
  • Because the bottleneck for numerical code is the interpreter rather than the directive machinery, OMP4Py's performance trajectory is tied to CPython's free-threading roadmap, not to the library itself.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 6 minor

Summary. OMP4Py is presented as the first pure-Python implementation of OpenMP. It exposes OpenMP-like directives through a context-manager API (with omp("...")) and an @omp decorator that rewrites the function's AST at import time, plus runtime library functions, with all threading executed natively via Python threads. The manuscript claims full support for the OpenMP 3.0 specification, illustrates the transformation for parallel, for, sections, single, task/taskwait, critical, and several data-environment clauses, and evaluates scalability on numerical benchmarks, non-numerical applications (graph clustering, wordcount), and a hybrid mpi4py+OMP4Py Jacobi solver. The main reported results are that numerical apps scale poorly under Python 3.13 free-threading (attributed to interpreter limitations), non-numerical apps reach 25.5x speedup at 48 threads, and hybrid MPI+OpenMP scales well up to 8 nodes.

Significance. If the completeness and semantic-fidelity claims are established, this is a useful and timely contribution: it is, to the reviewer's knowledge, the first attempt to bring the OpenMP directive model to pure Python using AST-based transformation, and it targets the recently introduced free-threaded Python 3.13, where such a library could have broad adoption. Strengths of the paper are the public repository, the clear worked examples of the AST transformations, the inclusion of non-numerical applications that are outside PyOMP/Numba's domain, a statistical check (Wilcoxon) for the single-thread overhead, and the demonstration that OMP4Py combines with mpi4py, which PyOMP cannot. The significance is conditional: the central claim of complete OpenMP 3.0 support is asserted rather than verified, and a described taskwait implementation appears to deviate from the OpenMP semantics.

major comments (4)
  1. [Section 3 (opening paragraph) and Section 5] Support for the complete OpenMP 3.0 specification is the load-bearing claim of the paper, and the manuscript provides no evidence for it. The evaluation and examples cover only a subset of the specification: the paper shows parallel, for, sections, single, task, taskwait, critical, and the clauses private, firstprivate, lastprivate, shared, reduction, copyprivate, collapse, and schedule. An OpenMP 3.0 conformance claim must also account for, among others, atomic, ordered, flush, master, threadprivate, copyin, default(none), omp_get_max_threads and the OMP_NUM_THREADS/OMP_SCHEDULE environment variables, none of which is tested or even inventoried. The paper's own background (Section 2.1) describes only the 'OpenMP Common Core' subset, which is narrower than OpenMP 3.0. Please provide a conformance suite with a coverage matrix and results for the full claimed surface, or explicitly reduce the claim to the implemented subset; the phrases 'complete specifications of version 3.0' and 'same level of control' cannot be evaluated otherwise.
  2. [Section 3.4] The taskwait implementation is described as follows: 'The omp taskwait function ensures that a thread consumes tasks from the shared list, only returning when the list is empty.' This is not OpenMP 3.0 taskwait semantics, which requires waiting only for completion of the current task's child tasks, not draining a team-wide task queue. As described, the implementation can wait for tasks created by other tasks or deadlock if new tasks are continually added, and it may execute tasks that are not children of the current task. Because tasking is part of the central 'complete OpenMP 3.0' claim, this semantic divergence should be corrected or explicitly justified with conformance tests.
  3. [Sections 4.1-4.3] Performance results are reported as averages over 10 runs without standard deviations, error bars, or confidence intervals. The key quantitative claims (3.18x best numerical speedup, 21.7x Cython pi speedup, 25.5x wordcount speedup, 4.85x hybrid speedup at 8 nodes) are therefore not assessable against run-to-run variability. Since these numbers are used to support the conclusion that OMP4Py 'significantly impacts' performance, please add per-thread-count variability measures (min/max, std, or CI) and state whether the reported differences are statistically significant.
  4. [Section 4.1] The conclusion that the poor numerical scalability 'can only be explained by' Python 3.13 free-threading limitations is stronger than the evidence. The comparison of OMP4Py with manual pure-Python distribution and with a Cython-compiled compute function shows that OMP4Py's iteration-distribution overhead is not the cause, but it does not isolate the interpreter (e.g., per-thread allocation, GC, or free-threading bugs) as the factor; a compiled Cython function may also behave differently with respect to the GIL. A direct experiment comparing free-threaded and GIL builds, or thread-contention profiling, is needed to support the attribution. This is a central conclusion of the experimental section and should be toned down or backed by such a test.
minor comments (6)
  1. [Figure 4] The user code in the top panel has 'for i in range(4): x = j', which uses an undefined j and incorrectly reuses i; it should presumably be 'for j in range(4)'.
  2. [Figure 10] The middle code listing calls omp4py.omp_get_num_threads() and omp4py.omp_get_thread_num(), but the paper's other listings import with 'from omp4py import *'; the module-qualified form requires an explicit 'import omp4py' that is not shown.
  3. [Section 3.3] The text refers to the 'taskwait clause'; taskwait is a directive, not a clause.
  4. [General] The manuscript does not state a repository version or commit hash for the OMP4Py code or the exact software environment used for the hybrid cluster experiments; pinning these would improve reproducibility.
  5. [Section 2.1] The characterization of Python iterators as 'sequential' while C++ iterators allow random access is imprecise: Python range objects support indexing; the relevant point is that arbitrary Python iterators are not random-access.
  6. [Abstract] Minor grammar issue: 'threading limitation ... reduce its effectiveness' should be 'reduces its effectiveness'.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: OMP4Py is presented as a software implementation with empirical benchmarks, and its central claims do not reduce to their own inputs.

full rationale

This paper is a systems/implementation contribution, not a derivation. The central claims are that OMP4Py is a pure Python OpenMP implementation, that it supports the full OpenMP 3.0 specification, and that it scales on non-numerical and hybrid MPI workloads. These claims are supported by code examples, AST-transformation descriptions, and execution measurements against sequential baselines, PyOMP, and mpi4py. No parameter is fitted to data and then renamed as a prediction; no quantity is defined in terms of the result it is supposed to establish. The only self-citation of note is reference [9], the authors' prior IgnisHPC work, which appears in a list of multiprocessing-based frameworks and is not load-bearing for the paper's novelty or performance conclusions. The strongest unsupported assertion is the claim of 'complete specifications of version 3.0' support, which is not backed by a conformance test suite or a full construct-by-construct enumeration. That is a verification and completeness concern, not a circularity concern: an unsupported claim is different from a claim that is true by construction or by self-citation. The benchmark comparisons are external and falsifiable, and the paper's scalability analysis explicitly attributes numerical slowdowns to CPython 3.13 free-threading issues rather than to its own implementation. Therefore, no circular step can be exhibited, and the honest finding is no significant circularity.

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

The paper introduces no new physical or mathematical entities; it is a software contribution. The free parameters list is empty because no model parameters are fitted. The key assumptions are the correctness and maturity of free-threaded CPython and the semantic fidelity of the AST rewriting process.

assumptions (2)
  • domain assumption Python 3.13 with --disable-gil provides correctly synchronized multithreaded execution for Python objects.
    OMP4Py relies on free-threaded CPython for its threading model; the paper itself acknowledges over 100 open free-threading issues (Section 4.1), so this is an assumption with acknowledged risk.
  • ad hoc to paper AST-based transformation preserves the intended program semantics for the supported OpenMP constructs.
    The correctness of OMP4Py depends on the decorator rewriting user source into equivalent threaded code; the paper shows example transformations but provides no formal verification or conformance test suite.

how reviews work

0 comments
Cite this review

Pith. "Pith review of OMP4Py: a pure Python implementation of OpenMP." pith.science (2026). https://pith.science/paper/MM5HUB72

@misc{pith2026241114887,
  author       = {Pith},
  title        = {Pith review of: OMP4Py: a pure Python implementation of OpenMP},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/MM5HUB72}},
  note         = {Machine review of arXiv:2411.14887}
}
read the original abstract

Python demonstrates lower performance in comparison to traditional high performance computing (HPC) languages such as C, C++, and Fortran. This performance gap is largely due to Python's interpreted nature and the Global Interpreter Lock (GIL), which hampers multithreading efficiency. However, the latest version of Python includes the necessary changes to make the interpreter thread-safe, allowing Python code to run without the GIL. This important update will enable users to fully exploit multithreading parallelism in Python. In order to facilitate that task, this paper introduces OMP4Py, the first pure Python implementation of OpenMP. We demonstrate that it is possible to bring OpenMP's familiar directive-based parallelization paradigm to Python, allowing developers to write parallel code with the same level of control and flexibility as in C, C++, or Fortran. The experimental evaluation shows that OMP4Py significantly impacts the performance of various types of applications, although the current threading limitation of Python's interpreter (v3.13) reduce its effectiveness for numerical applications.

Figures

Figures reproduced from arXiv: 2411.14887 by the authors.

Figure 1
Figure 1. Example of a Monte Carlo method for π calculation using OMP4Py. omp function, as mentioned earlier, have no effect. Therefore, we must instruct the Python interpreter to restructure the code according to the content of each OpenMP directive before exe￾cuting it. To accomplish this task, we employ Python decora￾tors. A decorator can be applied to a function or class to change its behaviour in a very elegant and intui… view at source ↗
Figure 2
Figure 2. Example of the parallel directive: user code (top) and its corre￾sponding translation by OMP4Py (bottom). (bottom). It is important to note that, in code generation ex￾amples, the prefix omp will be used for all internal OMP4Py symbols, with dynamically created symbols including a num￾ber to avoid collisions. The example shows a simple function with a parallel directive and six representative variables (’a’ to ’f’) … view at source ↗
Figure 3
Figure 3. Example of the for directive: user code (top) and its corresponding translation by OMP4Py (bottom). equivalent to for i in range(0, 10, 1) in Python, where the initial value, final value, and step are specified as argu￾ments. It is important to note that ranges cannot be used di￾rectly to divide the work because Python iterators are sequen￾tial, while C++ iterators allow random access, enabling direct access to any … view at source ↗
Figures from the paper (9 more)
Figure 4
Figure 4. Figure 4: Example of the for directive with collapse and lastprivate clauses: user code (top) and its corresponding translation by OMP4Py (bottom). iterations across all loops is large. When the collapse clause is used, the OMP4Py runtime effectively flattens the nested loops in…
Figure 5
Figure 5. Figure 5: Example of the sections directive: user code (top) and its corre￾sponding translation by OMP4Py (bottom). 1 from omp4py import * 2 3 @omp 4 def f(): 5 x = 0 6 with omp("parallel firstprivate(x)"): 7 with omp("single copyprivate(x)"): 8 x += 1 9 print(x) 1 from omp4py i…
Figure 6
Figure 6. Figure 6: Example of the single directive: user code (top) and its correspond￾ing translation by OMP4Py (bottom). the broadcast is complete, threads in the team have the updated value and print it (line 9, top code). The implementation of the single directive is similar to that …
Figure 7
Figure 7. Figure 7: Fibonacci calculation example using the tasking directives: user code [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]
Figure 8
Figure 8. Figure 8: Scalability of the different parallel numerical applications. Axis in log scale. To better understand the behavior of OMP4Py parallel ap￾plications, as an illustrative example, we will focus on track￾ing core usage while executing the pi application with different thre…
Figure 9
Figure 9. Figure 9: Average core usage when running the pi application using different number of threads. Time step is 5 seconds. implementations vary slightly across applications but remain consistently low, with all differences below 0.2%. The results of the Wilcoxon rank-sum test indic…
Figure 10
Figure 10. Figure 10: User codes for the pi application: (top) OMP4Py (middle) manually parallelized, and (bottom) compute function using Cython. preter when multiple threads execute the compute routine concurrently. In any case, these issues cannot be attributed to the code generated by O…
Figure 11
Figure 11. Figure 11: Scalability of the different user codes shown in [PITH_FULL_IMAGE:figures/full_fig_p013_11.png]
Figure 14
Figure 14. Figure 14: Scalability of a hybrid implementation (OMP4Py [PITH_FULL_IMAGE:figures/full_fig_p014_14.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

17 extracted references · 17 canonical work pages

  1. [1]

    tiobe.com/tiobe-index (2024)

    TIOBE Software, TIOBE index for November 2024, https://www. tiobe.com/tiobe-index (2024)

    work page 2024

  2. [2]

    Python Enhancement Proposals, PEP 703 – Making the Global Interpreter Lock Optional in CPython, https://peps.python.org/pep-0703 (2023)

    work page 2023

  3. [3]

    Padua, Encyclopedia of Parallel Computing, Springer Science & Busi- ness Media, 2011

    D. Padua, Encyclopedia of Parallel Computing, Springer Science & Busi- ness Media, 2011

    work page 2011

  4. [4]

    Dalcin, Y .-L

    L. Dalcin, Y .-L. L. Fang, mpi4py: Status update after 12 years of devel- opment, Computing in Science & Engineering 23 (4) (2021) 47–54

    work page 2021

  5. [5]

    T. G. Mattson, Y . H. He, A. E. Koniges, The OpenMP Common Core: Making OpenMP Simple Again, Scientific and Engineering Computation, MIT Press, 2019

    work page 2019

  6. [6]

    S. K. Lam, A. Pitrou, S. Seibert, Numba: a LLVM-based Python JIT com- piler, in: Proc. of the 2nd Workshop on the LLVM Compiler Infrastructure in HPC, ACM, 2015, pp. 1–6

    work page 2015

  7. [7]

    Ansel, E

    J. Ansel, E. Yang, H. He, N. Gimelshein, A. Jain, M. V oznesensky, B. Bao, P. Bell, D. Berard, E. Burovski, et al., Pytorch 2: Faster machine learning through dynamic python bytecode transformation and graph compilation, in: Proc. of the 29th ACM Int. Conf. on Architectural Sup- port for Programming Languages and Operating Systems, 2024, pp. 929– 947

    work page 2024

  8. [8]

    Abadi, P

    M. Abadi, P. Barham, J. Chen, Z. Chen, A. Davis, J. Dean, M. Devin, S. Ghemawat, G. Irving, M. Isard, et al., TensorFlow: a system for large- scale machine learning, in: Proc. of the 12th USENIX Conference on Operating Systems Design and Implementation, USENIX Association, 2016, p. 265–283

    work page 2016

Show all 17 references
  1. [9]

    Pi ˜neiro, J

    C. Pi ˜neiro, J. C. Pichel, A unified framework to improve the interoper- ability between HPC and Big Data languages and programming models, Future Generation Computer Systems 134 (2022) 123–139

    2022

  2. [10]

    T. A. Anderson, T. Mattson, Multithreaded parallel Python through OpenMP support in Numba, in: SciPy, 2021, pp. 140–147

    2021

  3. [11]

    T. G. Mattson, T. A. Anderson, G. Georgakoudis, PyOMP: Multithreaded parallel programming in Python, Computing in Science & Engineering 23 (6) (2021) 77–80

    2021

  4. [12]

    Hastings, Gilectomy, https://github.com/larryhastings/ gilectomy (2016)

    L. Hastings, Gilectomy, https://github.com/larryhastings/ gilectomy (2016)

    2016

  5. [13]

    Gross, Python Multithreading without GIL, https://github.com/ colesbury/nogil (2022)

    S. Gross, Python Multithreading without GIL, https://github.com/ colesbury/nogil (2022)

    2022

  6. [14]

    Python Enhancement Proposals, PEP 744 – JIT Compilation, https:// peps.python.org/pep-0744 (2024)

    2024

  7. [15]

    Behnel, R

    S. Behnel, R. Bradshaw, C. Citro, L. Dalcin, D. S. Seljebotn, K. Smith, Cython: The best of both worlds, Computing in Science & Engineering 13 (2) (2010) 31–39

    2010

  8. [16]

    A. A. Hagberg, D. A. Schult, P. Swart, J. Hagberg, Exploring network structure, dynamics, and function using networkx, Proceedings of the Python in Science Conference (2008)

    2008

  9. [17]

    1/mpi41-report.pdf (2023)

    Message Passing Interface Forum, MPI: A message-passing interface standard version 4.1, https://www.mpi-forum.org/docs/mpi-4. 1/mpi41-report.pdf (2023). 15

    2023

Pith tools

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