03.07.2014 Aufrufe

PC Games Hardware Magazin Ebay-Schnäppchen (Vorschau)

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

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!