Effizientes Lösen linearer Gleichungssysteme über GF(2) - CDC ...

2.4. CUDA 15
realisieren, da eine Zeitmessung mit Hilfe von CPU- oder GPU- Timern statt
finden kann. Die Vor- und Nachteile beider Möglichkeiten sollen im Folgenden
dargestellt werden.
Soll mit Hilfe des CPU-Timers ermittelt werden, wie lange ein Kernel
braucht, um seine Berechnungen durchzuführen, so kommt es vor, dass dieser
lediglich die Zeit misst, die für den Aufruf der CUDA API benötigt wird.
Dies liegt darin begründet, dass es sich bei Funktionen, wie Kernelaufrufe
und Kopiervorgänge zwischen Speichern, um asynchrone Prozesse handeln
kann. In diesem Fall wird die Kontrolle an den CPU Thread zurückgegeben
bevor die Prozesse ihre Berechnungen beendet haben. Wenn die korrekte Zeit
für die komplette Abarbeitung ermittelt werden soll muss zuerst der CPU
Thread mit dem GPU Thread synchronisiert werden. In diesem Fall wird der
CPU Thread bis zur Beendigung der Berechnungen blockiert. Bei den resultierenden
Werten sollte jedoch bedacht werden, dass die Synchronisation
von CPU und GPU ein Drosseln in der GPU-Pipeline hervorrufen und so die
Performanz negativ beeinflussen kann.
Um die benötigte Zeit eines Streams zu ermitteln eignet sich nur der synchrone
Defaultstream (Siehe auch Kapitel 2.3.3). Bei allen Anderen können
Zeiten für den Aufruf von weiteren Streams in den Messungen enthalten sein.
Im Defaultstream wird das Event erst ausgelöst, wenn alle Tasks und Kommandos
von allen vorangegangenen Streams beendet wurden.
Die CUDA Event API unterstützt Aufrufe, die Events erzeugen und zerstören
können. Diese ermöglichen es, eine genaue Zeitanalyse der Kernel mit Hilfe
von GPU-Timern durchzuführen. Spezielle Funktionen messen dafür die
Millisekunden zwischen dem Eintreten der Events. Ein weiterer Vorteil der
GPU Timer ist, dass sie mit der GPU-Clock arbeiten und somit betriebssystemunabhängig
sind.
Synchronisationsfunktionen
Es gibt verschiedene Funktionen mit deren Hilfe Threads synchronisiert werden
können. Mit threadfence() ist es möglich die weitere Abarbeitung zu
blockieren, bis alle globalen Speicherzugriffe für alle Threads auf einem Device
und alle Speicherzugriffe von allen Threads des selben Blocks auf den
Shared Memory abgeschlossen und die Ergebnisse sichtbar sind. Notwendig
wird dies, wenn Threads Daten lesen sollen, die von anderen erst kurz zuvor