A Structured Grid Solver with Polyhedral+Dataflow Representation

Davis, Eddie C.; Olschanowsky, Catherine; Straalen, Brian Van

doi:10.1007/978-3-030-72789-5_10

Cited by 3 publications

(1 citation statement)

References 42 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Here, we focus exclusively on Fortran and its do concurrent (DC) construct for GPU acceleration. DC is an alternative construct to the standard do loop which indicates that the loop has no data dependencies and can be computed out-of-order 2 . This can be used to hint to a compiler that the loop is likely (but may not be) parallelizable.…”

Section: Introductionmentioning

confidence: 99%

Acceleration of a production Solar MHD code with Fortran standard parallelism: From OpenACC to `do concurrent'

Caplan¹,

M.²,

Linker³

2023

Preprint

View full text Add to dashboard Cite

There is growing interest in using standard language constructs for accelerated computing, avoiding the need for (often vendor-specific) external APIs. These constructs hold the potential to be more portable and much more 'future-proof'. For Fortran codes, the current focus is on the do concurrent (DC) loop. While there have been some successful examples of GPU-acceleration using DC for benchmark and/or small codes, its widespread adoption will require demonstrations of its use in full-size applications. Here, we look at the current capabilities and performance of using DC in a production application called Magnetohydrodynamic Algorithm outside a Sphere (MAS). MAS is a state-of-the-art model for studying coronal and heliospheric dynamics, is over 70,000 lines long, and has previously been ported to GPUs using MPI+OpenACC. We attempt to eliminate as many of its OpenACC directives as possible in favor of DC. We show that using the NVIDIA nvfortran compiler's Fortran 202X preview implementation, unified managed memory, and modified MPI launch methods, we can achieve GPU acceleration across multiple GPUs without using a single OpenACC directive. However, doing so results in a slowdown between 1.25x and 3x. We discuss what future improvements are needed to avoid this loss, and show how we can still retain close to the original code's performance while reducing the number of OpenACC directives by a factor of five.

show abstract

Section: Introductionmentioning

confidence: 99%