Pith. sign in

REVIEW 3 major objections 5 minor 1 cited by

Exploring Performance-Productivity Trade-offs in AMT Runtimes: A Task Bench Study of Itoyori, ItoyoriFBC, HPX, and MPI

T0 review · 3 major / 5 minor · reviewed 2026-08-03 · deepseek-v4-flash

Pith's one-line read Itoyori, a PGAS-based AMT runtime, outperforms MPI and HPX on communication-intensive all-to-all graphs while requiring about half the code of MPI.

desk verdict Useful first Task Bench ports of Itoyori/ItoyoriFBC and honest caveats, but the 'intrinsic PGAS advantage' is really an implementation-level result and the HPX productivity ranking rests on a port the authors themselves say is not recommended. read the letter →

arxiv 2601.14608 v2 pith:US3APPO3 submitted 2026-01-21 cs.DC

classification cs.DC
keywords asynchronousmany-taskruntimesTaskBenchpartitionedglobaladdressspaceworkstealingprogrammerproductivityMPIHPXperformanceevaluation
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 tries to establish that the Itoyori runtime, which combines a partitioned global address space with nested fork-join task parallelism, occupies a trade-off position that neither MPI nor HPX fills: it is the most productive of the four Task Bench implementations (77 lines of code versus 137 for MPI and 224 for HPX) and the most efficient in dense all-to-all communication patterns. Its PGAS cache aggregates many remote dependencies into a single RDMA fetch, which is why it beats message-per-dependency implementations in communication-intensive scenarios. The downside is that Its random work stealing incurs overhead at fine task granularities, so the advantage appears only when there is enough parallelism to amortize scheduling costs. If the paper is right, task-parallel PGAS models offer a concrete way to reduce code complexity while improving performance on communication-heavy workloads, not just on irregular compute-bound ones.

What carries the argument

The central mechanism is Itoyori's PGAS cache with its checkout/checkin API. Global memory accesses are cached per process, and the API supports contiguous offset/length parameters, so a task with many dependencies on remote data can fetch all of them in a single RDMA operation rather than one message per dependency. This mechanism explains the all_to_all efficiency advantage over MPI and HPX; the offsetting cost comes from the random work stealing (RDWS) scheduler, whose failed steals dominate at fine granularity and raise the minimum effective task granularity.

What would settle it

Take the all_to_all benchmark and replace the HPX implementation's explicit MPI sends with HPX's native parcelport or with an aggregated remote-get API; if efficiency then matches or beats Itoyori, the PGAS-cache advantage is an artifact of the MPI-centric HPX port rather than an inherent property of the AMT designs compared.

Watch

Extended reading notes

Core claim

The paper's central claim is that Itoyori achieves the highest efficiency among the four compared implementations on dense all-to-all task graphs because its PGAS cache lets the runtime fetch data for multiple dependencies in a single RDMA operation using contiguous offset/length parameters, whereas MPI and HPX must send individual messages for each dependency. This same global-address-space abstraction also makes Itoyori the most productive implementation, nearly halving the lines of code needed compared with MPI. The counterweight is that Itoyori's random work stealing has a higher minimum effective task granularity, so the PGAS advantage only emerges when task granularity is large enough

Load-bearing premise

The comparison assumes each Task Bench implementation is a fair, idiomatic representative of its runtime; in particular, the HPX numbers come from an MPI-centric implementation, and a more idiomatic HPX port would change the reported productivity and potentially the performance rankings.

Editorial extensions

If this is right

  • In dense communication patterns such as all_to_all, a PGAS-style AMT can outperform MPI even though MPI has lower baseline overheads for regular communication-light workloads.
  • The all_to_all advantage scales with dependency degree: runtimes that send one message per dependency pay proportionally more as the graph becomes denser, while aggregated remote-get runtimes do not.
  • Itoyori requires enough task parallelism, roughly 16 tasks per core in this study, to amortize random-work-stealing costs before its PGAS advantage materializes.
  • If the productivity measurements hold, a task-parallel PGAS model can cut implementation effort for this benchmark class by roughly half compared with MPI.
  • HPX maintains efficiency under load imbalance but degrades when communication traffic is concentrated, so runtime choice depends on the communication topology of the target workload.

Reading between the lines

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

  • Editorial inference: the all_to_all result suggests a general runtimes design rule — exposing a bulk remote-get with offset/length descriptors may be more valuable than optimizing per-message injection, and the same mechanism could be bolted onto message-passing libraries.
  • Editorial inference: the authors' own caveat implies the 'AMTs do not inherently guarantee productivity' headline is fragile; a native HPX Task Bench implementation would likely lower HPX's LOC and NLC, making the comparison one of programming styles (MPI-centric versus native) as much as of runtimes.
  • Editorial inference: ItoyoriFBC's future-based model would likely close much of the efficiency gap with Itoyori if the artificial time-step barrier were removed, since the paper notes this would allow overlapping computation and communication; that is a natural next experiment.
  • Editorial inference: a testable extension is a sensitivity study of work-stealing parameters; if steal-attempt costs can be lowered below the observed 3 microseconds, Itoyori's METG would approach MPI's and the PGAS advantage would extend to finer-grained workloads.
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

3 major / 5 minor

Summary. The paper integrates two recent AMT runtimes, Itoyori and ItoyoriFBC, into the Task Bench benchmarking framework and compares them against existing MPI and HPX Task Bench ports. It reports application efficiency, Minimum Effective Task Granularity (METG), and productivity metrics (LOC, NLC) across stencil, spread, and all_to_all dependency patterns, on a cluster with up to 16 nodes. The central claims are that the Itoyori implementation achieves the highest efficiency in communication-intensive (all_to_all) settings due to a PGAS cache with contiguous RDMA aggregation, that Itoyori leads in programmer productivity, that MPI remains best for regular/static workloads, and that HPX, while robust under load imbalance, ranks last in productivity. The authors also report improvements to the existing HPX Task Bench port.

Significance. If its claims hold, this is a useful comparative data point for the AMT landscape: it is the first Task Bench integration of Itoyori and ItoyoriFBC, the code is released (Zenodo DOI), and the experimental setup (Task Bench, fixed hardware, METG) is external and reproducible in principle. The paper also contributes concrete fixes to the HPX Task Bench port, which is of independent value to the community. However, the headline quantitative rankings are fragile: the all_to_all 'intrinsic PGAS advantage' is argued against a single MPI implementation style, the HPX productivity ranking is explicitly confounded by the use of an MPI-centric port, and the reported figures show only five-run averages with no variance or description of the METG extraction procedure. These issues do not invalidate the raw measurements, but they do affect the strength of the system-level conclusions drawn from them.

major comments (3)
  1. [§4.4, Figure 5] The central attribution that Itoyori's all_to_all advantage is 'intrinsic to the PGAS architecture' is not established. The comparison is against the Task Bench MPI reference implementation, which uses per-dependency MPI_Isend/MPI_Irecv messages (§3.1). An idiomatic MPI implementation could instead use MPI_Alltoallv or pack all data destined for a neighbor into a single buffer. Since the paper's own fairness principle (§1) is that each implementation reflects its system's natural style, omitting an aggregated MPI variant means the observed advantage may be an artifact of this particular MPI port rather than an intrinsic PGAS property. Please either add such an MPI variant or rephrase the claim to refer specifically to the standard Task Bench MPI implementation.
  2. [§3.2, Table 1, §4.5, Abstract] The productivity claim that 'HPX ranks last' is load-bearing for the paper's conclusion that 'AMTs do not inherently guarantee improved productivity over MPI.' The paper itself states that the HPX port uses explicit MPI for inter-node communication and that the recommended HPX approach would yield lower LOC/NLC numbers. As reported, the ranking is a property of this particular port, not of HPX as a system. To support the productivity conclusion, please report the recommended HPX implementation's metrics or restrict the claim to the tested ports.
  3. [§4, Figures 1–5] All efficiency and METG figures are described as 'averages over five runs' but no variance, standard deviation, or min/max is shown. The METG is defined as the smallest task duration at which the system maintains 50% efficiency, but the extraction procedure is not described: is it interpolated from the discrete task-size sweeps, and is it computed per node count or from the combined data? Without these details, it is impossible to judge whether the reported differences (e.g., the small efficiency gaps in Figure 1 or the METG curves in Figures 1d and 2b) are significant. Please add error bars or at least report variance, and describe the METG estimation protocol.
minor comments (5)
  1. [Title] The title in the full text has a spacing artifact: 'T rade-offs' should be 'Trade-offs.'
  2. [§3.2] The phrase 'maximum tag size (222)' is ambiguous; presumably this is 2^22 or a specific MPI tag-UB value. Please clarify the notation.
  3. [§4] The system is called 'Goethe-NHR' in the text but reference [11] is listed as 'Goethe-HLR.' Please align the name.
  4. [§4.4] The sentence 'MPI and HPX implementations, constrained to sending individual messages for each dependency' should also mention that this refers to the specific Task Bench ports used, not to all possible MPI/HPX implementations.
  5. [§3.4] The ItoyoriFBC implementation intentionally inserts a barrier between time steps. This is disclosed, but a sentence in the conclusions or discussion reiterating that the efficiency gap between ItoyoriFBC and Itoyori is measured under this barrier-restricted mode would preempt misinterpretation.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation: the study is an external benchmark evaluation; performance and productivity claims are empirical measurements, not consequences of fitted parameters or self-citations.

full rationale

The paper's central claims are empirical results from Task Bench, an externally defined benchmarking framework, applied to independently existing runtimes (MPI, HPX, Itoyori, ItoyoriFBC). No parameter is fitted to the target outcome, no 'prediction' is derived from the measured quantities, and no uniqueness theorem or prior result by the same authors is invoked to force the conclusions. The all-to-all efficiency claim in §4.4 is an interpretation of measured data comparing specific implementations; even if the comparison is not fully general (e.g., an aggregated MPI_Alltoallv variant might change the outcome), that is a threat to external validity or fairness, not circularity. The paper itself flags the main fairness limitation: §3.2 states that the HPX implementation 'uses MPI for inter-node communication' and that 'the recommended HPX approach to avoid calling MPI explicitly would result in lower numbers,' and §4.5 acknowledges the HPX productivity result 'largely reflects the effort of adapting the MPI-centric Task Bench structure to HPX.' These are honest limitations, not circular steps. Self-citations such as [8], [9], [21], [22], [23] are references to the authors' own systems and prior work, but the benchmark measurements are externally generated and the cited results are not used as the load-bearing justification for the paper's empirical comparisons. Consequently, the derivation chain is self-contained with respect to circularity, and the appropriate score is 0.

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

No derived quantities fitted to data; the paper reports measured efficiencies and METGs. Its conclusions rest on external Task Bench methodology, representative-implementation assumptions, and hardware peak definitions.

assumptions (4)
  • domain assumption Task Bench synthetic task graphs (stencil, spread, all_to_all) with compute_bound/load_imbalance kernels are representative of the communication and irregularity structures of real scientific workloads.
    Used to generalize from benchmark graphs to claims about runtime suitability in §4.5; no external validation of representativeness is provided.
  • domain assumption Application efficiency computed as achieved FLOP/s relative to theoretical hardware peak is a fair cross-runtime comparison metric.
    Defined in §2; peak FLOP/s and FLOP counting for kernels are not fully specified, which can bias comparisons across runtimes.
  • domain assumption Forcing a barrier between time steps in the ItoyoriFBC implementation does not materially disadvantage it relative to the other runtimes.
    Section 3.4 says this is done 'for a fair comparison' and that removing barriers could improve efficiency; this assumption is acknowledged but not quantified.
  • domain assumption Default work-stealing and runtime parameter settings used for Itoyori/ItoyoriFBC and HPX are appropriate for comparison.
    Section 6 notes default settings were used and a sensitivity study is needed; results may change with tuning.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Exploring Performance-Productivity Trade-offs in AMT Runtimes: A Task Bench Study of Itoyori, ItoyoriFBC, HPX, and MPI." pith.science (2026). https://pith.science/paper/US3APPO3

@misc{pith2026260114608,
  author       = {Pith},
  title        = {Pith review of: Exploring Performance-Productivity Trade-offs in AMT Runtimes: A Task Bench Study of Itoyori, ItoyoriFBC, HPX, and MPI},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/US3APPO3}},
  note         = {Machine review of arXiv:2601.14608}
}
read the original abstract

Asynchronous Many-Task (AMT) runtimes offer a productive alternative to the Message Passing Interface (MPI). However, the diverse AMT landscape makes fair comparisons challenging. Task Bench, proposed by Slaughter et al., addresses this challenge through a parameterized framework for evaluating parallel programming systems. This work integrates two recent cluster AMTs, Itoyori and ItoyoriFBC, into Task Bench for comprehensive evaluation against MPI and HPX. Itoyori employs a Partitioned Global Address Space (PGAS) model with RDMA-based work stealing, while ItoyoriFBC extends it with futurebased synchronization. We evaluate these systems in terms of both performance and programmer productivity. Performance is assessed across various configurations, including compute-bound kernels, weak scaling, and both imbalanced and communication-intensive patterns. Performance is quantified using application efficiency, i.e., the percentage of maximum performance achieved, and the Minimum Effective Task Granularity (METG), i.e., the smallest task duration before runtime overheads dominate. Programmer productivity is quantified using Lines of Code (LOC) and the Number of Library Constructs (NLC). Our results reveal distinct trade-offs. MPI achieves the highest efficiency for regular, communication-light workloads but requires verbose, lowlevel code. HPX maintains stable efficiency under load imbalance across varying node counts, yet ranks last in productivity metrics, demonstrating that AMTs do not inherently guarantee improved productivity over MPI. Itoyori achieves the highest efficiency in communication-intensive configurations while leading in programmer productivity. ItoyoriFBC exhibits slightly lower efficiency than Itoyori, though its future-based synchronization offers potential for expressing irregular workloads.

Figures

Figures reproduced from arXiv: 2601.14608 by the authors.

Figure 1
Figure 1. Efficiency and METG for varying widths with a [PITH_FULL_IMAGE:figures/full_fig_p007_1.png] view at source ↗
Figure 2
Figure 2. Weak scaling from 1 to 16 nodes for a stencil graph, compute_bound kernel, and 16 width per core that this is due to the static partitioning among nodes. This result highlights that AMT performance is sensitive to communication topology and underscores the need for decentralized communication. The all_to_all pattern represents the worst-case communication scenario, where every task depends on all tasks from the prec… view at source ↗
Figure 3
Figure 3. Performance with load_imbalance kernels for a stencil graph, 2 20 iterations, and 16 width per core This difference stems from explicit, low-level communication management in MPI versus Itoyori’s abstract checkout/checkin API. The Itoyori implementation achieves the highest productivity and out￾performs MPI in communication-intensive scenarios (e.g., all_to_all) due to its PGAS cache. However, its RDWS introduces no… view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Communication-focused experiment with a spread graph, compute_bound kernel, 2 20 iterations, 1 KiB output size, and 16 width per core 0% 25% 50% 75% 100% 1 2 4 8 16 MPI HPX ITO FBC Efficiency Number of Nodes (a) 1 width per core 0% 25% 50% 75% 100% 1 2 4 8 MPI HPX ITO …
Figure 5
Figure 5. Figure 5: Communication-focused experiment with an [PITH_FULL_IMAGE:figures/full_fig_p010_5.png]

Discussion (0). Sign in to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

  1. From Fork-Join to Asynchronous Tasks: Parallelizing Tiled Cholesky Decomposition with OpenMP and HPX

    cs.DC 2026-06 unverdicted novelty 4.0 of 10

    HPX asynchronous tasks outperform OpenMP by 15-30% on tiled Cholesky with 3.8x lower task overhead; collapsed fork-join closes most of the gap to synchronous tasking.

Reference graph

Works this paper leans on

23 extracted references · 5 canonical work pages · cited by 1 Pith paper

  1. [1]

    MPI Forum: MPI: A Message-Passing Interface Standard Ver sion 5.0, https://www.mpi-forum.org/docs/mpi-5.0/mpi50-report .pdf

  2. [2]

    Tutorial at European Network on High-performance Embedded Architectu re and Compilation Conference (HiPEAC), https://doi.org/10.5281/zenodo.8425959 (2020)

    Fohry, C.: An overview of task-based parallel programmin g models. Tutorial at European Network on High-performance Embedded Architectu re and Compilation Conference (HiPEAC), https://doi.org/10.5281/zenodo.8425959 (2020)

  3. [3]

    The Journal of Su- percomputing (2018), https://doi.org/10.1007/s11227-018-2238-4

    Thoman, P., Dichev, K., Heller, T., et al.: A Taxonomy of Ta sk-Based Parallel Programming Technologies for High-Performance Computing . The Journal of Su- percomputing (2018), https://doi.org/10.1007/s11227-018-2238-4

  4. [4]

    and Lumsdaine, A.: A Comparative Study of Asy nchronous Many-Tasking Runtimes: Cilk, Charm++, ParalleX and AM++ (2 019), http://arxiv.org/abs/1904.00518

    Kulkarni, A. and Lumsdaine, A.: A Comparative Study of Asy nchronous Many-Tasking Runtimes: Cilk, Charm++, ParalleX and AM++ (2 019), http://arxiv.org/abs/1904.00518

  5. [5]

    and Petiton, S.G.: A Current Task-Based Progra mming Paradigms Analysis

    Jérôme, G. and Petiton, S.G.: A Current Task-Based Progra mming Paradigms Analysis. In: Computational Science (ICCS). Springer Inte rnational Publishing (2020), https://doi.org/10.1007/978-3-030-50426-7_16 A Task Bench Study of Itoyori, ItoyoriFBC, HPX, and MPI 13

  6. [6]

    In: Proceedi ngs International Con- ference for High Performance Computing, Networking, Stora ge and Analysis (SC)

    Slaughter, E., Wu, W., Fu, Y., et al.: Task Bench: A Paramet erized Benchmark for Evaluating Parallel Runtime Performance. In: Proceedi ngs International Con- ference for High Performance Computing, Networking, Stora ge and Analysis (SC). ACM (2020), https://doi.org/10.1109/SC41405.2020.00066

  7. [7]

    In: Proceedings Euro-Par Parallel Pro cessing Workshops (AMTE)

    Wu, N., Gonidelis, I., Liu, S., et al.: Quantifying Overhe ads in Charm++ and HPX using Task Bench. In: Proceedings Euro-Par Parallel Pro cessing Workshops (AMTE). Springer (2023), https://doi.org/10.1007/978-3-031-31209-0_1

  8. [8]

    and Taura, K.: Itoyori: Reconciling Global Add ress Space and Global Fork-Join Task Parallelism

    Shiina, S. and Taura, K.: Itoyori: Reconciling Global Add ress Space and Global Fork-Join Task Parallelism. In: International Conf erence for High Per- formance Computing, Networking, Storage and Analysis (SC) . ACM (2023), https://doi.org/10.1145/3581784.3607049

Show all 23 references
  1. [9]

    In: Pro- ceedings Euro-Par Parallel Processing Workshops (AMTE)

    Reitz, M., Gerhards, B., Hundhausen, J., et al.: Investig ating the Perfor- mance Difference of Task Communication via Futures or Side Eff ects. In: Pro- ceedings Euro-Par Parallel Processing Workshops (AMTE). S pringer (2025), https://doi.org/10.1007/978-3-031-90200-0_21

  2. [10]

    Journal of Open Sour ce Software (2020), https://doi.org/10.21105/joss.02352

    Kaiser, H., Diehl, P., Lemoine, A.S., et al.: HPX - The C ++ Standard Li- brary for Parallelism and Concurrency. Journal of Open Sour ce Software (2020), https://doi.org/10.21105/joss.02352

  3. [11]

    TOP500.org: Goethe-HLR, https://www.top500.org/system/179588

  4. [12]

    Karlin, I.: Lulesh programming model and performance po rts overview. Tech. rep., Lawrence Livermore National Laboratory (LLNL ( 2012), https://asc.llnl.gov/sites/asc/files/2021-01/lulesh_ports1.pdf

  5. [13]

    In: Pro- ceedings International Conference on Cluster Computing (C LUSTER)

    McIntosh-Smith, S., Martineau, M., Deakin, T., et al.: T eaLeaf: A Mini-Application to Enable Design-Space Explorations for Iterative Sparse L inear Solvers. In: Pro- ceedings International Conference on Cluster Computing (C LUSTER). IEEE (2017), https://doi.org/10.1109/CLUSTE...

  6. [14]

    and Shamis, P.: Distributed Task-Based Runtim e Systems - Cur- rent State and Micro-Benchmark Performance

    Hoque, R. and Shamis, P.: Distributed Task-Based Runtim e Systems - Cur- rent State and Micro-Benchmark Performance. In: Internati onal Conference on High Performance Computing and Communications (HPCC). I EEE (2018), https://doi.org/10.1109/HPCC/SmartCity/DSS.2018.00155

  7. [15]

    In: International Conferen ce for High Per- formance Computing, Networking, Storage and Analysis (SCC )

    Taura, K., Nakashima, J., Yokota, R., et al.: A task paral lel implementa- tion of fast multipole methods. In: International Conferen ce for High Per- formance Computing, Networking, Storage and Analysis (SCC ). IEEE (2012), https://doi.org/10.1109/SC.Companion.2012.86

  8. [16]

    and Taura, K.: MassiveThreads: A Thread Li brary for High Productivity Languages

    Nakashima, J. and Taura, K.: MassiveThreads: A Thread Li brary for High Productivity Languages. In: Concurrent Objects and Beyond . Springer (2014), https://doi.org/10.1007/978-3-662-44471-9_10

  9. [17]

    In : International Parallel and Distributed Processing Symposium (IPDPS)

    Bachan, J., Baden, S.B., Hofmeyr, S., et al.: UPC++: A Hig h-Performance Communication Framework for Asynchronous Computation. In : International Parallel and Distributed Processing Symposium (IPDPS). IE EE (2019), https://doi.org/10.1109/IPDPS.2019.00104

  10. [18]

    In: Proceeding s Euro-Par Parallel Processing

    Mena, J.A., Shaaban, O., Beltran, V., et al.: OmpSs-2@Cl uster: Distributed Mem- ory Execution of Nested OpenMP-Style Tasks. In: Proceeding s Euro-Par Parallel Processing. Springer (2022), https://doi.org/10.1007/978-3-031-12597-3_20

  11. [19]

    In : Proceedings of the international workshop on Parallel symbolic computati on

    Yelick, K., Bonachea, D., Chen, W.Y., et al.: Productivi ty and perfor- mance using partitioned global address space languages. In : Proceedings of the international workshop on Parallel symbolic computati on. ACM (2007), https://doi.org/10.1145/1278177.1278183

  12. [20]

    Lahnor, Mia Reitz, Jonas Posner, and Patrick Die hl Next Generation Platforms

    Baker, G.M., Bettencourt, M.T., Bova, S.W., et al.: ASC A TDM Level 2 Milestone #5325: Asynchronous Many-Task Runtime System Analysis and Assessment for 14 Torben R. Lahnor, Mia Reitz, Jonas Posner, and Patrick Die hl Next Generation Platforms. Tech. rep., Sandia National Lab ...

  13. [21]

    and Fohry, C.: Comparison of the HPC and Big Data Java Libraries Spark, PCJ and APGAS

    Posner, J., Reitz, M. and Fohry, C.: Comparison of the HPC and Big Data Java Libraries Spark, PCJ and APGAS. In: International Conferen ce for High Per- formance Computing, Networking, Storage and Analysis (SC) Workshops (PA W- ATM). IEEE (2018), https://doi.org/10.1109/PA W-A...

  14. [22]

    and Fohry, C.: A Comparison of Appli cation-Level Fault Tolerance Schemes for Task Pools

    Posner, J., Reitz, M. and Fohry, C.: A Comparison of Appli cation-Level Fault Tolerance Schemes for Task Pools. Future Generation Comput er Systems (2020), https://doi.org/10.1016/j.future.2019.11.031

  15. [23]

    Springer Nature Computer Science (2025), https://doi.org/10.1007/s42979-025-04405-3

    Posner, J., Ellersiek, T., Bietendorf, N., et al.: Towar d Dynamic Resource Man- agement: An Asynchronous Many-Task (AMT) Runtime System le veraging Dy- namic Processes with PSets (DPP). Springer Nature Computer Science (2025), https://doi.org/10.1007/s42979-025-04405-3

Pith tools

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