Pith. sign in

REVIEW 5 major objections 6 minor 39 references

Optimizing Fine-Grained Parallelism Through Dynamic Load Balancing on Multi-Socket Many-Core Systems

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

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

Pith's one-line read The paper claims that replacing GNU OpenMP's global task lock and centralized barrier with a lock-less task queue and a distributed tree barrier removes the dominant synchronization cost of fine-grained tasking, yielding up to 1522.8x…

desk verdict A solid engineering contribution with a plausible central claim, but the headline speedups rest on an unverified barrier invariant and fitted DLB parameters; worth a serious referee, not yet worth citing. read the letter →

arxiv 2502.05293 v2 pith:CN75B3BV submitted 2025-02-07 cs.DC

Wenyi Wang , Maxime Gonthier , Poornima Nookala , Haochen Pan , Ian Foster , Ioan Raicu , Kyle Chard This is my paper · ORCID
classification cs.DC
keywords fine-grainedtaskingGNUOpenMPlock-lessqueuedistributedtreebarrierdynamicloadbalancingNUMA-awareschedulingworkstealing
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

This paper tries to establish that GNU OpenMP's poor scaling on many-core machines is caused by synchronization overhead in the runtime — specifically a single global task lock and a centralized barrier guarded by an atomic counter — and that replacing those structures with lock-less alternatives makes fine-grained tasking practical at 192 threads. On the Barcelona OpenMP Task Suite benchmarks, the authors report speedups up to 1522.8x over stock GNU OpenMP using only the queue and tree barrier, and up to 4x additional improvement from their two NUMA-aware dynamic load-balancing strategies. The paper also contributes a lock-less inter-thread messaging protocol, per-thread profiling tools, and tuning guidance linking task size and steal size to the best strategy. A sympathetic reader would take the central claim as: synchronization, not the task graph, is the bottleneck for fine-grained OpenMP tasks.

What carries the argument

The load-bearing mechanism is a combination of two lock-less data structures. XQueue replaces GOMP's global priority queue: each worker has one master SPSC queue and one auxiliary SPSC queue per other worker; producers round-robin push task pointers to target queues, consumers drain their master queue then auxiliaries, and no atomic instructions are used, only cache-friendly reads and writes. The distributed tree barrier organizes workers in a binary tree; a worker is gathered when all workers have entered the barrier, the worker is idle, its current task has no unfinished dependencies, and all of its children are gathered, and it then atomically sets a per-parent complete flag, with release performed as a lock-less tree broadcast of flags. Around these, the lock-less messaging protocol uses a 64-bit request cell (40-bit round number plus 24-bit worker ID) and a round cell per victim so thieves can ask a victim to redirect or hand over tasks without locks or atomics; the victim validates the request by matching round numbers and increments its round after handling.

What would settle it

Instrument the runtime to record, for each worker, the barrier-exit timestamp and the global task count plus any pending dependency counters, then run the nine BOTS workloads at 192 threads. If any worker exits the team barrier while the global task count is nonzero, while a dependency on any in-flight task remains unresolved, or while any other worker has not yet reached the barrier and could still enqueue new work, the gather conditions are insufficient and the central claim collapses.

Watch

Extended reading notes

Core claim

The authors claim that the dominant cost in GNU OpenMP for fine-grained, short-running tasks is not the task computation itself but the runtime's synchronization: a single global priority task queue protected by a global task lock, and a centralized team barrier that atomically tracks a global task count. They integrate XQueue, a lock-less multi-producer/multi-consumer queue in which each worker owns an SPSC master queue and per-worker auxiliary queues with round-robin push, into GOMP, converting the global count to an atomic and removing the lock. They then replace the centralized barrier with a hybrid distributed tree barrier that gathers lock-free and releases lock-less, with a theoretical lower bound of half the atomic memory operations. On 192 cores, XQueue alone gives up to 96.5x over GOMP, and the queue plus tree barrier gives up to 1522.8x for NQueens. Finally, two lock-less NUMA-aware load-balancing strategies — redirect push (NA-RP) and batch work stealing (NA-WS) — communicate via lock-less request and round cells and improve performance up to 4x over the static round-robin XQueue schedule, with substantial gains in task locality.

Load-bearing premise

The whole result rests on the unproven assumption that the tree barrier's four gather conditions correctly detect when every task is finished, so a worker never leaves the barrier while another worker could still create work.

Editorial extensions

If this is right

  • With XGOMPTB, fine-grained workloads that were more than 1000x slower in stock GOMP become practical at 192 threads, so OpenMP task directives can now be used for tasks lasting tens of cycles without paying prohibitive runtime overhead.
  • The distributed tree barrier's theoretical lower bound of half the atomic memory access operations means barrier cost scales with tree depth and per-node flags rather than with a single contended global counter.
  • NA-RP is best for large tasks (above roughly 10^4 rdtscp cycles) and can deliver about 4x over static load balancing, while NA-WS improves all nine tested benchmarks and is described as a well-rounded, less sensitive default.
  • The tuning guidelines in Table IV let practitioners choose a strategy, NUMA-local probability, and steal size from measured task size, with the observed pattern that small tasks want small steal sizes and full NUMA locality.
  • The PoSp case study shows a 195x throughput gain at batch size 1 and a 32% peak-throughput gain over stock GOMP when batch sizes are chosen optimally.

Reading between the lines

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

  • Editorial inference: if the barrier's correctness premise holds, the same lock-less queue-plus-tree-barrier recipe could be ported to other lock-based OpenMP runtimes, since nothing in the design is specific to GCC's internals.
  • Editorial inference: the headline 1522.8x figure is a single-benchmark, single-machine upper bound; on workloads with large tasks or low lock contention the gains shrink considerably, so expected speedups should be predicted from task-size histograms rather than from the headline number.
  • Editorial inference: the tree barrier's correctness is asserted by design rather than proven, so a randomized dependency-DAG stress test or a formal model of the gather conditions would directly test whether the speedups hide a correctness assumption.
  • Editorial inference: the lock-less messaging protocol uses a 40-bit round number per victim, so after 2^40 handled requests the round wraps; on extremely long-running fine-grained workloads that wrap is a concrete scalability limit worth testing.
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

5 major / 6 minor

Summary. The paper proposes three optimizations to GNU OpenMP (GOMP) for fine-grained task parallelism on many-core NUMA systems: (1) integration of XQueue, a lock-less MPMC task queue, replacing GOMP's priority queue and global task lock; (2) a hybrid lock-free/lock-less distributed tree barrier to replace GOMP's centralized barrier; and (3) two NUMA-aware lock-less dynamic load balancing strategies, NA-RP and NA-WS. The authors evaluate the resulting XGOMP and XGOMPTB runtimes on nine BOTS benchmarks on a 192-core Intel Skylake machine and claim speedups over GOMP of up to 1522.8x, with additional up-to-4x gains from the load balancers over XGOMPTB. They also present profiling tools, parameter-tuning guidelines, and a Proof-of-Space blockchain application case study.

Significance. If the results are substantiated, the paper would demonstrate that GOMP's synchronization overhead is the dominant cost for fine-grained tasking on many-core systems and that a lock-less queue, distributed tree barrier, and NUMA-aware load balancing can remove that cost. The XQueue integration and the proposed DLB strategies are concrete and potentially useful engineering contributions, and the paper includes a real application (PoSp) plus profiling infrastructure. Credit is due for evaluating against external GOMP, LOMP, and XLOMP baselines, which makes the main XGOMPTB comparisons non-circular. However, the significance is conditional: the central correctness invariant of the distributed tree barrier is unproven, the DLB gains are selected from per-benchmark parameter sweeps, and the empirical claims rest on a single machine with no released artifact or raw data. These issues must be resolved before the headline speedups can be considered reliable.

major comments (5)
  1. [Section III-B] The safe-release invariant of the distributed tree barrier is not established. The paper replaces GOMP's centralized barrier, which releases only when the last worker has entered and the global task count is zero, with a tree barrier whose gather conditions are (i) all workers entered, (ii) the worker is idle, (iii) the current task has no unfinished dependencies, and (iv) all children barriers are gathered. Because XQueue is explicitly MPMC and the NA-RP/NA-WS strategies in Section IV can push or steal tasks into arbitrary workers' auxiliary queues, it is possible for a worker that has reported 'idle' to receive a task from another worker before the root completes the release. The paper provides no proof, model check, or stress test that these local conditions imply the global invariant that no task exists and none can be created. Since every headline speedup in Figs. 4 and 5 depends on this barrier releasing correctly, this is a load-bearing gap. Please add a formal correctness argument or, failing that, a randomized dependency-coupled stress test with assertion checks.
  2. [Section VI-B1 and Table II] The NQueens discussion is internally contradictory. The text states 'For NQueens, NA-RP is the best performing strategy' and then, in the same subsection, 'We see in Table II that NA-RP yields the worst average performance.' Table II reports NQueens NA-RP 26.5 s versus NA-WS 23.2 s, and Table III reports SLB 23.8 s, so on the reported averages NA-RP is not the best strategy. The subsequent explanation invoking profiling overhead is not supported by any presented data. Please correct the prose and reconcile the figure and table numbers.
  3. [Section VI-B and Table I] The DLB speedups are selected maxima over per-benchmark parameter sweeps. For each benchmark, the authors sweep Nvictim, Nsteal, Tinterval, and Plocal and then report the best configuration; the 'up to 4x' claim is therefore a best-case fitted value, not a prediction of expected behavior. Table I shows that the optimal parameters vary widely across benchmarks, and the tuning guidelines in Section VIII are derived from the same data used to select those optima. The paper should either validate the guidelines on held-out benchmarks or inputs, or report the full distribution of configuration results and a sensitivity analysis. Without this, the DLB comparison risks overfitting and does not support the strength of the claimed gains.
  4. [Section IV-B, Algorithm 1] The request construction 'newReq ← (tidi << 40) & round' cannot encode a request as described. With the 40-bit round occupying bits 0-39 and the 24-bit worker ID in bits 40-63, the bitwise AND of the shifted ID with the round value is identically zero. This should be a bitwise OR (or an explicit bit-field merge). As printed, the lock-less messaging protocol is not well defined, and the victim logic in Algorithm 2 cannot operate as described.
  5. [Section VI and reproducibility] The empirical claims are not reproducible from the manuscript. The paper reports speedups of up to 1522.8x based on BOTS measurements on a single machine, with no released code, no released raw data, and no reported variance for most of the central comparisons (Figs. 4-6). The statement in Section VI that the larger and smaller experiments 'yield similar results' is not accompanied by data. Given the magnitude of the claims, the authors should provide an artifact (code, scripts, raw logs, and configurations) and at least confidence or variance information for the main speedup figures.
minor comments (6)
  1. [Figure 10 caption] The caption reads 'A-WS (work-stealing)' but the strategy is named NA-WS throughout the paper.
  2. [Equation (1) and Section VIII] The definition of Ssteal mixes Nvictim, Nsteal, and a log-scaled Tinterval, but the units and the intended meaning of 'steal size' for NA-RP versus NA-WS are not clarified; please define the quantity precisely and explain why this combination is a meaningful independent variable.
  3. [Table II and Figure 7] Table II reports average times that appear inconsistent with the bars in Figure 7 (e.g., Fib NA-RP 9.9 s in Table II versus the corresponding bar in Figure 7). Please reconcile the two presentations or explain the difference.
  4. [Section III-B] The claim that the hybrid tree barrier 'yields a theoretical lower bound of half the atomic memory access operations' is asserted without a model or derivation; please provide the counting argument and state the assumptions.
  5. [Section IV-B, Algorithms 1-3] The symbol ctidthief is used before it is introduced, and the relationship between req, round, and the 64-bit request cell layout is not fully defined; please define all bit-field sizes and variable scopes where the algorithms are first presented.
  6. [Table IV] Entries such as 'Best Ssteal 100-101' are ambiguous; they presumably mean 10^0-10^1, but the exponent formatting should be explicit.

Circularity Check

0 steps flagged · score 2.0 of 10

No load-bearing circularity: speedups are direct measurements against external GOMP/LOMP/XLOMP baselines; DLB 'up to 4x' is an explicitly best-case sweep result, not a fitted prediction.

full rationale

The central claims in this paper are empirical, not derived. XGOMP and XGOMPTB are compared with unmodified GNU OpenMP, LLVM OpenMP, and XLOMP on the BOTS suite and a separate PoSp application, so the headline improvements (up to 96.5x, 1522.8x, and 4x) are measured against external baselines rather than obtained by substituting a definition into itself. The XQueue structure and the lock-less messaging protocol come from the authors' prior work [4,10], but the present paper integrates XQueue into GOMP and re-measures it; these self-citations are to published, code-backed artifacts and are not used as an argument to forbid alternatives, so they are not load-bearing. The distributed tree barrier's gather conditions in Section III-B are asserted without a formal proof or model check that they imply the global 'no task can still be enqueued' invariant; this is a genuine omitted-proof/correctness risk, but it is not a circularity because the paper does not define 'gathered' in terms of the speedup it later claims. The DLB evaluation in Section VI-B sweeps Nvictim, Nsteal, Tinterval, and Plocal per benchmark and reports the best observed configuration; the paper is explicit that this is 'with optimal settings' and later validates the resulting guidelines on larger inputs (Section VIII, Fig. 11), so the 'up to 4x' is a best-case selection rather than a fitted parameter renamed as a prediction. The asserted validation that scaled-down and full-size experiments give similar results is not shown with data, but that is a missing-evidence limitation, not a circular step. Overall, no derivation chain reduces to its own inputs; score 2 reflects only the presence of minor non-load-bearing self-citations.

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

The paper is empirical, so the ledger contains no fitted physical constants or invented physical entities. It does contain four per-benchmark tuned DLB parameters and several unproved correctness assumptions about lockless data structures, memory ordering, and barrier termination.

free parameters (4)
  • Nvictim = 1 to 24, per benchmark (Table I)
    Number of victims per steal request; chosen by parameter sweep to minimize execution time on each benchmark, not derived from theory.
  • Nsteal = 1 to 32, per benchmark (Table I)
    Maximum tasks stolen or redirected per request; tuned per benchmark.
  • Tinterval = 1e3 to 1e5 cycles, per benchmark (Table I)
    Timeout interval before a retry; tuned per benchmark and treated as a tuning knob.
  • Plocal = 0.03 to 1.0, per benchmark (Table I)
    Probability of stealing from a NUMA-local worker; tuned per benchmark, with some applications preferring remote steals.
assumptions (4)
  • domain assumption XQueue and its underlying B-queue are correct lockless MPMC and SPSC queues.
    Assumed from the authors' prior work [4]; the XGOMP and DLB results depend on this correctness.
  • domain assumption Converting GOMP's global task count to an atomic variable with acquire-release ordering preserves tasking correctness.
    Section III-A makes this change without a memory-model proof or stress-test evidence.
  • domain assumption The hybrid tree barrier's gather conditions guarantee deadlock-free and correct barrier release.
    Section III-B describes the barrier but provides no formal verification or model check.
  • domain assumption The lockless round/request messaging protocol prevents lost or stale steal requests despite non-atomic writes.
    Section IV-B describes the protocol but does not prove memory ordering or liveness; the DLB strategies rely on it.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Optimizing Fine-Grained Parallelism Through Dynamic Load Balancing on Multi-Socket Many-Core Systems." pith.science (2026). https://pith.science/paper/CN75B3BV

@misc{pith2026250205293,
  author       = {Pith},
  title        = {Pith review of: Optimizing Fine-Grained Parallelism Through Dynamic Load Balancing on Multi-Socket Many-Core Systems},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/CN75B3BV}},
  note         = {Machine review of arXiv:2502.05293}
}
abstract

Achieving efficient task parallelism on many-core architectures is an important challenge. The widely used GNU OpenMP implementation of the popular OpenMP parallel programming model incurs high overhead for fine-grained, short-running tasks due to time spent on runtime synchronization. In this work, we introduce and analyze three key advances that collectively achieve significant performance gains. First, we introduce XQueue, a lock-less concurrent queue implementation to replace GNU's priority task queue and remove the global task lock. Second, we develop a scalable, efficient, and hybrid lock-free/lock-less distributed tree barrier to address the high hardware synchronization overhead from GNU's centralized barrier. Third, we develop two lock-less and NUMA-aware load balancing strategies. We evaluate our implementation using Barcelona OpenMP Task Suite (BOTS) benchmarks. We show that the use of XQueue and the distributed tree barrier can improve performance by up to 1522.8$\times$ compared to the original GNU OpenMP. We further show that lock-less load balancing can improve performance by up to 4$\times$ compared to GNU OpenMP using XQueue.

Figures

Figures reproduced from arXiv: 2502.05293 by the authors.

Figure 1
Figure 1. Execution times for nine BOTS benchmarks with three OpenMP [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. XQueue on a 4-core system. Ci is consumer i, Pi is producer i. an auxiliary queue of another worker. It applies a round-robin approach across these queues starting with the master queue. If the chosen queue is full, the worker instead executes that task immediately. When dequeuing, the worker first dequeues from the master queue, if no task is found, it then dequeues a task from its auxiliary queues. The dequeued ta… view at source ↗
Figure 3
Figure 3. Load imbalance of Fib (above) and Sort (below) with XGOMP. Y-axes are Thread ID. Left (Timeline Summary), X-axis is Time, showing the amount of time each thread spends in each state. Right (Task Count), blue bar shows the number of tasks generated, green bar shows the number of tasks executed. 1: tidvictim ← pickVictimTID(plocal, tidi) 2: req ← getVictimRequest(tidvictim) 3: round ← getVictimRound(tidvictim) 4: curr… view at source ↗
Figures from the paper (7 more)
Figure 4
Figure 4. Figure 4: Absolute execution time of BOTS benchmarks (lower is better). [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]
Figure 5
Figure 5. Figure 5: XGOMP/XGOMPTB performance improvement over GOMP, 192 [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]
Figure 6
Figure 6. Figure 6: Scaling performance of different methods comparing execution time as the number of threads is increased for each BOTS application (lower is better) [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]
Figure 7
Figure 7. Figure 7: XGOMP DLB performance comparisons on BOTS with best perfor [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]
Figure 8
Figure 8. Figure 8: PoSp throughput comparing GOMP and XGOMPTB as the batch size [PITH_FULL_IMAGE:figures/full_fig_p011_8.png]
Figure 10
Figure 10. Figure 10: A-WS (work-stealing) approach performance improvement ( [PITH_FULL_IMAGE:figures/full_fig_p011_10.png]
Figure 11
Figure 11. Figure 11: XGOMP, NA-RP, and NA-WS performance comparison on BOTS [PITH_FULL_IMAGE:figures/full_fig_p012_11.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

39 extracted references · 37 canonical work pages

  1. [1]

    Welcome to the documentation of OpenMP in LLVM! — LLVM/OpenMP 20.0.0git documentation

    “Welcome to the documentation of OpenMP in LLVM! — LLVM/OpenMP 20.0.0git documentation.” [Online]. Available: https://openmp.llvm.org/

    work page

  2. [2]

    Cilk: an efficient multithreaded runtime system,

    R. D. Blumofe, C. F. Joerg, B. C. Kuszmaul, C. E. Leiserson, K. H. Randall, and Y . Zhou, “Cilk: an efficient multithreaded runtime system,” in 5th ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming , ser. PPOPP ’95. New York, NY , USA: Association for Computing Machinery, 1995, p. 207–216. [Online]. Available: https://doi.org/10.114...

    work page arXiv 1995

  3. [3]

    Berkeley UPC - Unified Parallel C

    “Berkeley UPC - Unified Parallel C.” [Online]. Available: https: //upc.lbl.gov/

    work page

  4. [4]

    Enabling extremely fine-grained parallelism via scalable concurrent queues on modern many-core architectures,

    P. Nookala, P. Dinda, K. C. Hale, K. Chard, and I. Raicu, “Enabling extremely fine-grained parallelism via scalable concurrent queues on modern many-core architectures,” in 29th International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems. Houston, TX, USA: IEEE, Nov. 2021, p. 1–8. [Online]. Available: https://ie...

    work page arXiv 2021

  5. [5]

    Synchronization strategies on many-core SMT systems,

    A. Navarro-Torres, J. Alastruey-Bened ´e, P. Ib ´a˜nez-Mar´ın, and M. Carpen-Amarie, “Synchronization strategies on many-core SMT systems,” in IEEE 33rd International Symposium on Computer Architecture and High Performance Computing (SBAC-PAD) , Oct. 2021, pp. 54–63, iSSN: 2643-3001. [Online]. Available: https://ieeexplore.ieee.org/document/9651585/?arnum...

    work page arXiv 2021

  6. [6]

    Everything you always wanted to know about synchronization but were afraid to ask,

    T. David, R. Guerraoui, and V . Trigonakis, “Everything you always wanted to know about synchronization but were afraid to ask,” in 24th ACM Symposium on Operating Systems Principles , ser. SOSP ’13. New York, NY , USA: Association for Computing Machinery, Nov. 2013, p. 33–48. [Online]. Available: https://dl.acm.org/doi/10. 1145/2517349.2522714

    arXiv 2013

  7. [7]

    Scaling synchronization in multicore programs: Advanced synchronization methods can boost the performance of multicore software

    A. Morrison, “Scaling synchronization in multicore programs: Advanced synchronization methods can boost the performance of multicore software.” Queue, vol. 14, no. 4, pp. 56–79, Aug. 2016. [Online]. Available: https://dl.acm.org/doi/10.1145/2984629.2991130

    work page arXiv 2016

  8. [8]

    Barcelona OpenMP Tasks Suite: A set of benchmarks targeting the exploitation of task parallelism in OpenMP,

    A. Duran, X. Teruel, R. Ferrer, X. Martorell, and E. Ayguade, “Barcelona OpenMP Tasks Suite: A set of benchmarks targeting the exploitation of task parallelism in OpenMP,” in International Conference on Parallel Processing , ser. ICPP ’09. USA: IEEE Computer Society, Sep. 2009, p. 124–131. [Online]. Available: https://doi.org/10.1109/ICPP.2009.64

    work page doi:10.1109/icpp.2009.64 2009

Show all 39 references
  1. [9]

    ISO/IEC/IEEE 9945,

    “ISO/IEC/IEEE 9945,” https://www.iso.org/standard/50516.html

  2. [10]

    X-OpenMP — eXtreme fine-grained tasking using lock-less work stealing,

    P. Nookala, K. Chard, and I. Raicu, “X-OpenMP — eXtreme fine-grained tasking using lock-less work stealing,” Future Generation Computer Systems , vol. 159, pp. 444–458, 2024. [Online]. Available: https://www.sciencedirect.com/science/article/pii/S0167739X24002541

    2024

  3. [11]

    Libfork: Portable continuation-stealing with stackless coroutines,

    C. J. Williams and J. Elliott, “Libfork: Portable continuation-stealing with stackless coroutines,” arXiv:2402.18480, no. arXiv:2402.18480, Feb. 2024. [Online]. Available: http://arxiv.org/abs/2402.18480

    2024 arXiv

  4. [12]

    Designs, lessons and advice from building large dis- tributed systems,

    J. Dean, “Designs, lessons and advice from building large dis- tributed systems,” 2009, https://www.cs.cornell.edu/projects/ladis2009/ talks/dean-keynote-ladis2009.pdf

    2009

  5. [13]

    RDTSCP — Read Time-Stamp Counter and Processor ID

    “RDTSCP — Read Time-Stamp Counter and Processor ID.” [Online]. Available: https://www.felixcloutier.com/x86/rdtscp

  6. [14]

    Charac- terizing and mitigating work time inflation in task parallel programs,

    S. L. Olivier, B. R. De Supinski, M. Schulz, and J. F. Prins, “Charac- terizing and mitigating work time inflation in task parallel programs,” Scientific Programming, vol. 21, no. 3-4, pp. 123–136, 2013

    2013

  7. [15]

    A NUMA-aware provably- efficient task-parallel platform based on the work-first principle,

    J. Deters, J. Wu, Y . Xu, and I.-T. A. Lee, “A NUMA-aware provably- efficient task-parallel platform based on the work-first principle,” in 2018 IEEE International Symposium on Workload Characterization (IISWC), Sep. 2018, p. 59–70, arXiv:1806.11128 [cs]. [Online]. Available: ...

    2018 arXiv

  8. [16]

    Proofs of space,

    S. Dziembowski, S. Faust, V . Kolmogorov, and K. Pietrzak, “Proofs of space,” in Advances in Cryptology - CRYPTO 2015 . Springer, 2015, pp. 585–605

    2015

  9. [17]

    The chia network blockchain,

    B. Cohen and K. Pietrzak, “The chia network blockchain,” White Paper, Chia. net, vol. 9, 2019

    2019

  10. [18]

    Blake3: One function to rule them all,

    J. O’Connor et al. , “Blake3: One function to rule them all,” https: //github.com/BLAKE3-team/BLAKE3-specs, 2019, accessed: 2025-01- 21

    2019

  11. [19]

    OpenMP application programming interface version 5.0,

    O. A. R. Board, “OpenMP application programming interface version 5.0,” https://www.openmp.org/specifications/, November 2018, accessed: 2025-01-21

    2018

  12. [20]

    Chia green paper,

    C. Network, “Chia green paper,” https://docs.chia.net/files/ ChiaGreenPaper 20241008.pdf, October 2024, accessed: 2025-01- 21

    2024

  13. [21]

    K-sizes in chia documentation,

    “K-sizes in chia documentation,” https://docs.chia.net/k-sizes/, accessed: 2025-01-21

    2025

  14. [22]

    Charm++: A portable concurrent object oriented system based on C++,

    L. V . Kale and S. Krishnan, “Charm++: A portable concurrent object oriented system based on C++,” in 8th Annual Conference on Object- oriented Programming Systems, Languages, and Applications, 1993, pp. 91–108

    1993

  15. [23]

    Swift/T: Large-scale application composition via distributed- memory dataflow processing,

    J. M. Wozniak, T. G. Armstrong, M. Wilde, D. S. Katz, E. Lusk, and I. T. Foster, “Swift/T: Large-scale application composition via distributed- memory dataflow processing,” in 13th IEEE/ACM International Sympo- sium on Cluster, Cloud, and Grid Computing. IEEE, 2013, pp. 95–102

    2013

  16. [24]

    Optimizing a parallel runtime system for multicore clusters: A case study,

    C. Mei, G. Zheng, F. Gioachin, and L. V . Kal ´e, “Optimizing a parallel runtime system for multicore clusters: A case study,” in TeraGrid Conference , ser. TG ’10. New York, NY , USA: Association for Computing Machinery, 2010. [Online]. Available: https://doi.org/10.1145/1838...

  17. [25]

    Lock contention management in multithreaded MPI,

    A. Amer, H. Lu, P. Balaji, M. Chabbi, Y . Wei, J. Hammond, and S. Matsuoka, “Lock contention management in multithreaded MPI,” ACM Transactions on Parallelel Computing , vol. 5, no. 3, Jan. 2019. [Online]. Available: https://doi.org/10.1145/3275443

    2019 doi

  18. [26]

    An efficient abortable- locking protocol for multi-level NUMA systems,

    M. Chabbi, A. Amer, S. Wen, and X. Liu, “An efficient abortable- locking protocol for multi-level NUMA systems,” SIGPLAN Notices , vol. 52, no. 8, p. 61–74, Jan. 2017. [Online]. Available: https: //doi.org/10.1145/3155284.3018768

    2017

  19. [27]

    Productive programming of GPU clusters with OmpSs,

    J. Bueno, J. Planas, A. Duran, R. M. Badia, X. Martorell, E. Ayguade, and J. Labarta, “Productive programming of GPU clusters with OmpSs,” in International Parallel and Distributed Processing Symposium , 2012

    2012

  20. [28]

    PaRSEC: A programming paradigm exploiting heterogeneity for enhancing scalability,

    G. Bosilca, A. Bouteiller, A. Danalis, M. Faverge, T. H´erault, and J. Don- garra, “PaRSEC: A programming paradigm exploiting heterogeneity for enhancing scalability,” Computing in Science and Engineering , vol. 15, no. 6, 2013

    2013

  21. [29]

    StarPU: A unified platform for task scheduling on heterogeneous multicore architectures,

    C. Augonnet, S. Thibault, R. Namyst, and P.-A. Wacrenier, “StarPU: A unified platform for task scheduling on heterogeneous multicore architectures,” Concurrency and Computation: Practice and Experience, Special Issue: Euro-Par 2009 , vol. 23, 2011

    2009

  22. [30]

    Design and analysis of scheduling strategies for multi-CPU and multi- GPU architectures,

    J. V . Ferreira Lima, T. Gautier, V . Danjean, B. Raffin, and N. Maillard, “Design and analysis of scheduling strategies for multi-CPU and multi- GPU architectures,” Parallel Computing, vol. 44, pp. 37–52, 2015

    2015

  23. [31]

    The data locality of work stealing,

    U. A. Acar, G. E. Blelloch, and R. D. Blumofe, “The data locality of work stealing,” Theory of Computing Systems , vol. 35, no. 3, pp. 321– 347, 2002

    2002

  24. [32]

    Legion: Express- ing locality and independence with logical regions,

    M. Bauer, S. Treichler, E. Slaughter, and A. Aiken, “Legion: Express- ing locality and independence with logical regions,” in International Conference on High Performance Computing, Networking, Storage and Analysis, ser. SC ’12. Washington, DC, USA: IEEE Computer Society Press...

    2012

  25. [33]

    Memory-aware scheduling of tasks sharing data on multiple GPUs with dynamic runtime systems,

    M. Gonthier, L. Marchal, and S. Thibault, “Memory-aware scheduling of tasks sharing data on multiple GPUs with dynamic runtime systems,” in IEEE International Parallel and Distributed Processing Symposium , 2022

    2022

  26. [34]

    Locality-Aware Scheduling of Independent Tasks for Runtime Systems,

    ——, “Locality-Aware Scheduling of Independent Tasks for Runtime Systems,” in 5th Workshop on Data Locality - 27th International European Conference on Parallel and Distributed Computing . Lisbon, Portugal: Springer, Aug. 2021, pp. 1–12. [Online]. Available: https://hal.science...

    2021

  27. [35]

    Scalable work stealing,

    J. Dinan, D. B. Larkins, P. Sadayappan, S. Krishnamoorthy, and J. Nieplocha, “Scalable work stealing,” in Conference on High Perfor- mance Computing Networking, Storage and Analysis, ser. SC ’09. New York, NY , USA: Association for Computing Machinery, 2009

    2009

  28. [36]

    Work-first and help-first scheduling policies for terminally strict parallel programs,

    Y . Guo, R. Barik, R. Raman, and V . Sarkar, “Work-first and help-first scheduling policies for terminally strict parallel programs,” in 23rd IEEE International Parallel and Distributed Processing Symposium , vol. 10, 2009

    2009

  29. [37]

    Hierarchical work-stealing,

    J.-N. Quintin and F. Wagner, “Hierarchical work-stealing,” in Euro-Par 2010 - Parallel Processing , P. D’Ambra, M. Guarracino, and D. Talia, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg, 2010, pp. 217– 229

    2010

  30. [38]

    Almost deterministic work stealing,

    S. Shiina and K. Taura, “Almost deterministic work stealing,” in In- ternational Conference for High Performance Computing, Networking, Storage and Analysis , ser. SC ’19. New York, NY , USA: Association for Computing Machinery, 2019

    2019

  31. [39]

    Mystic: Programmable sys- tems research testbed to explore a stack-wide adaptive system fabric,

    A. Orhean, A. Ballmer, T. Koehring, K. Hale, X. Sun, O. Trigalo, N. Hardavellas, S. Kapoor, and I. Raicu, “Mystic: Programmable sys- tems research testbed to explore a stack-wide adaptive system fabric,” in 8th Greater Chicago Area Systems Research Workshop (GCASR) , 2019

    2019

Pith tools

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