Experiences Porting Distributed Applications to Asynchronous Tasks: A Multidimensional FFT Case-study

TL;DR

The paper investigates whether asynchronous many-task runtimes like HPX can outperform traditional MPI-based parallelism for distributed algorithms, using a multidimensional FFT as a case study. It develops multiple HPX-based variants and an HPX backend for FFTW to port a 2D real-to-complex FFT and to compare shared-memory and distributed performance against FFTW backends and MPI+X implementations. The key finding is that asynchronous task execution does not automatically yield improvements for 2D FFT; in fact, enforcing synchronization can improve cache performance, while carefully chosen task graphs (notably hpx::experimental::for_loop) can achieve competitive results. A notable outcome is that HPX-based distributed FFTs using the LCI parcelport can outperform FFTW MPI backends by up to about a factor of 5 in communication-heavy workloads, highlighting the significant role of the communication substrate in distributed performance.

Abstract

Parallel algorithms relying on synchronous parallelization libraries often experience adverse performance due to global synchronization barriers. Asynchronous many-task runtimes offer task futurization capabilities that minimize or remove the need for global synchronization barriers. This paper conducts a case study of the multidimensional Fast Fourier Transform to identify which applications will benefit from the asynchronous many-task model. Our basis is the popular FFTW library. We use the asynchronous many-task model HPX and a one-dimensional FFTW backend to implement multiple versions using different HPX features and highlight overheads and pitfalls during migration. Furthermore, we add an HPX threading backend to FFTW. The case study analyzes shared memory scaling properties between our HPX-based parallelization and FFTW with its pthreads, OpenMP, and HPX backends. The case study also compares FFTW's MPI+X backend to a purely HPX-based distributed implementation. The FFT application does not profit from asynchronous task execution. In contrast, enforcing task synchronization results in better cache performance and thus better runtime. Nonetheless, the HPX backend for FFTW is competitive with existing backends. Our distributed HPX implementation based on HPX collectives using MPI parcelport performs similarly to FFTW's MPI+OpenMP. However, the LCI parcelport of HPX accelerated communication up to a factor of 5.

Figures (5)

• Figure 1: Strong scaling runtimes on up to $128$ cores for a $2^{14} \times 2^{14}$ FFT. Task-futurization-based implementations are visualized with circles, while implementations based on are visualized with squares. Implementations capable of distributed computing are highlighted with dashed lines.
• Figure 2: Selected strong scaling runtime distributions on up to $128$ cores for a $2^{14} \times 2^{14}$ FFT (compare Figure \ref{['fig:shared_runtime_16384_hpx']}). The partial runtimes correspond to the computation steps in Section \ref{['parallel']}.
• Figure 3: Strong scaling runtimes on up to $128$ cores for a $2^{14} \times 2^{14}$ FFT. The different FFTW's backends are visualized with triangles. FFTW's ESTIMATE planning (left) is compared to MEASURE planning (right). The runtimes of the implementation using the respective planning are also included.
• Figure 4: Measured planing time for FFTW backend strong scaling (see Figure \ref{['fig:shared_runtime_16384_fftw3']}). The different FFTW's backends are visualized with triangles. The plan times of the implementation are included for comparison.
• Figure 5: Distributed strong scaling on a 16-node cluster with $48$-core nodes for a $2^{14} \times2^{14}$ matrix. The FFTW backends are visualized with triangles, while our HPX implementations are visualized using circles and squares (compare Figure \ref{['fig:shared_runtime_16384_hpx']}.