Engineering Papers⌕ Search

SEARCH · Engineering Papers

Results for “GPU Programming”

Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.

Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.

At least 73 records · Page 4
All sourcesNASA NTRSDOE OSTI
DOE OSTI2010

High Performance Molecular Dynamic Simulation on Single and Multi-GPU Systems

The programming techniques supported and employed on these GPUs and Multi-GPUs systems are not sufficient to address problems exhibiting irregular, and unbalanced workload such as Molecular Dynamic (MD) simulations of systems with non-uniform densities. In this paper, we propose a task-based dynamic load-balancing solution to employ on MD simulations for single- and multi-GPU systems. The solution allows load balancing at a finer granularity than what is supported in existing APIs such as NVIDIA’s CUDA. Experimental results with a single-GPU configuration show that our fine-grained task solution can utilize the hardware more efficiently than the CUDA scheduler. On multi-GPU systems, our solution achieves near-linear speedup, load balance, and significant performance improvement over techniques based on standard CUDA APIs.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2017

Addressing Global Data Dependencies in Heterogeneous Asynchronous Runtime Systems on GPUs

Large-scale parallel applications with complex global data dependencies beyond those of reductions pose significant scalability challenges in an asynchronous runtime system. Internodal challenges include identifying the all-to-all communication of data dependencies among the nodes. Intranodal challenges include gathering together these data dependencies into usable data objects while avoiding data duplication. This paper addresses these challenges within the context of a large-scale, industrial coal boiler simulation using the Uintah asynchronous many-task runtime system on GPU architectures. We show significant reduction in time spent analyzing data dependencies through refinements in our dependency search algorithm. Multiple task graphs are used to eliminate subsequent analysis when task graphs change in predictable and repeatable ways. Using a combined data store and task scheduler redesign reduces data dependency duplication ensuring that problems fit within host and GPU memory. Furthermore, these modifications did not require any changes to application code or sweeping changes to the Uintah runtime system. We report results running on the DOE Titan system on 119K CPU cores and 7.5K GPUs simultaneously. Our solutions can be generalized to other task dependency problems with global dependencies among thousands of nodes which must be processed efficiently at large scale.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2024

Hls4ml Synthesis Testing

HLS4ml (high level synthesis for machine learning) Is a Python package used to translate commonly used open-source machine learning models into HLS. This is useful in machine learning applications on FPGAs. Machine learning algorithms are only as fast as the hardware that they are used on, and some applications require high speed without sacrificing accuracy. In these situations, an FPGA is a good choice since it is faster than a CPU or a GPU, but programming an FPGA is difficult. This is where HLS4ml can be used to simplify the process, as a well-known learning model can be converted to HLS and more easily deployed onto an FPGA. There are many use cases for a machine learning algorithm running on an FPGA. For example, detectors in a particle accelerator cannot keep every event that they detect, and so a computer must decide which events to keep and which to discard. Using an FPGA with a machine learning algorithm would be a good way to keep as many events as possible.

Swanson, Caiden↗
DOE OSTI2026

Center for Integrated Simulation of Fusion Relevant RF Actuators

This project was part of the “Center for Integrated Simulation of Fusion Relevant RF Actuators” SciDAC-4 project, led by Dr. Paul Bonoli (MIT). Rather than use an acronym (CISFRRFA), the project will be referred to in this document as the “RF-SciDAC4”. The larger SciDAC-4 project goals were to: 1. Develop an integrated simulation of the antenna + sheath + scrape-off-layer + core plasma system which fully utilizes leadership class computing resources to move towards a quantitative predictive capability for the response to RF power. 2. Work closely with the SciDAC-4 Whole Device Modeling (WDM) community to make both our new code development efforts, as well as the established hierarchy of RF tools, available within their environment, and to utilize WDM technologies to implement the couplings below. 3. Validate this predictive capability on appropriately diagnosed experiments including dedicated RF test stands, linear devices, and existing tokamaks. 4. Use these tools to inform design of robust, impurity-mitigating RF heating and current drive sources for future fusion devices.

70 PLASMA PHYSICS AND FUSION TECHNOLOGY↗
NASA NTRSDate not supplied

Improvements to a Batch Pentadiagonal Solver on NVIDIA GPUs

This poster presents the recent work in OVERFLOW to port the batched pentadiagonal solver to NVIDIA GPUs. There are five pentadiagonal systems for each pencil in the grid but three of these systems share the same LHS. Our first simple approach for porting the pentadiagonal solver to the GPUs was to take advantage of the shared LHS by assigning three threads to the three LHS of each pencil. We demonstrated that this custom solver was 92% faster than the NVIDIA batched pentadiagonal library implementation on a V100 GPU due to the lower memory bandwidth requirements. The second approach treated each pentadiagonal system as a 2x2 block tridiagonal system and used a variant of the parallel cyclic reduction algorithm to solve the problem. One benefit of this approach is that it does not require interleaving the data between each system. We demonstrated that this algorithm is 2.18x faster than the NVIDIA library implementation for the same amount of work. If we take advantage of our shared LHS, this approach is 2.58x faster than the library implementation on a V100 GPU.

GPU Programming↗
NASA NTRSDate not supplied

GPU Implementation of the OVERFLOW CFD Code

The high-performance computing (HPC) landscape is quickly changing to systems where most of the performance comes from specialized chips, specifically graphics processing units (GPUs). Such GPU systems are throughput machines, where efficient use of the GPU often requires code refactoring to expose a few orders of magnitude more fine grain parallelism than was previously used on the CPU. Recent modifications to OVERFLOW, an overset, structured grid, computational fluid dynamics flow solver, written in Fortran will be presented. These modifications include both code modernization efforts and algorithmic changes to enable OVERFLOW to efficiently utilize GPUs. Many of these algorithmic changes would likely also be applicable for other structured grid, stencil-based codes wanting to utilize GPUs. The capabilities that have been ported to run on the GPUs are presented, along with the performance gains of the GPU version relative the CPU version of OVERFLOW.

GPU Programming↗
NASA NTRSDate not supplied

GPU Implementation of the OVERFLOW CFD Code

The high-performance computing (HPC) landscape is quickly changing to systems where most of the performance comes from specialized chips, specifically graphics processing units (GPUs). Such GPU systems are throughput machines, where efficient use of the GPU often requires code refactoring to expose a few orders of magnitude more fine grain parallelism than was previously used on the CPU. Recent modifications to OVERFLOW, an overset, structured grid, computational fluid dynamics flow solver, written in Fortran will be presented. These modifications include both code modernization efforts and algorithmic changes to enable OVERFLOW to efficiently utilize GPUs. Many of these algorithmic changes would likely also be applicable for other structured grid, stencil-based codes wanting to utilize GPUs. The capabilities that have been ported to run on the GPUs are presented, along with the performance gains of the GPU version relative the CPU version of OVERFLOW.

GPU Programming↗
NASA NTRSDate not supplied

Strategies for the GPU Implementation of the OVERFLOW CFD Code

Wondering how to port a large, computational fluid dynamics (CFD) solver, written in Fortran, to run effectively on GPUs? Join this talk to learn about the strategies NASA’s OVERFLOW CFD code has used to effectively utilize GPUs to greatly improve the time to solution compared to CPUs. OVERFLOW is an overset, structured grid, computational fluid dynamics (CFD) flow solver developed by NASA and widely used by government, US industry, and academia. It is known for its effective use of CPU hardware, but this talk will discuss recent efforts to modify the code to run efficiently on GPUs. We will describe our use of OpenACC, CUDA Fortran, and CUDA C++, discussing why and how we use each to map our problem onto NVIDIA GPUs. We will also describe structural changes we made in the code to expose enough parallelism to effectively use the GPU hardware. Finally, we will present the performance benefits from running OVERFLOW on GPUs compared to the well optimized CPU version of the code.

GPU Programming↗
DOE OSTI2016

Graphics processing unit-assisted lossless decompression

Systems and methods for decompressing compressed data that has been compressed by way of a lossless compression algorithm are described herein. In a general embodiment, a graphics processing unit (GPU) is programmed to receive compressed data packets and decompress such packets in parallel. The compressed data packets are compressed representations of an image, and the lossless compression algorithm is a Rice compression algorithm.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2024

hls4ml

hls4ml (high level synthesis for machine learning) Is a Python package used to translate commonly used open-source machine learning models into HLS. This is useful in machine learning applications on FPGAs. Machine learning algorithms are only as fast as the hardware that they are used on, and some applications require high speed without sacrificing accuracy. In these situations, an FPGA is a good choice since it is faster than a CPU or a GPU, but programming an FPGA is difficult. This is where hls4ml can be used to simplify the process, as a well-known learning model can be converted to HLS and more easily deployed onto an FPGA. There are many use cases for a machine learning algorithm running on an FPGA. For example, detectors in a particle accelerator cannot keep every event that they detect, and so a computer must decide which events to keep and which to discard. Using an FPGA with a machine learning algorithm would be a good way to keep as many events as possible.

Swanson, Caiden↗
DOE OSTI2020

Density Matrix Quantum Circuit Simulation via the BSP Machine on Modern GPU Clusters

As quantum computers evolve, simulations of quantum programs on classical computers will be essential in validating quantum algorithms, understanding the effect of system noise, and design applications for future quantum computers. In this paper, we propose a novel multi-GPU programming model called MG-BSP that constructs a virtual BSP machine on top of modern multi-GPU platforms, and tweak the programming model to build a multi-GPU density matrix quantum simulator. We propose and evaluated a new formulation minimizing communication and prove that the transformation conserves original semantics when noise is introduced. We build the tool-chain to support quantum assembly open standard, synthesize testing quantum circuit, and enable ultra-deep quantum simulation. We evaluated our design on four state-of-the-art multi-GPU platforms including the latest DGX-1 and DGX-2 systems. We demonstrate simulation of 1 million gates in 94 minutes, far deeper circuits than has been demonstrated in prior work. A roofline-model analysis show that we have reached near-optimal performance under memory bound.

Li, Ang↗
DOE OSTI2011

DOE SBIR Phase-1 Report on Hybrid CPU-GPU Parallel Development of the Eulerian-Lagrangian Barracuda Multiphase Program

This report gives the result from the Phase-1 work on demonstrating greater than 10x speedup of the Barracuda computer program using parallel methods and GPU processors (General-Purpose Graphics Processing Unit or Graphics Processing Unit). Phase-1 demonstrated a 12x speedup on a typical Barracuda function using the GPU processor. The problem test case used about 5 million particles and 250,000 Eulerian grid cells. The relative speedup, compared to a single CPU, increases with increased number of particles giving greater than 12x speedup. Phase-1 work provided a path for reformatting data structure modifications to give good parallel performance while keeping a friendly environment for new physics development and code maintenance. The implementation of data structure changes will be in Phase-2. Phase-1 laid the ground work for the complete parallelization of Barracuda in Phase-2, with the caveat that implemented computer practices for parallel programming done in Phase-1 gives immediate speedup in the current Barracuda serial running code. The Phase-1 tasks were completed successfully laying the frame work for Phase-2. The detailed results of Phase-1 are within this document. In general, the speedup of one function would be expected to be higher than the speedup of the entire code because of I/O functions and communication between the algorithms. However, because one of the most difficult Barracuda algorithms was parallelized in Phase-1 and because advanced parallelization methods and proposed parallelization optimization techniques identified in Phase-1 will be used in Phase-2, an overall Barracuda code speedup (relative to a single CPU) is expected to be greater than 10x. This means that a job which takes 30 days to complete will be done in 3 days. Tasks completed in Phase-1 are: Task 1: Profile the entire Barracuda code and select which subroutines are to be parallelized (See Section Choosing a Function to Accelerate) Task 2: Select a GPU consultant company and jointly parallelize subroutines (CPFD chose the small business EMPhotonics for the Phase-1 the technical partner. See Section Technical Objective and Approach) Task 3: Integrate parallel subroutines into Barracuda (See Section Results from Phase-1 and its subsections) Task 4: Testing, refinement, and optimization of parallel methodology (See Section Results from Phase-1 and Section Result Comparison Program) Task 5: Integrate Phase-1 parallel subroutines into Barracuda and release (See Section Results from Phase-1 and its subsections) Task 6: Roadmap of Phase-2 (See Section Plan for Phase-2) With the completion of Phase 1 we have the base understanding to completely parallelize Barracuda. An overview of the work to move Barracuda to a parallelized code is given in Plan for Phase-2.

02 PETROLEUM↗
DOE OSTI2013

A Programming Framework for Scientific Applications on CPU-GPU Systems

At a high level, my research interests center around designing, programming, and evaluating computer systems that use new approaches to solve interesting problems. The rapid change of technology allows a variety of different architectural approaches to computationally difficult problems, and a constantly shifting set of constraints and trends makes the solutions to these problems both challenging and interesting. One of the most important recent trends in computing has been a move to commodity parallel architectures. This sea change is motivated by the industry’s inability to continue to profitably increase performance on a single processor and instead to move to multiple parallel processors. In the period of review, my most significant work has been leading a research group looking at the use of the graphics processing unit (GPU) as a general-purpose processor. GPUs can potentially deliver superior performance on a broad range of problems than their CPU counterparts, but effectively mapping complex applications to a parallel programming model with an emerging programming environment is a significant and important research problem.

99 GENERAL AND MISCELLANEOUS↗
DOE OSTI2019

DaCe - Data Centric Parallel Programming

DaCe is a parallel programming framework that takes code in Python/NumPy and other programming languages, and maps it to high-performance CPU, GPU, and FPGA programs, which can be optimized to achieve state-of-the-art. Internally, DaCe uses the Stateful DataFlow multiGraph (SDFG) data-centric intermediate representation: A transformable, interactive representation of code based on data movement. Since the input code and the SDFG are separate, it is possible to optimize a program without changing its source, so that it stays readable. On the other hand, transformations are customizable and user-extensible, so they can be written once and reused in many applications. With data-centric parallel programming, we enable direct knowledge transfer of performance optimization, regardless of the application or the target processor.

Ben-Nun, Tal↗
DOE OSTI2022

Portability for GPU-accelerated molecular docking applications for cloud and HPC: can portable compiler directives provide performance across all platforms?

High-throughput structure-based screening of drug-like molecules has become a common tool in biomedical research. Recently, acceleration with graphics processing units (GPUs) has provided a large performance boost for molecular docking programs. Both cloud and high-performance computing (HPC) resources have been used for large screens with molecular docking programs; while NVIDIA GPUs have dominated cloud and HPC resources, new vendors such as AMD and Intel are now entering the field, creating the problem of software portability across different GPUs. Ideally, software productivity could be maximized with portable programming models that are able to maintain high performance across architectures. While in many cases compiler directives have been used as an easy way to offload parallel regions of a CPU-based program to a GPU accelerator, they may also be an attractive programming model for providing portability across different GPU vendors, in which case the porting process may proceed in the reverse direction: from low-level, architecture-specific code to higher-level directive-based abstractions. MiniMDock is a new mini-application (miniapp) designed to capture the essential computational kernels found in molecular docking calculations, such as are used in phar-maceutical drug discovery efforts, in order to test different solutions for porting across GPU architectures. Here we extend MiniMDock to GPU offloading with OpenMP directives, and compare to performance of kernels using CUDA and HIP on NVIDIA and AMD GPUs, respectively, as well as across different compilers, exploring performance bottlenecks. We document this reverse-porting process, from highly optimized device code to a higher-level version using directives, compare code structure, and describe barriers that were overcome in this effort.

Thavappiragasam, Mathialakan↗
DOE OSTI2011

Exploring Fine-Grained Task-based Execution on Multi-GPU Systems

Many-core Graphics Processing Units (GPUs) have been utilized as the computation engine in many scientific fields due to the high peak performance, cost effectiveness, and the availability of user friendly programming environments, e.g., NVIDIA CUDA. However, the conventional data parallel GPU programming paradigm cannot satisfactorily address issues such as load balancing and GPU resource utilization due to the irregular and unbalanced workload patterns exhibited in some applications. In this paper, we explore the design space of task-based solutions for multi-GPU systems. By employing finer-grained tasks than what is supported in the current CUDA, and allowing task sharing, our solutions enable dynamic load balancing. We evaluate our solutions with a Molecular Dynamics application with different atom distributions (from uniform distribution to highly non-uniform distribution). Experimental results obtained on a 4-GPU system show that, for non-uniform distributed systems, our solutions achieve excellent speedup, and significant performance improvement over other solutions based on the standard CUDA APIs.

99 GENERAL AND MISCELLANEOUS↗
DOE OSTI2013

Summer Student Internship working on the GPU

This summer internship consisted of learning computer programming skills and languages including Thrust, CUDA, C++, C and Linux. The application of this programming is for use in GPU, graphics processing units, that are processors that perform math intensive calculations rapidly in three dimensions typically in advanced video games (“NVIDIA GeForce…”). Our goal is to apply this technology towards exa-scale computing on the LANL supercomputing infrastructure. My mentors use these machines to do computations. The completed algorithms include KD tree and Top K. In order to access the GPU, CUDA was used. CUDA is a parallel computer architecture for general computing on the GPUs. There are different means by which to access CUDA. The first approach uses libraries, like Thrust, Linear Algebra, and Signal and Image Processing. Another approach parallelizes loops in Fortran or C and in the last approach people develop custom parallel algorithms using familiar language (“What is CUDA”). The algorithms I worked on this summer use the first approach of using the thrust library of parallel algorithms and data structures.

97 MATHEMATICS AND COMPUTING↗
DOE OSTI2023

TeraChem protocol buffers ( TCPB ): Accelerating QM and QM/MM simulations with a client–server model

The routine use of electronic structures in many chemical simulation applications calls for efficient and easy ways to access electronic structure programs. Here, we describe how the graphics processing unit (GPU) accelerated electronic structure program TeraChem can be set up as an electronic structure server, to be easily accessed by third-party client programs. We exploit Google’s protocol buffer framework for data serialization and communication. The client interface, called TeraChem protocol buffers (TCPB), has been designed for ease of use and compatibility with multiple programming languages, such as C++, Fortran, and Python. To demonstrate the ease of coupling third-party programs with electronic structures using TCPB, we have incorporated the TCPB client into Amber for quantum mechanics/molecular mechanics (QM/MM) simulations. The TCPB interface saves time with GPU initialization and I/O operations, achieving a speedup of more than 2× compared to a prior file-based implementation for a QM region with ~250 basis functions. We demonstrate the practical application of TCPB by computing the free energy profile of p-hydroxybenzylidene-2,3-dimethylimidazolinone (p-HBDI - )—a model chromophore in green fluorescent proteins—on the first excited singlet state using Hamiltonian replica exchange for enhanced sampling. All calculations in this work have been performed with the non-commercial freely-available version of TeraChem, which is sufficient for many QM region sizes in common use.

37 INORGANIC, ORGANIC, PHYSICAL, AND ANALYTICAL CH↗