High-level Programming of Many-Core Architectures - Marques, Frederico Mariano de Almeida (2016)
Nowadays computational systems are heterogeneous typically containing CPUs and GPUs. Offloading computations to a GPU allows more computations per time unit, spe- cially when GPUs are more efficient than CPUs for some type of computations, like matrix multiplication. There is, nonetheless, a specific complexity associated with writing portable code, specially when dealing with the integration of the programming of GPUs in mainstream programming languages, avoiding low-level complex frameworks like CUDA and OpenCL. The proposals put forth to solve these questions can be divided into two fields: spe- cialized skeleton frameworks with reduced expressiveness, and languages (or language extensions) that follow a best-effort strategy. Nonetheless, efficient usage of these lan- guages requires the programmer reasons about code compatibility while considering the GPUs execution model and the limitations of the compilers themselves. The herein documented approach takes a different route, offering a programming model in which the programmer expresses the GPU computations by manipulating data structures in a way that is equivalent to the computations designed for CPU. This expres- siveness is achieved without prejudice to the guarantee that the expressed computations will run in GPU context. The methodology chosen to implement this approach rests on an expression template layer. This expression template layer generates both the Marrow framework code, to launch the OpenCL kernels, and the OpenCL kernels to be run. The generated code is reused in subsequent executions being that the generation only happens at the first time a computation is to be computed. From the tests developed there was a significant reduction of lines of code. The technique’s overhead has a reduced impact in the computation time, as shown by our results, being that the most noticeable feature is that the overhead is not proportional to the expressions complexity; our results point to an overhead of 9 to 10% in worst case scenario, and approaching 0% as the OpenCL computational time increases.