Pith. sign in

REVIEW 4 major objections 5 minor 6 references

ParEVO: verified training data plus compiler- and race-detector-guided evolution yields fast, correct parallel code that beats expert kernels on irregular data.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

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

A pipeline of fine-tuned LLMs plus evolutionary repair produces parallel code for irregular workloads that the authors measure as ~13.6x faster on graph kernels and up to 4.1x faster than a human expert on Maximal Independent Set.

T0 review reviewed 2026-08-02 challenge →

load-bearing objection Plausible and checkable system for LLM parallel-code synthesis with real assets, but its headline speedup numbers are unreliable until the reference baseline and failure handling are defined. the 4 major comments →

arxiv 2603.02510 v2 pith:FRYYNM3E submitted 2026-03-03 cs.LG cs.DCcs.NEcs.PF

ParEVO: Synthesizing Code for Irregular Data: High-Performance Parallelism through Agentic Evolution

Liu Yang , Zeyu Nie , Andrew Liu , Felix Zou , Deniz Altinb\"uken , Amir Yazdanbakhsh , Quanquan C. Liu This is my paper
classification cs.LG cs.DCcs.NEcs.PF
keywords ParEVOparallel code synthesisirregular dataParlayLibevolutionary coding agentrace detectionwork-span primitivesspeedup benchmark
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

ParEVO is trying to establish that the hardest part of high-performance computing—writing correct, fast parallel code for irregular data such as graphs, sparse matrices, and unbalanced trees—can be automated with a language model. The recipe has three parts: a 13,820-example corpus in which every program is verified to compile and pass tests, so the model learns to map instructions onto the composable functional primitives of the ParlayLib parallel library; fine-tuning of base models on that corpus; and an evolutionary agent that treats compilers, dynamic race detectors, and runtime profiles as fitness signals, iterating candidate programs until they are correct and then fast. The authors report that the best fine-tuned model reaches a 106.87x average speedup on the ParEval benchmark, 13.6x on irregular graph problems, and that evolution yields up to 4.125x speedup over an expert-written Rust Maximal Independent Set baseline. A sympathetic reader would care because this points to a path from 'LLMs write plausible code' to 'LLMs compete with expert parallel programmers.'

Core claim

The central discovery is that the abstraction level matters as much as the model: when a language model is trained to generate code in terms of ParlayLib's high-level work-span primitives—scan, reduce, filter, pack, sort—the parallelization problem becomes a local transformation task that Transformer attention can manage, rather than a global state-tracking problem. ParEVO couples this with a verification-gated corpus and an Evolutionary Coding Agent that uses deterministic tools as critics: a candidate program that fails to compile, triggers a dynamic race detector, or times slowly is fed back as a prompt for the next mutation, with MAP-Elites used to preserve diversity among survivors. On

What carries the argument

The load-bearing machinery is the three-stage pipeline. (1) A synthetic corpus is built by mutating 593 hand-written golden examples with type, constraint, and algorithmic mutations, then accepting only candidates that compile and pass unit tests; the resulting 13,820 verified instruction pairs include slow-fast performance comparisons so the model learns to select more efficient algorithms. (2) Base models are low-rank fine-tuned on this corpus, with an additional preference-optimization stage that suppresses failure modes. (3) The Evolutionary Coding Agent (ECA) maintains a population of candidates, compiles and runs each one, assigns fitness 0 to any program that fails compilation, tests,

Load-bearing premise

The load-bearing premise is that the speedups are ratios against a meaningful, fixed reference: the paper reports large average speedups but never states which implementation the generated code is timed against, nor whether tasks that fail to compile or pass are excluded from the speedup mean.

What would settle it

Re-run the released ParEVO-generated programs over every ParEval task against a stated single-threaded reference implementation, record per-task speedups, and report the median and geometric mean alongside the arithmetic mean. If the median drops below roughly 10x or the 106x figure collapses when the single 1103x scan outlier is removed, the headline average is an artifact of baseline choice and one dominant task.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

  • LLM-based code synthesis can reach performance-sensitive parallel kernels, not just sequential code: generated programs compile, pass tests, and come with race-detector-cleared concurrency.
  • Targeting a high-level primitive library shifts the hard part of parallelization into a form Transformers can learn; this design principle should transfer to other composable parallel DSLs.
  • An evolutionary loop driven by compiler and runtime diagnostics reliably repairs the last mile of correctness and performance, adding roughly 2.2x over the first valid generated solution.
  • Fine-tuning for safety incurs an alignment tax: correctness gains on graph problems (Pass@1 from 0.42 to 0.76) come with reduced peak speedup (21.7x to 13.6x), so performance-oriented users still need evolutionary search to rediscover risky-but-fast patterns.
  • The same corpus-plus-evolution pipeline extends to at least one other language (Rust with Rayon), indicating the approach is not tied to a single parallel library.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The reported 106.87x average speedup is an arithmetic mean over tasks, and the paper's own category breakdown shows a single scan task at 1103x dominating the mean; a median-based comparison would likely place typical per-task speedups closer to 10x. This is my reading of the published numbers, not a claim the paper makes.
  • Because the tables never state the reference implementation used in the speedup denominator, the headline figures could mix a correctness filter with runtime gains: if only tasks that compile and pass contribute to the mean, then a model that produces a few very fast solutions can score higher than a model that outputs many correct but slightly slower ones. Recomputing speedups against a fixed ref
  • The paper's abstraction-alignment argument makes a testable prediction: ParEVO's advantage should shrink on targets without high-level composable primitives, such as MPI or CUDA kernels where synchronization is explicit, because the model must then manage global state and inter-thread timing—the exact regime where base LLMs fail.
  • If the evolutionary agent's power comes from deterministic tool feedback, applying it to GPU or distributed code should be harder: dynamic race detection and profiling are less mature in those settings, so the observed ~2.2x evolution gain might shrink or require new verification tools.
Share X Bluesky LinkedIn Reddit HN

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

4 major / 5 minor

Summary. ParEVO is presented as an end-to-end system for generating parallel C++ (ParlayLib) and Rust (Rayon/RPB) code for irregular workloads. It has three stages: (i) construction of a synthetic Parlay-Instruct corpus by mutating seed tasks with a teacher model and compiler/unit-test rejection; (ii) SFT/DPO fine-tuning of DeepSeek-6.7B, Qwen3-30B, and Gemini-2.5-Pro; (iii) an evolutionary coding agent (ECA) that uses compiler diagnostics, dynamic race detection, and profiler feedback to refine candidates. The headline empirical claims are an average 106x Speedup@1 on ParEval for Gemini-2.5-Parlay, a 13.6x speedup on graph problems, up to a 4.1x speedup over expert PBBS/RPB baselines on Maximal Independent Set, and a 2.2x ECA improvement over single-shot generation.

Significance. If the central numbers were properly grounded, the paper would be a significant step: it shows a concrete route to aligning LLM generation with a high-level parallel library and uses deterministic execution feedback, not LLM-as-judge, for repair. Strengths include release of the corpus, model checkpoints, and code; evaluation against external benchmarks (ParEval, PBBS, RPB); and explicit discussion of a correctness-speedup tradeoff. My assessment is that the current evidence does not yet support the headline magnitudes: the speedup metric is underspecified, several reporting choices mix overall and category-level results, and the ECA ablation is on training-distribution problems. These are fixable with a reanalysis and clearer measurement protocol, which is why I recommend major revision rather than rejection.

major comments (4)
  1. [§4.2, Table 1, Fig. 4(c)] Speedup@1 is the load-bearing metric but its denominator is never defined. The methodological note says only that the arithmetic mean is used; it does not state whether the reference is the ParEval sequential reference, a hand-written sequential baseline, the base model's output, or a single-threaded run, nor whether tasks that fail to compile/pass are assigned a value of 0 or excluded. With Gemini-2.5-Parlay Pass@1=0.33, the 'expected speedup' interpretation requires including the 67% non-passing draws as no speedup; averaging passing-only runs is a different quantity. Please define the denominator, give the all-task and passing-only means, and report per-task speedups. Until then the abstract's 106x claim is not well-formed.
  2. [Abstract; §4.7, Table 4] The abstract's 'robust 13.6x speedup specifically on complex irregular graph problems' is contradicted by Table 4, which shows the fine-tuned model's graph-category Speedup@1 drops from 21.76x (Gemini-2.5-Pro) to 13.67x (Gemini-2.5-Parlay); the same table also shows the Pass@1 increase from 0.42 to 0.76. The intro's 'Pass@1 jumps from 0.42 to 0.76' is thus a graph-category statement, while Table 1 shows overall Pass@1 drops from 0.77 to 0.33. Headline numbers must distinguish overall vs graph-specific results, and a reduction in speedup should not be reported as 'robust' without qualification.
  3. [§4.5, Table 2] The expert-baseline comparison is not yet interpretable. Table 2 reports 'best speedup across test inputs' with no input sizes, repetitions, or variance; for Maximal Independent Set, the baseline's 32-thread speedup over its own one-thread run is only 1.116x, while ParEVO's is 0.938x, i.e., ParEVO is slower than its own single-thread run yet the table says it is 4.125x faster than the expert baseline. The basis for calling the baseline 'state-of-the-art human-written' and the 4.125x claim need a detailed measurement protocol (inputs, trials, compilers, thread counts, warm-up), and ideally per-input results.
  4. [§4.6, Table 3] The only direct evidence for the Evolutionary Coding Agent's contribution is evaluated on a 'reserved set of training problems' from DMOJ, the same source used to build the Parlay-Instruct corpus. This cannot establish generalization, and the 2.2x multiplier may reflect distribution overlap with training. Please run the ECA ablation on held-out ParEval/PBBS/RPB tasks and report pass rates and speedups per task, or explicitly label the result as a training-distribution pilot.
minor comments (5)
  1. [§3.5, §4] The final benchmark promised for held-out DMOJ problems does not appear in Section 4 or the appendix; either add the results or remove/qualify the promise.
  2. [§4.2, Table 1] The text says ParEVO achieves a 'near-perfect Build@1 rate'; Table 1 lists Build@1=0.84 for Gemini-2.5-Parlay. Please qualify which category or correct the wording.
  3. [§3.1, Eq. (1)] The corpus acceptance criterion is compilation plus unit-test pass; the abstract's phrase 'explicitly filters for empirically performant algorithms' is supported only for the smaller slow-fast performance subset (with the 1.2x threshold), not for all 13,820 pairs.
  4. [Table 2] Several entries are garbled or duplicated (e.g., 'MAXIMALMATCHINGPAREVO (GEMINI) RUST 0.192821.43286835×1.0708×'; PLANESWEEP and HISTOGRAM share a 27.59x speedup), making the expert comparison hard to audit.
  5. [§4.5, Fig. 12] The MIS baseline is described as unsafe RPB code with a data race; calling it 'state-of-the-art human-written' without specifying which version is being compared is confusing. Clarify whether the 4.1x comparison is against that unsafe implementation.

Circularity Check

0 steps flagged

No significant circularity: ParEVO's central claims are measured against external benchmarks and do not reduce to the training corpus or to self-citations.

full rationale

The paper's derivation chain is training-corpus construction -> fine-tuning -> ECA -> evaluation. The headline speedups on ParEval are computed against the external ParEval suite (Nichols et al., 2024), the expert-baseline comparisons are against PBBS and RPB, and the DMOJ evaluation is described as held-out, so the core 'prediction' is not an input to the pipeline. The only self-citations (ParEVO 2026a/b, HuggingFace URLs) are pointers to released artifacts, not load-bearing evidence. The ECA ablation (Table 3) is computed on 'a reserved set of training problems sourced from DMOJ' (footnote 1), which is an in-sample evaluation and a generalization concern, but it is not circular: the 2.2x speedup is an empirical measurement of the search loop, not a parameter fitted to that value and renamed as a prediction. Likewise, §4.2's 'expected speedup' definition leaves the reference baseline of Speedup@1 unspecified, which undermines the interpretability of the 106x figure, but an undefined denominator is a measurement-validity issue rather than a step in which a result is equivalent to its input by construction. No uniqueness theorem, ansatz cited from same authors, or known-result renaming carries the argument.

Axiom & Free-Parameter Ledger

4 free parameters · 4 axioms · 0 invented entities

No invented entities: the paper introduces a dataset, three model checkpoints, and a search loop — artifacts, not postulated entities with falsifiable handles. The free parameters are the pipeline's acceptance thresholds, selection hyperparameters, granularity constants, and the averaging convention, each of which shapes the measured gains. The axioms are domain assumptions about ParlayLib's guarantees, race-detector sufficiency, and benchmark/corpus disjointness.

free parameters (4)
  • Trajectory acceptance threshold = 1.2x speedup
    Section 3.1.2 discards optimization pairs where C_opt is <1.2x faster than C_base; this filter defines the training distribution for the performance-comparison task and shapes all downstream speedup measurements.
  • ECA selection hyperparameters = k=3 elite, d=5 MAP-Elites; dims = code length, cyclomatic complexity, sync-primitive frequency
    Section 3.3; no sensitivity analysis is provided, and the Table 3 ECA gain (2.2x) is conditional on these choices.
  • Speedup averaging convention = arithmetic mean of Speedup@1 over passing tasks
    Section 4.2 explicitly selects arithmetic-mean over geometric-mean aggregation; with a 1103x scan outlier, this choice moves the headline from ~10x median to 106x.
  • Granularity constants in evolved kernels = e.g., spec_for block=16 (Maximal Matching), block=256 (MIS)
    Appendix code diffs show the ECA tuned these constants; their contribution to the Table 2 speedups is unreported.
axioms (4)
  • domain assumption ParlayLib primitives are 'correct by construction' and yield provably scalable code (Sections 1, 5.1)
    The abstraction-alignment thesis — that mapping loops to ParlayLib primitives yields mathematically sound, scaling code — is asserted, not proven; the paper's own Table 4 shows generated code that is correct but 1.6x slower than the base model's atomics-based version.
  • domain assumption Dynamic race detection is an 'absolute, non-negotiable filter' for correctness (Section 3.3)
    Dynamic race detectors only observe executed schedules; the ECA treats their silence as a correctness guarantee. This is standard practice, but it is a premise about tool coverage, not a proof.
  • domain assumption The 20 DMOJ problems used for trajectory synthesis are disjoint from the DMOJ held-out evaluation and from the 'reserved training problems' in Table 3
    Never stated. Section 3.1.2 curates 20 DMOJ graph problems; Section 4.6 evaluates ECA on 'a reserved set of training problems' — if these overlap, the 2.2x ablation and DMOJ generalization numbers partly reflect memorization.
  • domain assumption Manually adapting ParEval prompts to ParlayLib preserves task difficulty and semantics (Appendix C)
    The benchmark comparison is only as clean as the prompt adaptation; Figures 18-19 present the adapted prompts but there is no validation that the adaptation is neutral across models.

reviewed 2026-08-02 · how reviews work

0 comments
Cite this review

Pith. "Pith review of ParEVO: Synthesizing Code for Irregular Data: High-Performance Parallelism through Agentic Evolution." pith.science (2026). https://pith.science/paper/FRYYNM3E

@misc{pith2026260302510,
  author       = {Pith},
  title        = {Pith review of: ParEVO: Synthesizing Code for Irregular Data: High-Performance Parallelism through Agentic Evolution},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/FRYYNM3E}},
  note         = {Machine review of arXiv:2603.02510}
}
Share X Bluesky LinkedIn Reddit HN
read the original abstract

The transition from sequential to parallel computing is essential for modern high-performance applications but is hindered by the steep learning curve of concurrent programming. This challenge is magnified for irregular data structures (such as sparse graphs, unbalanced trees, and non-uniform meshes) where static scheduling fails and data dependencies are unpredictable. Current Large Language Models (LLMs) often fail catastrophically on these tasks, generating code plagued by subtle race conditions, deadlocks, and sub-optimal scaling. We bridge this gap with ParEVO, a framework designed to synthesize high-performance parallel algorithms for irregular data. Our contributions include: (1) The Parlay-Instruct Corpus, a curated dataset of 13,820 tasks synthesized via a "Critic-Refine" pipeline that explicitly filters for empirically performant algorithms that effectively utilize Work-Span parallel primitives; (2) specialized DeepSeek, Qwen, and Gemini models fine-tuned to align probabilistic generation with the rigorous semantics of the ParlayLib library; and (3) an Evolutionary Coding Agent (ECA) that improves the "last mile" of correctness by iteratively repairing code using feedback from compilers, dynamic race detectors, and performance profilers. On the ParEval benchmark, ParEVO achieves an average 106x speedup (with a maximum of 1103x) across the suite, and a robust 13.6x speedup specifically on complex irregular graph problems, outperforming state-of-the-art commercial models. Furthermore, our evolutionary approach matches state-of-the-art expert human baselines, achieving up to a 4.1x speedup on specific highly-irregular kernels. Source code and datasets are available at https://github.com/WildAlg/ParEVO.

Figures

Figures reproduced from arXiv: 2603.02510 by Amir Yazdanbakhsh, Andrew Liu, Deniz Altinb\"uken, Felix Zou, Liu Yang, Quanquan C. Liu, Zeyu Nie.

Figure 1
Figure 1. Figure 1: A representative sample from the training corpus. Each sample includes a natural language instruction, the ground-truth parallel implementation, and an executable unit test used for verifi￾cation. Performance Optimization Dataset. To enable the model to reason about runtime efficiency, we curated a benchmark of 20 challenging graph problems from the DMOJ competitive programming platform (DMOJ Devel￾opers, … view at source ↗
Figure 2
Figure 2. Figure 2: Comparison of Event Generation Strategies. Left: Code A employs a Map-Scan-Write pattern to enable lock-free parallel writing. Right: Code B relies on sequential push back, preventing parallelization and incurring reallocation costs. The agent maintains a diverse population of candidate so￾lutions, each associated with specific performance metrics (test coverage, execution time) and diagnostic artifacts (c… view at source ↗
Figure 3
Figure 3. Figure 3: Overview of the ParEVO Framework. The system integrates human expert context (problem formulation, parallel tooling) with an evolutionary LLM agent. The cycle iteratively refines candidate parallel algorithms through a rigorous evaluation framework (correctness verification, dynamic race detection, and performance profiling), using metrics to guide the selection of the next population via MAP-Elites. mance… view at source ↗
Figure 4
Figure 4. Figure 4: ParEval Metrics Comparison between Gemini-2.5-Pro and Gemini-2.5-Parlay. (a-c) highlight that fine-tuning signifi￾cantly improves the model’s ability to construct valid ParlayLib code, with substantial gains in build and pass rates as well as im￾proved running time over the base model. For this ablation study, we utilized a reserved set of training problems sourced from DMOJ1 . In [PITH_FULL_IMAGE:figures… view at source ↗
Figure 6
Figure 6. Figure 6: Strong Scaling results. (c) Algorithms like Discrete Fourier Transform show excellent scaling with ParEVO’s gener￾ated code, reaching nearly 40× speedup on 64 cores [PITH_FULL_IMAGE:figures/full_fig_p009_6.png] view at source ↗
Figure 5
Figure 5. Figure 5: Semantic Alignment Example. The base model (top) fails to compile due to incorrect API usage and strict type defi￾nitions in the lambda. The fine-tuned model (bottom) correctly identifies sort inplace and uses auto to handle the complex number types safely. While the actual prompt in each iteration contains more context (other iterations/metrics) by the default template of openevolve, the structural system… view at source ↗
Figure 7
Figure 7. Figure 7: Impact of Fine-tuning on DeepSeek-6.7B. The fine-tuned model (DeepSeek-Parlay) shows massive gains in pass rate and speedup compared to the base model. The DeepSeek-Syntax model is the finetuned model of DeepSeek-6.7B-Base purely on ParlayLib syntax. dense_la fft geometrygraph histogram reduce scan search sort sparse_la stencil transform 0.0 0.2 0.4 0.6 0.8 1.0 1.2 Mean Build@1 0.62 0.77 0.23 0.58 1.00 0.3… view at source ↗
Figure 8
Figure 8. Figure 8: Impact of Fine-tuning on Qwen3-Coder-30B-A3B-Instruct. The fine-tuned model (Qwen3-Rust) shows gains in speedup compared to the base model. B.3. Comparison vs. Expert Human Baselines (PBBS & RPB) A key contribution of this work is benchmarking against expert human code [PITH_FULL_IMAGE:figures/full_fig_p016_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: Runtime and Scalability comparisons against expert Rust and C++ baselines. ParEVO solutions track or beat the scalability of hand-optimized code. In (m)-(o), BackForward BFS specifically refers to the new BFS algorithm ParEVO generated, which uses a different method than the baseline implementation that uses multiqueue BFS. 18 [PITH_FULL_IMAGE:figures/full_fig_p018_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: Code comparison for Maximal Matching. Left (Baseline): Uses mixed safe/unsafe access (potential aliasing bugs) and collects results using two separate passes (red highlights). Right (ParEVO): Uses consistent raw pointer access to ensure memory visibility, increases block granularity to 16, and uses a single-pass unzip for result collection (green highlights). 19 [PITH_FULL_IMAGE:figures/full_fig_p019_10.png] view at source ↗
Figure 11
Figure 11. Figure 11: Code comparison for Minimum Spanning Forest (MSF). Left (Baseline): Uses standard indexing for the reservation array (incurring bounds checks) and standard unwrap() (incurring branch checks), highlighted in red. Right (ParEVO): Adopts a “Maximal Unsafe” strategy, converting all data structures to raw pointers. It uses unwrap unchecked() and pointer arithmetic (.add()) to eliminate all runtime safety check… view at source ↗
Figure 12
Figure 12. Figure 12: Code comparison for Maximal Independent Set (MIS). Left (Baseline): Uses unsafe standard Vec<u8> (red), causing undefined behavior (data races) during reads and writing via raw pointers. It uses a small block size (20). Right (ParEVO): Uses Vec<AtomicU8> (green) for correct synchronization using Relaxed ordering. It optimizes throughput with a larger block size (256) and employs a zero-copy cast to conver… view at source ↗
Figure 13
Figure 13. Figure 13: Code comparison for Spanning Forest. Left (Baseline): Performs a fresh allocation for the reservation array on every call (red) and uses checked indexing/unwrapping inside the hot loop. Right (ParEVO): Implements a memory recycling mechanism via rs cache (green) to reuse the large reservation vector across calls. It also employs get unchecked and AtomicUnionFind to eliminate bounds checking and pointer de… view at source ↗
Figure 14
Figure 14. Figure 14: Code comparison for BFS. Left (Baseline): Uses a standard asynchronous approach where every edge relaxation requires a CAS loop and a queue push (red), leading to high contention on scale-free graphs. Right (ParEVO): Implements Direction-Optimizing BFS (Ligra-style). It dynamically switches between ”Push” (Sparse) and ”Pull” (Dense) modes based on the frontier density (green), drastically reducing edge ch… view at source ↗
Figure 15
Figure 15. Figure 15: Runtime Histograms for Graph Shortest Path. The fine-tuned model (b) exhibits tighter variance (reliability) but a higher median runtime due to overhead from safety-focused primitives. 23 [PITH_FULL_IMAGE:figures/full_fig_p023_15.png] view at source ↗
Figure 16
Figure 16. Figure 16: Code comparison for Shortest Path (Problem 19 in ParEval). Left (Baseline): Effectively uses std::atomic and Compare￾and-Swap (CAS) to manage visitation state in parallel, resulting in a significantly faster runtime. Right (Finetuned): Chooses a high-overhead initialization step (copying the adjacency matrix via tabulate) and falls back to sequential logic for the queue update loop (red), causing O(N 2 ) … view at source ↗
Figure 17
Figure 17. Figure 17: Runtime Histograms for ParEval Problem 34 (Scan). The fine-tuned model (b) exhibits tighter variance and highly predictable performance compared to the wider distribution of the base model (a). 24 [PITH_FULL_IMAGE:figures/full_fig_p024_17.png] view at source ↗
Figure 18
Figure 18. Figure 18: The prompting strategy adopted from the ParEval paper (Nichols et al., 2024). The templates include specific placeholders (function name, prompt) populated dynamically during evaluation. ParEval Extension Examples C++ Prompt (ParlayLib): /* Compute the discrete fourier transform of x. Store the result in output. Use ParlayLib to compute in parallel. Example: input: [1, 4, 9, 16] output: [30+0i, -8-12i, -1… view at source ↗
Figure 19
Figure 19. Figure 19: Representative examples of our manual extensions to the ParEval dataset. The prompts are tailored to enforce specific parallel backends while maintaining identical input/output specifications. 25 [PITH_FULL_IMAGE:figures/full_fig_p025_19.png] view at source ↗
Figure 20
Figure 20. Figure 20: An example of the Concise prompt formulation for the PBBSBench maximalIndependentSet task. The model is provided with the function signature and a request to use ParlayLib, but implementation details of the Graph structure are omitted. RPB Prompt Structure Part 1: Context (Excerpt of ParlayLib-Rust Primitives) The prompt begins by providing the full suite of helper functions (truncated here for brevity). … view at source ↗
Figure 21
Figure 21. Figure 21: An example of the RPB prompting template. We inject the full set of parallel primitive definitions (represented by the flatten excerpt in Part 1) prior to the specific task instructions (Part 2) to ground the model in the available Rust-ParlayLib equivalence layer. 26 [PITH_FULL_IMAGE:figures/full_fig_p026_21.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

6 extracted references · 2 linked inside Pith

  1. [3]

    { 4let(dist, src) = (val.0, val.1); 5ifdata.shortest_distance[src].load(Ordering::Relaxed) < dist {return; } 6 7letnew_distance = dist + 1; 8foriingraph.nodes[src]..graph.nodes[src + 1] { 9lettarget = graph.edges[i].target; 10let mutold_distance = data.shortest_distance[target ].load(Ordering::Relaxed); 11 12// HOT LOOP: High Contention Point 13whilenew_d...

  2. [19]

    common/graph.h

    { 20Ok(_) => { 21// QUEUE PUSH: Locking overhead 22 pq.push(ValType(new distance, target)) ; 23break; 24}, 25Err(x) => old_distance = x,// Retry on failure 26} 27} 28} 29} 30 ParEVO (Optimized) 1impl<’a, Fa, Cond> EdgeMap<’a, Fa, Cond> { 2pub fnapply(&self, frontier: VertexSubset) -> VertexSubset { 3letn =self.g_out.num_nodes(); 4letm =self.g_out.num_edge...

    2024

  3. [2013]

    confident hallucinations

    doi: 10.1145/2442516.2442530. URL https: //doi.org/10.1145/2442516.2442530. Shun, J., Blelloch, G. E., Kyrola, A., Simhadri, H. V ., Tang- wongsan, K., Fineman, J. T., and Gibbons, P. B. Brief announcement: The problem based benchmark suite. In Proceedings of the 24th ACM Symposium on Parallelism in Algorithms and Architectures (SPAA ’12). ACM, 2012. doi:...

    arXiv 2012

  4. [2020]

    Anderson, D., Blelloch, G

    URL https://github.com/cmuparlay/ parlaylib. Anderson, D., Blelloch, G. E., Dhulipala, L., Dobson, M., and Sun, Y . The problem-based benchmark suite (PBBS), V2. InProceedings of the 27th ACM SIG- PLAN Symposium on Principles and Practice of Par- allel Programming (PPoPP ’22). ACM, 2022. doi: 10.1145/3503221.3508422. 10 ParEVO: Synthesizing Code for Irreg...

    arXiv 2022

  5. [2024]

    Du, M., Tuan, L

    GitHub repository. Du, M., Tuan, L. A., Liu, Y ., Qing, Y ., Huang, D., He, X., Liu, Q., Ma, Z., and kiong Ng, S. Afterburner: Reinforce- ment learning facilitates self-improving code efficiency optimization.arXiv preprint arXiv:2505.23387, 2025. Eniser, H. F., Zhang, H., David, C., Wang, M., Christakis, M., Paulsen, B., Dodds, J., and Kroening, D. Toward...

    Pith/arXiv arXiv 2025

  6. [2025]

    URL https: //arxiv.org/abs/2509.06503

    doi: 10.48550/ARXIV .2509.06503. URL https: //arxiv.org/abs/2509.06503. Bitan, T., Kadosh, T., Kaplan, E., Meiri, S., Chen, L., Morales, P., Hasabnis, N., and Oren, G. Unipar: A uni- fied llm-based framework for parallel and accelerated code translation in hpc. In2025 IEEE High Performance Extreme Computing Conference (HPEC). IEEE, 2025. Blelloch, G. E., ...

    Pith/arXiv arXiv doi:10.48550/arxiv.2509.06503 2025

This paper was first reviewed by deepseek-v4-flash on August 2, 2026.