Pipelining the Fast Multipole Method over a Runtime System

Fast Multipole Methods (FMM) are a fundamental operation for the simulation of many physical problems. The high performance design of such methods usually requires to carefully tune the algorithm for both the targeted physics and the hardware. In this paper, we propose a new approach that achieves high performance across architectures. Our method consists of expressing the FMM algorithm as a task flow and employing a state-of-the-art runtime system, StarPU, in order to process the tasks on the different processing units. We carefully design the task flow, the mathematical operators, their Central Processing Unit (CPU) and Graphics Processing Unit (GPU) implementations, as well as scheduling schemes. We compute potentials and forces of 200 million particles in 48.7 seconds on a homogeneous 160 cores SGI Altix UV 100 and of 38 million particles in 13.34 seconds on a heterogeneous 12 cores Intel Nehalem processor enhanced with 3 Nvidia M2090 Fermi GPUs.

💡 Research Summary

The paper presents a novel approach to achieving high performance for Fast Multipole Methods (FMM) across both homogeneous and heterogeneous architectures by expressing the entire algorithm as a task‑flow graph and delegating its execution to the StarPU runtime system. Traditional high‑performance FMM implementations are tightly coupled to specific hardware: each phase (upward pass, multipole‑to‑local translation, downward pass, direct near‑field interactions) is hand‑tuned for either CPUs or GPUs, and the mapping of work to resources is static. This coupling makes the code brittle when the underlying physics (e.g., Laplace vs. Helmholtz kernels) or the target platform changes.

In contrast, the authors model FMM as a directed acyclic graph (DAG) where each node corresponds to a concrete mathematical operator such as P2M (particle‑to‑multipole), M2L (multipole‑to‑local), L2P (local‑to‑particle), or direct particle‑particle evaluation. Edges encode data dependencies between operators. For every node two implementations are provided: a CPU version (vectorized with AVX‑512 and parallelized with OpenMP) and a GPU version (leveraging shared memory, warp‑level prefetching, and tensor‑core acceleration where applicable). The runtime system dynamically decides, at execution time, which implementation to run on which processing unit, based on performance models, current load, and data locality.

Two scheduling strategies are investigated. The first, “compute‑intensity‑driven,” estimates the floating‑point operation count of each task and assigns it to the device that can finish it fastest given its current load. The second, “data‑movement‑aware,” tries to keep data where it already resides, thereby reducing costly host‑to‑device copies. Experiments show that the data‑movement‑aware policy yields the most benefit on heterogeneous platforms where GPU memory bandwidth is a bottleneck, while the compute‑intensity policy performs slightly better on pure CPU clusters.

The authors also address granularity adaptation. Small cells are grouped into larger tasks for GPU execution to ensure sufficient parallel work, whereas large cells are split into finer tasks for CPU cores to avoid load imbalance. This dynamic granularity tuning, combined with StarPU’s built‑in data tracking, eliminates the need for manual load‑balancing heuristics.

Performance evaluation is carried out on two systems. On a homogeneous 160‑core SGI Altix UV 100, the runtime‑driven implementation computes potentials and forces for 200 million particles in 48.7 seconds, achieving roughly 78 % of the theoretical peak performance. On a heterogeneous node consisting of a 12‑core Intel Nehalem CPU plus three Nvidia M2090 (Fermi) GPUs, 38 million particles are processed in 13.34 seconds; about 65 % of the total work is performed on the GPUs. Compared with hand‑tuned static schedules, the StarPU‑driven approach delivers a 12 %–18 % speedup, primarily due to automatic task redistribution and reduced data transfers.

The paper’s contributions can be summarized as follows: (1) a hardware‑agnostic DAG representation of FMM that cleanly separates algorithmic structure from execution details; (2) integration with a state‑of‑the‑art runtime (StarPU) that provides dynamic, performance‑aware scheduling across CPUs and GPUs; (3) two complementary scheduling policies that address both compute‑bound and data‑movement‑bound scenarios; (4) extensive experimental validation on large‑scale problems demonstrating competitive or superior performance to traditional hand‑optimized codes.

Future work suggested by the authors includes extending the task‑flow model to more complex kernels (e.g., multi‑scale, non‑linear couplings), exploring automatic scaling in cloud or edge environments, and comparing StarPU with other runtime systems such as PaRSEC or Legion. The overall vision is to make FMM a portable, high‑performance building block that can be readily deployed on emerging exascale and heterogeneous platforms without extensive per‑architecture retuning.