CSC 5001– High Performance Systems

Read the program.

Compile it thanks to nvcc compiler.

Then launch the program using the buttons "play" on the left of the code blocks.

In the first section named "Raw code", you can read a CUDA code written without any precautions. Run the code and observe the result. You may not be agree with the result of 2 + 2 = 0.

In the second section, we introduce how debugging this code with the debugger cuda-gdb.
For this purpose, you need to :

• compile adding the options"-g -G" so that debugging symbols are included. For this purpose, you need to save your code in a file by beginning it with "%%writefile file_name.cu" (instead of "%%cu") and compile it explicitly in a separate cell. Note that in a notebook, shell commands start with ! .
• write in a file the sequence of instructions to be followed by the debugger. Indeed, cuda-gdb is interactive (you are expected to type commands as you go along), but running programs in the Colab environnement is not. Typical commands would go like this:
  1. set the debugger up to check lots of possible errors:
     1. memory checks : memcheck on,
     2. stop in case of API failures : api_failures stop,
     3. stop on exceptions : catch throw,
  2. run the program (possibly with command line options) : r option1 option2 ,
  3. show the kernel call stack (GPU) : bt,
  4. print all local variables : info locals,
  5. switch to the host thread : thread 1
  6. and show the host program call stack (CPU) : bt.
• call the debugger with your program and execute the commands from debug_instructions.txt. If your program terminates fine, cuda-gdb will complain that there is no stack (since the program finished)

After running all cells of the "Debugging" notebook section, you should get an exception and lots of information. There is an illegal address detected in line 5 of add.cu, which is in kernel add. You may identify and fix the problem by hand but it should have been caught by the cuda errors management, object of the next section.

Note : If you do use printf to debug, be sure to flush the buffer by adding a line break at the end. This applies to any C program. Example: printf("Works up to here\n"); . Nevertheless, the interface between the Jupyter Notebook and the executed program is a little fragile. So if your program crashes, there might not be ANY output at all, even if you have printf everywhere.

In the third section "Code with error management", we instrument the code to check the return error code of calls to CUDA. The program should fail now (and no longer crash and give a wrong result).
As CUDA calls on GPU fail with silent error, it is required to retrieve and check the error code of all of them. Since kernel calls do not have a return value, first of all, you can check for invalid launch argument with the error code of cudaPeekAtLastError(); and then, you can check if errors occurred during the kernel execution thanks to the error code of cudaDeviceSynchronize, that forces the kernel completion. Note that most of the time, a developper will use the cudaMemcpy as synchronization primitive (the cudaDeviceSynchronize would be in duplicate then). In this cas, the cudaMemcpy call can return either errors which occurred during the kernel execution or those from the memory copy itself.

In the last section, we have outsourced the error management code so that you can use it more easily in the rest of your exercises.
Notice that the first line of the cell has changed. Now, each cell is saved as a file and the compilation and execution are launched explicitly in two additional cells with a shell command. Note that in a notebook, shell commands start with ! .

Last but not least, it remains you to fix the problem.

lien vers l'exercice

Ecrivez le code effectuant le calcul de SAXPY en vous basant sur ce squelette (Makefile). Commencez par une version sans thread, puis une version avec threads en utilisant 256 threads.

Dans un premier temps, écrivez une version utilisant uniquement la mémoire globale en utilisant des blocks deux dimensions de taille 32. Pour vous aider, vous pouvez vous appuyer sur le squelette suivant (squelette, (Makefile), qui initialise les matrices. Comparez le temps d'exécution avec une version openMP que vous devez écrire.

Ecrivez l'algorithme par tuile puis comparer les temps d'exécution des deux implémentations (avec et sans tuile). Comparez également le temps d'exécution lorsque TILE_WIDTH=16 et TILE_WIDTH=32.

Comparez le temps d'exécution du code que vous avez écrit à la question 2 au temps d'exécution fourni ici qui utilise cuBLAS. Notez que pour compiler ce code, vous devez ajouter -lcublas à la compilation.