16 November 2011

On November 16th I gave a two hour work-shop on GPU Programming as part of the Research Computing Course Week organized by the Univeristy of Oslo.

The workshop consisted of three parts:

  1. Introduction to GPU Programming [pdf]
    • Abstractions for GPU Programming
    • GPU Hardware
  2. Beginner and intermediate CUDA [pdf]
    • Hello World Example
    • CUDA Memories
    • Two-pass Gaussian Blur with Shared Memory
  3. GPU Algorithm Design and Lifecycle Management [pdf]
    • The 13 Dwarves
    • Testing and Reporting GPU Algorithms
During the break we also had a discussion on the design of USITs new cluster which will contain some GPU nodes.

3 November 2011

Talk: GPU Algorithm Design


On November 2nd  I gave a completely new talk at FFI on Algorithm Design for GPUs. 


I will present some of this material in the coming NOTUR course week (November 14.-17.).

8 September 2011

Formal Code Reviews

On September 8th I did a short presentation on code reviews for the SINTEF SCORE Project.
[pdf]

26 May 2011

GPU Computing - Supercomputing Everywhere

I gave the following talk at the NOTUR2011 annual meeting on the 26th of May 2011.

Abstract: Modern GPUs (Graphics Processing Units) are now fully programmable many-core processors that offer unprecedented levels of floating point performance. They brings terascale computing to the laptop, and petascale computing to clusters. We present an overview of the current state of GPU computing, starting with a brief overview of the existing hardware architectures, and motivating why many-core computing is here to stay. Furthermore, we describe the various approaches to GPU programming, focusing mostly on CUDA and OpenCL. These languages expose the SPMD (Single-Process, Multiple-Data) programming model, making it relatively easy to port existing scientific algorithms to many-core processors and achieving an order of magnitude speedup. 
[pdf]

19 May 2011

Memory Management and Object Lifetimes

On May 19th I did a presentation for the SCORE project on memory management and object lifetimes in C++ for the SCORE project.
[pdf]

25 August 2010

Running 64-bit OpenMP Debug Builds compiled with Visual Studio 2008 SP1

Scenario: 
You have a recent (Vista/Win7) 64-bit operating system from Microsoft, with Visual Studio 2008 Professional SP1 installed (VS2008). Furthermore you have installed the .NET Framework 3.5 for 64-bit compilers. You now want to compile and debug your OpenMP application as a 64-bit binary to get access to all that juicy RAM for your application.

(Please note: Visual Studio Express does not officially support OpenMP.)

In theory this should be as easy as right-clicking on your project and selecting the Debug configuration on the X64 platform. Unfortunately, when you start this application, either in the shell or via Ctrl-F5 you get the following extremely helpful message:

The application has failed to start because its side-by-side configuration is in correct. Please see the application event log or use the command-line sxstrace.exe tool for more detail.


Since you are a highly trained professional you open the Event Viewer application and look at the log:


Activation context generation failed for "c:\Users\jse\Documents\Visual Studio 2008\Projects\OpenMP 64-bit Debug test\x64\Debug\OpenMP 64-bit Debug test.exe". Dependent Assembly Microsoft.VC90.DebugOpenMP,processorArchitecture="amd64",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8" could not be found. Please use sxstrace.exe for detailed diagnosis.


At this point, you start Googling and several hours later you end up with the following insight:


Solution part 1 - the missing DLL:
The first problem is that the X64 OpenMP Debug DLL (vcomp90d.dll) is not correctly installed in %windir%\winsxs. However, the dll is hopefully located in redist\Debug_NonRedist\amd64.
This is presumably a bug in the Visual Studio installer, but Microsoft does not seem to eager to fix it.


The file can however not reliably just be copied to the winsxs directory, since we need a hashcode and a manifest file, so to get it properly installed we fire up the venerable Visual Studio IDE and create a new project. As project type choose Other Project Types->Setup Project and give a suitable name to it.


Once the project is opened right click on it, and choose Add->Merge Module, you should now get a dialog box where you can add  Microsoft_VC90_DebugOpenMP_x86_x64.msm to the project. 
Next you build your solution, and invoke the installer you just created.


Verify that you now have a  directory roughly  named %windir%\winsxs\amd64_microsoft.vc90.debugopenmp_1fc8b3b9a1e18e3b_9.0.30729.1_none_239c2888a12512d1. The DLL should now be properly installed.


Solution part 2 - linking with the right library version:
If now you now try to start the application, you end up with the exact same error message as we initially got. The event log tells us this is because the application is looking for version 9.0.21022.8 of the DLL, but the one we just installed is version 9.0.30728.1. The first version is the one that was included in the VS2008 retail package, while the latter is from the service pack. 


The default behavior of VS2008 is to:


...default behavior of applications compiled with Visual C++ 2008 and later releases. When you compile an application, it is bound to the original release version of libraries available. This is true even if you have a later release installed on your computer.


Luckily this policy is easy to fix, just add _BIND_TO_CURRENT_OPENMP_VERSION=1 preprocessor definitions of your project. (Configuration Properties->C/C++->Preprocessor).

(This second step can also be solved by adding a version redirect in %windir%\winsxs\manifest

That's it! You should now be able to run your 64-bit OpenMP Debug builds both from VS2008 and from the shell. You can now go back to actually getting your application working!

Thanks to Microsoft for really making the life of developers so challenging!

References:

31 July 2010

Rittrapport: Sølvstufossrittet

Sølvstufossrittet ved Sarpsborg er et av de mer teknisk krevende maratonrittene i Norge, og det burde således passe meg ganske bra. 
Det var likevel litt tilfeldig at jeg stilte opp, men for min del var det eneste mulighet til å få kjørt et maratonritt før Ultrabirken (UB). Rittet skulle derfor brukes til både å teste dekk, spiseregime samt løpstaktikk. Det som skulle testes ut var:
  • Raven 2.2 dekk på vått og teknisk føre. 
  • På Lillehamer-Oslo spiste jeg hver halvtime (gel eller bar). Nå skulle jeg forsøke det samme i terrengritt. Jevn spising blir helt essensiellt på UB, hvor jeg fort skal være ute i over åtte timer.
  • Fylling av flaske underveis. Jeg startet bare med en flaske, og planen var å drikke så mye jeg ville, og heller fylle flasken på en matstasjon.
  • Jeg mistenker at jeg ofte starter litt for rolig i ritt, og kjører meg jevnt og trutt oppover. Denne gangen skulle jeg forsøke å henge med teten fra start, og se hva som skjedde.
Kjøringen fra Oslo gikk unna på en drøy time, og jeg fikk en grei oppvarming. Eliten startet for seg, og så var det vår tur. Uvanlig lite knuffing om startposisjoner gjorde at jeg enkelt fikk stilt meg i 2. startledd. En kilometer med masterstart bak motorsykkel skaper stor strekk i feltet, men jeg sitter med i tetpuljen, pulsen er dog i høyeste laget og etter tyve minutter skjønner jeg at dette går for fort. 

Jeg slipper puljen og får pulsen litt ned. Dessverre medfører dette at neste tog med ryttere suser forbi og jeg har brent av for mye krutt til at jeg orker å legge meg på hjul.

I første terrengparti er det mange ryttere foran meg, flere er engstelige på det våte føret og det blir mye kaos. Jeg klarer å kjøre meg opp noen plasser, og ligger for meg selv når jeg kommer ut på grusen igjen. De neste par timene kjører jeg i fra i terrenget og blir tatt igjen på grusen, men det er stort sett den samme gruppen jeg kjører med. Etter to timer er det ett lang asfasltstrekke og jeg møter virkelig veggen. Gruppa drar ifra, det er motvind, jeg har vondt i ryggen - tvilen om hvorfor jeg driver med dette kommer sigende. Likevel ER jo dette det morsomste jeg vet, og jeg SKAL jobbe meg til mål.

De neste to timene ser jeg knapt en eneste rytter, de som er raskere enn meg er foran, de som er tregere er bak. Jeg tråkker og spiser jevnt og trutt.  Jeg er så ensom at jeg lurer på om jeg har kjørt feil, men jeg passerer blide og flinke løypevakter jevnt og trutt. Jeg passerer skiltet med 10 km igjen, og i en sugende grusmotbakke kommer det to ryttere snikende, den første rekker å passere meg før vi svinger inn på et langt stiparti. Dette tenner meg til en siste kraftanstrengelse, jeg girer opp på storeskiva og suser ifra. Slutten består en lang og bratt grusklatringen og mye flytsti. Midtveis i bakken ser jeg de to ta kraftig innpå, og på slutten har førstemann nesten hjulet mitt, men så er det sti igjen, og jeg skjønner jeg har taket på ham. Litt dårlig merking gjør at jeg kjører noen hundre meter for langt på slutten, men dette endrer ikke resultatlisten og koster meg bare et snaut minutt. 

Det var virkelig godt å komme til mål, og det var både brus og burgere til deltagerne. At regnet først begynte etter at jeg var kommet til mål var også en bonus! Men grådig sliten, det var jeg.

Jeg ender på en 7. plass i klassen, med sluttid 4:32:23. Fornøyd med plasseringen, men ikke helt fornøyd med egen innsats.


Oppsummering av testing:
  • Raven fungerte supert, selv på vått føre. Så lenge det ikke er for mye stein i løypa er dette nå mitt førstevalg til ritt, uansett hvor vått det er. 
  • Jeg fikk gjennomført spiseplanen min, men det krevde mye disiplin denne gangen også.
  • Jeg fylte flasken en gang underveis, og de hadde klare et litersbeger på matstasjonen så gikk veldig rask å fylle. Håper de er like flinke på UB.
  • Den harde starten var ikke noen suksess. Det ble veldig tungt etter to timer, og jeg er ganske sikker på at det ville gått fortere totalt sett med en litt roligere start. Jeg slapp også så tidlig at jeg ikke fikk glede av god plassering i første terrengparti.