Comparing the Performance of MC/DC's on-GPU Event-based Processing Methods in Multigroup and Continuous-energy Problems

Braxton Cuneo; Ilham Variansyah; Joanna Piper Morgan; Kyle E. Niemeyer

REVIEW 2 major objections 5 minor 14 references

Comparing the Performance of MC/DC's on-GPU Event-based Processing Methods in Multigroup and Continuous-energy Problems

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

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

Pith's one-line read MC/DC's asynchronous event scheduling wins early GPU scaling

desk verdict A useful, honest benchmark of two GPU schedulers in MC/DC, but the stack baseline's tuning is under-reported and the speedup numbers come without error bars. read the letter →

arxiv 2506.00263 v1 pith:SRZ2XSVP submitted 2025-05-30 physics.comp-ph

Braxton Cuneo , Joanna Piper Morgan , Ilham Variansyah , Kyle E. Niemeyer This is my paper · ORCID

classification physics.comp-ph MSC 65C0582D75

keywords MC/DCMonteCarloneutrontransportthread-dataremappingevent-basedprocessingGPUcomputingC5G7benchmarkcontinuous-energyasynchronousscheduling

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

MC/DC, a Python Monte Carlo neutron transport package, runs on GPUs by handing thread-data remapping to the Harmonize runtime, which offers two event-based schemes: a conventional stack-based method and a newer asynchronous method. Using the 3D C5G7 k-eigenvalue benchmark and a continuous-energy infinite pin cell problem on four NVIDIA Tesla V100s, the paper compares how fast the two schemes process particle histories. It finds that the asynchronous method reaches the shared upper-performance limit faster in the C5G7 problem, yielding speedups that grow with iteration count and triple in some runs, indicating stronger strong-scaling at small work sizes. In the continuous-energy problem, asynchronous remapping is often slower than stack-based remapping, but its relative performance depends on particle count, tally resolution, and whether the transport loop is treated as one monolithic event or split into five event types. The practical conclusion is that asynchronous remapping suits smaller-scale runs and finely decomposed event systems, while stack-based remapping wins at larger particle counts.

What carries the argument

Thread-data remapping (TDR) is the organizing idea: particle work is subdivided into event types, and particles are regrouped so warps execute similar paths, trading task-analysis cost for reduced divergence. The stack-based method bins particles into global input/output stacks per event type, using atomic size counters and warp-wide bulk pushes and pops. The asynchronous method stores particles in warp-local work links in shared memory, grouped by event ID and linked into lock-free lists, spilling to global memory only when the local stash is full; this gives locality and cheaper remapping at small particle counts but a larger shared-memory footprint per warp, lowering occupancy. The paper also varies the transport-loop task decomposition: a monolithic step event versus a five-event split of movement, collision, surface crossing, domain crossing, and closeout, which changes where remapping can occur.

What would settle it

Run the same two benchmarks with an independently tuned stack-based implementation whose input-buffer threshold and per-stack capacities are varied systematically; if a different threshold removes or reverses the asynchronous method's early-scaling advantage in C5G7, the claimed ranking is an artifact of tuning rather than of the algorithm. Kernel profiling that measures per-SM warp occupancy and atomic-wait cycles would also directly test the paper's occupancy explanation for the tally-resolution penalty.

Watch

Extended reading notes

Core claim

The central claim is that the two thread-data-remapping algorithms available in Harmonize, the stack-based event scheme and the distributed asynchronous scheme, have complementary performance regimes, and that event decomposition can flip their ranking. In the 3D C5G7 benchmark, both methods converge to the same ceiling of roughly 6.9e5 histories per second, but asynchronous remapping approaches that ceiling much earlier, with speedups relative to the stack method increasing with cycle count and reaching about 3x in some cases. In the continuous-energy pin cell, the asynchronous method is generally slower under the monolithic single-event task scheme, and its relative speedup drops as particle count and tally resolution increase; stack-based remapping benefits from amortizing its fixed costs over larger particle counts. The counter-intuitive result is that combining asynchronous remapping with a five-event decomposed transport loop can outperform both the monolithic stack baseline and either change applied alone, because asynchronous remapping is cheap at most particle counts and can therefore profit from the divergence reduction of finer event decomposition.

Load-bearing premise

The comparison assumes the stack-based and asynchronous runtimes are equally mature, equally well-tuned implementations of the same interface, so that differences in speed come from the algorithms themselves rather than from tuning choices such as the stack buffer threshold or implementation quality.

Editorial extensions

If this is right

For problems run at small scale or with work spread thinly across GPUs, asynchronous remapping should be the default because it reaches the performance ceiling sooner.
For large particle counts, stack-based remapping is the safer choice because it amortizes fixed remapping costs over more data.
MC/DC users can treat event decomposition as a performance lever: the five-event split combined with asynchronous remapping beat both the monolithic baseline and either change alone in part of the continuous-energy space.
The shared upper performance limit in C5G7 points to transport-logic memory traffic, not remapping, as the next bottleneck to optimize.
Improving asynchronous remapping's warp occupancy, for example through lock-free stash sharing across warps, would likely extend its advantage to higher tally resolutions.

Reading between the lines

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

A testable extension is to sweep the stack-buffer threshold and per-stack capacities at the same particle counts; the paper's 2e6 per-stack capacity inflection point predicts a sharp performance break there that is directly measurable.
The decomposition result suggests a search over finer or alternative event splits: if asynchronous remapping is cheap at most particle counts, then more event types should keep reducing divergence until stash occupancy or spill becomes the limiting factor.
The occupancy theory implies the relative ranking may shift on GPUs with different shared-memory sizes or warp widths; a reader could check whether larger shared memory per SM weakens the tally-resolution penalty.
For production use, a hybrid policy is implicit: choose asynchronous below some particle-count or tally-resolution threshold and stack-based above it, with the threshold to be calibrated per problem.

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.

Desk Editor's Note

read the letter

Colleague,

Quick take: this is a clean, clearly written performance study comparing two event-based GPU scheduling methods in MC/DC. The asynchronous method wins at low particle counts in the C5G7 benchmark, and the authors show that decomposing the continuous-energy transport loop into five events changes the ranking. That's genuinely new data and a practical scheduling rule for MC/DC users. It's not a novel algorithm—the two runtimes are prior work, with the asynchronous one detailed by Cuneo and Bailey [9]—but the head-to-head benchmark and the decomposition analysis are a real extension.

What the paper does well: it gives enough problem setup to reproduce the benchmarks (fixed benchmarks, specific cycle counts, particle counts, tally resolutions), it offers plausible mechanistic explanations (stash locality, warp occupancy, amortization of stack costs), and it's honest about where those explanations are speculative (they say kernel profiling is needed). No fitted parameters, no circular derivation. The five-event decomposition is a nice contribution and the counter-intuitive result that the two poor-performing options combine well is worth following up.

Where it's soft: the numbers have no error bars or repeated-run statistics. A performance paper without any measure of run-to-run variance is hard to trust for the size of the speedups, especially when the differences are a factor of 2-3 at small particle counts. More specifically, the stack-based baseline's configuration is under-reported. Section 3.1 mentions a threshold for concluding a kernel launch ('until the most full output buffer exceeds a threshold value') but never states the value. Section 5.2 attributes an inflection in the decomposed scheme to 'each stack's provisioned capacity... 2×10^6' without saying how that capacity was chosen or whether the monolithic scheme uses a different, favorable allocation. If the threshold or capacity were different, the early-scaling advantage of the asynchronous method could shrink or vanish. This isn't a fatal flaw—the trends are consistent with prior work [9] and the arguments are plausible—but it's exactly the kind of tuning sensitivity that a referee should ask the authors to document or sweep.

A separate, minor point: the claimed cause of the shared performance ceiling (global memory loads in transport logic) is asserted without profiling. They acknowledge this, so I don't hold it against them.

Who this is for: MC/DC and Harmonize developers, and anyone comparing event-based schedulers on GPUs for Monte Carlo transport. A serious referee should engage with it; the paper is solid enough to warrant revision rather than rejection. My recommendation: send it to review, ask for repeated runs, error bars, and a sensitivity study on the stack threshold/capacity, then it's publishable as-is or with minor revisions.

Referee Report

2 major / 5 minor

Summary. The paper describes two GPU thread-data remapping (TDR) algorithms used by MC/DC through the Harmonize runtime: a conventional stack-based event-based method and a distributed asynchronous method. It compares their performance on a 3D C5G7 k-eigenvalue benchmark with multigroup cross sections and on a continuous-energy infinite pin cell problem, run on four NVIDIA Tesla V100s. For C5G7, the asynchronous method is reported to approach the same upper-performance limit as the stack-based method but with stronger early scaling, yielding speedups that grow with cycle count and triple in some cases. For the continuous-energy problem, the comparison is mixed: the asynchronous method is slower than the stack-based method under the monolithic task scheme for most surveyed points, but combined with a decomposed five-event task scheme it outperforms the monolithic stack-based baseline in some configurations. The paper also proposes mechanistic explanations for the observed trends, including shared-memory locality, warp occupancy, and amortization of fixed remapping costs.

Significance. If the reported performance ranking is robust, the paper gives MC/DC users a practical scheduling rule—use asynchronous remapping for small particle counts—and demonstrates that task decomposition can reverse the relative ranking of the two remapping methods, an interesting result for GPU Monte Carlo transport. The paper is clearly written, builds on open-source software (MC/DC and Harmonize), and provides concrete benchmark definitions that make the experiments reproducible. The qualitative trends are plausible, and the authors are transparent about the need for further profiling to confirm the proposed causes. However, the empirical basis is not yet fully established: the stack-based baseline contains undocumented tuning parameters, and no repeated-run statistics or error bars are reported, so the central comparison is under-supported.

major comments (2)

[§3.1, §5.2] The stack-based baseline is defined by at least two unstated parameters: the output-buffer threshold that ends a kernel launch (§3.1) and the per-stack provisioned capacity, which is invoked in §5.2 as 2×10^6 only for the decomposed task scheme. The paper gives no sensitivity sweep over the threshold, no value for the monolithic stack capacity, and no justification that the chosen configuration is representative rather than favorable to the asynchronous method. Because the reported asynchronous advantage in C5G7 is largest at small particle counts (Fig. 5), exactly where buffer-fill thresholds determine kernel-launch boundaries, a different stack configuration could shrink, eliminate, or reverse the claimed early-scaling benefit; the practical recommendation to use asynchronous remapping at small history counts therefore rests on an unexamined configuration.
[§5.1, §5.2, Figs. 5–7] The paper reports no repeated-run statistics, error bars, or confidence intervals for any timing measurement. Single measurements (the number of replicates is not stated) are used to assert that asynchronous remapping 'triples' performance in some C5G7 cases and to rank the four method/task combinations in the continuous-energy problem. Without an estimate of run-to-run variability, the reader cannot tell whether the observed speedups and orderings are significant or within noise, particularly for the smaller particle counts where the differences are largest.

minor comments (5)

[§5.1, §5.2] The axes of Figs. 5–7 are not fully described in the text; the reader must infer what 'iterations' and 'speedup' refer to, and the x-axis units for particle counts are not specified. Please define all axes and the speedup baseline explicitly in the captions or text.
[§5.2] The phrase 'on a the monolithic' contains a typo; also, the file path 'examples/fixed source/ inf pin ce/input.py' should use underscores for clarity and avoid a space before 'inf'.
[§5.1] The paper states that both algorithms converge to 'approximately 6.9 × 10^5 histories per second' but does not explain how this throughput is measured (e.g., wall-clock time per active cycle, including initialization and tally finalization). Please clarify the definition.
[§5.2] The mechanistic explanations—warp occupancy, amortization of fixed costs, and the 'reasonably cheap' characterization of asynchronous remapping—are presented without direct supporting measurements; the paper acknowledges kernel profiling is needed, but the conclusions should more clearly separate measured trends from hypothesized causes.
[§2, §3] The paper cites the Harmonize repository without specifying the exact version or commit used for the benchmarks; please provide this detail to improve reproducibility.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity: the paper reports direct benchmark measurements, and the only self-citation is explanatory, not load-bearing.

full rationale

The paper's central claims are empirical performance comparisons of two GPU event-processing methods on the 3D C5G7 benchmark and a continuous-energy infinite pin cell problem. The reported speedups are direct runtime measurements against external benchmark problems; there are no fitted parameters, no quantity is 'predicted' from its own fitted output, and no derivation chain reduces to the paper's inputs. The only self-referential element is citation [9] (Cuneo and Bailey), used to explain the observed asynchronous-method behavior: 'As shown in prior research [9], problems that do not exhibit rapid growth in simulated histories use less global memory for particle storage with asynchronous remapping versus stack-based remapping.' This citation supports a post-hoc explanation of the measured results, but it does not define the benchmark outcome or supply the performance data. Likewise, the paper's reference to [14] about amortizing stack-based remapping costs is an external explanation, not a premise that forces the conclusion. Concerns about stack-buffer threshold tuning or shared-memory occupancy are reproducibility and generalization risks, not circularity: the comparison remains an empirical measurement of the specific implementations tested. No uniqueness theorem, no ansatz smuggled via citation, and no renaming of known results as organization are present. The paper is self-contained against external benchmarks, so the circularity score is low.

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

No fitted parameters, model constants, or new physical entities are introduced. The paper is purely an empirical performance study, so its load-bearing premises are about implementation fairness and measurement reliability.

assumptions (3)

domain assumption The two Harmonize runtimes in MC/DC v0.11.1 fairly represent the general stack-based and asynchronous TDR approaches.
Section 3 describes both but provides no evidence of equal optimization; unfair tuning would invalidate cross-method conclusions.
domain assumption The benchmark definitions are correct implementations of C5G7 (Hou et al.) and the infinite pin cell example.
Section 4 references external definitions but no verification is given.
domain assumption Observed runtime differences are larger than run-to-run variance.
Figures 5-7 lack error bars and repeated-run statistics; Section 5 draws conclusions from single speedup curves.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Comparing the Performance of MC/DC's on-GPU Event-based Processing Methods in Multigroup and Continuous-energy Problems." pith.science (2026). https://pith.science/paper/SRZ2XSVP

@misc{pith2026250600263,
  author       = {Pith},
  title        = {Pith review of: Comparing the Performance of MC/DC's on-GPU Event-based Processing Methods in Multigroup and Continuous-energy Problems},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/SRZ2XSVP}},
  note         = {Machine review of arXiv:2506.00263}
}

read the original abstract

Monte Carlo / Dynamic Code (MC/DC) is a portable Monte Carlo neutron transport package for rapid numerical methods exploration in heterogeneous and HPC contexts, developed under the auspices of the Center for Exascale Monte Carlo Neutron Transport (CEMeNT). To support execution on GPUs, MC/DC delegates resource and execution management to Harmonize (another CEMeNT software project). In this paper, we describe and compare the performance of the two methods that Harmonize currently provides: a stack-based method and a distributed, asynchronous method. As part of this investigation, we analyze the performance of both methods under the 3D C5G7 k-eigenvalue benchmark problem and a continuous-energy infinite pin cell problem, as run across 4 NVIDIA Tesla V100s. We find that the asynchronous method exhibits stronger early scaling compared to the stack-based method in the 3D C5G7 benchmark. We also found that the asynchronous method exhibits mixed performance relative to the stack-based method in the continuous-energy problem, depending upon tally resolution, particle count, and transport loop decomposition.

Figures

Figures reproduced from arXiv: 2506.00263 by the authors.

**Figure 2.** A diagram illustrating an example stash state, reproduced with permission from Ref. [9]. [PITH_FULL_IMAGE:figures/full_fig_p006_2.png] view at source ↗

**Figure 3.** A diagram illustrating how work is transferred between shared memory and global memory [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗

Figures from the paper (4 more)

**Figure 4.** Figure 4: A diagram of potential paths of flow control under the tested monolithic task scheme (left) [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]

**Figure 5.** Figure 5: A graph depicting the speedup conferred by asynchronous remapping on the previously [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]

**Figure 6.** Figure 6: Graphs depicting the speedup conferred by the decomposed task scheme with stack-based [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]

**Figure 7.** Figure 7: A graph depicting the speedup conferred by the joint use of the decomposed task scheme [PITH_FULL_IMAGE:figures/full_fig_p010_7.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

14 extracted references · 13 canonical work pages

[9]

Divergence reduction in Monte Carlo neutron transport with on-GPU asynchronous scheduling,

B. Cuneo and M. Bailey, “Divergence reduction in Monte Carlo neutron transport with on-GPU asynchronous scheduling,” ACM Trans. Model. Comput. Simul., vol. 34, no. 1, 2023

work page 2023
[1]

MC/DC: Monte Carlo Dynamic Code version 0.11.1,

Center for Exascale Monte Carlo Neutron Transport (CEMeNT), “MC/DC: Monte Carlo Dynamic Code version 0.11.1,” Oct. 2024. [Online]. Available: https://doi.org/10.5281/zenodo. 14010170

doi:10.5281/zenodo 2024
[2]

Monte Carlo / Dynamic Code (MC/DC): An accelerated Python package for fully transient neutron transport and rapid methods development,

J. P. Morgan, I. Variansyah, S. L. Pasmann, K. B. Clements, B. Cuneo, A. Mote, C. Goodman, C. Shaw, J. Northrop, R. Pankaj, E. Lame, B. Whewell, R. G. McClarren, T. S. Palmer, L. Chen, D. Y. Anistratov, C. T. Kelley, C. J. Palmer, and K. E. Niemeyer, “Monte Carlo / Dynamic Code (MC/DC): An accelerated Python package for fully transient neutron transport a...

work page 2024
[3]

Development of MC/DC: a performant, scalable, and portable Python-based Monte Carlo neutron transport code,

I. Variansyah, J. P. Morgan, J. Northrop, K. E. Niemeyer, and R. G. McClarren, “Development of MC/DC: a performant, scalable, and portable Python-based Monte Carlo neutron transport code,” in International Conference on Mathematics and Computational Methods Applied to Nuclear Science and Engineering, Niagara Falls, Ontario, Canada, 2023. 10

work page 2023
[4]

Numba: a LL VM-based Python JIT compiler,

S. K. Lam, A. Pitrou, and S. Seibert, “Numba: a LL VM-based Python JIT compiler,” in Proceedings of the Second Workshop on the LL VM Compiler Infrastructure in HPC. Austin Texas: ACM, Nov. 2015, pp. 1–6

work page 2015
[5]

harmonize,

Center for Exascale Monte Carlo Neutron Transport (CEMeNT), B. Cuneo, and J. P. Morgan, “harmonize,” Apr. 2024. [Online]. Available: https://github.com/CEMeNT-PSAAP/ harmonize

work page 2024
[6]

Streamlining gpu applications on the fly: thread divergence elimination through runtime thread-data remapping,

E. Zhang, Y. Jiang, Z. Guo, and X. Shen, “Streamlining gpu applications on the fly: thread divergence elimination through runtime thread-data remapping,” in Proceedings of the 24th ACM International Conference on supercomputing, ser. ICS ’10. ACM, 2010, pp. 115–126

work page
[7]

Revisiting ilp designs for throughput- oriented gpgpu architecture,

P. Xiang, Y. Yang, M. Mantor, N. Rubin, and H. Zhou, “Revisiting ilp designs for throughput- oriented gpgpu architecture,” in 2015 15th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing, 2015, pp. 121–130

work page 2015

Show all 14 references

[8]

Status of vectorized monte carlo for particle transport analysis,

W. R. Martin and F. B. Brown, “Status of vectorized monte carlo for particle transport analysis,” Int. J. Supercomput. Appl.; (United States), vol. 2, no. 1, 1 1987. [Online]. Available: https://www.osti.gov/biblio/5954420

1987
[10]

Multigroup Monte Carlo on GPUs: Compar- ison of history- and event-based algorithms,

S. P. Hamilton, S. R. Slattery, and T. M. Evans, “Multigroup Monte Carlo on GPUs: Compar- ison of history- and event-based algorithms,” Annals of Nuclear Energy, vol. 113, pp. 506–518, Mar. 2018

2018
[11]

An alternative to stride-based rng for monte carlo transport,

B. S. Cuneo and I. Variansyah, “An alternative to stride-based rng for monte carlo transport,” Transaction of the American Nuclear Society, vol. 130:1, pp. 423–426, Jun. 2024

2024
[12]

Memory management with explicit regions,

D. Gay and A. Aiken, “Memory management with explicit regions,” in Proceedings of the ACM SIGPLAN 1998 Conference on Programming Language Design and Implementation, ser. PLDI ’98. New York, NY, USA: Association for Computing Machinery, 1998, p. 313–323. [Online]. Available: ht...

1998
[13]

OECD/NEA benchmark for time-dependent neutron transport calculations without spatial homogenization,

J. J. Hou, K. N. Ivanov, V. F. Boyarinov, and P. A. Fomichenko, “OECD/NEA benchmark for time-dependent neutron transport calculations without spatial homogenization,” Nuclear Engineering and Design, vol. 317, pp. 177–189, 2017

2017
[14]

Progress Porting LLNL Monte Carlo Transport Codes to Nvidia GPUs,

M. Pozulp, R. Bleile, P. Brantley, S. Dawson, M. McKinley, and A. R. M. Y. M. O’Brien, “Progress Porting LLNL Monte Carlo Transport Codes to Nvidia GPUs,” in International Conference on Mathematics and Computational Methods Applied to Nuclear Science and Engi- neering, Niagara...

2023

Pith tools

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

[1] [9]

Divergence reduction in Monte Carlo neutron transport with on-GPU asynchronous scheduling,

B. Cuneo and M. Bailey, “Divergence reduction in Monte Carlo neutron transport with on-GPU asynchronous scheduling,” ACM Trans. Model. Comput. Simul., vol. 34, no. 1, 2023

work page 2023

[2] [1]

MC/DC: Monte Carlo Dynamic Code version 0.11.1,

Center for Exascale Monte Carlo Neutron Transport (CEMeNT), “MC/DC: Monte Carlo Dynamic Code version 0.11.1,” Oct. 2024. [Online]. Available: https://doi.org/10.5281/zenodo. 14010170

doi:10.5281/zenodo 2024

[3] [2]

Monte Carlo / Dynamic Code (MC/DC): An accelerated Python package for fully transient neutron transport and rapid methods development,

J. P. Morgan, I. Variansyah, S. L. Pasmann, K. B. Clements, B. Cuneo, A. Mote, C. Goodman, C. Shaw, J. Northrop, R. Pankaj, E. Lame, B. Whewell, R. G. McClarren, T. S. Palmer, L. Chen, D. Y. Anistratov, C. T. Kelley, C. J. Palmer, and K. E. Niemeyer, “Monte Carlo / Dynamic Code (MC/DC): An accelerated Python package for fully transient neutron transport a...

work page 2024

[4] [3]

Development of MC/DC: a performant, scalable, and portable Python-based Monte Carlo neutron transport code,

I. Variansyah, J. P. Morgan, J. Northrop, K. E. Niemeyer, and R. G. McClarren, “Development of MC/DC: a performant, scalable, and portable Python-based Monte Carlo neutron transport code,” in International Conference on Mathematics and Computational Methods Applied to Nuclear Science and Engineering, Niagara Falls, Ontario, Canada, 2023. 10

work page 2023

[5] [4]

Numba: a LL VM-based Python JIT compiler,

S. K. Lam, A. Pitrou, and S. Seibert, “Numba: a LL VM-based Python JIT compiler,” in Proceedings of the Second Workshop on the LL VM Compiler Infrastructure in HPC. Austin Texas: ACM, Nov. 2015, pp. 1–6

work page 2015

[6] [5]

harmonize,

Center for Exascale Monte Carlo Neutron Transport (CEMeNT), B. Cuneo, and J. P. Morgan, “harmonize,” Apr. 2024. [Online]. Available: https://github.com/CEMeNT-PSAAP/ harmonize

work page 2024

[7] [6]

Streamlining gpu applications on the fly: thread divergence elimination through runtime thread-data remapping,

E. Zhang, Y. Jiang, Z. Guo, and X. Shen, “Streamlining gpu applications on the fly: thread divergence elimination through runtime thread-data remapping,” in Proceedings of the 24th ACM International Conference on supercomputing, ser. ICS ’10. ACM, 2010, pp. 115–126

work page

[8] [7]

Revisiting ilp designs for throughput- oriented gpgpu architecture,

P. Xiang, Y. Yang, M. Mantor, N. Rubin, and H. Zhou, “Revisiting ilp designs for throughput- oriented gpgpu architecture,” in 2015 15th IEEE/ACM International Symposium on Cluster, Cloud and Grid Computing, 2015, pp. 121–130

work page 2015