Pith. sign in

REVIEW 4 major objections 5 minor 28 references

Unstructured Hydrodynamics on Spatial Dataflow Architectures: A Joint Code and Data Decomposition Approach

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

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

Pith's one-line read A joint code-and-data decomposition maps an unstructured mesh code to a wafer-scale chip, beating a GPU by up to 4.8x.

desk verdict Real hardware speedup and a genuinely automatable pipeline, but the model's decomposition guidance is not as validated as claimed—worth a serious referee. read the letter →

arxiv 2607.18650 v1 pith:77YVATWK submitted 2026-07-21 cs.DC

Piotr Luczynski , Tal Ben-Nun , Leighton Wilson , Brian Van Essen This is my paper
classification cs.DC
keywords spatialdataflowarchitecturewafer-scaleprocessorunstructuredmeshcodeanddatadecompositionperformancemodelingLULESHSDFGcommunicationlibrary
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 argues that unstructured-mesh applications—long considered infeasible on spatial dataflow processors because of indirect memory accesses and long, irregular communication—can be mapped onto such hardware systematically. The key move is to treat code size as a scarce resource alongside data, jointly decomposing the program and the domain. The authors derive analytical models for local compute, communication, and instruction memory, automate the analysis from a dataflow intermediate representation, and generate low-level code for a wafer-scale spatial processor. Running the LULESH shock-hydrodynamics proxy, they report up to 4.8x speedup over an NVIDIA A100 and measured runtimes within about 50% of their model's predictions. If correct, this extends wafer-scale architectures beyond the structured-grid kernels they were built for.

What carries the argument

The central mechanism is a joint decomposition that solves `min T_Seq + T_Comm + T_Map` subject to `M_C + M_D < 48 KB`, where `M_C` is instruction memory and `M_D` is data memory per processing element. The argument hangs on three pieces: an analytical local-compute and instruction-count model derived from the SDFG (stateful dataflow multigraph) intermediate representation; a communication model that uses a snake-shaped space-filling curve to tile the Z dimension so physical distance between logical neighbors stays bounded; and code-mapping strategies—subprogram PEs arranged in a ring, code swapping, or a control system—selected by the model. The SDFG representation is what lets the compiler

What would settle it

Compile a suite of dataflow-graph-generated subprograms, compare predicted versus measured instruction bytes, and check whether the predicted optimal mapping (subprograms vs code swapping) matches an exhaustive search over decompositions on the hardware. A mismatch on a non-trivial problem—or a code-size ratio that grows worse with program complexity—would falsify the claim that the model can guide decomposition decisions.

Watch

Extended reading notes

Core claim

On the paper's own terms, the central claim is that larger unstructured grid codes can outperform GPUs on spatial dataflow architectures, provided the mapping is guided by a joint model of computation, communication, and instruction-memory constraints. The authors instantiate this for LULESH on the Cerebras Wafer-Scale Engine: automatically generated code plus a communication library achieves up to 4.8x speedup over an NVIDIA A100, and the measured end-to-end runtime stays within 50.5–50.9% of the model's predictions across domain sizes. The discovery is not a single kernel optimization but a demonstrated end-to-end pipeline—dataflow-graph-based analysis, space-filling-curve decomposition, c

Load-bearing premise

The load-bearing premise is that the analytical code-size estimate `I_local` accurately predicts how many bytes of compiled instructions each processing element will need; the paper's own measurements show that estimate can be off by a factor of about 1.85, and the choice between subprogram PEs and code swapping is decided by that budget.

Editorial extensions

If this is right

  • Unstructured mesh codes—not just structured stencils—can be systematically ported to wafer-scale spatial architectures, broadening the class of HPC workloads these chips can serve.
  • The analytical models predict performance with roughly constant overhead, so decomposition decisions can be made without exhaustive hardware search.
  • The reusable communication library for 3D face and corner exchanges can be adapted to other mesh-based physics codes.
  • If instruction memory is the binding constraint, future wafer-scale designs with larger per-PE instruction storage would likely improve these speedups further.
  • The same dataflow-graph-based code-generation pipeline could automate porting of other NumPy-style scientific codes.

Reading between the lines

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

  • The model's code-size estimates appear to undercount compiled code by roughly 1.85x (predicted 9,374 B vs measured 17,360 B for Lagrange Nodal; 9,126 B vs 14,264 B for Lagrange Element). Since the optimal mapping in Table IV hinges on `M_C + M_D < 48 KB`, this suggests the optimality of the chosen subprogram or swapping strategy may be sensitive to that error.
  • The methodology could be tested on other unstructured proxy applications with more irregular connectivity to see whether the constant-overhead model accuracy generalizes beyond LULESH.
  • One could search the full decomposition space empirically on the hardware—varying `e_x, e_y, e_z` and the code-mapping approach—and compare against the model's predicted optimum; the current paper validates runtime but not the optimality of the decomposition choice.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 5 minor

Summary. The paper presents an automated, model-centric pipeline for mapping LULESH, an unstructured Lagrangian hydrodynamics proxy application, onto the Cerebras Wafer-Scale Engine. The authors derive local compute/memory and communication cost models from an SDFG representation of PyLULESH, jointly optimize the data decomposition and the mapping of code to PEs under a 48 KB per-PE memory constraint, and contribute a 3D mesh communication library plus an SDFG-to-CSL code generator with DSD-oriented optimizations. The evaluation reports up to 4.8x end-to-end speedup over an NVIDIA A100, with the measured WSE runtime reported as within 50.5-50.9% of the model prediction, while measured code sizes are about 1.85x larger than predicted.

Significance. If the methodology is validated, this is a significant step toward systematic mapping of full unstructured scientific applications onto spatial dataflow architectures, an area previously limited to structured stencils and hand-tuned kernels. The paper should be credited for a concrete, reproducible implementation: an automated analysis pass over SDFGs, a reusable communication library, aggressive memory-reuse and DSD-generation passes, and a direct hardware measurement of speedup over a GPU. However, the strongest contribution claimed—that the model reliably guides decomposition and code-mapping decisions—is not currently supported by the evidence reported in the paper. The measured speedup is credible, but the model-based methodology needs considerably more validation before the central claims can be accepted.

major comments (4)
  1. [Section IX-B, Tables V-VI] The code-size model underestimates measured code size by roughly 1.85x: Lagrange Nodal predicted 9,374 B vs. measured 17,360 B, and Lagrange Element predicted 9,126 B vs. measured 14,264 B. This error is load-bearing because Section VI solves the constrained optimization min T_Seq+T_Comm+T_Map subject to M_C+M_D<48 KB, and Table IV selects both k_p and the subprogram-vs-swapping approach from model predictions. A factor-of-two underestimate changes feasibility and can change the optimal mapping: a configuration predicted to fit within the 32 KB instruction budget may not fit, or may require an additional subprogram PE. The statement in Section IV-A that local instructions alone exceed 24 KB also appears inconsistent with the ~18.5 KB sum of the predicted local code sizes. The code-size model needs calibration, or the optimization needs to be repeated under perturbed code-size estimates.
  2. [Section IX-C, Fig. 12; Section VI] The paper claims that measured runtime being within 50% of prediction 'validates the model's utility for guiding decomposition decisions.' This does not follow: a constant multiplicative error does not, by itself, preserve the argmin of T_Seq+T_Comm+T_Map over (e_x,e_y,e_z,k_p), or the subprogram-vs-swapping choice. The per-function runtime errors in Tables V-VI are 1.7-1.95x, and the communication model in Fig. 11 shows large constant offsets. The paper never runs an alternative decomposition or a sensitivity analysis (e.g., perturbing each model term by +50-100%) to show that the Table IV optima are stable. Since the model is used to choose the implementation and then validated on the code produced under that choice, an independent mapping or perturbation study is needed to separate the model's predictive value from co-design effects.
  3. [Section III-C and Section V-B] The closed-form expressions for T_nodal, T_element, and the communication terms T_x, T_y, T_z are asserted without a visible derivation. The coefficients (e.g., 7603, 96, 933, 4297), the dependence on SIMD width, and the treatment of boundary nodes are not tied to the SDFG tasklet counts or to per-instruction cycle counts, and the communication model contains unstated approximations (e.g., the number of links N_z and the E_z expression). Because the full optimization is a sum of these terms, these omissions are load-bearing. Please provide the derivation and, ideally, per-kernel model-vs-measured tables for the dominant terms.
  4. [Section IX-C] The A100 baseline is underspecified. The text states only that the GPU is an 'NVIDIA A100 40 GB' running CUDA 13.1, and that both codes run in 32-bit precision. It does not say whether the GPU code is the PyLULESH/OpenMP port, a hand-written CUDA implementation, the optimization flags, the problem sizes, or the measured GPU kernel time definition. The 4.8x speedup is a direct measurement, but its meaning depends entirely on the baseline. Please specify the GPU implementation and, if possible, compare with published LULESH GPU results.
minor comments (5)
  1. [Fig. 1 and Fig. 12] The '50.5-50.9% difference' is not precisely defined. Relative to measured runtime, model runtime, or total runtime? The abstract's phrase 'within 50%' is ambiguous and should be stated as 'measured runtime is at most X% larger than predicted' or similar.
  2. [Section IV-A] The relationship between the claimed 'upwards of 24 KB' of local instructions, the 32 KB hardware instruction budget, and the 48 KB total PE memory is confusing. Please state explicitly which quantities are included in M_C and M_D and reconcile the 24 KB statement with the sum of Tables V-VI predictions.
  3. [Section IX-A, Fig. 11] The text says the communication model is 'quite far' from measured performance, yet concludes that the model is validated because the gap is roughly constant. Consider reporting the constant offset explicitly and incorporating it into the model, so that claims about predictive accuracy are quantitative.
  4. [Tables I-II] Please define what 'code size' includes (e.g., loop body, full function, DSD setup) and specify whether the reported runtimes include DSD setup and loop overhead.
  5. [Section VII] The communication library is described as reusable, but the paper demonstrates it only for LULESH. Clarify which components (e.g., the filter-based Z communication, the combined field exchange) are application-specific and which are generic.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: models are independently constructed and compared, not defined by the target measurements.

full rationale

Walking the derivation chain, the local compute and code-size model (Section III) is built from SDFG structural quantities (tasklet count N_t, degree deg(t), memlet volume D_t, SIMD width) and from microbenchmarks of CSL primitives (Tables I-II), not from LULESH's final runtime. The communication model (Section V) instantiates the independent Spatial Computer model with the paper's own tiling and space-filling-curve parameters, and the allreduce cost is taken from prior published work. The joint optimization (Section VI) minimizes T_Seq+T_Comm+T_Map subject to M_C+M_D < 48 KB; none of these quantities is defined in terms of the measured end-to-end runtime, and no parameter is fitted to the results in Tables V-VI or Figure 12. The measured-versus-predicted comparisons are genuine empirical checks: the reported ~1.85x code-size error and ~1.95x runtime gap are accuracy and validation weaknesses, not evidence that the prediction is equivalent to its inputs. The self-citations ([10], [14], [7]) are published, externally grounded models and tools, and they are not used to define the target quantity. While the model shaped implementation choices, that is normal model-guided engineering, not circularity; a model can guide a search and still be tested on the resulting artifact. Therefore no circular step can be exhibited from the paper's own equations or reduction chain.

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

The models rely on measured hardware constants and on asserted SDFG-to-cost summations that are not fully auditable. The most fragile input is the code-size estimate: it is ~1.85x below compiled reality, yet it determines which mapping strategy is chosen. No new physical entities are postulated.

free parameters (4)
  • Per-instruction cycle counts (DSD/map/loop) = FMA: loop 7139, map 1525, DSD 29 cycles; indirect: loop 224, map 81 cycles (Tables I-II)
    Microbenchmarked on the target hardware; parameterize Tlocal but are not fitted to full-program runtime.
  • RAMP latency T_R = ≈2 cycles
    Taken from prior work [10]; used in all communication formulas.
  • Control-system command overhead O = 50-60 cycles per command
    Taken from [20] and used in Tcontrol; the paper admits it is 'not fully representative'.
  • SIMD vectorization threshold = ≥4 elements
    Assumed for the Tnodal/Telement vectorized branches (Section III-C); not justified by a hardware measurement.
assumptions (6)
  • domain assumption Intra-PE average parallelism is 1, so depth equals work in the Work-Depth model.
    Explicitly stated in Section III-C; needed to justify summing tasklet costs without overlap.
  • domain assumption The Spatial Computer model [14] is a valid predictor of WSE communication time.
    Used throughout Section V to derive TComm; no validation is given for this model on the CS-2 for these patterns beyond the paper's own 50%-offset results.
  • domain assumption Microbenchmark cycle counts for individual CSL constructs are representative inside the full generated application.
    The entire Tlocal model (Sections III-A/B) transfers small benchmarks to the full program; the 50% offset in Fig. 12 shows this transfer is only approximate.
  • domain assumption LULESH's communication reduces to element exchange, nodal exchange, and two allreduces per iteration, with corner contributions accumulated in one XY pass.
    Stated in Sections II-D and VII; depends on the standard LULESH mesh structure and the accumulate-as-you-receive ordering.
  • domain assumption The closed-form Tnodal/Telement expressions are correct sums over SDFG tasklets.
    Presented in Section III-C without a per-tasklet breakdown; Tables V-VI show the predicted runtime is ~2x below measured, so the closed forms omit compiler-address-generation costs.
  • ad hoc to paper Code size and data size add within the 48 KB per-PE budget and the instruction budget is 32 KB minus data spillover.
    Sections IV-A/B define the constraint used for all mapping decisions; the code-size model is later shown to under-predict by ~1.85x, so this constraint is applied with an unverified input.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Unstructured Hydrodynamics on Spatial Dataflow Architectures: A Joint Code and Data Decomposition Approach." pith.science (2026). https://pith.science/paper/77YVATWK

@misc{pith2026260718650,
  author       = {Pith},
  title        = {Pith review of: Unstructured Hydrodynamics on Spatial Dataflow Architectures: A Joint Code and Data Decomposition Approach},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/77YVATWK}},
  note         = {Machine review of arXiv:2607.18650}
}
read the original abstract

Spatial Dataflow Architectures are an emerging hardware pattern in high-performance computing, whose mesh-connected fixed-memory processing elements are tailored for structured grid kernels with two-dimensional neighborhoods. However, practical multiphysics codes are often computed on unstructured grids, which induce indirect memory accesses and high-dimensional communication patterns, making them infeasible to directly map onto said architectures. This work takes a principled, model-centric approach to partitioning unstructured problems onto spatial dataflow architectures. Through communication and memory modeling, we propose a joint decomposition that considers both the size of the application's fields and its subroutines. In particular, we automate the analysis process of the original code, define a high-dimensional decomposition that minimizes communication via space-filling curves, and apply memory optimization techniques, crucial in this memory-limited environment. We demonstrate mapping the Livermore Unstructured Lagrangian Explicit Shock Hydrodynamics (LULESH) application to the Cerebras Wafer-Scale Engine, showing that larger, unstructured grid codes can still outperform GPUs.

Figures

Figures reproduced from arXiv: 2607.18650 by the authors.

Figure 1
Figure 1. Overview of our approach. severely limited. For larger scientific codes, a single PE might not be able to store the entire program. Second, unlike CPU or GPU clusters, where network latency is largely uniform, phys￾ical distance on the WSE directly determines communication cost. Data partitioning strategies in the 2D space are therefore crucial. Lastly, developers must consider both the domain and code layout while … view at source ↗
Figure 2
Figure 2. Overview of a single PE on a CS-2 chip. • Performance and communication models that have con￾stant overhead over experimental execution time. • A reusable communication library for mesh-based ap￾plications supporting efficient neighborhood exchange across all dimensions of a 3D decomposition. • An automated code generator that performs novel mem￾ory optimizations and generates efficient WSE code. II. BACKGROUND AND … view at source ↗
Figure 5
Figure 5. Schematic overview of a Stateful Dataflow Multigraph (SDFG). [PITH_FULL_IMAGE:figures/full_fig_p003_5.png] view at source ↗
Figures from the paper (6 more)
Figure 6
Figure 6. Figure 6: Different approaches for mapping code with their respective costs. [PITH_FULL_IMAGE:figures/full_fig_p005_6.png]
Figure 7
Figure 7. Figure 7: Optimal memory mapping approach by MC and local domain size s = √3 e (left), and predicted runtime overhead at MC = 48 KB (right). C. Comparison Comparing these approaches in our LULESH-specific en￾vironment, let us assume that each PE comprises 48 KB and that MD = 4 ·…
Figure 8
Figure 8. Figure 8: Overview of the 3D domain decomposition approach. [PITH_FULL_IMAGE:figures/full_fig_p007_8.png]
Figure 9
Figure 9. Figure 9: Cross-tile communication diagram. A control wavelet at the end [PITH_FULL_IMAGE:figures/full_fig_p008_9.png]
Figure 10
Figure 10. Figure 10: SDFG transformation stages. After the three passes, the maps are merged into a single map with a single tasklet, enabling a single DSD operation. [PITH_FULL_IMAGE:figures/full_fig_p009_10.png]
Figure 11
Figure 11. Figure 11: Predicted runtime (model) vs. measured for XY element and Z [PITH_FULL_IMAGE:figures/full_fig_p010_11.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

28 extracted references · 4 canonical work pages

  1. [1]

    Benchmarking the cerebras wafer scale engine-2 architecture,

    T. Miyajima and L. Fukuoka, “Benchmarking the cerebras wafer scale engine-2 architecture,” inProceedings of the SC ’25 Workshops of the International Conference for High Performance Computing, Networking, Storage and Analysis, SC Workshops 2025, St Louis, MO, USA, November 16-21, 2025. ACM, 2025, pp. 818–822. [Online]. Available: https://doi.org/10.1145/3...

    arXiv 2025

  2. [2]

    Massively scalable stencil algorithm,

    M. Jacquelin, M. Araya-Polo, and J. Meng, “Massively scalable stencil algorithm,”CoRR, vol. abs/2204.03775, 2022. [Online]. Available: https://doi.org/10.48550/arXiv.2204.03775

    arXiv doi:10.48550/arxiv.2204.03775 2022

  3. [3]

    Scalable distributed high-order stencil computations,

    ——, “Scalable distributed high-order stencil computations,” in SC22: International Conference for High Performance Computing, Networking, Storage and Analysis, Dallas, TX, USA, November 13-18, 2022, F. Wolf, S. Shende, C. Culhane, S. R. Alam, and H. Jagode, Eds. IEEE, 2022, pp. 30:1–30:13. [Online]. Available: https://doi.org/10.1109/SC41404.2022.00035

    arXiv 2022

  4. [5]

    Breaking the molecular dynamics timescale barrier using a wafer-scale system,

    K. Santos, S. Moore, T. Oppelstrup, A. Sharifian, I. Sharapov, A. Thompson, D. Z. Kalchev, D. Perez, R. Schreiber, S. Pakin, E. A. Leon, J. H. Laros, M. James, and S. Rajamanickam, “Breaking the molecular dynamics timescale barrier using a wafer-scale system,” inSC24: International Conference for High Performance Computing, Networking, Storage and Analysi...

    arXiv 2024

  5. [6]

    Breaking the mold: overcoming the time constraints of molecular dynamics on general-purpose hardware,

    D. Perez, A. P. Thompson, S. G. Moore, T. Oppelstrup, I. Sharapov, K. Santos, A. Sharifian, D. Z. Kalchev, R. Schreiber, S. Pakin, E. A. Leon, J. H. L. III, M. James, and S. Rajamanickam, “Breaking the mold: overcoming the time constraints of molecular dynamics on general-purpose hardware,”CoRR, vol. abs/2411.10532, 2024. [Online]. Available: https://doi....

    arXiv doi:10.48550/arxiv.2411.10532 2024

  6. [7]

    Stateful dataflow multigraphs: A data-centric model for performance portability on heterogeneous architectures,

    T. Ben-Nun, J. de Fine Licht, A. N. Ziogas, T. Schneider, and T. Hoefler, “Stateful dataflow multigraphs: A data-centric model for performance portability on heterogeneous architectures,” inProceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis, 2019, pp. 1–14. [Online]. Available: https://doi.org/10.1...

    arXiv 2019

  7. [8]

    Fast stencil-code computation on a wafer-scale processor,

    K. Rocki, D. V . Essendelft, I. Sharapov, R. Schreiber, M. Morrison, V . Kibardin, A. Portnoy, J. F. Dietiker, M. Syamlal, and M. James, “Fast stencil-code computation on a wafer-scale processor,” in SC20: International Conference for High Performance Computing, Networking, Storage and Analysis, 2020, pp. 1–14. [Online]. Available: https://doi.org/10.1109...

    arXiv 2020

  8. [9]

    Scaling the “memory wall

    H. Ltaief, Y . Hong, L. Wilson, M. Jacquelin, M. Ravasi, and D. E. Keyes, “Scaling the “memory wall” for multi-dimensional seismic processing with algebraic compression on cerebras cs-2 systems,” in Proceedings of the International Conference for High Performance Computing, Networking, Storage and Analysis, 2023, pp. 1–12. [Online]. Available: https://doi...

    arXiv 2023

Show all 28 references
  1. [10]

    Near-optimal wafer-scale reduce,

    P. Luczynski, L. Gianinazzi, P. Iff, L. Wilson, D. De Sensi, and T. Hoefler, “Near-optimal wafer-scale reduce,” inProceedings of the 33rd International Symposium on High-Performance Parallel and Distributed Computing, 2024, pp. 334–347. [Online]. Available: https://doi.org/10....

    2024

  2. [11]

    The cerebras software development kit: A technical overview,

    J. Selig, “The cerebras software development kit: A technical overview,” Cerebras Systems, Inc., Tech. Rep., March 2023. [Online]. Available: https://f.hubspotusercontent30.net/hubfs/8968533/Cerebras SDK Technical Overview White Paper.pdf

    2023

  3. [12]

    A more practical PRAM model,

    P. B. Gibbons, “A more practical PRAM model,” inProceedings of the first annual ACM symposium on Parallel algorithms and architectures, 1989, pp. 158–168. [Online]. Available: https://doi.org/10.1145/72935.72953

    1989

  4. [13]

    BSP vs LogP,

    G. Bilardi, K. T. Herley, A. Pietracaprina, G. Pucci, and P. Spirakis, “BSP vs LogP,” inProceedings of the eighth annual ACM symposium on Parallel algorithms and architectures, 1996, pp. 25–32. [Online]. Available: https://doi.org/10.1145/237502.237504

    1996

  5. [14]

    The spatial computer: A model for energy-efficient parallel computation,

    L. Gianinazzi, T. Ben-Nun, S. Ashkboos, Y . Baumann, P. Luczynski, and T. Hoefler, “The spatial computer: A model for energy-efficient parallel computation,”CoRR, vol. abs/2205.04934, 2022. [Online]. Available: https://doi.org/10.48550/arXiv.2205.04934

    2022 doi arXiv

  6. [15]

    Hydrodynamics challenge problem,

    R. D. Hornung, J. A. Keasler, and M. B. Gokhale, “Hydrodynamics challenge problem,” 6 2011. [Online]. Available: https://doi.org/10.2172/1117905

    2011 doi

  7. [16]

    Exploring traditional and emerging parallel programming models using a proxy application,

    I. Karlin, A. Bhatele, J. Keasler, B. L. Chamberlain, J. D. Cohen, Z. DeVito, R. Haque, D. Laney, E. Luke, F. Wang, D. F. Richards, M. Schulz, and C. H. Still, “Exploring traditional and emerging parallel programming models using a proxy application,” in27th IEEE International...

    2013 doi

  8. [17]

    MLIR: Scaling compiler infrastructure for domain specific computation,

    C. Lattner, M. Amini, U. Bondhugula, A. Cohen, A. Davis, J. Pienaar, R. Riddle, T. Shpeisman, N. Vasilache, and O. Zinenko, “MLIR: Scaling compiler infrastructure for domain specific computation,” in2021 IEEE/ACM International Symposium on Code Generation and Optimization (CGO...

    2021

  9. [18]

    LLVM: a compilation framework for lifelong program analysis & transformation,

    C. Lattner and V . Adve, “LLVM: a compilation framework for lifelong program analysis & transformation,” inInternational Symposium on Code Generation and Optimization, 2004. CGO 2004., 2004, pp. 75–86. [Online]. Available: https://doi.org/10.1109/CGO.2004.1281665

    2004 arXiv

  10. [19]

    Python port of the livermore unstructured lagrangian explicit shock hydrodynamics (lulesh),

    L. L. N. Laboratory, “Python port of the livermore unstructured lagrangian explicit shock hydrodynamics (lulesh),” 2023. [Online]. Available: https://github.com/LLNL/pylulesh

    2023

  11. [20]

    A system level compiler for massively-parallel, spatial, dataflow architectures,

    D. Van Essendelft, P. Wingo, T. Jordan, R. Smith, and W. Saidi, “A system level compiler for massively-parallel, spatial, dataflow architectures,”arXiv preprint arXiv:2506.15875, 2025. [Online]. Available: https://doi.org/10.48550/arXiv.2506.15875

    2025 doi arXiv

  12. [21]

    Towards extremely fast context switching in a block-multithreaded processor,

    W. Gr ¨unewald and T. Ungerer, “Towards extremely fast context switching in a block-multithreaded processor,” in22rd EUROMICRO Conference ’96, Beyond 2000: Hardware and Software Design Strategies, September 2-5, 1996, Prague, Czech Republic. IEEE Computer Society, 1996, pp. 59...

  13. [22]

    The effect of context switches on cache performance,

    J. C. Mogul and A. Borg, “The effect of context switches on cache performance,” inASPLOS-IV Proceedings - Forth International Conference on Architectural Support for Programming Languages and Operating Systems, Santa Clara, California, USA, April 8-11, 1991, D. A. Patterson an...

    1991

  14. [23]

    W. D. Hillis,The connection machine. MIT press, 1985, ISBN: 9780262081573

    1985

  15. [24]

    Bader,Space-Filling Curves - An Introduction with Applications in Scientific Computing, ser

    M. Bader,Space-Filling Curves - An Introduction with Applications in Scientific Computing, ser. Texts in Computational Science and Engineering. Springer, 2013, vol. 9. [Online]. Available: https://doi.org/10.1007/978-3-642-31046-1

    2013 doi

  16. [25]

    Empirical analysis of space-filling curves for scientific computing applications,

    D. R. DeFord and A. Kalyanaraman, “Empirical analysis of space-filling curves for scientific computing applications,” in42nd International Conference on Parallel Processing, ICPP 2013, Lyon, France, October 1-4, 2013. IEEE Computer Society, 2013, pp. 170–179. [Online]. Availab...

    2013 doi

  17. [26]

    Parallel domain decomposition and load balancing using space-filling curves,

    S. Aluru and F. E. Sevilgen, “Parallel domain decomposition and load balancing using space-filling curves,” inProceedings of the Fourth International on High-Performance Computing, HiPC 1997, Bangalore, India, 18-21 December, 1997. IEEE Computer Society, 1997, pp. 230–

    1997

  18. [27]

    Claude Sonnet 4.6,

    Anthropic, “Claude Sonnet 4.6,” 2026

    2026

  19. [28]

    GPT-5.4,

    OpenAI, “GPT-5.4,” 2026

    2026

  20. [235]

    Available: https://doi.org/10.1109/HIPC.1997.634498

    [Online]. Available: https://doi.org/10.1109/HIPC.1997.634498

    1997

Pith tools

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