User Source Code Research Articles

The use of functional programming library to parallelize on graphics accelerators with CUDA technology

Modern graphics accelerators (GPUs) can signi cantly speed up the execution of numerical tasks. However, porting programs to graphics accelerators is not an easy task, sometimes requiring their almost complete rewriting. CUDA graphics accelerators, thanks to technology developed by NVIDIA, allow you to have a single source code for both conventional processors (CPUs) and CUDA. However, in this single source code, you need to somehow tell the compiler which parts of this code to parallelize on shared memory. The use of the functional programming library developed by the authors allows you to hide the use of one or another parallelization mechanism on shared memory within the library and make the user source code completely independent of the computing device used (CPU or CUDA). This article shows how this can be done.

Functional Programming Libraries for Graphics Accelerators

Modern graphics accelerators (GPUs) can significantly speed up the execution of numerical tasks. However, porting programs to graphics accelerators is not an easy task, sometimes requiring their almost complete rewriting. CUDA graphics accelerators, thanks to the technology developed by NVIDIA, allow you to have a single source code for both conventional processors (CPUs) and graphics accelerators (CUDA). However, parallelization on shared memory is done differently and still must be specified explicitly. The use of the functional programming library developed by the authors makes it possible to hide the use of one or another parallelization mechanism on shared memory inside the library and make the user source code independent of the computing device used (CPU or CUDA). Functional programming is based on the modern mathematical theory, namely the Category Theory, in which the notions of Functors and Monads are widely used. Our work intensively utilizes these notions and extends them to grid expressions used in solving numerical problems.

Применение библиотеки функционального программирования для распараллеливания вычислений на графических ускорителях с технологией CUDA

Modern graphics accelerators (GPUs) can significantly speed up the execution of numerical tasks. However, porting programs to graphics accelerators is not an easy task, sometimes requiring their almost complete rewriting. CUDA graphics accelerators, thanks to technology developed by NVIDIA, allow you to have a single source code for both conventional processors (CPUs) and CUDA. However, in this single source code, you need to somehow tell the compiler which parts of this code to parallelize on shared memory. The use of the functional programming library developed by the authors allows you to hide the use of one or another parallelization mechanism on shared memory within the library and make the user source code completely independent of the computing device used (CPU or CUDA). This article shows how this can be done.

Using the functional programming library for solving numerical problems on graphics accelerators with CUDA technology

Modern graphics accelerators (GPUs) can significantly speed up the execution of numerical tasks. However, porting programs to graphics accelerators is not an easy task. Sometimes the transfer of programs to such accelerators is carried out by almost completely rewriting them (for example, when using the OpenCL technology). This raises the daunting task of maintaining two independent source codes. However, CUDA graphics accelerators, thanks to technology developed by NVIDIA, allow you to have a single source code for both conventional processors (CPUs) and CUDA. The machine code generated when compiling this single text depends on which compiler it is compiled with (the usual one, such as gcc, icc and msvc, or the compiler for CUDA, nvcc). However, in this single source code, you need to somehow tell the compiler which parts of this code to parallelize on shared memory. For the CPU, this is usually done using OpenMP and special pragmas to the compiler. For CUDA, parallelization is done in a completely different way. The use of the functional programming library developed by the authors allows you to hide the use of one or another parallelization mechanism on shared memory within the library and make the user source code completely independent of the computing device used (CPU or CUDA). This article shows how this can be done.

ACC_TEST: Hybrid Testing Approach for OpenACC-Based Programs

In recent years, OpenACC has been used in many supercomputers and attracted many non-computer science specialists for parallelizing their programs in different scientific fields, including weather forecasting and simulations. OpenACC is a high-level programming model that supports parallelism and is easy to learn to use by adding high-level directives without considering too many low-level details. Testing parallel programs is a difficult task, made even harder if using programming models, especially if they have been badly programmed. If so, it will be challenging to detect their runtime errors as well as their causes, whether the error is from the user source code or from the programming model directives. Even when these errors are detected and the source code modified, we cannot guarantee that the errors have been corrected or are still hidden. There are many tools and studies that have investigated several programming models for identifying and detecting related errors. However, OpenACC has not been targeted clearly in any testing tool or previous studies, even though OpenACC has many benefits and features that could lead to increasing use in achieving parallel systems with less effort. In this paper, we enhance ACC_TEST with the ability to test OpenACC-based programs and detect runtime errors by using hybrid-testing techniques that enhance error coverage occurring in OpenACC as well as overheads and testing time.

Shielding design of laser electron photon beamlines at SPring-8

Shielding design for two new laser electron photon beamlines using backward Compton scattering with the photon energy of up to 76 MeV at NewSUBARU and 2.9 GeV at SPring-8 have been performed by using the Monte Carlo code FLUKA with a modified user source code including the beam dumps which have double-layer and triple-layer structures, respectively. The leakage dose distributions depending on the various conditions of photon beam transport lines and local shields were simulated to estimate the effect of the shield components to transport high energy photons at long beamlines.

Generic program monitoring by trace analysis

Program execution monitoring consists of checking whole executions for given properties, and collecting global run-time information. Monitoring gives valuable insights and helps programmers maintain their programs. However, application developers face the following dilemma: either they use existing monitoring tools which never exactly fit their needs, or they invest a lot of effort to implement relevant monitoring code. In this paper, we argue that when an event-oriented tracer exists, the compiler developers can enable the application developers to easily code their own monitors. We propose a high-level primitive called foldt which operates on execution traces. One of the key advantages of our approach is that it allows a clean separation of concerns; the definition of monitors is totally distinct from both the user source code and the language compiler. We give a number of applications of the use of foldt to define monitors for Mercury program executions: execution profiles, graphical abstract views, and two test coverage measurements. Each example is implemented by a few simple lines of Mercury.

A portable high‐level database debugger and software performance monitor

AbstractThe package DBDEBUG assits the users of CODASYL (network) database management systems in two ways. It can be used by applications programmers to debug their programs, and by the database administrator to monitor the performance of the database. The user may select the sections (or even individual statements) of his program to be traced and/or monitored. He may list the specific records and items he wishes to be investigated; he may also restrict tracing and monitoring to only certain DML verbs.The user's database schema and subschema are submitted to processors which generate a data dictionary. This data dictionary is then used by DBDEBUG in modifying the user's DML source code in order to obtain the specified tracing or performance statistics. The output is high‐level in that it reflects the high‐level language (DML COBOL) in which the user's source code was written.The package is designed to be portable. All but one of its components are written in standard Pascal or ANSI COBOL; assembler code is restricted to a ten‐line subroutine which obtains L/O and CPU times from the operating system.