Pith. sign in

REVIEW 4 major objections 4 minor 93 references

Usability Evaluation of Cloud for HPC Applications

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

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

Pith's one-line read Cloud instances with OS-bypass or RDMA networks can run small- and medium-scale tightly coupled HPC jobs as well as on-premises clusters, a cross-cloud study of 11 applications argues.

desk verdict Broad, honest dataset on HPC in the cloud, but the AMG2023 topology inconsistency weakens the flagship Kubernetes-vs-VM comparison. read the letter →

arxiv 2506.02709 v2 pith:2IORH5YV submitted 2025-06-03 cs.DC cs.PF

Vanessa Sochat , Daniel Milroy , Abhik Sarkar , Aniruddha Marathe , Tapasya Patki This is my paper
classification cs.DCcs.PF
keywords HPCinthecloudKubernetesforRDMAnetworkingproxyapplicationsusabilityevaluationscalabilitybenchmarkscomputinghighperformance
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 reports a large cross-cloud experiment asking whether commercial cloud environments can reasonably host traditional high-performance computing workloads. The authors set up the same 11 HPC proxy applications and benchmarks on three major clouds, in both virtual-machine and Kubernetes form, and compared them with on-premises clusters at up to 256 nodes and 256 GPUs. Their central conclusion is that clouds with OS-bypass or RDMA-style networks can be well-suited to small- and medium-scale tightly coupled HPC jobs, in the range of tens to a few hundred CPU nodes. The paper also makes a methodological point: portability across ephemeral, changing environments should be treated as a dimension of performance, not a separate concern. A sympathetic reader would care because the result offers concrete guidance for scientific teams deciding whether cloud can absorb HPC work without a dedicated center.

What carries the argument

The load-bearing mechanism is the network fabric: OS-bypass and RDMA support that lets MPI traffic bypass the operating system and virtualization overhead that otherwise penalizes cloud HPC. The study's measurement instrument is a suite of 11 proxy applications and synthetic benchmarks, including AMG2023, Laghos, LAMMPS, Kripke, MiniFE, MT-GEMM, Mixbench, OSU benchmarks, Stream, and Quicksilver, run with identical containers across VM and Kubernetes environments. The same containers in both setups, with Flux-based orchestration on Kubernetes and Singularity on VMs, are what allow the paper to attribute performance differences to the environment rather than to application build.

What would settle it

Re-run the CPU suite with the same core count per node on every cloud and the on-premises cluster, using the same RDMA-class fabric, and check whether Laghos still fails to scale beyond 64 nodes while AMG2023 and LAMMPS remain competitive; if the Laghos gap disappears, the paper's blanket suitability claim overreaches, and if it persists, the claim is confirmed for all but the most tightly coupled applications.

Watch

Extended reading notes

Core claim

The paper's central claim is that the cloud is no longer categorically unsuitable for HPC: environments with OS-bypass or RDMA-based network fabrics can run small to medium HPC applications well, at scales of tens to a few hundred CPU nodes. It argues this on the basis of measured application figures of merit across VM and Kubernetes environments, using the same containers in both to isolate environment effects. The claim is qualified: applications that strong-scale, like LAMMPS, and weak-scale, like AMG2023, are the strongest cloud candidates, while the tightly coupled solver Laghos ran an order of magnitude slower on cloud and became infeasible beyond 64 nodes. The authors present the study as the first of its breadth and as a foundation for best practices rather than a definitive performance ranking.

Load-bearing premise

The comparisons depend on the assumption that the hardware and network configurations chosen across environments are similar enough that performance differences can be blamed on the cloud environment rather than on different processors, core counts, or fabrics.

Editorial extensions

If this is right

  • A scientific team without its own center can run tightly coupled MPI jobs at tens-to-a-few-hundred-node scale on cloud, provided it chooses RDMA or OS-bypass instance types and uses containers for portability.
  • Kubernetes becomes a credible execution layer for HPC, not just for cloud-native services, when the underlying network bypasses the kernel; the remaining performance delta with VMs is identified as a key open question.
  • Portability should be weighed as a first-class cost: time spent optimizing one platform may be better spent making the workload run reasonably well across several, because cloud environments change and vanish quickly.
  • Applications that weak-scale, such as AMG2023, can be economical on GPU cloud: despite more expensive instance types, shorter runtimes made the representative GPU runs cheaper than CPU runs in the reported cost table.
  • Older GPU generations such as the V100 remain a practical route to moderate-scale GPU capacity, with the caveat that software and driver support may be deprecated.

Reading between the lines

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

  • If the OS-bypass network is indeed the main equalizer, then the actionable generalization for teams is a network-first checklist: choose an RDMA-capable instance, verify placement, and only then compare performance; otherwise the ranking reflects fabric choice rather than cloud usability.
  • The reported hookup-time data suggest a testable rule for mixed on-premises and cloud operation: include measured hookup time in the cost model, since it can dominate short runs and varies by cloud and scale.
  • A natural follow-up experiment, already implied by the paper's future-work list, would repeat the suite on current-generation GPUs and on the newly released VM images; this would separate hardware-generation effects from environment usability effects.
  • The observation that instance types can hide different underlying hardware indicates a reproducibility risk: studies that report results by instance label may be conflating node-to-node hardware variation with environment differences.
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 / 4 minor

Summary. The paper presents a cross-platform usability and performance evaluation of 11 HPC proxy applications and benchmarks across three public clouds (AWS, Azure, Google Cloud), two on-premises clusters, VM and Kubernetes environments, and CPU and GPU configurations. It reports qualitative usability scores, scaling results for applications such as AMG2023, Laghos, LAMMPS, Kripke, MiniFE, MT-GEMM, Quicksilver, OSU benchmarks, and STREAM, together with cost data and suggested practices. The central claim, stated in Section 4.1, is that cloud environments with OS-bypass or RDMA-based networks can be well-suited to small-to-medium HPC applications at tens to a few hundred CPU nodes, with AMG2023 and LAMMPS given as examples. The paper also claims to be the first study of this breadth, covering more than 10 applications across multiple environments at over 100 nodes and 100 GPUs, with a substantial data release of 25,541 runs.

Significance. If the conclusions hold, this would be a valuable reference for HPC practitioners evaluating cloud adoption: the breadth of applications and environments, the reproducible artifact release (Zenodo DOI), the containerized application set, and the qualitative usability framework are genuine contributions. The paper also provides practical details, such as an Azure InfiniBand daemonset and VM images, that are likely to save other teams considerable effort. However, the quantitative comparative performance claims are weakened by several internal control issues: inconsistent AMG2023 process topologies between VM and Kubernetes, OSU point-to-point benchmarks run concurrently on the same nodes for EKS and AKS, and mixed Azure ECC states that are not controlled for. These issues directly affect the evidence cited for the central suitability claim, so the manuscript needs substantial revision before the comparative results can be accepted as reliable.

major comments (4)
  1. [§3.3 (AMG2023) and §4.1] In the AMG2023 size-64 GPU runs, VM environments used the process topology -P 4 4 4 while Kubernetes environments used -P 8 4 2, and the authors state that -P 8 4 2 gives about 10% higher FOM on GKE at size 64. Only the corrected GKE value is reported in Figure 2. Since AMG2023 is cited in Section 4.1 as evidence that cloud environments are well-suited and is the basis of the cost comparison in Table 4, the Kubernetes-versus-VM comparison for this application is confounded in favor of Kubernetes by roughly the reported 10%. Please rerun the affected VM size-64 runs with the same topology, report results for both topologies, or explicitly restrict the comparative claims to configurations with matched process topologies.
  2. [§3.3 (OSU Benchmarks)] The point-to-point latency and bandwidth tests for EKS and AKS were run simultaneously on the same nodes, which the authors state likely negatively impacted performance. This makes the EKS and AKS OSU results non-comparable with the other environments, and these data are used to support networking-related conclusions, such as identifying which fabrics provide the lowest latency and highest bandwidth. Please rerun the benchmarks in isolation, or remove the simultaneously-run EKS/AKS results from the comparative analysis and clearly state that those environments are not compared on point-to-point metrics.
  3. [§3.3 (Mixbench and ECC)] Azure GPU environments had a mixture of ECC settings, with ECC off for 12.5-25% of instances and on for 50-100%, while all other cloud GPU environments had ECC on. The paper notes that ECC can reduce performance by up to 15%, so any Azure GPU performance advantage in applications such as MiniFE, MT-GEMM, or the GPU OSU measurements could partly reflect ECC state rather than environmental quality. Report the ECC status for every Azure GPU run and either control for it statistically or explicitly exclude the affected comparisons from performance conclusions.
  4. [§2.2, §2.4, and §3.3] Cross-platform comparisons are made across nodes with substantially different resource counts and interconnects: Google CPU nodes have 56 cores versus 96 on AWS and Azure, the on-premises A cluster has 112 cores per node, and the on-premises B cluster uses POWER9 with a different fabric and only 4 GPUs per node versus 8 on cloud GPU nodes. The paper acknowledges these differences but still draws comparative conclusions, such as the claim that on-premises Laghos FOM is one order of magnitude larger than cloud. For strong-scaling runs, equal node counts do not imply equal per-core or per-GPU resources; please normalize by core or GPU count, or restrict comparative claims to configurations that are equivalent in resource count.
minor comments (4)
  1. [Abstract and §1] The abstract says the study covers 'six environments,' while Table 3 and Section 4 discuss 11 cloud environments plus two on-premises clusters; the environment count should be made consistent throughout.
  2. [Contributions and §4] The contributions list mentions '12 cloud environments' while the Discussion says '11 cloud environments'; the difference is explained by the missing AWS ParallelCluster GPU assessment, but this should be stated in the same place to avoid an apparent inconsistency.
  3. [§3.1] In the 'Accounts and Resources' paragraph, the sentence 'We ascribe a medium score to for acquiring GPUs on AWS' contains a typo ('to for') and should be corrected.
  4. [Table 4] The total costs in Table 4 are sums over iterations and cluster sizes, but the number of iterations and any excluded failed runs are not given; adding this information would make the cost totals reproducible from the stated methodology.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the study is an empirical benchmark measurement with external applications, and its conclusions do not reduce to fitted or self-cited inputs.

full rationale

The paper is an empirical cross-platform usability and performance study. Its central claims, such as the Section 4.1 statement that cloud environments with OS-bypass or RDMA-based networks can be well-suited to small and medium HPC apps, are supported by measured FOM values from external benchmark suites (CORAL-2, OSU, STREAM) and publicly maintained proxy applications (AMG2023, Laghos, LAMMPS, Kripke, MiniFE, MT-GEMM, Mixbench, Quicksilver). No equation in the paper is derived from the claim it supports, and no parameter is fitted to a subset of data and then reported as a prediction; the reported FOMs are directly computed from wall-clock times or benchmark outputs. Self-citations appear when describing the Flux Operator and Flux scheduler used to orchestrate Kubernetes experiments, as well as in references to the authors' prior converged-computing work, but these citations are tooling descriptions rather than load-bearing evidence for the measured performance results. The AMG2023 process-topology inconsistency (the use of -P 4 4 4 for VM environments versus -P 8 4 2 for Kubernetes environments, with the latter giving about 10% higher FOM at size 64 on GKE) is a genuine experimental confound that weakens one specific VM-versus-Kubernetes comparison, but it is not a circularity: the reported values are still external measurements, not outputs of a model defined by those measurements. Similarly, acknowledged hardware differences (56 cores per Google Cloud node versus 96 on AWS/Azure, different fabrics, and the older V100 GPU) affect comparability without making any claim definitionally equivalent to its input. Because the paper contains no derivation, fitting, or uniqueness argument imported from the authors' own prior results, there is no circularity to flag.

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

The paper is an empirical measurement study, so it introduces no fitted constants. Its load-bearing assumptions are the representativeness of the proxy applications, the comparability of heterogeneous hardware and network setups, and the consistency of subjective usability ratings.

free parameters (3)
  • AMG2023 problem size = 256x256x128
    Chosen by hand; weak scaling means per-rank size changes, and size was limited to fit 16GB V100 GPUs and integer indexing. Affects all AMG results.
  • AMG2023 process topology = -P 4 4 4 for VM, -P 8 4 2 for Kubernetes
    Different topologies used across environments; the GKE size-64 result uses -P 8 4 2, which the authors tested to give about 10% higher FOM than -P 4 4 4. This hand-chosen setting confounds the size-64 GPU comparison.
  • LAMMPS problem size = 64x32x32 (GPU), 64x64x32 (CPU)
    Chosen so the problem fits on the smallest GPU memory (Google V100 16GB and on-prem B), not derived from any benchmark rule.
assumptions (4)
  • domain assumption Proxy applications are representative of HPC workloads
    Section 2.8: applications chosen from CORAL-2 and common proxy apps; conclusions about HPC in general rest on this.
  • domain assumption On-premises clusters are a valid baseline
    Section 2.2 and Table 2: cluster A uses Intel/Omni-Path, cluster B uses IBM POWER9/InfiniBand, while clouds use AMD EPYC/x86 and various networks; relative comparisons assume architectural differences do not dominate.
  • domain assumption Subjective usability ratings are consistent
    Section 2.5: low/medium/high scores reflect the authors' 'subjective experience', yet are used as quantitative environment characteristics.
  • domain assumption Cloud environments are stable snapshots
    Section 2.1: 'the data collected is a snapshot of clouds' states with a shorter term of representation'; conclusions may not generalize over time.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Usability Evaluation of Cloud for HPC Applications." pith.science (2026). https://pith.science/paper/2IORH5YV

@misc{pith2026250602709,
  author       = {Pith},
  title        = {Pith review of: Usability Evaluation of Cloud for HPC Applications},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/2IORH5YV}},
  note         = {Machine review of arXiv:2506.02709}
}
read the original abstract

The rise of AI and the economic dominance of cloud computing have created a new nexus of innovation for high performance computing (HPC), which has a long history of driving scientific discovery. In addition to performance needs, scientific workflows increasingly demand capabilities of cloud environments: portability, reproducibility, dynamism, and automation. As converged cloud environments emerge, there is growing need to study their fit for HPC use cases. Here we present a cross-platform usability study that assesses 11 different HPC proxy applications and benchmarks across three clouds (Microsoft Azure, Amazon Web Services, and Google Cloud), six environments, and two compute configurations (CPU and GPU) against on-premises HPC clusters at a major center. We perform scaling tests of applications in all environments up to 28,672 CPUs and 256 GPUs. We present methodology and results to guide future study and provide a foundation to define best practices for running HPC workloads in cloud.

Figures

Figures reproduced from arXiv: 2506.02709 by the authors.

Figure 1
Figure 1. Kripke grind time – the amount of time to complete a unit of work for CPU environments. Lower values are better [PITH_FULL_IMAGE:figures/full_fig_p006_1.png] view at source ↗
Figure 2
Figure 2. AMG2023 Overall FOM for each of CPU and GPU. Higher values are better. Cloud environments excelled for GPU runs, while [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗
Figure 3
Figure 3. Laghos Major kernels total rate (megadofs [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: LAMMPS millions of atoms steps/second for each of CPU (problem size 64x64x32) and GPU (problem size 64x32x32). GPU runs were [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]
Figure 5
Figure 5. Figure 5: OSU Benchmark results for CPU cluster size 256 nodes for cloud and on-premises environments. Infiniband and on-premises low [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]
Figure 6
Figure 6. Figure 6: MiniFE (Mini Finite Element Conjugate Gradient) millions of floating-point operations per second. Higher values are better. [PITH_FULL_IMAGE:figures/full_fig_p008_6.png]
Figure 7
Figure 7. Figure 7: MT-GEMM Giga Floating-Point Operations (GFLops) per [PITH_FULL_IMAGE:figures/full_fig_p008_7.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

93 extracted references · 71 canonical work pages

  1. [1]

    Ahn, Ned Bass, Albert Chu, Jim Garlick, Mark Grondona, Stephen Herbein, Helgi I

    Dong H. Ahn, Ned Bass, Albert Chu, Jim Garlick, Mark Grondona, Stephen Herbein, Helgi I. Ingólfsson, Joseph Koning, Tapasya Patki, Thomas R.W. Scogland, Becky Springmeyer, and Michela Taufer. 2020. Flux: Overcoming scheduling challenges for exascale workflows. Future Generation Computer Systems 110 (2020), 202–213. https://doi.org/10.1016/j.future.2020.04.006

    doi:10.1016/j.future.2020.04.006 2020

  2. [2]

    Ahn, Jim Garlick, Mark Grondona, Don Lipari, Becky Springmeyer, and Martin Schulz

    Dong H. Ahn, Jim Garlick, Mark Grondona, Don Lipari, Becky Springmeyer, and Martin Schulz. 2014. Flux: A Next-Generation Resource Management Framework for Large HPC Centers. In2014 43rd International Conference on Parallel Processing Workshops. 9–17. https://doi.org/10.1109/ICPPW.2014.15

    doi:10.1109/icppw.2014.15 2014

  3. [3]

    Ahn, Xiaohua Zhang, Jeffrey Mast, Stephen Herbein, Francesco Di Natale, Dan Kirshner, Sam Ade Jacobs, Ian Karlin, Daniel J

    Dong H. Ahn, Xiaohua Zhang, Jeffrey Mast, Stephen Herbein, Francesco Di Natale, Dan Kirshner, Sam Ade Jacobs, Ian Karlin, Daniel J. Milroy, Bronis De Supin- ski, Brian Van Essen, Jonathan Allen, and Felice C. Lightstone. 2022. Scalable Composition and Analysis Techniques for Massive Scientific Workflows. In 2022 IEEE 18th International Conference on e-Sci...

    arXiv 2022

  4. [4]

    Amazon Web Services. 2022. The Elastic Fabric Adapter (EFA). https://docs.aws. amazon.com/AWSEC2/latest/UserGuide/efa.html Accessed: 2024-12-12

    2022

  5. [5]

    Amazon Web Services. 2022. webAWS Placement Groups. https://docs.aws. amazon.com/AWSEC2/latest/UserGuide/placement-groups.html

    2022

  6. [6]

    Amazon Web Services. 2023. Capacity Blocks for ML. https://docs.aws.amazon. com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html. Accessed: 2025-1-31

    2023

  7. [7]

    Anonymous. 2023. eksctl

    2023

  8. [8]

    Anonymous. 2024. Compatibility for HPC, a Story of Rainbows and Sched- ulers. https://hpckp.org/talks/compatibility-for-hpc-a-story-of-rainbows-and- schedulers/. Accessed: 2024-12-14

    2024

Show all 93 references
  1. [9]

    Anonymous. 2024. converged-computing/aks-infiniband-install: Example proto- type for installing Infiniband on an AKS cluster. https://github.com/converged- computing/aks-infiniband-install. Accessed: 2024-12-14

    2024

  2. [10]

    Anonymous. 2024. converged-computing/performance-study: Performance Study Release v0.0.1. https://doi.org/10.5281/zenodo.14396613

    2024 doi

  3. [11]

    Anonymous. 2024. eksctl bug: placement group for reservations

    2024

  4. [12]

    Anonymous. 2024. experiments/aws/parallel-cluster/cpu Configuration

    2024

  5. [13]

    Anonymous. 2024. supermarket-fish-problem: What architecture do you get for your cloud instance? It’s like white fish at the supermarket - maybe you don’t know

    2024

  6. [14]

    HPC Wiki Authors. 2024. Scaling. https://hpc-wiki.info/hpc/Scaling. Accessed: 2024-12-18

    2024

  7. [15]

    Oras Authors. 2024. ORAS: OCI Registry As Storage. https://oras.land/docs/ quickstart. Accessed: 2024-12-14

    2024

  8. [16]

    Microsoft Azure. 2024. Proximity placement groups. https://learn.microsoft.com/ en-us/azure/virtual-machines/co-location. Accessed: 2024-12-14

    2024

  9. [17]

    Angel M Beltre, Pankaj Saha, Madhusudhan Govindaraju, Andrew Younge, and Ryan E Grant. 2019. Enabling HPC Workloads on Cloud Infrastructure Using Kubernetes Container Orchestration Mechanisms. In 2019 IEEE/ACM Interna- tional Workshop on Containers and New Orchestration Paradi...

    2019

  10. [18]

    Moon, Xiaohua Zhang, Joseph R

    Harsh Bhatia, Francesco Di Natale, Joseph Y. Moon, Xiaohua Zhang, Joseph R. Chavez, Fikret Aydin, Chris Stanley, Tomas Oppelstrup, Chris Neale, Sara Kokkila Schumacher, Dong H. Ahn, Stephen Herbein, Timothy S. Carpenter, San- drasegaram Gnanakaran, Peer-Timo Bremer, James N. G...

    2021

  11. [19]

    Harsh Bhatia, Tapasya A Patki, Stephanie Brink, Loic E Pottier, Thomas M Stitt, Konstantinos Parasyris, Daniel J Milroy, Daniel E Laney, Robert C Blake, Jae- Seung Yeom, et al. 2023. Autonomous MultiScale Library. https://doi.org/10. 11578/dc.20230721.1

    2023

  12. [20]

    Mark S Birrittella, Mark Debbage, Ram Huggahalli, James Kunz, Tom Lovett, Todd Rimmer, Keith D Underwood, and Robert C Zak. 2016. Enabling scalable high-performance systems with the Intel Omni-Path architecture. IEEE Micro 36, 4 (2016), 38–47

    2016

  13. [21]

    François Broquedis, Jérôme Clet-Ortega, Stéphanie Moreaud, Nathalie Furmento, Brice Goglin, Guillaume Mercier, Samuel Thibault, and Raymond Namyst. 2010. hwloc: A generic framework for managing hardware affinities in HPC applica- tions. In 2010 18th Euromicro Conference on Par...

    2010

  14. [22]

    Maechling, Fabio Silva, Mei-Hui Su, Kevin R

    Scott Callaghan, Philip J. Maechling, Fabio Silva, Mei-Hui Su, Kevin R. Milner, Robert W. Graves, Kim B. Olsen, Yifeng Cui, Karan Vahi, Albert Kottke, Chris- tine A. Goulet, Ewa Deelman, Thomas H. Jordan, and Yehuda Ben-Zion. 2024. Using open-science workflow tools to produce ...

    2024

  15. [23]

    Y Chang, R Hood, Haoqiang Jin, S Heistand, Samson Cheung, M Djomehri, Gabriele Jost, and D Kokron. 2018. Evaluating the Suitability of Commercial Clouds for NASA’s High Performance Computing Applications: A Trade Study . Technical Report NAS-2018-01. NASA

    2018

  16. [24]

    Google Cloud. 2024. Define compact placement for GKE nodes. https://cloud. google.com/kubernetes-engine/docs/how-to/compact-placement. Accessed: 2024-12-14

    2024

  17. [25]

    Google Cloud. 2024. GoogleCloudPlatform/scientific-computing-examples: Open Source examples using Google Cloud to solve various Scientific and Techni- cal Computing problems. https://github.com/GoogleCloudPlatform/scientific- computing-examples. Accessed: 2024-12-12

    2024

  18. [26]

    Google Cloud. 2024. Network Service Tiers overview. https://cloud.google.com/ network-tiers/docs/overview. Accessed: 2024-12-12

    2024

  19. [27]

    Google Cloud. 2024. Operating system details: Rocky Linux for Google Cloud. https://cloud.google.com/compute/docs/images/os-details#rocky_linux. Ac- cessed: 2024-12-12

    2024

  20. [28]

    CNCF. [n. d.]. Kubernetes - DevStats. https://k8s.devstats.cncf.io/d/9/companies- table?orgId=1&var-period_name=Last%20century&var-metric=contributors. Ac- cessed: 2025-4-10

    2025

  21. [29]

    Susan Coghlan and Katherine Yelick. 2011. The Magellan Final Report on Cloud Computing. Technical Report. Lawrence Berkeley National Lab. (LBNL), Berkeley, CA (United States). https://doi.org/10.2172/1076794

    2011 doi

  22. [30]

    Knapp, Benjamin Stump, and Alexander J

    John Coleman, Kellis Kincaid, Gerald L. Knapp, Benjamin Stump, and Alexander J. Plotkowski. 2023. AdditiveFOAM: Release 1.0. https://doi.org/10.5281/zenodo. 8034098

    2023 doi

  23. [31]

    Andrew D Copeland, Nicholas B Chang, and Stephen Leung. 2009. GPU acceler- ated decoding of high performance error correcting codes. In Proc. 14th Annual Workshop on HPEC. 15–16

    2009

  24. [32]

    Ben Cumming. 2017. cuda-stream: cuda stream benchmark: based on work by Massimiliano Fatica@NVIDIA

    2017

  25. [33]

    Tamara Dancheva, Unai Alonso, and Michael Barton. 2023. Cloud benchmarking and performance analysis of an HPC application in Amazon EC2. Cluster Com- puting 27, 2 (June 2023), 2273–2290. https://doi.org/10.1007/s10586-023-04060-4

    2023 doi

  26. [34]

    Vikki Davies. 2021. The history of cloud computing. https://cybermagazine.com/ cloud-security/history-cloud-computing. Accessed: 2024-5-29

    2021

  27. [35]

    Carpenter, Chris Neale, Sara Kokkila-Schumacher, Tomas Oppelstrup, Liam Stanton, Xiaohua Zhang, Shiv Sundram, Thomas R

    Francesco Di Natale, Harsh Bhatia, Timothy S. Carpenter, Chris Neale, Sara Kokkila-Schumacher, Tomas Oppelstrup, Liam Stanton, Xiaohua Zhang, Shiv Sundram, Thomas R. W. Scogland, Gautham Dharuman, Michael P. Surh, Yue Yang, Claudia Misale, Lars Schneidenbach, Carlos Costa, Cha...

    2019

  28. [36]

    Veselin A Dobrev, Tzanio V Kolev, and Robert N Rieben. 2012. High-order curvilinear finite element methods for Lagrangian hydrodynamics. SIAM J. Sci. Comput. 34, 5 (Jan. 2012), B606–B641. 2025, Conference, Sochat et al

    2012

  29. [37]

    Elias. 2025. mixbench: A GPU benchmark tool for evaluating GPUs and CPUs on mixed operational intensity kernels (CUDA, OpenCL, HIP, SYCL, OpenMP). https://github.com/ekondis/mixbench

    2025

  30. [38]

    Erin Filliater. 2012. InfiniBand Technology and Usage Update. In Mellanox Tech- nologies, Storage Developer Conference (SDC), SNIA, Santa Clara, CA

    2012

  31. [39]

    Todd Gamblin, Matthew LeGendre, Michael R Collette, Gregory L Lee, Adam Moody, Bronis R De Supinski, and Scott Futral. 2015. The Spack package man- ager: bringing order to HPC software chaos. In Proceedings of the International Conference for High Performance Computing, Networ...

    2015

  32. [40]

    Gartner. 2024. Forecast: Public Cloud Services, Worldwide, 2022-2028, 2Q24 Update. https://www.gartner.com/en/documents/5541595. Accessed: 2025-4-12

    2024

  33. [41]

    Michael Gienger. 2015. High performance computing in the cloud: A survey on performance and usability. In Sustained Simulation Performance 2015 . Springer International Publishing, Cham, 29–40

    2015

  34. [42]

    Abhishek Gupta and Dejan Milojicic. 2011. Evaluation of HPC applications on cloud. In 2011 Sixth Open Cirrus Summit . IEEE

    2011

  35. [43]

    Jeff Hammond. 2017. STREAM: STREAM benchmark

    2017

  36. [44]

    Honeypot. 2022. Kubernetes: The Documentary [PART 1]

    2022

  37. [45]

    Islam, and Daniel J

    Md Rajib Hossen, Vanessa Sochat, Abhik Sarkar, Mohammad A. Islam, and Daniel J. Milroy. 2024. Enabling Workload-Driven Elasticity in MPI-based En- sembles. In 2024 IEEE International Conference on Cluster Computing (CLUSTER) . 250–262. https://doi.org/10.1109/CLUSTER59578.2024.00029

    2024

  38. [46]

    HPCWire. 2023. ACCESS Initiative Paves the Way for Equitable Access to HPC Resources for Smaller Research Teams. https://www.hpcwire.com/off-the- wire/access-initiative-paves-the-way-for-equitable-access-to-hpc-resources- for-smaller-research-teams/. Accessed: 2025-4-7

    2023

  39. [47]

    Guangchao Hu, Yang Zhang, and Wenbo Chen. 2019. Exploring the performance of singularity for high performance computing scenarios. In 2019 IEEE 21st Inter- national Conference on High Performance Computing and Communications; IEEE 17th International Conference on Smart City; I...

    2019

  40. [48]

    IBM. 2025. IBM Spectrum LSF Session Scheduler. https://www.ibm.com/docs/ en/spectrum-lsf/10.1.0?topic=lsf-session-scheduler. Accessed: 2025-2-06

    2025

  41. [49]

    Morris A Jette and Tim Wickberg. 2023. Architecture of the Slurm workload manager. InWorkshop on Job Scheduling Strategies for Parallel Processing. Springer, 3–23

    2023

  42. [50]

    ju-shim. 2024. Enable InfiniBand. https://learn.microsoft.com/en-us/azure/ virtual-machines/extensions/enable-infiniband. Accessed: 2024-12-14

    2024

  43. [51]

    ju-shim. 2024. Set up Message Passing Interface (MPI) for HPC - Azure Virtual Machines - Azure Virtual Machines. https://learn.microsoft.com/en-us/azure/ virtual-machines/setup-mpi. Accessed: 2024-12-14

    2024

  44. [52]

    Alexey Kopytov. 2004. Sysbench: a system performance benchmark. http://sysbench. sourceforge. net/ (2004)

    2004

  45. [53]

    Gregory M Kurtzer, Vanessa Sochat, and Michael W Bauer. 2017. Singularity: Sci- entific containers for mobility of compute. PLoS One 12, 5 (May 2017), e0177459

    2017

  46. [54]

    Lawrence Livermore National Laboratory. 2017. CORAL-2 Benchmarks. https: //asc.llnl.gov/coral-2-benchmarks. Accessed: 2025-4-8

    2017

  47. [55]

    Jack Lange, Thomas Papatheodore, Todd Thomas, Chad Effler, Aaron Haun, Carlos Cunningham, Kyle Fenske, Rafael Ferreira da Silva, Ketan Maheshwari, Junqi Yin, et al . 2023. Evaluating the Cloud for Capability Class Leadership Workloads. Technical Report. Oak Ridge National Labo...

    2023 doi

  48. [56]

    Lawrence Livermore National Laboratory. 2020. MiniFE Coral-2 Benchmark. https://asc.llnl.gov/sites/asc/files/2020-06/MiniFE_Summary_v2.0.pdf

    2020

  49. [57]

    Hyungro Lee, Matteo Turilli, Shantenu Jha, Debsindhu Bhowmik, Heng Ma, and Arvind Ramanathan. 2019. DeepDriveMD: Deep-Learning Driven Adaptive Molecular Simulations for Protein Folding . In 2019 IEEE/ACM Third Workshop on Deep Learning on Supercomputers (DLS) . IEEE Computer S...

    2019

  50. [58]

    Peini Liu and Jordi Guitart. 2022. Performance characterization of containeriza- tion for HPC workloads on InfiniBand clusters: an empirical study. Cluster Com- puting 25, 2 (01 Apr 2022), 847–868. https://doi.org/10.1007/s10586-021-03460-8

    2022 doi

  51. [59]

    Zhengchun Liu, Ryan Lewis, Rajkumar Kettimuthu, Kevin Harms, Philip Carns, Nageswara Rao, Ian Foster, and Michael E Papka. 2020. Characterization and identification of HPC applications at leadership computing facility. InProceedings of the 34th ACM International Conference on ...

    2020

  52. [60]

    Mark Lohmeyer and Laura Ionita. 2023. Introducing Dynamic Workload Sched- uler. https://cloud.google.com/blog/products/compute/introducing-dynamic- workload-scheduler. Accessed: 2025-2-6

    2023

  53. [61]

    AMG Maintainers. 2024. AMG2023: Algebraic multigrid solver. https://github. com/LLNL/AMG2023

    2024

  54. [62]

    AMG Maintainers. 2024. AMG2023: Algebraic multigrid solver issues. https: //github.com/LLNL/AMG2023/issues/13

    2024

  55. [63]

    Hypre Maintainers. 2024. hypre: Parallel solvers for sparse linear systems featur- ing multigrid methods

    2024

  56. [64]

    Kripke Maintainers. 2020. Kripke Coral 2 Benchmark. https://asc.llnl.gov/sites/ asc/files/2020-09/Kripke_Summary_v1.2.2-CORAL2_0.pdf

    2020

  57. [65]

    Laghos Maintainers. [n. d.]. High-order Lagrangian Hydrodynamics Miniappr. https://github.com/CEED/Laghos

  58. [66]

    Lammps Maintainers. 2020. LAMMPS ReaxFF Coral 2 Benchmark. https://asc. llnl.gov/sites/asc/files/2020-09/CORAL2_Benchmark_Summary_LAMMPS.pdf

    2020

  59. [67]

    Linux Maintainers. 2024. dmidecode(8): DMI table decoder - Linux man page. https://linux.die.net/man/8/dmidecode. Accessed: 2024-12-14

    2024

  60. [68]

    OCI Maintainers. 2024. OCI Compatibility Working Group

    2024

  61. [69]

    John D McCalpin. 1995. Stream benchmark.Link: www. cs. virginia. edu/stream/ref. html# what 22, 7 (1995)

    1995

  62. [70]

    Daniel J Milroy, Claudia Misale, Giorgis Georgakoudis, Tonia Elengikal, Abhik Sarkar, Maurizio Drocco, Tapasya Patki, Jae-Seung Yeom, Carlos Eduardo Arango Gutierrez, Dong H Ahn, and Yoonho Park. 2022. One Step Closer to Converged Computing: Achieving Scalability with Cloud-Na...

    2022

  63. [71]

    NERSC. [n. d.]. NERSC proxy suite. https://www.nersc.gov/research-and- development/nersc-proxy-suite/. Accessed: 2025-4-11

    2025

  64. [72]

    Marco A. S. Netto, Rodrigo N. Calheiros, Eduardo R. Rodrigues, Renato L. F. Cunha, and Rajkumar Buyya. 2018. HPC Cloud for Scientific and Business Applications: Taxonomy, Vision, and Research Challenges. ACM Comput. Surv. 51, 1, Article 8 (Jan. 2018), 29 pages. https://doi.org...

    2018 doi

  65. [73]

    NVIDIA. 2024. Unified Communication - X Framework Library. https: //docs.nvidia.com/networking/display/HPCXv215/Unified+Communication+- +X+Framework+Library. Accessed: 2024-12-14

    2024

  66. [74]

    A Paniraja Guptha. 2023. Enhancing OSU Micro-Benchmarks to be an All-In-One Solution for MPI Benchmarking. https://rave.ohiolink.edu/etdc/view?acc_num= osu1689877244466085. Accessed: 2024-5-30

    2023

  67. [75]

    Luc Peterson, Ben Bay, Joe Koning, Peter Robinson, Jessica Semler, Jeremy White, Rushil Anirudh, Kevin Athey, Peer-Timo Bremer, Francesco Di Natale, David Fox, Jim A

    J. Luc Peterson, Ben Bay, Joe Koning, Peter Robinson, Jessica Semler, Jeremy White, Rushil Anirudh, Kevin Athey, Peer-Timo Bremer, Francesco Di Natale, David Fox, Jim A. Gaffney, Sam A. Jacobs, Bhavya Kailkhura, Bogdan Kustowski, Steven Langer, Brian Spears, Jayaraman Thiagara...

    2022

  68. [76]

    PRACE. [n. d.]. PRACE hpc-kernels. https://repository.prace-ri.eu/git/CodeVault/ hpc-kernels/dense_linear_algebra/-/tree/master?ref_type=heads. Accessed: 2025-4-11

    2025

  69. [77]

    Daniel Reed, Dennis Gannon, and Jack Dongarra. 2022. Reinventing High Performance Computing: Challenges and Opportunities. arXiv (March 2022). arXiv:2203.02544 [cs.DC]

    2022 arXiv

  70. [78]

    Hyperion Research. 2025. Hyperion: HPC-AI Market Grew 23.5% in 2024, to Exceed $100B by 2028. https://insidehpc.com/2025/04/hyperion-hpc-ai-market- grew-23-5-in-2024-to-exceed-100b-by-2028/. Accessed: 2025-4-12

    2025

  71. [79]

    Richards, Ryan C

    David F. Richards, Ryan C. Bleile, Patrick S. Brantley, Shawn A. Dawson, Michael Scott McKinley, and Matthew J. O’Brien. 2017. Quicksilver: A Proxy App for the Monte Carlo Transport Code Mercury. In 2017 IEEE International Conference on Cluster Computing (CLUSTER) . 866–873. h...

    2017

  72. [80]

    Rynge, G

    M. Rynge, G. Juve, J. Kinney, J. Good, B. Berriman, A. Merrihew, and E. Deelman

  73. [81]

    SchedMD. 2024. Slurm Workload Manager - Slinky. https://slurm.schedmd.com/ slinky.html. Accessed: 2024-12-11

    2024

  74. [82]

    Amazon Web Services. 2024. Recent improvement to Open MPI AllReduce and the impact to application performance. https://aws.amazon.com/blogs/hpc/recent- improvement-to-open-mpi-allreduce-and-the-impact-to-application- performance/. Accessed: 2024-12-14

    2024

  75. [83]

    Gilad Shainer, Ali Ayoub, Pak Lui, Tong Liu, Michael Kagan, Christian R Trott, Greg Scantlen, and Paul S Crozier. 2011. The development of Mellanox/NVIDIA GPUDirect over InfiniBand—a new model for GPU to GPU communications. Computer Science-Research and Development 26 (2011), 267–273

    2011

  76. [84]

    Pavel Shamis, Manjunath Gorentla Venkata, M Graham Lopez, Matthew B Baker, Oscar Hernandez, Yossi Itigin, Mike Dubman, Gilad Shainer, Richard L Graham, Liran Liss, Yiftah Shahar, Sreeram Potluri, Davide Rossetti, Donald Becker, Dun- can Poole, Christopher Lamb, Sameer Kumar, C...

    2015

  77. [85]

    Nayanah Siva. 2008. 1000 genomes project. Nature Biotechnology 26, 3 (March 2008), 256–257. https://github.com/pegasus-isi/1000genome-workflow Pub- lisher: Nature Publishing Group. Usability Evaluation of Cloud for HPC Applications 2025, Conference,

    2008

  78. [86]

    Vanessa Sochat, Aldo Culquicondor, Antonio Ojea, and Daniel Milroy. 2024. The Flux Operator. F1000Res. 13, 203 (March 2024), 203

    2024

  79. [87]

    Vanessa Sochat, David Fox, and Daniel Milroy. 2024. HPC Alongside User-space Kubernetes. arXiv:2406.06995 [cs.DC] https://arxiv.org/abs/2406.06995

    2024 arXiv

  80. [88]

    Vanessa Sochat, Christian Kniep, and Eduardo Arango. 2024. HPC Containers Community Survey 2024. https://doi.org/10.5281/zenodo.11206333

    2024 doi

  81. [89]

    Bollig, and William Magro

    Vanessa Sochat, Daniel Milroy, Claudia Misale, Jakob Luettgau, Evan F. Bollig, and William Magro. 2024. Converged Computing: A Best of Both Worlds of High-Performance Computing and Cloud . Computing in Science & Engineering 26, 03 (July 2024), 4–7. https://doi.org/10.1109/MCSE...

    2024

  82. [90]

    PBS Works. 2025. OpenPBS. https://www.openpbs.org/. Accessed: 2025-2-06

    2025

  83. [91]

    Andy B Yoo, Morris A Jette, and Mark Grondona. 2003. Slurm: Simple linux utility for resource management. In Workshop on job scheduling strategies for parallel processing. Springer, 44–60

    2003

  84. [92]

    Younge, Kevin Pedretti, Ryan E

    Andrew J. Younge, Kevin Pedretti, Ryan E. Grant, and Ron Brightwell. 2017. A Tale of Two Systems: Using Containers to Deploy HPC Applications on Super- computers and Clouds . In2017 IEEE International Conference on Cloud Computing Technology and Science (CloudCom). IEEE Comput...

    2017 doi

  85. [2014]

    Astrophysics Data System 485 (May 2014), 211

    Producing an Infrared Multiwavelength Galactic Plane Atlas Using Mon- tage, Pegasus, and Amazon Web Services. Astrophysics Data System 485 (May 2014), 211. https://ui.adsabs.harvard.edu/abs/2014ASPC..485..211R Conference Name: Astronomical Data Analysis Software and Systems XX...

    2014

Pith tools

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