# Task-Based HPC in the Cloud: Price-Performance Analysis of N-Body Simulations with StarPU

Nicolas Vanz, Vanderlei Munhoz, Márcio Castro, Laércio Lima Pilla, Olivier Aumage

► To cite this version:

Nicolas Vanz, Vanderlei Munhoz, Márcio Castro, Laércio Lima Pilla, Olivier Aumage. Task-Based HPC in the Cloud: Price-Performance Analysis of N-Body Simulations with StarPU. IC2E 2025 - 13th IEEE International Conference on Cloud Engineering, Sep 2025, Rennes, France. hal-05235814

HAL Id: hal-05235814

https://inria.hal.science/hal-05235814v1

Submitted on 2 Sep 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
Task-Based HPC in the Cloud: Price-Performance
Analysis of N-Body Simulations with StarPU

Nicolas Vanz¹, Vanderlei Munhoz¹,², Márcio Castro¹, Laércio Lima Pilla², Olivier Aumage²

¹Federal University of Santa Catarina (UFSC), Florianópolis, Brazil
{nicolas.vanz, marcio.castro}@ufsc.br

²University of Bordeaux, CNRS, Bordeaux INP, Inria, LaBRI, Talence, France
{vanderlei.munhoz-pereira-filho, laercio.pilla, olivier.aumage}@inria.fr

*Abstract*—Public cloud environments present significant challenges for traditional High Performance Computing (HPC) applications due to infrastructure limitations that differ substantially from dedicated HPC systems. Unlike traditional HPC clusters optimized for tightly coupled parallel workloads, cloud platforms were designed primarily for web services and data processing applications. Key obstacles include high-latency networks, hardware virtualization overhead, and limited availability of specialized accelerators, all of which can severely impact the performance of compute-intensive applications such as physics simulations. This study investigates the feasibility of running HPC workloads on public cloud infrastructure using standard and cost-effective instance configurations rather than expensive specialized “HPC” offerings. We deploy heterogeneous clusters on Amazon Web Services using the HPC@Cloud Toolkit, incorporating various instance types, including GPU-accelerated nodes with different computational capabilities. Our evaluation focuses on N-body simulations implemented using a task-based parallel programming model, leveraging the StarPU runtime system to dynamically schedule computational tasks across various processing units. Our experimental results demonstrate three key findings: (1) smaller GPU-equipped instances (g6.2xlarge) achieve performance comparable to larger instances while costing approximately one-sixth the price, challenging conventional scaling assumptions for cloud-based HPC; (2) strategic GPU utilization yields up to 8.2× performance improvements over CPU-only configurations while reducing total execution costs by 24.4×; and (3) while task-based programming models effectively address network limitations through dynamic scheduling, complex tree-based algorithms like TBFMM face significant optimization challenges in cloud environments due to load balancing issues and expensive parameter tuning requirements. These findings provide practical guidance for researchers and practitioners seeking cost-effective cloud HPC deployments, demonstrating that commodity cloud infrastructures can be viable for regular computational workloads but require careful algorithmic-resource matching for optimal efficiency.

*Index Terms*—Cloud Computing, HPC, MPI, StarPU, Task Scheduling

# I. INTRODUCTION

The cloud computing paradigm provides major benefits to its users, such as on-demand access to the latest technologies, resource elasticity, and the pay-as-you-go pricing scheme. Despite these benefits, this type of infrastructure still has several limitations when faced with High-Performance Computing (HPC) requirements [1], [2].

Historically, the cloud has evolved to become a massive shared environment built on top of commodity hardware, opti-

mized to run web services and to guarantee extreme uptime requirements for businesses [3]. Meanwhile, the requirements for scientific computing have developed differently from business ones. In a scientific computing context, it is common to work with large datasets that exceed the memory capacity of a single machine, requiring data partitioning across multiple compute nodes. The distributed nature of this approach introduces a hefty communication overhead due to internode data transfers and synchronization. This overhead can significantly degrade performance, especially in cloud environments, where network latency and bandwidth limitations are more pronounced due to the use of virtualization and the shared nature of public cloud resources. There is a broad consensus that network speed remains a major bottleneck to the viability of HPC in the cloud [1], [2], [4]. To address these challenges, applications must be designed strategically to minimize inter-node communication. This includes not only algorithmic considerations, but also the selection of appropriate programming models, execution frameworks, and scheduling policies that can dynamically optimize task placement and data movement.

At the same time, with the slowing pace of improvements in single-processor performance, the trend in HPC points towards heterogeneous computing to maximize efficiency. In particular, the use of hardware accelerators, especially GPUs, has grown rapidly in recent years. Today, GPUs power the majority of the world's top supercomputing clusters, offering substantial performance gains for parallel workloads [5]. Previous research examining the viability of public cloud resources for tightly coupled or non-trivial parallel HPC applications has largely neglected the potential of accelerated instances [6], [7]. These omissions represent a significant gap in understanding how modern cloud infrastructures can effectively support demanding scientific computing workloads.

Task-based parallelism presents a compelling model for heterogeneous architectures because it abstracts the computation into discrete tasks, augmented with explicit constraints such as data dependencies for more recent models [8]–[10] that enable their dynamic parallel scheduling across diverse processing units. Unlike traditional models that rely heavily on static workload distribution, task-based systems enable fine-grained control over resource utilization, allowing schedulers to assign tasks to the most suitable compute units based on real-time availability and performance characteristics. This
dynamic scheduling flexibility should be particularly advanta-
geous in cloud environments, where hardware heterogeneity
is common, and resource contention can vary over time.
Moreover, task-based parallelism inherently reduces idle time
and improves load balancing [11], mitigating the performance
penalties introduced by slower interconnects or non-uniform
hardware configurations. Additionally, data dependency in-
formation that distinguishes read-only from read-write data
accesses allows runtime systems to automatically manage
data replication and consistency. This capability enables the
elimination of redundant data transfers through intelligent
caching mechanisms.

Our research investigates the practical feasibility of running
traditional task-based HPC applications on standard public
cloud resources rather than premium-priced HPC offerings.
Although cloud platforms often market high-powered in-
stances for HPC workloads, these resources are often pro-
hibitively expensive, subject to limited availability, or locked
behind long-term contracts. Furthermore, in the case of Ama-
zon Web Services (AWS), severe quotas are imposed on new
users that can prevent access even to small GPU-enabled
instances, contradicting the on-demand resource availability
promised by the NIST definition of Cloud Computing [12].
Given these constraints, we conducted small-scale experiments
designed to evaluate optimization principles that could be
generalized to larger deployments.

We evaluated two N-body simulation approaches across
various AWS configurations: a brute-force method<fnref n="1" /> and a more
sophisticated Fast Multipole Method (FMM) using a rotational
kernel<fnref n="2" />. Both applications implement task-based parallelism
through the StarPU framework, which is able to dynamically
schedule computational tasks across heterogeneous computing
resources, including CPUs and GPUs. For cloud infrastructure
management, we have deployed the HPC@Cloud Toolkit
to rapidly provision and test different AWS configurations.
Our analysis examines both computational performance and
associated costs, enabling us to provide actionable recom-
mendations to organizations seeking cost-effective cloud-based
HPC solutions.

In summary, we highlight the following key insights and
contributions:

1) We demonstrate that smaller GPU-equipped instances of the g6.2xlarge type in AWS deliver comparable performance to their larger counterparts at approximately one-sixth the cost, challenging conventional scaling assumptions for cloud-based HPC.

2) We show how task-based programming models can significantly mitigate network limitations in the cloud through dynamic scheduling, strategic task placement, and reduced data movement.

3) We provide evidence-based recommendations for re-source selection and workload distribution to maximize

performance-to-cost ratios when executing HPC applica-
tions in public cloud environments.

This paper is organized as follows. Section II provides background information on the N-Body Problem and some of the software used in our study. Section III presents related work. Section IV details the two N-Body solvers considered in our study. Section V gives an overview of the public cloud infrastructure used in our experiments. Section VI presents the experimental results and analysis. Finally, Section VII provides concluding remarks and future work directions.

II. BACKGROUND

This section provides essential background on the key tech-
nologies and methodologies underlying our study. We begin
with an overview of N-body simulations and their computa-
tional challenges, followed by an introduction to the TBFMM
library, which implements an efficient alternative to brute-force
approaches. We then examine the StarPU runtime system,
which enables dynamic task scheduling across heterogeneous
computing resources. Finally, we describe the HPC@Cloud
toolkit, which facilitates rapid deployment and management
of HPC workloads in cloud environments.

A. The N-Body Problem

The N-Body Problem is a widely studied problem in com-
putational physics and astrophysics, which models the motion
of a system of particles under mutual interactions, typically
governed by Newtonian gravity or electrostatic forces [13]. Its
challenge lies in the fact that each particle exerts a force on
every other particle, resulting in a computational complexity
that scales quadratically with the number of bodies involved.
As such, even systems of modest size can require an immense
number of calculations, particularly when high-precision or
long-term simulations are needed. This makes the N-Body
Problem an ideal benchmark for evaluating the performance
and scalability of HPC platforms.

Traditionally, the N-Body problem is solved using direct
methods, which explicitly compute all pairwise interactions, or
approximate methods, such as the Barnes-Hut algorithm [14]
or the Fast Multipole Method (FMM) [15], which reduce
computational complexity by grouping distant particles and
approximating their influence. These algorithms are often
parallelized using MPI or hybrid MPI and OpenMP models
to distribute the workload across multiple compute nodes.
In more modern implementations, GPU acceleration is also
used to take advantage of the high-throughput capabilities of
these devices to handle a large number of concurrent interac-
tions [16]. The inherently parallel nature of force calculations
makes the N-body problem particularly well suited for task-
based programming models, where each force computation or
particle update can be treated as an independent task that may
be scheduled dynamically across available resources.

B. TBFMM

TBFMM [17] is a C++ library that implements the Fast
Multipole Method (FMM), a hierarchical algorithm used

<footnote n="1">¹https://github.com/nicolasvanz/N-Body-Problem-StarPU-OpenMP</footnote>

<footnote n="2">²https://gitlab.inria.fr/bramas/tbfmm</footnote>
to accelerate the computation of long-range interactions in systems governed by pairwise kernels. While the N-Body Problem is a classical application, TBFMM supports a wide range of kernel-based problems across fields such as fluid dynamics and electrodynamics. TBFMM works by partitioning space into a tree structure and approximating distant interactions through multipole expansions, reducing computational complexity from $O(n^2)$ to approximately $O(n)$. TBFMM is designed for high scalability and integrates well with task-based parallel runtimes, such as StarPU, making it well suited for execution on heterogeneous computing environments.

### C. StarPU

StarPU [8] is a runtime system that enables task-based parallelism in heterogeneous architectures by abstracting low-level hardware details and efficiently managing resource scheduling. It allows computations to be expressed as a graph of tasks with explicit data dependencies, which StarPU dynamically schedules across available processing units such as CPUs and GPUs. This approach helps maximize resource utilization while minimizing idle time and unnecessary data movement. StarPU is particularly effective for applications with irregular workloads.

StarPU offers several task scheduling policies that optimize the distribution of workloads on heterogeneous computing resources. The default scheduler, Locality Work Stealing (LWS) [8], attempts to schedule a task on a worker that released its last dependency. It also enables workers to correct load imbalance by stealing work from neighbors in a locality-aware manner, while other scheduling policies factor in task completion time predictions on possibly heterogeneous units when making assignments. Particularly notable is the Deque Model Data-Aware (DMDA) scheduler [8], which makes scheduling decisions based on both estimated task execution times and data transfer costs. DMDA maintains performance models for each computational kernel on different processing units and uses these models to predict execution times, automatically updating its estimates as tasks complete. By considering both computation time and data movement costs, DMDA is able to minimize overall execution time, making it especially valuable in public cloud environments, where data transfers can be one of the most significant bottlenecks.

### D. HPC@Cloud Toolkit

The HPC@Cloud Toolkit [18] is an open-source framework designed to simplify the deployment and management of HPC workloads in cloud environments<fnref n="3" />. It provides a set of tools and scripts that automate the provisioning of cloud resources, enabling users to quickly configure and manage complex HPC clusters on public cloud platforms such as Amazon Web Services (AWS). The toolkit supports a wide range of HPC configurations, allowing users to specify different instance types, networking configurations, and storage options to match the needs of their particular workload. By abstracting

much of the complexity involved in resource orchestration, HPC@Cloud accelerates the process of establishing and scaling HPC applications in the cloud.

While there are alternatives such as AWS ParallelCluster, which offers a native AWS solution with deep integration into AWS services and comprehensive job scheduler support, the HPC@Cloud Toolkit provides a more flexible, cloud-agnostic approach that emphasizes simplicity and rapid prototyping. Unlike ParallelCluster's focus on production-grade clusters with extensive configuration options, HPC@Cloud prioritizes ease of use and quick deployment for research and development scenarios, abstracting away much more from the end-user. Notably, HPC@Cloud spawns extremely lightweight clusters with minimal system dependencies, reducing both setup time and computational overhead compared to ParallelCluster's more feature-rich but resource-intensive deployments. This makes HPC@Cloud particularly suitable for academic environments and experimental workloads where rapid iteration and testing across different configurations is essential.

## III. RELATED WORK

Researchers widely agree that network performance represents the primary bottleneck that limits cloud-based HPC applications today [1], [2], [4]. However, this conventional wisdom has been challenged by recent findings. De Sensi et al. [19] conducted a comprehensive study demonstrating that AWS HPC instances with at least 100 Gbps network bandwidth exhibit performance noise characteristics comparable to traditional on-premise HPC hardware. These results indicate that properly configured cloud resources can effectively support demanding HPC workloads from a performance perspective.

Despite this demonstrated potential, a significant research gap remains. Few studies have systematically evaluated and documented the real-world performance of HPC applications deployed on public cloud platforms [4]. This lack of comprehensive evaluation leaves our understanding of cloud HPC performance incomplete, particularly regarding how diverse scientific applications behave across different cloud configurations and workload scenarios.

Zhuang et al. [20] demonstrated the successful use of AWS resources to execute simulations of Earth sciences models. More specifically, they worked with the global 3-D chemical transport model GEOS-Chem, leveraging c5n.18xlarge instances with Elastic Fabric Adapter (EFA) technology. In this setup, they were able to achieve performance and costs similar to those of the NASA Pleiades supercomputer.

Fernandez [6] conducted an in-depth study on MPI-based tightly coupled parallel solvers on public cloud infrastructure. The study tested the High Performance Conjugate Gradient (HPCG) benchmark [21] in clusters with up to 4500 cores across five providers. The results for some configurations were promising, particularly for clusters comprised of c5n.18xlarge instances, the same one used by Zhuang et al., which would place them in the 64th

<footnote n="3">³HPC@Cloud Toolkit's repository: https://github.com/lapesd/hpcac-toolkit</footnote>
percentile of the HPCG list [22]. Although small clusters with z1d.12xlarge instances demonstrated performance comparable to high-end Intel-powered supercomputers, larger clusters (exceeding 100 cores) exhibited severe scalability limitations. These findings address one of the fundamental concerns regarding cloud computing for HPC applications: the ability to efficiently scale to thousands of cores. Although the benchmarks presented represent the lower end of this threshold, they demonstrate that public cloud infrastructure can potentially support such workloads, despite remaining challenges in achieving linear scaling for larger deployments.

Munhoz, Castro, and Rego [23] conducted a comprehensive evaluation of DynEMol [24], an application to simulate electron dynamics in molecular systems. Their study focused on deploying DynEMol on AWS using cost-efficient ephemeral resources, specifically spot instances, to assess performance and economic feasibility. Their investigation also included an evaluation of c5n class instances, although employing configurations smaller than those used in the studies by Fernandez [6] and Zhuang et al. [20]. Their findings conclusively advocated for vertical scaling strategies when deploying HPC applications in cloud environments, primarily to avoid the performance degradation associated with limited network bandwidth between nodes. Our research corroborates and extends these conclusions by demonstrating the critical importance of infrastructure selection when executing performance-sensitive applications, highlighting how thoughtful architectural choices can significantly mitigate performance challenges in cloud-based HPC deployments.

Teylo et al. [25] assessed the use of ephemeral public cloud infrastructures to execute bag-of-tasks applications. We consider their research complementary to ours, as it offers valuable insights into employing cost-effective resources for HPC workloads. However, while their work focuses on embarrassingly parallel applications, we extend this approach to other types of workloads, such as TBFMM rotational kernels, which present different computational and communication characteristics.

Other works, such as Cardoso et al. [26], demonstrated significant performance gains by leveraging Google Cloud Platform's TPU-accelerated instances for Generative Adversarial Network (GAN) training workloads. Their implementation achieved an almost linear scaling, reducing the training time from one week to approximately one hour, while maintaining accurate results. However, Google TPUs are expensive, a kind of specialized hardware that is not available in other providers, have limited availability, and often require reserved quota allocations. In contrast, our study focuses on more readily available infrastructures and generalist processing units, which are offered by all major cloud providers at various price points.

Unfortunately, truly HPC-oriented technologies are often locked behind expensive contracts with cloud providers, creating substantial cost barriers [1], [27]. This is true not only for faster networks, but also for accelerated computing resources. In our experience with AWS, we encountered significant allocation restrictions for GPU-powered instances, with our

account initially having zero available capacity for this type of infrastructure. This limitation required explicit quota increase requests before we could proceed with our GPU-accelerated experiments. Users must submit manual requests and engage directly with support to gain access to these resources. This contradicts the fundamental concept of cloud computing as a public utility, as defined by the National Institute of Standards and Technology (NIST) [12], which emphasizes on-demand self-service without requiring human interaction with service providers. Furthermore, migrating existing HPC applications to cloud environments typically involves considerable development overhead, further increasing the total cost of cloud adoption [1], [18].

Our study diverges from previous research by focusing on the economic viability of running HPC workloads on readily available commodity cloud resources rather than specialized hardware. By evaluating performance in standard AWS instances, we provide insights relevant to organizations with budget constraints that cannot afford premium HPC-specific offerings. This approach acknowledges the practical reality that while dedicated HPC resources in the cloud offer superior performance, the cost-benefit ratio may favor standard instances for many scientific computing workloads.

Regarding migration feasibility, applications already using task-based frameworks like StarPU can be adapted to cloud environments with minimal code modifications. However, applications built on traditional MPI-only models require a more substantial refactoring to effectively utilize heterogeneous resources. While this transition demands initial investment, our findings demonstrate that the resulting flexibility in resource selection and potential cost savings justify this effort, especially for organizations seeking to leverage the cloud's elasticity without committing to expensive specialized instances.

# IV. N-BODY SOLVERS

## A. A Naïve Implementation of an N-Body Simulation

Our first solver implements a direct brute-force approach to the N-body problem by systematically calculating gravitational forces on each particle through the evaluation of all pairwise interactions. This computationally intensive method exhibits quadratic complexity $O(n^2)$, making it an ideal benchmark for evaluating cloud infrastructure performance under heavy computational loads.

Although this direct approach produces high-precision results, our primary objective is to use this algorithmically demanding workload as a stress test for comparing various cloud computing configurations, rather than exploiting its accuracy for scientific applications. The naïve algorithm applies Equation 1 to compute the forces between the pair of particles during each simulation time step [28], [29]. This equation represents a simplified form of Newton's law of universal gravitation, assuming that all bodies have identical masses.

$$ \vec{F}_{ij} = \frac{\vec{r}_j - \vec{r}_i}{(|\vec{r}_j - \vec{r}_i|^2 + \epsilon^2)} \quad (1) $$
Thus, the overall force acting on a particle i is determined by summing the forces applied by all remaining particles as stated in Equation 2:

$$ \vec{F}_i = \sum_{\substack{j=1 \\ j \neq i}}^{N} \vec{F}_{ij} \qquad (2) $$

In doing so, we derive the acceleration for each particle, which correlates with the total force. Subsequently, we update their velocity (Equation 3) and position (Equation 4).

$$ \vec{v}_i(t + \Delta t) = \vec{v}_i(t) + \vec{a}_i(t) \cdot \Delta t \qquad (3) $$

$$ \vec{r}_i(t + \Delta t) = \vec{r}_i(t) + \vec{v}_i(t) \cdot \Delta t \qquad (4) $$

From a computational perspective, our system uses two data arrays: position vectors and velocity vectors. We defined two StarPU tasks: `bodyForce` to compute the total force on each particle, and `integratePositions` to update particle positions. Both tasks provide CPU and CUDA implementations, enabling execution on either CPUs or GPUs based on available resources.

To enable parallel execution, we asynchronously partition the data arrays according to the specific indices each task accesses, then assign these partitions to individual tasks. The degree of parallelism scales directly with the number of partitions created. Within each task, we achieve additional parallelization through OpenMP for CPU execution and CUDA for GPU execution.

These tasks exhibit different data access patterns: computing the total force requires access to the entire position array, whereas updating positions operates only on segmented data. StarPU handles this data management implicitly, minimizing unnecessary data transfers and reducing communication overhead, particularly beneficial in multi-node configurations.

## B. TBFMM's Rotational Kernel

The rotational kernel in TBFMM [17] implements a fast multipole method that accelerates N-body simulations using an elegant mathematical approach. This kernel represents long-range interactions using spherical harmonic expansions and applies a rotation-based algorithm to optimize performance. The core innovation lies in decomposing complex multipole translations into three more efficient steps: first rotating the coordinate system to align with the translation axis, then performing a simpler translation along this axis, and finally rotating back to the original orientation. The kernel extensively precomputes rotation matrices (Wigner D-matrices) and translation coefficients to further accelerate operations, making it particularly effective for large-scale simulations with millions of particles.

TFBMM provides a StarPU integration framework that supports GPU acceleration through specialized callback functions for data transfers and execution management. However, the current TBFMM implementation remains primarily CPU-centric. The core FMM operations that define the

algorithm's computational complexity, including particle-to-multipole (P2M), multipole-to-multipole (M2M), multipole-to-local (M2L), local-to-local (L2L), and local-to-particle (L2P) transformations, are implemented exclusively for CPU execution. Only particle-to-particle (P2P) direct interaction computations have been ported to CUDA, representing a limited subset of the overall algorithmic workload. This design reflects the inherent challenges in efficiently parallelizing the hierarchical tree operations and complex spherical harmonic rotations on GPU architectures, where the irregular memory access patterns and dependency structures of tree-based algorithms can diminish the performance benefits of massively parallel execution.

A critical parameter in TBFMM's performance is the tree height, which determines the depth of the hierarchical octree structure used to organize particles spatially. This parameter directly controls the trade-off between tree-based operations and direct particle-particle interactions: shallow trees result in fewer hierarchical levels but more particles per leaf node, leading to computationally expensive direct interactions, while deeper trees create more hierarchical levels with fewer particles per leaf, shifting the computational burden toward tree traversal and multipole operations. Optimal tree height selection depends on the particle distribution and system size, as inappropriate depths can lead to either excessive P2P computations or unnecessary tree overhead, significantly impacting scalability and memory bandwidth utilization.

Originally designed for single-node execution, TBFMM lacks native MPI support, limiting its viability for large-scale simulations. However, TBFMM could theoretically be distributed across multiple nodes using StarPU's Server-Client extension in conjunction with its rotational kernel. In this approach, a server node manages task scheduling and data movement, while client nodes execute computations. The server maintains the global task dependency graph and handles the necessary data transfers between nodes. Although this solution introduces some communication overhead compared to a dedicated MPI implementation, it would enable TBFMM to scale across multiple cloud instances with some code modifications. However, a significant limitation is that StarPU's Server-Client extension does not support GPU multi-node acceleration currently, restricting distributed experiments to CPU-only configurations. Given that our single-node results demonstrate TBFMM's heavy reliance on GPU acceleration for the computationally expensive P2P operations, the absence of CUDA support in the distributed configuration would severely undermine performance benefits. This fundamental constraint, combined with the added complexity of Server-Client implementation, would make this distributed approach impractical for achieving meaningful performance improvements in multi-node TBFMM deployments.

## V. PUBLIC CLOUD INFRASTRUCTURE

With the HPC@Cloud Toolkit, we can define the desired infrastructure for each experiment using markup language. A command-line interface allows users to orchestrate the entire
life-cycle of cloud resources by abstracting the dozens of network, compute, and storage resources that would otherwise need to be manually requested individually.

Unlike generalist Infrastructure as Code (IaC) tools such as Terraform, HPC@Cloud is specifically designed for academic research and typical HPC and MPI usage patterns. The toolkit automatically configures all necessary components, providing users with a cluster ready to execute their workloads immediately. Additionally, the toolkit can run predefined scripts for experiment initialization and ensure thorough decommisioning upon completion, preventing orphaned resources and unnecessary costs.

Resource utilization tracking is implemented through automated tagging, where the toolkit assigns identifiers to every provisioned component using the provider tagging mechanism. Cost analysis is particularly streamlined on AWS, which offers robust tag-based filtering capabilities in its billing and cost management console.

Table I presents the AWS instance types used to evaluate the naïve N-body simulation and TBFMM algorithms. All instances have simultaneous multithreading disabled to ensure experimental consistency.

<table><caption>TABLE I

INSTANCE SPECIFICATIONS USED IN OUR EXPERIMENTS.</caption><thead><tr><td>Instance Type</td><td>Cores</td><td>GPU</td><td>Price (USD/h)</td></tr></thead><tbody><tr><td>g6.2xlarge</td><td>4</td><td>1x NVIDIA L4</td><td>0.9776</td></tr><tr><td>g6.4xlarge</td><td>8</td><td>1x NVIDIA L4</td><td>1.3232</td></tr><tr><td>g6.8xlarge</td><td>16</td><td>1x NVIDIA L4</td><td>2.0144</td></tr><tr><td>m5.16xlarge</td><td>32</td><td></td><td>3.0720</td></tr><tr><td>g6.16xlarge</td><td>32</td><td>1x NVIDIA L4</td><td>3.3968</td></tr><tr><td>c5n.18xlarge</td><td>36</td><td>-</td><td>3.8800</td></tr><tr><td>g6.24xlarge</td><td>48</td><td>4x NVIDIA L4</td><td>6.6752</td></tr></tbody></table>

The c5n.18xlarge instance type is powered by Intel Xeon Platinum 8124M processors, while m5.16xlarge is powered by Intel Xeon Platinum 8175. The g6 instance type family is powered by AMD EPYC 7R13 processors. We prepare machine images specific for each processor brand. For Intel instances, we use the Intel HPC toolkit 2025.1.0.666, with their proprietary compilers, MPI distribution, and libraries. For AMD instances, we use OpenMPI 5.0.7 and AMD Optimizing CPU Libraries (AOCL) 5.1. For GPU-powered instances, we use CUDA 12.8, and communications are handled by UCX 1.18. The g6 instance type family is powered by NVIDIA L4 GPUs. StarPU 1.4.7 is used in all of our experiments. All images are built on top of the official release of Amazon Linux, version 2023.6.20250218.

## VI. RESULTS AND DISCUSSION

To systematically evaluate the scalability of both our naïve N-body implementation and the TBFMM algorithm in AWS, we prepared a set of tests varying workload sizes and cluster configurations. For the N-body implementation, our evaluation encompasses both horizontal scaling (increasing the number of instances) and vertical scaling (increasing the computational power of individual machines). For TBFMM, we focus on

vertical scaling to assess how the algorithm performs under different single-node resource configurations. We present and discuss the results for the N-body and TBFMM algorithms in the following separate subsections.

### A. Naïve N-Body Simulation Experiments

For the N-body experiments we evaluated two problem dimensions: (i) a smaller problem size where $n = 2^{19} = 524,288$ particles; and (ii) a larger problem size where $n = 2^{20} = 1,048,576$ particles. Each simulation was executed for ten time steps. Due to the quadratic complexity ($O(n^2)$) of the brute-force N-body algorithm, the larger problem size represents a four-fold increase in computational workload, offering insight into how performance scales with increasing problem size. We intentionally limited the number of time steps, as the application exhibits a constant execution time per step; increasing the number of steps would scale the total runtime linearly without yielding additional information about scalability. We configured StarPU to use the DMDA scheduling policy, which automatically builds performance models during initial calibration runs. These precomputed models were then reused across all subsequent experiments to ensure consistent scheduling decisions while avoiding repeated calibration overhead. Results represent the average of five repetitions, demonstrating consistent performance patterns across trials.

We organized the N-body experiments into two categories: single-node and multi-node runs. The single-node experiments compare CPU-only, GPU-only, and hybrid CPU-GPU implementations across all instance types listed in Table I. Based on the single-node results, we identified the g6.2xlarge instance as the optimal choice, delivering performance comparable to larger GPU instances while providing superior cost efficiency. We selected this instance type for the subsequent multi-node experiments, evaluating horizontal scaling across clusters ranging from two to sixteen nodes.

1) Single-node results: Figure 1 illustrates the execution times of our naïve N-Body simulation in single-node environments. It compares performance between CPU-only, GPU-only, and hybrid CPU-GPU configurations using g6.2xlarge, g6.16xlarge, c5n.18xlarge, and m5.16xlarge instances.

The results reveal dramatic performance improvements and cost savings when using the g6 instance family. GPUs excel at this type of parallel workload due to their ability to efficiently handle the numerous concurrent force calculations inherent in N-body simulations. Despite the substantial CPU capacity of the m5.16xlarge and c5n.18xlarge instances, they are 3.14x and 3.96x more expensive, respectively, than the smaller g6.2xlarge instance.

Due to the significantly faster bodyForce CUDA kernel, the StarPU scheduler using the DMDA policy heavily favored executing tasks on CUDA workers. This resulted in virtually identical performance between g6.16xlarge and g6.2xlarge instances, despite the larger instance costing 3.47x more. This finding demonstrates that the GPU becomes
<figure><img src="image_2.png" /><figcaption>Fig. 1. N-Body simulation performance across single-node configurations for $2^{19}$ and $2^{20}$ particles. Error bars show standard deviation across multiple runs.</figcaption></figure>

<figure><img src="image_3.png" /><figcaption>Fig. 2. N-Body simulation performance across multi-node configurations for $2^{19}$ and $2^{20}$ particles. Error bars show standard deviation across multiple runs.</figcaption></figure>

<figure><img src="image_4.png" /></figure>

the primary performance bottleneck, making additional CPU cores largely irrelevant for this workload.

The performance and cost relationships remain consistent across both workload sizes. Runtime and costs are linearly scaled approximately four times when the particle count is doubled from $2^{19}$ to $2^{20}$, which aligns with the expected four-fold computational increase.

These results demonstrate that strategic instance selection can dramatically improve cost efficiency without compromising performance. Furthermore, the cost comparison underscores that relying exclusively on CPU resources ultimately proves substantially more expensive for this class of computation; despite lower hourly rates for CPU-only instances, their significantly longer execution times result in higher overall costs for equivalent computational work.

However, it should be noted that while the g6.2xlarge instance presents an optimal price-performance ratio for the problem sizes evaluated, its more limited system memory may become a constraint for extremely large simulations. When scaling to substantially larger particle counts or more complex simulation parameters, the expanded memory capacity of g6.16xlarge instances may become necessary despite their higher cost, highlighting the importance of matching instance characteristics to specific workload requirements.

## 2) Multi-node results
We conducted experiments on clusters ranging from two to sixteen nodes to evaluate the performance and scalability of the naïve N-body simulation across distributed platforms. Based on the single-node results presented in Section VI-A1, we selected the g6.2xlarge instance type for these horizontal scaling experiments due to its optimal price-performance ratio.

The results, shown in Figure 2, demonstrate nearly linear performance scaling as cluster size increases. This indicates that, for the problem sizes tested, the combination of CPU processing, GPU acceleration, and MPI communication introduced minimal overhead relative to the computational workload. The strong scaling behavior suggests that inter-node communication costs remain negligible compared to the intensive force calculations performed by each GPU.

The near-linear speedup achieved by our implementation creates an economically favorable scaling pattern: doubling computational resources approximately halves execution time, effectively balancing the increased per-hour costs of additional nodes. This relationship results in stable total execution costs, as clearly depicted in Figure 2, with only a modest 9.19% cost increase when scaling from one to sixteen g6.2xlarge nodes.

The cost variations between configurations underscore the
importance of considering economic factors alongside performance metrics when determining optimal cloud resource allocations. Although StarPU's automatic performance models integrated with the DMDA scheduler effectively optimize computational efficiency, incorporating real-time cost considerations into scheduling decisions could further reduce overall execution expenses. This highlights the potential value of cost-aware scheduling policies that dynamically balance performance optimization with economic constraints in cloud environments.

## B. TBFMM Rotational Kernel Simulation Experiments

We evaluated TBFMM's performance using the library compiled directly from source code<fnref n="4" />. The compilation incorporated FFTW version 3.3.10⁵ for discrete Fourier transform computations and was configured with StarPU support and CUDA kernels enabled, while SPECX and Inastemp components were disabled. All experiments utilized the DMDA scheduler, and rotational kernel tests were performed following StarPU's automatic calibration procedures.

Following the experimental design of our N-body simulations, we evaluated two distinct workload configurations: (i) $n = 2^{19} = 524,288$ particles and (ii) $n = 2^{20} = 1,048,576$ particles. For each configuration, we varied the tree height parameter, which controls the number of hierarchical levels in the octree structure used by TBFMM for spatial decomposition, between 3 and 4 levels. This experimental setup enables us to analyze how heterogeneous computational resources impact performance in this sophisticated tree-based fast multipole algorithm, providing a direct comparison with the brute-force computational approach employed in our N-body implementation.

Figure 3 and Figure 4 illustrate the execution time and costs of TBFMM's rotational kernel across instance types of the g6 family. Our analysis reveals significant challenges in vertical scaling for TBFMM at the tested problem sizes and tree heights. The system exhibits diminishing returns and even performance degradation, especially beyond 15 CPU workers. Performance gains were only achieved by scaling up to the g6.24xlarge instance type, which provides 4 NVIDIA L4 GPUs compared to the single GPU available on other instance types. However, this configuration still delivered worse performance than the much cheaper g6.2xlarge instance, which uses only a single NVIDIA L4 GPU. This pattern strongly suggests that the workload tested is better suited for GPU acceleration than for CPU parallelism at higher thread counts, possibly due to memory bandwidth constraints or scheduling overhead on multicore CPUs.

Tree-based algorithms like TBFMM present unique performance tuning challenges that extend beyond simple resource scaling, as evidenced by the dramatic performance differences between tree heights 3 and 4 in our experiments. The hierarchical octree structure creates complex dependencies between

<figure><img src="image_5.png" /></figure>

<figure><img src="image_6.png" /><figcaption>Fig. 3. TBFMM rotational kernel execution time and costs across different instance types. Error bars show standard deviation across multiple runs.</figcaption></figure>

problem size, tree depth, and parallelization efficiency that are not present in simpler algorithms.

This complexity has significant implications for Cloud Computing deployments, where empirical parameter tuning can incur substantial costs due to the need for extensive experimentation across different instance types and configurations. While StarPU's automatic calibration provides some assistance in optimizing task scheduling, it cannot address the fundamental algorithmic parameters such as tree height and particle distribution that critically affect performance. Users must still conduct expensive trial-and-error experiments to determine optimal configurations, making cloud-based TBFMM deployments costly and time-consuming to optimize. The unpredictable performance patterns observed across our instance types further compound this challenge, as seemingly more powerful configurations can deliver worse cost-performance ratios.

The performance differences between tree configurations can be understood by examining how the algorithm distributes work across available processors. Figure 5 shows trace data of the g6.24xlarge execution with $2^{20}$ particles and reveals a fundamental load balancing problem. While the instance provides 44 CPU workers and 4 CUDA workers, the trace clearly demonstrates that most computation is handled by the CUDA workers, while the majority of CPU workers remain

<footnote n="4">⁴TBFMM commit SHA: 40c79278c3e9967b1537079a62246b5711490739</footnote>

<footnote n="5">⁵FFTW official page: https://www.fftw.org/</footnote>
<figure><img src="image_7.png" /></figure>

<figure><img src="image_8.png" /><figcaption>Fig. 4. TBFMM rotational kernel execution time and costs across different instance types. Error bars show standard deviation across multiple runs.</figcaption></figure>

<figure><img src="image_9.png" /><figcaption>Fig. 5. TBFMM rotational kernel execution trace data showing worker activity in the g6.24xlarge instance.</figcaption></figure>

sleeping (shown in purple) throughout most of the execution.

This idle behavior occurs because TBFMM's task distribution heavily favors GPU acceleration for computationally intensive operations, particularly the expensive particle-to-particle (P2P) calculations. The intermittent CPU activity visible in the trace corresponds to tree traversal operations and data movement tasks that cannot be efficiently parallelized or offloaded to GPUs. With tree height 3 and the given problem size, the algorithm generates insufficient parallel work to effectively utilize all available CPU cores, while simultaneously concentrating the computational load on the limited GPU resources.

This workload distribution explains why scaling up to more CPU cores provides diminishing returns, as the bottleneck lies not in CPU availability but in the algorithm's ability to generate sufficient parallel work that can effectively utilize heterogeneous computing resources. The trace data confirms that simply adding more CPU workers does not improve performance when the computational workload is inherently better suited for GPU acceleration.

## VII. FINAL REMARKS

This study investigated the feasibility and performance characteristics of running HPC workloads on public cloud infrastructure using task-based programming models and het-

erogeneous computing resources. Through the comprehensive evaluation of both a direct N-body simulation and TBFMM's sophisticated hierarchical algorithm across various AWS configurations, we identified critical factors that determine the success of cloud-based HPC deployments.

Our experiments reveal several key findings that offer practical guidance for organizations considering cloud-based HPC deployments. Most notably, we found that cheaper GPU instances can dramatically outperform more expensive CPU-only machines while reducing costs significantly. When we replaced `m5.16xlarge` instances with `g6.2xlarge` instances for our direct N-body simulation, we achieved approximately a 8.2× improvement in runtime and reduced total execution costs by 24.4×. These performance gains are particularly strong for computationally intensive workloads that do not require extensive data movement.

Our analysis also revealed that the `g6.2xlarge` instance delivered nearly identical performance to the much larger `g6.16xlarge` instance while costing approximately one-sixth the price. This demonstrates that strategic instance selection can dramatically improve cost efficiency without sacrificing performance, a finding with immediate implications for budget-conscious organizations looking to maximize their computational capabilities in the public cloud within financial constraints.

However, our study also highlights significant challenges in
optimizing tree-based algorithms such as TBFMM for cloud environments. The complex relationship between problem size, tree depth, and parallelization efficiency creates a multi-dimensional optimization problem that requires extensive empirical testing. Our trace analysis revealed fundamental load balancing issues where most CPU workers remained idle while computation concentrated on limited GPU resources. This workload distribution pattern explains why simply adding more computational resources does not guarantee improved performance, particularly for algorithms with inherent structural bottlenecks.

The economic implications of parameter tuning in cloud environments present a critical consideration often overlooked in traditional HPC research. StarPU's performance model calibration, while essential for optimal scheduling, consumes significant computational resources and incurs real costs in pay-per-use cloud environments. Organizations must carefully balance the investment in calibration against expected performance returns, particularly for short-lived applications where optimization costs may exceed execution savings.

Task-based programming models proved effective in addressing many cloud-specific challenges through dynamic scheduling and intelligent data management. StarPU's ability to adapt to heterogeneous resources and minimize unnecessary data transfers demonstrates the potential of runtime systems to abstract away cloud infrastructure complexities. However, current limitations in distributed GPU support constrain the scalability advantages that could be achieved in multi-node configurations in the cloud.

Our findings suggest that the viability of cloud-based HPC depends critically on matching algorithmic characteristics to available cloud resources rather than simply migrating existing codes to more powerful instances. Applications with regular computational patterns and high parallelism, like our direct N-body implementation, can benefit significantly from horizontal scaling in the cloud. In contrast, applications with complex dependencies and irregular workload distributions, exemplified by TBFMM, require more careful consideration of cost-benefit trade-offs and may require algorithmic modifications to achieve cloud efficiency.

## A. Future Work

Several research directions emerge from our findings that could significantly advance cloud-based HPC capabilities.

The development of cloud-aware scheduling policies represents the most critical need, incorporating real-time cost models alongside performance metrics to enable economically optimized resource allocation. Such schedulers would dynamically balance computational efficiency against financial constraints, potentially reducing overall execution costs while maintaining performance standards.

Enhanced support for distributed heterogeneous execution in task-based runtimes would substantially improve scalability for complex applications. Extending StarPU's multi-node capabilities to fully support GPU acceleration across distributed

configurations could unlock significant performance potential currently limited by architectural constraints.

Additionally, the usage of ephemeral cloud resources, particularly spot instances, presents an opportunity to dramatically reduce computational costs further. Although an efficient fault-tolerant mechanism would be required, given the unreliability of spot machines, spot instances are heavily discounted and could present viable ways to run applications even if they are not fully optimized.

Finally, the development of automated parameter space exploration tools specifically designed for cloud environments could address the high costs associated with empirical optimization. Such tools would intelligently navigate the complex relationships between algorithmic parameters, instance configurations, and cost constraints to identify optimal deployments without requiring exhaustive manual experimentation.

These research directions collectively aim to make sophisticated HPC workloads more accessible and cost-effective for organizations lacking dedicated high-performance computing infrastructure, potentially democratizing access to advanced computational capabilities through intelligent utilization of public cloud resources.

## ACKNOWLEDGMENTS

This work was partially funded by Conselho Nacional de Desenvolvimento Científico e Tecnológico (CNPq), Fundação de Amparo à Pesquisa e Inovação do Estado de Santa Catarina (FAPESC) through the call Nº 18/2024 and Amazon Web Services (AWS) through the CNPq/AWS call Nº 64/2022 (Cloud Credits for Research).

## REFERENCES

[1] M. A. S. Netto, R. N. Calheiros, E. R. Rodrigues, R. L. F. Cunha, and R. Buyya, “HPC cloud for scientific and business applications: Taxonomy, vision, and research challenges,” *ACM Comput. Surv.*, vol. 51, no. 1, Jan. 2018. [Online]. Available: https://doi.org/10.1145/3150224

[2] G. Guidi, M. Ellis, A. Buluç, K. Yelick, and D. Culler, “10 years later: Cloud computing is closing the performance gap,” in *Companion of the ACM/SPEC International Conference on Performance Engineering*, ser. ICPE ’21. New York, NY, USA: Association for Computing Machinery, 2021, p. 41–48. [Online]. Available: https://doi.org/10.1145/3447545.3451183

[3] A. Liberman García, “The evolution of the cloud: the work, progress and outlook of cloud infrastructure,” Ph.D. dissertation, Massachusetts Institute of Technology, 2015.

[4] T. Dancheva, U. Alonso, and M. Barton, “Cloud benchmarking and performance analysis of an HPC application in Amazon EC2,” *Cluster Computing*, vol. 27, no. 2, pp. 2273–2290, 2024.

[5] J. Wei, M. Chen, L. Wang, P. Ren, Y. Lei, Y. Qu, Q. Jiang, X. Dong, W. Wu, Q. Wang, K. Zhang, and X. Zhang, “Status, challenges and trends of data-intensive supercomputing,” *CCF Transactions on High Performance Computing*, vol. 4, no. 2, pp. 211–230, 2022. [Online]. Available: https://doi.org/10.1007/s42514-022-00109-9

[6] A. Fernandez, “Evaluation of the performance of tightly coupled parallel solvers and mpi communications in iaas from the public cloud,” *IEEE Transactions on Cloud Computing*, vol. 10, no. 4, pp. 2613–2622, 2022.

[7] S. Kehrer and W. Blochinger, “Taskwork: a cloud-aware runtime system for elastic task-parallel hpc applications,” in *CLOSER 2019 : proceedings of the 9th International Conference on Cloud Computing and Services Science : Heraklion, Crete, Greece, May 2-4, 2019*, V. Mendez Munoz, Ed., 2019, pp. 198 – 209.
[8] C. Augonnet, S. Thibault, R. Namyst, and P.-A. Wacrenier, “StarPU: a unified platform for task scheduling on heterogeneous multicore architectures,” *Concurrency and Computation: Practice and Experience*, vol. 23, no. 2, pp. 187–198, 2011. [Online]. Available: https://inria.hal.science/inria-00550877

[9] J. Bueno, J. Planas, A. Duran, X. Martorell, E. Ayguadé, R. M. Badia, and J. Labarta, “Productive programming of gpu clusters with ompss,” in *Parallel and Distributed Processing Symposium (IPDPS)*, 2012.

[10] R. Hoque, T. Hérault, G. Bosilca, and J. Dongarra, “Dynamic task discovery in PaRSEC: a data-flow task-based runtime,” in *ScalA ’17: The 8th Workshop on Latest Advances in Scalable Algorithms for Large-Scale Systems*, 2017.

[11] R. Pereira, “Efficient Use of Task-based Parallelism in HPC Parallel Applications,” *Thesis*, Ecole normale supérieure de lyon - ENS LYON, Nov. 2023. [Online]. Available: https://theses.hal.science/tel-04466797

[12] H. Cloud, “The NIST definition of cloud computing,” *National institute of science and technology, special publication*, vol. 800, no. 2011, p. 145, 2011.

[13] D. Heggie, “The classical gravitational n-body problem,” *Encyclopedia of Mathematical Physics*, 04 2005.

[14] J. Barnes and P. Hut, “A hierarchical o(n log n) force-calculation algorithm,” *Nature*, vol. 324, no. 6096, pp. 446–449, 1986. [Online]. Available: https://doi.org/10.1038/324446a0

[15] Q. Wang, “A hybrid fast multipole method for cosmological n-body simulations,” *Research in Astronomy and Astrophysics*, vol. 21, no. 1, p. 003, jan 2021. [Online]. Available: https://dx.doi.org/10.1088/1674-4527/21/1/3

[16] S. L. Grimm, J. G. Stadel, R. Brasser, M. M. Meier, and C. Mordasini, “GENGA. II. GPU Planetary N-body Simulations with Non-Newtonian Forces and High Number of Particles,” *The Astrophysical Journal*, vol. 932, no. 2, p. 124, jun 2022. [Online]. Available: https://dx.doi.org/10.3847/1538-4357/ac6dd2

[17] B. Bramas, “TBFMM: A C++ generic and parallel fast multipole method library,” *Journal of Open Source Software*, vol. 5, no. 56, p. 2444, 2020.

[18] V. Munhoz and M. Castro, “Enabling the execution of hpc applications on public clouds with hpc@cloud toolkit,” *Concurrency and Computation: Practice and Experience*, vol. 36, no. 8, p. e7976, 2024. [Online]. Available: https://onlinelibrary.wiley.com/doi/abs/10.1002/cpe.7976

[19] D. De Sensi, T. De Matteis, K. Taranov, S. Di Girolamo, T. Rahn, and T. Hoefler, “Noise in the clouds: Influence of network performance variability on application scalability,” *Proc. ACM Meas. Anal. Comput. Syst.*, vol. 6, no. 3, Dec. 2022. [Online]. Available: https://doi.org/10.1145/3570609

[20] J. Zhuang, D. J. Jacob, H. Lin, E. W. Lundgren, R. M. Yantosca, J. F. Gaya, M. P. Sulprizio, and S. D. Eastham, “Enabling high-performance cloud computing for earth science modeling on over a thousand cores: Application to the geos-chem atmospheric chemistry model,” *Journal of Advances in Modeling Earth Systems*, vol. 12, no. 5, p. e2020MS002064, 2020, e2020MS002064 2020MS002064. [Online]. Available: https://agupubs.onlinelibrary.wiley.com/doi/abs/10.1029/2020MS002064

[21] J. Dongarra, M. A. Heroux, and P. Luszczek, “Hpcg benchmark: a new metric for ranking high performance computing systems,” *Knoxville, Tennessee*, vol. 42, 2015.

[22] “HPCG top 500,” https://top500.org/lists/hpcg/, accessed: 2025-05-06.

[23] V. Munhoz, M. Castro, and L. Rego, “Evaluating the Parallel Simulation of Dynamics of Electrons in Molecules on AWS Spot Instances,” in *Anais do Simpósio em Sistemas Computacionais de Alto Desempenho (WSCAD)*, 10 2023, pp. 205–216.

[24] B. Abraham, L. Rego, and L. Gundlach, “Electronic-vibrational coupling and electron transfer,” *The Journal of Physical Chemistry C*, vol. 123, 07 2019.

[25] L. Teylo, L. Arantes, P. Sens, and L. M. d. A. Drummond, “Scheduling Bag-of-Tasks in Clouds using Spot and Burstable Virtual Machines,” *IEEE Transactions on Cloud Computing*, vol. 11, no. 1, pp. 984–996, 2023.

[26] R. Cardoso, D. Golubovic, I. P. Lozada, R. Rocha, J. Fernandes, and S. Vallecorsa, “Accelerating gan training using highly parallel hardware on public cloud,” in *EPJ web of conferences*, vol. 251. EDP Sciences, 2021, p. 02073.

[27] T. Lynn, G. Fox, A. Gourinovitch, and P. Rosati, “Understanding the determinants and future challenges of cloud computing adoption for high performance computing,” *Future Internet*, vol. 12, no. 8, 2020. [Online]. Available: https://www.mdpi.com/1999-5903/12/8/135

[28] L. Nylons, M. Harris, and J. Prins, “Fast n-body simulation with cuda,” *GPU gems*, vol. 3, pp. 62–66, 2007.

[29] S. F. P. Zwart, R. G. Belleman, and P. M. Geldof, “High-performance direct gravitational n-body simulations on graphics processing units,” *New Astronomy*, vol. 12, no. 8, pp. 641–650, 2007.