Embedding Foreign Code

Clifton-Everest, Robert; McDonell, Trevor L.; Chakravarty, Manuel M. T.; Keller, Gabriele

doi:10.1007/978-3-319-04132-2_10

Cited by 10 publications

(7 citation statements)

References 12 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…As with Sarek, Accelerate computations are transformed to an internal representation that is compiled to Cuda, OpenCL or REPA code, using specific plugins. Accelerate also allows to use external CUDA code via an FFI [16] making it very similar to SPOC. However, comes from the possibility, for Sarek to describe computations that are not vector operations.…”

Section: High-level Gpgpu Programmingmentioning

confidence: 99%

GPGPU Composition with OCaml

Bourgoin

Chailloux

2014

Proceedings of ACM SIGPLAN International Workshop on Libraries, Languages, and Compilers for Array Programming

View full text Add to dashboard Cite

GPGPU programming promises high performance. However, to achieve it, developers must overcome several challenges. The main ones are : write and use hyper-parallel kernels on GPU, manage memory transfers between CPU and GPU, and compose kernels, keeping individual performance of components while optimizing the global performance. In this article, we propose to study the composition by distinguishing the location where it is done : kernel composition on the GPU, kernel generation by the CPU, and overall composition. To achieve it, we use the SPOC library, developed in OCaml. SPOC offers abstractions over the Cuda and OpenCL frameworks. It proposes a specific language, called Sarek, to express kernels and different parallel skeletons to compose them. We show that by increasing the level of abstraction to handle kernels, programs are easier to write and that some optimizations (via kernel generation and transfers scheduling) become possible. Thus, we win on both sides : expressiveness and efficiency.

show abstract

Section: High-level Gpgpu Programmingmentioning

confidence: 99%

GPGPU Composition with OCaml

Bourgoin

Chailloux

2014

Proceedings of ACM SIGPLAN International Workshop on Libraries, Languages, and Compilers for Array Programming

View full text Add to dashboard Cite

show abstract

“…The next sections discuss the new approach to template instantiation that avoids these problems, and appeared in [33].…”

Section: Array Operations As Skeletonsmentioning

confidence: 99%

“…In fact, CUDA does not permit us to do this, as the scalar function is translated into GPU kernel code, which can not include further parallel operations. 5 Nevertheless, even though array valued arguments to scalar functions will always be let- Since the new code generator based on quasiquoting [33] is able to dynamically rewrite the entire skeleton -including the function prototype -we are no longer forced to access arrayvalued arguments via global variables. In order to use the inbuilt L2 cache available devices of compute capability 2.0 and higher, arrays referenced from scalar code are marshalled to the kernel via the kernel function parameters, and read using standard array indexing.…”

Section: Array References In Scalar Codementioning

confidence: 99%

See 1 more Smart Citation

Optimising purely functional GPU programs

McDonell

Chakravarty

Keller

et al. 2013

Proceedings of the 18th ACM SIGPLAN International Conference on Functional Programming

Self Cite

View full text Add to dashboard Cite

Purely functional, embedded array programs are a good match for SIMD hardware, such as GPUs. However, the naive compilation of such programs quickly leads to both code explosion and an excessive use of intermediate data structures. The resulting slowdown is not acceptable on target hardware that is usually chosen to achieve high performance. In this paper, we discuss two optimisation techniques, sharing recovery and array fusion, that tackle code explosion and eliminate superfluous intermediate structures. Both techniques are well known from other contexts, but they present unique challenges for an embedded language compiled for execution on a GPU. We present novel methods for implementing sharing recovery and array fusion, and demonstrate their effectiveness on a set of benchmarks.

show abstract

“…• The DSL approach needs a special mechanism to interface with foreign code since DSL programs cannot directly use the FFI features already available to the host language [5].…”

Section: Introductionmentioning

confidence: 99%

Native offload of Haskell repa programs to integrated GPUs

Liu

Day

Glew

et al. 2014

Proceedings of the 3rd ACM SIGPLAN Workshop on Functional High-Performance Computing

View full text Add to dashboard Cite

In light of recent hardware advances, general-purpose computing on graphics processing units (GPGPU) is becoming increasingly commonplace, and needs novel programming models due to GPUs' radically different architecture. For the most part, existing approaches to programming GPUs within a high-level programming language choose to embed a domain-specific language (DSL) within a host metalanguage and then implement a compiler that maps programs written within that DSL to code in low-level languages such as OpenCL or CUDA. An alternative, underexplored, approach is to compile a restricted subset of the host language itself directly down to OpenCL/CUDA. We believe more research should be done to compare these two approaches and their relative merits. As a step in this direction, we implemented a quick proof of concept of the alternative approach. Specifically, we extend the Repa library with a computeG function to offload a computation to the GPU. As long as the requested computation meets certain restrictions, we compile it to OpenCL 2.0 using the recently added feature for shared virtual memory. We can successfully run nine benchmarks on an Intel integrated GPU. We obtain the expected performance from the GPU on six of those benchmarks, and are close to the expected performance on two more. In this paper, we describe an offload primitive for Haskell, how to extend Repa to use it, how to implement that primitive in the Intel Labs Haskell Research Compiler, and evaluate the approach on nine benchmarks, comparing to two different CPUs, and for one benchmark to handwritten OpenCL code.

show abstract

Embedding Foreign Code

Cited by 10 publications

References 12 publications

GPGPU Composition with OCaml

GPGPU Composition with OCaml

Optimising purely functional GPU programs

Native offload of Haskell repa programs to integrated GPUs

Contact Info

Product

Resources

About