From: Raphael Couturier Date: Thu, 20 Sep 2012 18:29:18 +0000 (+0200) Subject: ajout X-Git-Url: https://bilbo.iut-bm.univ-fcomte.fr/and/gitweb/book_gpu.git/commitdiff_plain/f69f75dd5354fe34ad3b1360af061a8f1aebb9aa?ds=sidebyside;hp=-c ajout --- f69f75dd5354fe34ad3b1360af061a8f1aebb9aa diff --git a/BookGPU/Chapters/chapter1/biblio.bib b/BookGPU/Chapters/chapter1/biblio.bib new file mode 100644 index 0000000..f3b0ccc --- /dev/null +++ b/BookGPU/Chapters/chapter1/biblio.bib @@ -0,0 +1,35 @@ +@misc{ch1:cuda, + author = {{NVIDIA Corporation}}, + keywords = {CUDA}, + note = {Version 4.0}, + title = {{NVIDIA CUDA C} Programming Guide}, + year = 2011 +} + +@Article{ch1:Buck:2004:BGS, + author = "I. Buck and T. Foley and D. Horn and J. + Sugerman and K. Fatahalian and M. Houston and P. + Hanrahan", + title = "{Brook} for {GPUs}: stream computing on graphics + hardware", + journal = "ACM Transactions on Graphics", + volume = "23", + number = "3", + pages = "777--786", + month = aug, + year = "2004", +} + + +@article{ch1:CMR:12, + author = "B. Cloutier and B. K. Muite and P. Rigge", + title = "A comparison of CPU and GPU performance for Fourier pseudospectral simulations of the Navier-Stokes, Cubic Nonlinear Schrödinger and Sine Gordon Equations", + journal = "Computational Physics (physics.comp-ph)", + year = "2012", + archivePrefix = "arXiv", + eprint = "1206.3215", + primaryClass = "physics.comp-ph", +} + + + diff --git a/BookGPU/Chapters/chapter1/ch1.tex b/BookGPU/Chapters/chapter1/ch1.tex new file mode 100755 index 0000000..9a3f4eb --- /dev/null +++ b/BookGPU/Chapters/chapter1/ch1.tex @@ -0,0 +1,275 @@ +\chapterauthor{Raphaël Couturier}{Femto-ST Institute, University of Franche-Comte} + + +\chapter{Presentation of the GPU architecture and of the CUDA environment} +\label{chapter1} + +\section{Introduction}\label{ch1:intro} + +This chapter introduces the Graphics Processing Unit (GPU) architecture and all +the concepts needed to understand how GPUs work and can be used to speed up the +execution of some algorithms. First of all this chapter gives a brief history of +the development of Graphics card until they can be used in order to make general +purpose computation. + + + +\section{Brief history of Video Card} + +Video card or Graphics card have been introduced in personnal computers to +produce high quality graphics faster than classical Central Processing Unit +(CPU) and to alleviate CPU from this task. In general, display tasks are very +repetitive and very specific. Hence, some manufacturers have produced more and +more sofisticated video cards, providing 2D accelerations then 3D accelerations, +then some light transforms. Video cards own their own memory to perform their +computation. From at least two dedaces, every personnal computer has a video +card which a simple for desktop computers or which provides many accelerations +for game and/or graphic oriented computers. In the latter case, graphic cards +may be more expensive than the CPU. + +After 2000, video cards allowed to apply arithmetics operations simulatenously +on a sequence of pixels, also later called stream processing. In this case, +information of the pixels (color, location and other information) are combined +in order to produce a pixel color that can be displayed on a +screen. Simultaneous computations are provided by shaders which calculate +rendering effects on graphics hardware with a high degree of flexibility. These +shaders handles the stream data with pipelines + + +Some reasearchers tried to apply those operations on other data, representing +something different from pixels, and consequently this resulted in the first +uses of video cards for performing general purpose computation. The programming +model was not easy to use at all and was very dependent of the hardware +constraints. More precisely it consisted in using either DirectX of OpenGL +functions providing an interface to some classical operations for videos +operations (memory transfers, texture manipulation, ...). Floating point +operations were most of the time unimaginable. Obviously when something bad +happened, programmers had no way (and tools) to detect it. + +\section{GPGPU} + +In order to benefit from the computing power of more recent video cards, CUDA +was first proposed in 2007 by NVidia. It unifies the programming model for some +of their most performant video cards. Cuda~\cite{ch1:cuda} has quickly been +considered by the scientific community as a great advance for general purpose +graphics processing unit (GPGPU) computing. Of course other programming model +have been proposed. The other well-known alternative is OpenCL which aims at +proposing an alternative to Cuda and which is multi-platform and portable. This +is a great advantage since it is even possible to execute OpenCL programs on +traditionnal CPUs. The main drawbacks is that it is less tight with the +hardware and consequently provides sometimes less efficient programs. Moreover, +Cuda benefits from more mature compilation and optimization procedures. Other +less known environment have been proposed, but most of them have been stopped, +for example we can cited: FireStream by ATI which is not maintened anymore and +replaced by OpenCL, BrookGPU by Standford University~\cite{ch1:Buck:2004:BGS}. +Another environment based on pragma (insertion of pragma directives inside the +code to help the compiler to generate efficient code) is call OpenACC. For a +comparison with OpenCL, interested readers may refer to~\cite{ch1:CMR:12}. + + + +\section{Architecture of current GPUs} + +Architecure of current GPUs is constantly evolving. Nevertheless some trends +remains true through this evolution. Processing units composing a GPU are far +more simpler than a traditional CPU but it is much easier to integrate many +computing units inside a GPU card than many cores inside a CPU. This is due to +the fact that cores of a GPU a simpler than cores of a CPU. In 2012, the most +powerful GPUs own more than 500 cores and the most powerful CPUs have 8 +cores. Figure~\ref{ch1:fig:comparison_cpu_gpu} shows the number of cores inside +a CPU and inside a GPU. In fact, in a current NVidia GPU, there are +multiprocessors which have 32 cores (for example on Fermi cards). The core clock +of CPU is generally around 3GHz and the one of GPU is about 1.5GHz. Although the +core clock of GPU cores is slower, the amount of cores inside a GPU provides +more computational power. This measure is commonly represented by the number of +floating point operation per seconds. Nowadays most powerful GPUs provide more +than 1TFlops, i.e. $10^{12}$ floating point operations per second. Nevertheless +GPUs are very efficient to perform some operations but not all kinds of +operations. They are very efficient to execute repetitive work in which only the +data change. It is important to keep in mind that multiprocessors inside a GPU +have 32 cores. Later we will see that these 32 cores need to do the same work to +get maximum performance. + +\begin{figure}[b!] +\centerline{\includegraphics[]{Chapters/chapter1/figures/nb_cores_CPU_GPU.pdf}} +\caption[Comparison of number of cores in a CPU and in a GPU]{Comparison of number of cores in a CPU and in a GPU.} +\label{ch1:fig:comparison_cpu_gpu} +\end{figure} + +On most powerful GPU cards, called Fermi, multiprocessors are called streaming +multiprocessors (SM). Each SM contains 32 cores and is able to perform 32 +floating point or integer operations on 32bits numbers per clock or 16 floating +point on 64bits number per clock. SM have their own registers, execution +pipelines and caches. On Fermi architecture, there are 64Kb shared memory + L1 +cache and 32,536 32bits registers per SM. More precisely the programmer can +decide what amount of shared memory and L1 cache SM can use. The constaint is +that the sum of both amounts is less or equal to 64Kb. + +Threads are used to benefit from the important number of cores of a GPU. Those +threads are different from traditional threads for CPU. In +chapter~\ref{chapter2}, some examples of GPU programming will explicit the +details of the GPU threads. However, threads are gathered into blocks of 32 +threads, called ``warp''. Those warps are important when designing an algorithm +for GPU. + + +Another big difference between CPU and GPU is the latency of memory. In CPU, +everything is optimized to obtain a low latency architecture. This is possible +through the use of cache memories. Moreover, nowadays CPUs perform many +performance optimizations such as speculative execution which roughly speaking +consists in executing a small part of code in advance even if later this work +reveals to be useless. In opposite, GPUs do not have low latency memory. In +comparison GPUs have ridiculous cache memories. Nevertheless the architecture of GPUs is optimized for throughtput computation and it takes into account the memory latency. + + + +\begin{figure}[b!] +\centerline{\includegraphics[scale=0.7]{Chapters/chapter1/figures/low_latency_vs_high_throughput.pdf}} +\caption[Comparison of low latency of CPU and highthroughput of GPU]{Comparison of low latency of CPU and highthroughput of GPU.} +\label{ch1:fig:latency_throughput} +\end{figure} + +Figure~\ref{ch1:fig:latency_throughput} illustrates the main difference of +memory latency between a CPU and a GPU. In a CPU, tasks ``ti'' are executed one +by one with a short memory latency to get the data to process. After some tasks, +there is a context switch that allows the CPU to run concurrent applications +and/or multi-threaded applications. Memory latencies are longer in a GPU, the +the principle to obtain a high throughput is to have many tasks to +compute. Later we will see that those tasks are called threads with CUDA. With +this principle, as soon as a task is finished the next one is ready to be +executed while the waiting for data for the previous task is overlapped by +computation of other tasks. + + + +\section{Kinds of parallelism} + +Many kinds of parallelism are avaible according to the type of hardware. +Roughtly speaking, there are three classes of parallism: instruction-level +parallelism, data parallelism and task parallelism. + +Instruction-level parallelism consists in re-ordering some instructions in order +to executed some of them in parallel without changing the result of the code. +In modern CPUs, instruction pipelines allow processor to execute instruction +faster. With a pipeline a processor can execute multiple instruction +simultaneously due to the fact that the output of a task is the input of the +next one. + +Data parallelism consists in executing the same program with different data on +different computing units. Of course, no depency should exist between the the +data. For example, it is easy to parallelize loops without dependency using the +data parallelism paradigm. This paradigm is linked with the Single Instructions +Multiple Data (SIMD) architecture. This is the kind of parallism providing by +GPUs. + +Taks parallelism is the common parallism achieved out on cluster and grid and +high performance architecture where different tasks are executed by different +computing units. + +\section{CUDA Multithreading} + +The data parallelism of CUDA is more precisely based on the Single Instruction +Multiple Thread (SIMT) model. This is due to the fact that the programmer access +to the cores by the intermediate of threads. In the CUDA model, all cores +execute the same set of instructions but with different data. This model has +similarities with vector programming model proposed for vector machines through +the 1970s into the 90s, notably the various Cray platforms. On the CUDA +architecture, the performance is led by the use of a huge number of threads +(from thousand upto to millions). The particularity of the model is that there +is no context switching as in CPUs and each thread has its own registers. In practice, threads are executed by SM and are gathered into groups of 32 threads. Those groups are call ``warps''. Each SM alternatively executes ``active warps'' and warps becoming temporaly inactive due to waiting of data (as shown in Figure~\ref{ch1:fig:latency_throughput}). + +The key to scalability in the CUDA model is the use of a huge number of threads. +In practice threads are not only gathered in warps but also in thread blocks. A +thread block is executed by only one SM and it cannot migrate. Typical size of +thread block is a number power of two (for example: 64, 128, 256 or 512). + + + +In this case, without changing anything inside a CUDA code, it is possible to +run your code with a small CUDA device or most performant Tesla CUDA cards. +Blocks are executed in any number depending on the number of SM available. So +the programmer must conceive its code having this issue in mind. This +independence between threads blocks provides the scalability of CUDA codes. + +\begin{figure}[b!] +\centerline{\includegraphics[scale=0.65]{Chapters/chapter1/figures/scalability.pdf}} +\caption[Scalability of GPU]{Scalability of GPU.} +\label{ch1:fig:scalability} +\end{figure} + + +A kernel is a function which contains a block a instruction that are executed by +threads of a GPU. When the problem considered is a 2 dimensions or 3 dimensions +problem, it is possible to group thread blocks into grid. In practice, the +number of thread blocks and the size of thread block is given in parameter to +each kernel. Figure~\ref{ch1:fig:scalability} illustrates an example of a +kernel composed of 8 thread blocks. Then this kernel is executed on a small +device containing only 2 SMs. So in in this case, blocks are executed 2 by 2 in +any order. If the kernel is executed on a larger CUDA device containing 4 SMs, +blocks are executed 4 by 4 simultaneously. The execution times should be +approximately twice faster in the latter case. Of course, that depends on other +parameters that will be described later. + +Thread blocks provide a way to cooperation in the sens that threads of the same +block cooperatively load and store blocks of memory they all +use. Synchronizations of threads in the same block are possible (but not between +thread of different blocks). Threads of the same block can also share results in +order to compute a single result. In chapter~\ref{chapter2}, some examples will +explicit that. + + +\section{Memory hierarchy} + +The memory hierarchy of GPUs is different from the one of CPUs. In practice, +there is registers, local memory, shared memory, cache memroy and global memory. + +As previously mentioned each thread can access its own registers. It is +important to keep in mind that the number of registers per block is limited. On +recent cards, this number is limited to 64Kb per SM. Access to registers is +very fast, so when possible it is a good idea to use them. + +Likewise each thread can access local memory which in practice much slower than +registers. In practice, local memory is automatically used by the compiler when +all the registers are occupied. So the best idea is to optimize the use of +registers even if this implies to reduce the number of threads per block. + +Shared memory allows cooperation between threads of the same block. This kind +of memory is fast by it requires to be manipulated manually and its size is +limited. It is accessible during the execution of a kernel. So the principle is +to fill the shared memory at the start of the kernel with global data that are +used very frequently, then threads can access it for their computation. They +can obviously change the content of this shared memory either with computation +or load of other data and they can store its content in the global memory. So +shared memory can be seen as a cache memory manageable manually. This requires +obviously an effort from the programmer. + +On recent cards, the programmer may decide what amount of cache memory and +shared memory is attributed to a kernel. The cache memory is a L1 cache which is +directly managed by the GPU. Sometimes, this cache provides very efficient +result and sometimes the use of shared memory is a better solution. + +\begin{figure}[b!] +\centerline{\includegraphics[scale=0.60]{Chapters/chapter1/figures/memory_hierarchy.pdf}} +\caption[Memory hierarchy of a GPU]{Memory hierarchy of a GPU.} +\label{ch1:fig:memory_hierarchy} +\end{figure} + + +Figure~\ref{ch1:fig:memory_hierarchy} illustrates the memory hierarchy of a +GPU. Threads are represented on the top of the figure. They can access to their +own registers and their local memory. Threads of the same block can access to +the shared memory of this block. The cache memory is not represented here but it +is local to a thread. Then each block can access to the global memory of the +GPU. + + +%%http://people.maths.ox.ac.uk/gilesm/pp10/lec2_2x2.pdf +%%https://people.maths.ox.ac.uk/erban/papers/paperCUDA.pdf +%%http://forum.wttsnxt.com/my_forum/viewtopic.php?f=5&t=9519 +%%http://www.cs.nyu.edu/manycores/cuda_many_cores.pdf +%%http://www.cc.gatech.edu/~vetter/keeneland/tutorial-2011-04-14/02-cuda-overview.pdf +%%http://people.maths.ox.ac.uk/~gilesm/cuda/ + + +\putbib[Chapters/chapter1/biblio] + diff --git a/BookGPU/Chapters/chapter1/figures/low_latency_vs_high_throughput.pdf b/BookGPU/Chapters/chapter1/figures/low_latency_vs_high_throughput.pdf new file mode 100644 index 0000000..6ecca71 Binary files /dev/null and b/BookGPU/Chapters/chapter1/figures/low_latency_vs_high_throughput.pdf differ diff --git a/BookGPU/Chapters/chapter1/figures/low_latency_vs_high_throughput.svg b/BookGPU/Chapters/chapter1/figures/low_latency_vs_high_throughput.svg new file mode 100644 index 0000000..8daddbd --- /dev/null +++ b/BookGPU/Chapters/chapter1/figures/low_latency_vs_high_throughput.svg @@ -0,0 +1,1164 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + Processing part + + + + Waiting for data + + + + Context switching + + + + + + + + + + + + CPU: optimized for low latency + GPU: optimized for high throughput + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Data ready to be processed + t1 + t2 + t3 + t4 + t1 + t2 + t3 + t4 + ti + + diff --git a/BookGPU/Chapters/chapter1/figures/memory_hierarchy.pdf b/BookGPU/Chapters/chapter1/figures/memory_hierarchy.pdf new file mode 100644 index 0000000..88448ae Binary files /dev/null and b/BookGPU/Chapters/chapter1/figures/memory_hierarchy.pdf differ diff --git a/BookGPU/Chapters/chapter1/figures/memory_hierarchy.svg b/BookGPU/Chapters/chapter1/figures/memory_hierarchy.svg new file mode 100644 index 0000000..b09f295 --- /dev/null +++ b/BookGPU/Chapters/chapter1/figures/memory_hierarchy.svg @@ -0,0 +1,2926 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + Registers + + Registers + + Registers + + Registers + + Registers + + Registers + + Registers + + Registers + + Local var + + Local var + + Local var + + Local var + + Local var + + Local var + + Local var + + Local var + + Shared memory + + + + + + + + + Registers + + Registers + + Registers + + Registers + + Registers + + Registers + + Registers + + Registers + + Local var + + Local var + + Local var + + Local var + + Local var + + Local var + + Local var + + Local var + + Shared memory + + + + + + + + + Registers + + Registers + + Registers + + Registers + + Registers + + Registers + + Registers + + Registers + + Local var + + Local var + + Local var + + Local var + + Local var + + Local var + + Local var + + Local var + + Shared memory + + Global memory + + + + + diff --git a/BookGPU/Chapters/chapter1/figures/nb_cores_CPU_GPU.pdf b/BookGPU/Chapters/chapter1/figures/nb_cores_CPU_GPU.pdf new file mode 100644 index 0000000..977117c Binary files /dev/null and b/BookGPU/Chapters/chapter1/figures/nb_cores_CPU_GPU.pdf differ diff --git a/BookGPU/Chapters/chapter1/figures/nb_cores_CPU_GPU.svg b/BookGPU/Chapters/chapter1/figures/nb_cores_CPU_GPU.svg new file mode 100644 index 0000000..ef5444e --- /dev/null +++ b/BookGPU/Chapters/chapter1/figures/nb_cores_CPU_GPU.svg @@ -0,0 +1,649 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + Core 1 + + Core 2 + CPU + + GPU + + Core 3 + + Core 4 + + Core 5 + + Core 6 + + Core 7 + + Core 8 + + + Multiprocessor 1 + 32 cores + + Multiprocessor 3 + 32 cores + + + + Multiprocessor 2 + 32 cores + + Multiprocessor 4 + 32 cores + + + + + + + + Multiprocessor 15 + 32 cores + + + + Multiprocessor 16 + 32 cores + + + + + + + diff --git a/BookGPU/Chapters/chapter1/figures/scalability.pdf b/BookGPU/Chapters/chapter1/figures/scalability.pdf new file mode 100644 index 0000000..28398a0 Binary files /dev/null and b/BookGPU/Chapters/chapter1/figures/scalability.pdf differ diff --git a/BookGPU/Chapters/chapter1/figures/scalability.svg b/BookGPU/Chapters/chapter1/figures/scalability.svg new file mode 100644 index 0000000..fe91a9c --- /dev/null +++ b/BookGPU/Chapters/chapter1/figures/scalability.svg @@ -0,0 +1,1061 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + Block 1 + + Block 2 + Kernel + + Block 3 + + Block 4 + + Block 5 + + Block 6 + + Block 7 + + Block 8 + + + + Block 1 + + Block 2 + + Block 3 + + Block 4 + + Block 5 + + Block 6 + + Block 7 + + Block 8 + + SM 1 + + SM 2 + + Device + + + SM 1 + + + + SM 2 + + + Device + + + SM 1 + + + + SM 2 + + + + Block 1 + + Block 2 + Block 3 + + Block 4 + + Block 5 + + Block 6 + Block 7 + + Block 8 + + + + + Time + + + diff --git a/BookGPU/Chapters/chapter2/ch2.tex b/BookGPU/Chapters/chapter2/ch2.tex new file mode 100755 index 0000000..b06e9be --- /dev/null +++ b/BookGPU/Chapters/chapter2/ch2.tex @@ -0,0 +1,45 @@ +\chapterauthor{Author Name1}{Affiliation text1} +\chapterauthor{Author Name2}{Affiliation text2} + + +\chapter{Introduction to CUDA} +\label{chapter2} + +\section{Introduction}\label{intro} +In this chapter we give some simple examples on CUDA programming. The goal is +not to provide an exhaustive presentation of all the functionalities of CUDA but +rather giving some basic elements. Of course, readers that do not know CUDA are +invited to read other books that are specialized on CUDA programming. + + +\section{First example} + +This first example is intented to show how to build a very simple example with +CUDA. The goal of this example is to performed the sum of two arrays and +putting the result into a third array. A cuda program consists in a C code +which calls CUDA kernels that are executed on a GPU. + + +As GPUs have their own memory, the first step consists in allocating memory on +the GPU. A call to \texttt{cudaMalloc} allows to allocate memory on the GPU. The +first parameter of this function is a pointer on a memory on the device +(i.e. the GPU). In this example, \texttt{d\_} is added on each variable allocated +on the GPU meaning this variable is on the GPU. The second parameter represents +the size of the allocated variables, this size is in bits. + +In this example, we want to compare the execution time of the additions of two +arrays in CPU and GPU. So for both these operations, a timer is created to +measure the time. CUDA proposes to manipulate timers quick easily. The first +step is to create the timer, then to start it and at the end to stop it. For +each of these operations a dedicated functions is used. + +In order to compute the same sum with a GPU, the first step consits in +transferring the data from the CPU (considered as the host with CUDA) to the GPU +(considered as the device with CUDA). A call to \texttt{cudaMalloc} allows to +copy the content of an array allocated in the host to the device when the fourth +parameter is set to \texttt{cudaMemcpyHostToDevice}. The first parameter of the +function is the destination array, the second is the source array and the third +is the number of elements to copy (exprimed in bytes). + +\putbib[biblio] + diff --git a/aa b/aa deleted file mode 100644 index e69de29..0000000 diff --git a/plan.txt b/plan.txt new file mode 100644 index 0000000..fa82f37 --- /dev/null +++ b/plan.txt @@ -0,0 +1,112 @@ +Chapter 1: Presentation of the GPU architecture +Author: Raphaël Couturier: University of Franche-Comte, France +This chapter will introduce the GPU architecture and the classical model proposed by CUDA. All backgrounds necessary for the remainder of the book will be first presented here. + + +Chapter 2: Simple examples with CUDA +Author: Raphaël Couturier: University of Franche-Comte, France + + +**** Part : image processing + +Chapter 3: Fast kernels for image and signal processing +Authors: Gilles Perrot, Raphaël Couturier and Stéphane Domas: University of Franche-Comte, France, Nicolas Bertaux, University of Aix-Marseille, France +In this chapter, we will introduce and present many kernels that can drastically enhance signal and image processing algorithms. Although these kernels seem to be very common, they have not yet been well described in the literature. + + +Chapter 4: Region Based Algorithm for Large Images Segmentation on GPU +Authors: Gilles Perrot, Raphaël Couturier and Stéphane Domas: University of Franche-Comte, France, Nicolas Bertaux, University of Aix-Marseille, France +In this chapter, we will present an algorithm for region-based active contour techniques (snakes) as they seem to achieve a high level of robustness and fit with a large range of applications. + + + + + +**** Part : Software Development + + +Chapter 5: On the development of high-performance software library for emerging architectures: design and analysis +Authors: Allan P. Engsig-Karup, Bernd Dammann, Jeppe R. Frisvad and Stefan Lemvig: Technical University of Denmark, Denmark +This chapter will present performance portable tuning techniques via a modern parallel programming. Then it will focus on efficient and scalable iterative methods for solution of high-order numerical methods and strategies for efficient implementations on desktop architectures. + + +Chapter 6: Pertinence and development methodologies for GPU and cluster of GPU +Authors: Sylvain Contassot-Vivier: University of Nancy, France, Stéphane Vialle, Supélec, Metz, France +This chapter proposes to draw the main frontiers of the fields of applicability of GPU acceleration as well as development methodologies to obtain efficient codes in classical scientific applications. + + + +Chapter 7: Fast GPU-accelerated desktop application +Authors: Allan P. Engsig-Karup, Bernd Dammann, Jeppe R. Frisvad and Stefan Lemvig: Technical University of Denmark, Denmark +This chapter will present discussions, analysis and highlights of a new massively parallel engineering tool for nonlinear free surface flows intended for both engineering analysis and interactive real-time computing, e.g. for applications in coastal and offshore engineering and first of its kind physics-based ship simulation. + + + + + + +**** Part : Optimization + +Chapter 8: GPU-accelerated Tree-based Exact Optimization Methods +Authors: Imen Chakroun, Nouredine Melab and El-Ghazali Talbi: INRIA Lille, France +This chapter will present the latest techniques and algorithms for solving tree-based exact optimization methods on GPU. + +Chapter 9: Parallel Meta-heuristics for Solving Challenging Problems on GPU Accelerators +Authors: Thé Van Luong, Nouredine Melab and El-Ghazali Talbi: INRIA Lille, France +This chapter will describe parallel metaheuristics for solving complex problems in science and industry. This work is based on local search metaheuristics. + +Chapter 10: Linear programming on a GPU: a study case based on the simplex method and the branch-cut-and bound algorithm +Authors: Paul Albuquerque: HES-SO, Geneva, Switzerland, Xavier Meyer and Bastien Chopard: University of Geneva, Switzerland +This chapter will address the main issues related to programming the simplex method on a GPU. Then it will present how to integrate this GPU-based simplex method in a branch-cut-and-bound framework which will take place between the CPU and the GPU. + +Chapter 11: Performing large scale robust regression on GPUs +Authors: Gleb Beliakov and Gang Li: Deakin University, Melbourne, Australia +In this chapter we will report on the use of GPUs for large scale robust data analysis. Identification of outliers in large multivariate data sets is difficult, because outliers shift regression models in their direction so much that they become undetectable by their residuals. + + + +***** Part : Numerical applications + +Chapter 12: Sparse linear system solvers with the GMRES method on gpu clusters +Authors: Lilia Ziane Khodja, Raphaël Couturier and Jacques Bahi: University of Franche Comte, France +In this chapter, the adaptation of the GMRES method will be presented and several techniques (compression, partitioning …) allowing to increase the scalability of this algorithm for GPU cluster will be described. + + +Chapter 13: Parallel solution of the Obstacle problem on GPU clusters +Authors: Lilia Ziane Khodja, Raphaël Couturier and Jacques Bahi: University of Franche Comte, France, Ming Chau and Pierre Spiteri: University of Toulouse, France +This chapter is devoted to the implementation of the Obstable problem on GPU clusters. This problem is a non linear PDE occurring in financial mathematics (option pricing) and constrained structure mechanics. Synchronous and asynchronous implementations will be analyzed. + +Chapter 14: Complex fluid lattice Boltzmann on GPU clusters +Authors: Kevin Stratford and Alan Gray: University of Edinburg, United Kingdom +This chapter will present a complex fluid lattice Boltzmann application such that it can scale and perform excellently on large-scale GPU clusters. + +Chapter 15: Deployment on GPU of an atomic physics program +Authors: Pierre Fortin, Rachid Habel, Fabienne Jézéquel and Jean-Luc Lamotte: University of Paris 6, France Stan Scott +This chapter will describe the deployment on GPUs of PROP, a program of the 2DRMP suite which models electron collisions with H-like atoms and ions. + +Chapter 16: GPU-based envelop-follow simulation techniques for power converters design +Authors: Sheldon Tan + students: University of California, Riverside, USA +This chapter will introduce a new envelope-following parallel transient analysis method for the general switching power converters. This method exploits the parallelism in the envelope-following method and parallelize the Newton update solving part, which is the most computational expensive, in GPU platforms to boost the simulation performance. + +Chapter 17: Domain decomposition method on GPU architecture +Authors: Frédéric Magoules: Ecole centrale, Paris, France +This chapter will present how GPU architecture can increase performances of domain decomposition methods. + + + + + + + + + +**** Part Other + +Chapter 18: Pseudo Random Number Generator on GPU +Authors: Raphaël Couturier and Christophe Guyeux: University of Franche-Comte, France +This chapter will present some pseudo random number generators which are essential in many applications. We have proposed a generator which has chaotic properties which are proved, whereas it is not the case for other generators. Our generator succeeds to pass all statistical battery series. + + +Chapter 19: Solving large sparse linear systems for integer factorization on GPUs +Authors: Bertil Schmidt and Hao Yu Dang: University of Mainz, Germany +This chapter will present the number field sieve (NFS) which is the current state-of-the-art integer factorization method. It will focus on how GPUs can be used to accelerate this highly time consuming operation.