Erfolgreiche ePaper selbst erstellen
Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.
grafikkarten | Accelerated Computing @ Home<br />
(Quelle: http://www.cs.virginia.edu/kim/docs/ispass11.pdf)<br />
nigung durch massiv-parallele Prozessoren.<br />
Denn bei Weitem nicht<br />
alle Algorithmen lassen sich mir<br />
nichts, dir nichts auf größere Mengen<br />
an Rechenwerken verteilen.<br />
Bei Grafikberechnungen gibt es<br />
mehr als ausreichend Parallelität,<br />
wie bereits angesprochen, und zudem<br />
müssen die berechneten Pixel<br />
nicht mehr von der Grafikkarte zur<br />
CPU zurückgeschickt werden. Im<br />
Bereich allgemeinerer Funkionen<br />
gestaltet sich das schwieriger, und<br />
selbst wenn diese Verteilung durch<br />
trickreiche Rechenschritte möglich<br />
ist, muss sie sich immer noch<br />
rentieren. Denn zwischen CPU und<br />
GPU müssen die Daten hin und her<br />
Geeignet für GPU-Beschleunigung?<br />
re bei sehr schnellen GPUs einen<br />
großen Teil der Gesamtlaufzeit<br />
ausmacht. Je kleiner der Datensatz,<br />
desto krasser wird dieses Missverhältnis,<br />
sodass in einer relativen<br />
Balkendarstellung die eigentliche<br />
Berechnungszeit kaum noch zu<br />
erkennen ist. Im Extremfall SAXPY<br />
lag das Verhältnis von Gesamt zur<br />
Kernellaufzeit bei 43:1 im Durchschnitt<br />
über alle Messgrößen.<br />
Solche Probleme erklären oftmals<br />
auch die Ergebnisse, die wir immer<br />
wieder in sogenannten Showcase-<br />
Benchmarks ermitteln. Bei Nutzung<br />
zusätzlicher Recheneinheiten<br />
via Open CL oder auch Cuda findet<br />
Wir haben hier unterschiedliche Kernel- und Transferzeiten dargestellt. Je nachdem an welcher Stelle eine Beschleunigung<br />
stattfindet, lässt sich durchaus eine Menge Arbeitszeit einsparen (Fall IV).<br />
I<br />
II<br />
Host<br />
Host<br />
geschickt werden, manchmal sogar<br />
mehrfach für eine Berechnung.<br />
Das kostet jedes mal Zeit, sodass<br />
der Entwickler eines Programmes<br />
prüfen muss, ob die gesparte<br />
Rechenzeit durch die zusätzliche<br />
Latenz nicht wieder aufgefressen<br />
wird.<br />
Spezielle Mikro-Benchmarks einzelner,<br />
verbreiteter Algorithmen<br />
wie zum Beispiel SAXPY, SGEMM,<br />
FFT oder Sortierungen und andere<br />
mehr zeigen einem Forschungspapier<br />
(siehe Bild links) zufolge<br />
deutlich, dass der Prozentsatz der<br />
Transferzeiten von Daten von und<br />
zum Grafikprozessor insbesonde-<br />
Fußangel: Rechen- vs. Datenübertragungszeit<br />
Für jede Berechnung auf der GPU müssen dieser die entsprechenden Daten zur Verfügung gestellt werden. Diese<br />
Mikro-Benchmarks zeigen, dass manchmal der Datentransfer zigfach länger dauert als die eigentliche Berechnung.<br />
Kernelzeit<br />
Kernelzeit<br />
Ergebnis<br />
Ergebnis<br />
per se eine Beschleunigung statt,<br />
die Rechenzeit verkürzt sich gegenüber<br />
der CPU-Version, aber schnellere<br />
Grafikchips werden durch<br />
einen großen Anteil der Transferzeiten<br />
oder mangelnde Parallelisierungsmöglichkeiten<br />
bei niedrigem<br />
Datenaufkommen daran gehindert,<br />
ihre Leistung voll auszuspielen. Unser<br />
frischer Open-CL-Benchmark<br />
auf der nächsten Seite zeigt das Problem<br />
– ebenso wie in der Vergangenheit<br />
bereits Winzip oder frühe<br />
Versionen des inzwischen eingestellten<br />
Vreveal-Videokonverters<br />
(zunächst Cuda, später Open CL).<br />
Mindestanforderung:<br />
Software<br />
Aus dem oben Gesagten lassen sich<br />
mehrere Grundregeln ableiten, die<br />
eine Software erfüllen muss, damit<br />
sie sinnvoll beschleunigt werden<br />
kann. Zunächst einmal muss sich<br />
die Aufgabe des Programms in einen<br />
Algorithmus pressen lassen,<br />
den auch eine GPU ausführen kann.<br />
Zudem muss ausreichend Daten-<br />
Parallelität vorhanden sein, sodass<br />
auch Tausende von Recheneinheiten<br />
einer GPU genutzt werden<br />
können. Damit die Transferzeiten,<br />
also das möglicherweise mehrfach<br />
nötige Hin-und-her-Schieben der<br />
Daten, die Gewinne in der reinen<br />
Rechenzeit nicht auffressen, muss<br />
der Anteil Letzterer an der Gesamtlaufzeit<br />
möglichst groß sein. Hier<br />
schlägt auch das Problem zu, dass<br />
in manchen Aufgabenstellungen<br />
zwar eine effiziente Arbeit von<br />
GPUs möglich wäre, die Größe der<br />
Datenfelder für Heimanwender<br />
aber schlicht nicht ausreichend ist,<br />
um die Transferlatenz auszugleichen.<br />
Im professionellen Bereich<br />
dagegen, zum Beispiel in der Forschung<br />
oder auf Supercomputern,<br />
die grundsätzlich gleichen Kernel<br />
so lange rechnen, lohnt es sich<br />
eben doch, solche Berechnungen<br />
auf eine GPU auszulagern.<br />
III<br />
IV<br />
Host<br />
Host<br />
Kernel -<br />
zeit<br />
Ergebnis<br />
Zeit<br />
Kernelzeit<br />
Einsparung<br />
Ergebnis<br />
Einsparung<br />
Mindestanforderung:<br />
<strong>Hardware</strong><br />
Wenn man denn ein Programm<br />
gefunden hat, welches sinnvoll<br />
durch zusätzliche Prozessorkraft<br />
beschleunigt werden kann, muss<br />
noch ein geeigneter Rechenknecht<br />
vorhanden sein. In fast allen Fällen<br />
handelt es sich dabei um einen Grafikprozessor,<br />
der sich durch seine<br />
parallel arbeitenden Rechenwerke<br />
besonders für diese Aufgabe eignet<br />
46<br />
<strong>PC</strong> <strong>Games</strong> <strong>Hardware</strong> | 08/14<br />
www.pcgameshardware.de