Towards Distributed Software Resilience in Asynchronous Many-Task Programming Models.
Abstract not provided.
SEARCH · Engineering Papers
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.
Abstract not provided.
Abstract not provided.
A processing system selectively allocates space to store a group of one or more cache lines at a cache level of a cache hierarchy having a plurality of cache levels based on memory access patterns of a software application executing at the processing system. The processing system generates bit vectors indicating which cache levels are to allocate space to store groups of one or more cache lines based on the memory access patterns, which are derived from data granularity and movement information. Based on the bit vectors, the processing system provides hints to the cache hierarchy indicating the lowest cache level that can exploit the reuse potential for a particular data.
Explore the source record for details and available documents.
Explore the source record for details and available documents.
Hardware specialization has become the silver bullet to achieve efficient high performance, from Systems-on-Chip systems, where hardware specialization can be ``extreme'', to large-scale HPC systems. As the complexity of the systems increases, so does the complexity of programming such architectures in a portable way. This work introduces the Minos Computing Library (MCL), as system software, programming model, and programming model runtime that facilitate programming extremely heterogeneous systems. MCL supports the execution of several multi-threaded applications within the same compute node, performs asynchronous execution of application tasks, efficiently balances computation across hardware resources, and provides performance portability. We show that code developed on a personal desktop automatically scales up to fully utilize powerful workstations with 8 GPUs and down to power-efficient embedded systems. MCL provides up to 17.5x speedup over OpenCL on NVIDIA DGX-1 systems and up to 1.88x speedup on single-GPU systems. In multi-application workloads, MCL dynamically resource allocation provides up to 2.43x performance improvement over manual, static allocation of computing resources.
Accelerator-based heterogeneous computing is the de facto standard in current and upcoming exascale machines. These heterogeneous resources empower computational scientists to select a machine or platform well-suited to their domain or applications. However, this diversity of machines also poses challenges related to programming model selection: inconsistent availability of programming models across different exascale systems, lack of performance portability for those programming models that do span several systems, and inconsistent performance between different models on a single platform. We explore these challenges on exascale-similar hardware, including AMD MI100 and NVIDIA A100 GPUs. By extending the sourceto-source compiler OpenARC, we demonstrate the power of automated translation of applications written in a single frontend programming model (OpenACC) into a variety of backend models (OpenMP, OpenCL, CUDA, HIP) that span the upcoming exascale environments. This translation enables us to compare performance within and across devices and to analyze programming model behavior with profiling tools.
Chemical looping with oxygen uncoupling (CLOU) is a promising carbon capture technology that utilizes two interconnected fluidized-bed reactors to separate oxygen from air using a metal oxide, and then to use that oxygen to combust fuel in a nitrogen-free environment. CLOU is particularly well suited for solid fuels such as coal since released O 2 will readily combust with solid char. This study presents simulations of the University of Utah's dual fluidized bed chemical looping process development unit (PDU) operating as a CLOU system at 100 kW th , using CPFD Software's Barracuda-VR™ CFD modeling program. A full 3D model of the PDU was used including both reactors, as well as loop seals and cyclone separators. Hydrodynamic settings and the drag model are based on previous cold-flow validation experiments. Mechanisms describing CLOU reaction kinetics for cuprous oxide oxidation in the air reactor and cupric oxide reduction in the fuel reactor were adapted from previously completed experimental work. Coal char kinetics were based on the carbon-hydrogen-nitrogen-oxygen-sulfur, CHNOS, method. Submodels for devolatilization, gasification, and homogenous gas-phase reactions used relationships from the literature. Results predict volatile burnout almost immediately, though coal combustion continues into the upper portions of the fuel reactor and cyclone. Lastly, nitrogen gas leakage into the fuel reactor is shown to be mostly carryover from the air reactor
Most parallel scientific programs contain compiler directives (pragmas) such as those from OpenMP (Hermanns in Parallel programming in Fortran 95 using openMP, 2002. School of Aeronautical Engineering, Universidad Politécnica de Madrid, España, 2011), explicit calls to runtime library procedures such as those implementing the Message Passing Interface (MPI) (in A message-passing interface standard version 4.0, 2021. https://www.mpi-forum.org/docs/mpi-4.0/mpi40-report.pdf), or compiler-specific language extensions such as those provided by CUDA (Ruetsch and Fatica in CUDA Fortran for scientists and engineers: best practices for efficient CUDA Fortran programming, Elsevier, 2013). By contrast, the recent Fortran standards empower developers to express parallel algorithms without directly referencing lower-level parallel programming models (Numrich in Parallel programming with co-arrays, CRC Press, 2018, and Curcic in Modern Fortran: building efficient parallel applications, Manning Publications, 2020). Fortran’s parallel features place the language within the Partitioned Global Address Space (PGAS) class of programming models. When writing programs that exploit data parallelism, application developers often find it straightforward to develop custom parallel algorithms. Problems involving complex, heterogeneous, staged calculations, however, pose much greater challenges. Such applications require careful coordination of tasks in a manner that respects dependencies prescribed by a directed acyclic graph. When rolling one’s own solution proves difficult, extending a customizable framework becomes attractive. Further, the paper presents the design, implementation, and use of the Framework for Extensible Asynchronous Task Scheduling (FEATS), which we believe to be the first task scheduling tool written in modern Fortran. We describe the benefits and compromises associated with choosing Fortran as the implementation language, and we propose ways in which future Fortran standards can best support the use case in this paper.
Performance of distributed graph algorithms can benefit greatly by forming rapport between algorithmic abstraction and the underlying runtime system that is responsible for scheduling work and exchanging messages. However, due to their dynamic and irregular nature of computation, distributed graph algorithms written in different programming models impose varying degree of workload pressure on the runtime. To cope with such vastly different workload characteristics, a runtime has to make several trade-offs. One such trade-off arises, for example, when the runtime scheduler has to choose among alternatives such as whether to execute algorithmic work, or progress the network by probing network buffers, or throttle sending messages (termed flow control). This tradeoff decides between optimizing the throughput of a runtime scheduler by increasing the rate of execution of algorithmic work, and reducing the latency of the network messages. Another trade-off exists when a decision has to be made about when to send aggregated messages in buffers (message coalescing). This decision chooses between trading off latency for network bandwidth and vice versa. At any instant, such trade-offs emphasize either on improving the quantity of work being executed (by maximizing the scheduler throughput) or on improving the quality of work (by prioritizing better work). However, encoding static policies for different runtime features (such as flow control, coalescing) can prevent graph algorithms from achieving their full potential, thus can undermine the actual performance of a distributed graph algorithm . In this paper, we investigate runtime support for distributed graph algorithms in the context of two paradigms: variants of wellknown Bulk-Synchronous Parallel model and asynchronous programming model. We explore generic runtime features such as message coalescing (aggregation) and flow control and show that execution policies of these features need to be adjusted over time to make a positive impact on the execution time of a distributed graph algorithm. Since synchronous and asynchronous graph algorithms have different workload characteristics, not all of such runtime features may be good candidates for adaptation. Each of these algorithmic paradigms may require different set of features to be adapted over time. We demonstrate which set of feature(s) can be useful in each case to achieve the right balance of work in the runtime layer. Existing implementation of different graph algorithms can benefit from adapting dynamic policies in the underlying runtime.
As opposed to the Open Computing Language (OpenCL) programming model, in which host and device codes are generally written in different programming languages, SYCL can combine host and device codes for an application in a type-safe way to improve development productivity and performance portability. Hence, this report shows the experimental results of applying the SYCL programming model to medical imaging applications for a study on performance portability and programming productivity between OpenCL and SYCL. Rodinia is a widely used open-source benchmark suite for heterogeneous computing. We choose two medical imaging applications (Heart Wall and Particle Filter) in the benchmark suite, migrate the OpenCL implementations of the applications to the SYCL implementations, and evaluate their performance and productivity on Intel® microprocessors that contain a central processing unit (CPU) and an integrated graphics processing unit (GPU). The maturing SYCL compilers, which are based on a conformant implementation of the SYCL 1.2.1 Khronos specification, have been actively optimized for Intel® computing platforms. The experimental results are promising in terms of the raw performance and productivity. Although the SYCL implementation of the Heart Wall application does not execute successfully on a CPU, the SYCL implementations of the application can achieve comparable or better performance than the OpenCL implementation on Intel® integrated GPUs. For the Particle Filter application, the performance difference between the SYCL and OpenCL implementations is comparable on the GPUs for most cases, but the SYCL implementations are on average 4X faster than the OpenCL implementations on Intel® Xeon® CPUs. For programming productivity, we arguably use lines of code as a way to measure programming productivity in software. The SYCL programs reduce the lines of code of the OpenCL programs by 52% and 38% for the Heart Wall and Particle Filter, respectively. The results indicate that SYCL is a promising programming model for heterogeneous computing with the maturing compilers. We organize the remainder of the report as follows. Section II introduces the SYCL programming model, compares the major differences between an OpenCL program and a SYCL program, and describes the characteristics of the two applications. Section III describes the SYCL programming model in more details, and shows the SYCL implementation of a kernel function in the Particle Filter application as an example. In Section IV, we evaluate the performance of the applications on the CPUs and GPUs. Section V concludes the report.
The main contribution of this work is to increase the coding productivity of GPU programming by using the concept of Static Graphs. GPU capabilities have been increasing significantly in terms of performance and memory capacity. However, there are still some problems in terms of scalability and limitations to the amount of work that a GPU can perform at a time. To minimize the overhead associated with the launch of GPU kernels, as well as to maximize the use of GPU capacity, we have combined the new CUDA Graph API with the CUDA programming model (including CUDA math libraries) and the OpenACC programming model. We use as test cases two different, well-known and widely used problems in HPC and AI: the Conjugate Gradient method and the Particle Swarm Optimization. In the first test case (Conjugate Gradient) we focus on the integration of Static Graphs with CUDA. In this case, we are able to significantly outperform the NVIDIA reference code, reaching an acceleration of up to 11x thanks to a better implementation, which can benefit from the new CUDA Graph capabilities. In the second test case (Particle Swarm Optimization), we complement the OpenACC functionality with the use of CUDA Graph, achieving again accelerations of up to one order of magnitude, with average speedups ranging from 2x to 4x, and performance very close to a reference and optimized CUDA code. Our main target is to achieve a higher coding productivity model for GPU programming by using Static Graphs, which provides, in a very transparent way, a better exploitation of the GPU capacity. The combination of using Static Graphs with two of the current most important GPU programming models (CUDA and OpenACC) is able to reduce considerably the execution time w.r.t. the use of CUDA and OpenACC only, achieving accelerations of up to more than one order of magnitude. Finally, we propose an interface to incorporate the concept of Static Graphs into the OpenACC Specifications.
Creation of an NCS Program Health model has enabled Y-12 and its stakeholders to arrive at a complete and common understanding as to what constitutes the "NCS Program."
Recently, the Partitioned Global Address Space (PGAS) parallel programming model has emerged as a usable distributed memory programming model. XcalableMP (XMP) is a PGAS parallel programming language that extends base languages such as C and Fortran with directives in OpenMP-like style. XMP supports a global-view model that allows programmers to define global data and to map them to a set of processors, which execute the distributed global data as a single thread. In XMP, the concept of a coarray is also employed for local-view programming. In this study, we port Gyrokinetic Toroidal Code - Princeton (GTC-P), which is a three-dimensional gyrokinetic PIC code developed at Princeton University to study the microturbulence phenomenon in magnetically confined fusion plasmas, to XMP as an example of hybrid memory model coding with the global-view and local-view programming models. In local-view programming, the coarray notation is simple and intuitive compared with Message Passing Interface (MPI) programming while the performance is comparable to that of the MPI version. Thus, because the global-view programming model is suitable for expressing the data parallelism for a field of grid space data, we implement a hybrid-view version using a global-view programming model to compute the field and a local-view programming model to compute the movement of particles. Finally, the performance is degraded by 20% compared with the original MPI version, but the hybrid-view version facilitates more natural data expression for static grid space data (in the global-view model) and dynamic particle data (in the local-view model), and it also increases the readability of the code for higher productivity.
The SYCL standard specifies a cross-platform abstraction layer that enables programming of heterogeneous computing systems using standard C++ [1]. In the Open Computing Language (OpenCL) programming model, host and device codes are written in different languages [2 ]. To improve development productivity and performance portability, the SYCL programming model combines host and device codes for an application in a type-safe way. In this report, we are interested in applying the SYCL programming model to a computationally intensive routine derived from the Hardware Accelerated Cosmology Code (HACC) framework for a study on performance portability on a heterogeneous computing device. We use Intel® OneAPI toolkit [3] to build the OpenCL and SYCL programs, and evaluate the performance of both implementations on Intel® integrated GPUs. We find that the SYCL implementation can achieve the same performance as the OpenCL implementation after we specify a target backend for the compiler to build the SYCL program in offline compilation. Without the specification of a target backend, the runtime will have to compile intermediate device codes for a target platform. Such runtime overhead may become significant compared to the execution of a kernel on a target device. As the kernel routine is compute-bound, we evaluate the impact of the number of compute units upon the kernel’s raw performance using two GPUs. When the hardware resource is not underutilized, we can obtain almost linear performance speedup from 48 compute units to 72 compute units in offline compilation, which indicates that the number of compute units on a GPU are important to improving the raw performance of a compute-bound kernel. The experimental results show that SYCL is a promising programming model for heterogeneous computing. The remainder of the report is organized as follows: In Section II, we describe the SYCL programming model, the steps to map an OpenCL program to a SYCL program, and the architecture of an integrated GPU. Section III introduces the kernel routine, and presents the OpenCL and SYCL implementations of the kernel. In Section IV, we evaluate the performance of the implementations on the GPUs. Section V concludes the report.
Parallel patterns, views, and spaces are promising abstractions to capture the programmer's intent as well as the contextual information that can be used by an underlying runtime to efficiently map software to parallel hardware. These abstractions can be valuable in cases where an algorithm must accommodate requirements of code and performance portability across hardware architectures and vendor programming models. Kokkos is a parallel programming model for host- and accelerator architectures that relies on these abstractions and targets these requirements. It consists of a pure C++ interface, a specification, and a programming library. The programming library exposes patterns and types and maps them to an underlying abstract machine model. The abstract machine model offers a generic view of parallel hardware. While Kokkos is gaining popularity in large-scale HPC applications at some DOE laboratories, we believe that the implemented concepts are of interest to a broader audience including academia as they may contribute to a generic, vendor, and architecture-independent education of parallel programming. In this work, we give an insight into the design considerations of this programming model and list important abstractions. Further, we document best practices obtained from giving virtual classes on Kokkos and give pointers to resources that the reader may consider valuable for a lecture on generic parallel programming for students with preexisting knowledge on this matter.
As opposed to the Open Computing Language (OpenCL) programming model in which host and device codes are generally written in different languages, the SYCL programming model can combine host and device codes for an application in a type-safe way to improve development productivity. In this paper, we chose the HACCmk routine, a representative compute-bound kernel, as a case study on the performance of the SYCL programming model targeting a heterogeneous computing device. More specifically, we introduced the SYCL programming model, presented the OpenCL and SYCL implementations of the routine, and compared the performance of the two implementations using the offline and online compilation on Intel (R) Iris (TM) Pro integrated GPUs. We found that the overhead of online compilation may become significant compared to the execution time of a kernel. Compared to the performance of OpenCL implementations, the SYCL implementation can maintain the performance using the offline compilation. The number of execution units in a GPU are critical to improving the raw performance of a compute-bound kernel.
Since the inception of the first community solar program in 2006, a number of different utility, solar industry and consumer driven community solar program models have emerged across the country with varying regulatory and solar market frameworks behind them. There is little consistency in how programs are administered, participant benefits are assigned, and customers are charged for participation. Further, while it is regularly speculated that community solar programs meet the needs of customers, no such consumer research has been completed against different community solar program models. This collaborative research effort addressed three primary issues: Program design models are numerous and evolving, with varying degrees of applicability across different state policy, utility regulatory, and solar market types. The agents, transaction methods, and accruing costs and benefits are highly variable and largely built on anecdotally successful model evolution. ‘Community solar’ (shared/group solar, solar gardens, etc.) has become a catch-all concept that means different things to different stakeholders, limiting constructive program development and growth. Everything from green pricing programs to remote net metering to metering aggregation has been framed as community solar. Consumer research on individual concepts and program models has been done, but no comprehensive and comparative market research on the broader design models and attributes has been performed. SEPA’s collaborative research effort on Community Solar Design Models for Consumer, Industry, & Utility Success is premised on the principle that greater standardization of community solar models and better understanding of consumer interests are key underpinnings of increased community solar deployment. Utilizing a cross-sectional multi-stakeholder working group, as well as focus groups and surveys, webinars, targeted outreach, and other tools, this project aims to expand the community solar knowledge base, facilitate information exchange, identify opportunities for standardization and improvement, determine what consumers’ interests are and how best to message to them, promote the research results within the solar and utility industries, and advance key opportunities for strategic deployment plans for community solar. A summary of these key takeaways/lessons learned during the grant period include: Siting of system should be evaluated up-front in the process Engage stakeholders collaboratively and early to help ensure the best chance for a successful program IT/billing departments must have a seat at the design table Establish upfront target objectives with respect to residential and commercial program access levels helps ensure program success Balance trade-offs to manage utility and developer risk with customer participation carefully to optimize pricing and sizing the program offering Over the course of the 42 month grant period, SEPA and its project team conducted a series of activities all designed to accelerate the number and size of community solar programs across the country. These activities included: Community Solar Program Design Models (2 reports) – SEPA, in collaboration with its projects team, the Coalition for Community Solar Access, and over 60 administrators of actual community solar programs, developed two reports providing hard data on the developments of community solar. These reports touched on program performance, quantity and type of programs, and program design steps, among other aspects. The reports collectively received over 2000 unique downloads. Market Research Report – SEPA, in collaboration with The Shelton Group, conducted a series of national surveys and focus groups to identify what customers were looking for in a community solar offering. The resulting report, “What the Community Solar Customer Wants”, received over 1,000 unique downloads. Technical Assistance Projects – SEPA supported 8 organizations who were pursuing community solar programs. Based on this support, over 5.7 MWs of new solar capacity have been developed. Technical Assistance Case Studies – SEPA developed two case studies detailing the technical assistance work in Fremont, NE Department of Utilities and the public power arm of Minster Ohio. These two reports have received 1,002 unique downloads. Webinar – SEPA hosted two webinars on community solar which collectively received 743 participants. The webinars focused on disseminating the findings of the research conducted under this project, as well as the research conducted in separate solar market pathways projects. Community Solar Design Workshops – 120 registrants learned about the trends in community solar and participated a business case exercise to design their own programs.