GPU vs CPU-Leistung für gängige algorithmen
Ich bin daran interessiert zu wissen, ob eine gemeinsame algorithmen (Sortieren, suchen, Graphen, etc.) haben portiert wurde OpenCL (oder jede GPU-Sprache), und wie die Leistung im Vergleich zu den gleichen Algorithmus, der von der CPU ausgeführt. Ich bin besonders daran interessiert, die Ergebnisse (zahlen).
Dank!
Schreibe einen Kommentar
Du musst angemeldet sein, um einen Kommentar abzugeben.
Gibt es schon ein paar Proben dieser Art von Sache, die auf der NVidia-website. Bedenken Sie, dass einige Dinge wie das Sortieren brauchen Sie spezielle algorithmen für die effiziente Parallelität und vielleicht nicht ganz so leistungsfähig wie ein nicht-Gewinde-Algorithmus auf einem single-core.
GPUs sind hoch spezialisierte hardware entwickelt, um eine kleine Gruppe von Aufgaben sehr gut und hoch parallelisiert. Dies ist im Grunde Arithmetik (besonders single-precision floating point math obwohl neuere GPUs sehr gut mit double precision). Als solche sind Sie nur geeignet, um bestimmte algorithmen. Ich bin mir nicht sicher, ob die Sortierung passt, die Kategorie (im Allgemeinen Fall zumindest).
Häufiger Beispiele sind Preise von Finanzinstrumenten, die große Mengen von matrix-Mathematik und sogar besiegen Verschlüsselung (durch brute force). That being said, ich habe Schnelle parallele GPU-Sortierung mit einem hybrid-Algorithmus.
Eine weitere, Häufig zitierte Beispiel ist läuft SETI@HOME auf einer Nvidia-GPU aber es ist äpfel mit Birnen vergleichen. Die Einheiten der Arbeit für die GPUs sind anders (und sehr begrenzt) im Vergleich zu dem, was CPUs normalerweise tun.
Haben Sie einen Blick auf Schub:
VORSICHTIG SEIN, SEHR VORSICHTIG bei performance-zahlen zitiert, die für GPGPU. Viele Leute mögen die post wirklich beeindruckende zahlen, die nicht berücksichtigen, die übertragung benötigte Zeit, um die Eingabe von Daten von der CPU auf die GPU und die output-Daten zurück, beide gehen über einen PCIe-Engpass.
Bild Größenänderung müssen, werden Häufig auf vielen Webseiten, akzeptieren, Bild hochlädt.
Ändern der Größe einer 2600ish x 2000ish 2MB jpeg-Bild (bis 512x512) nahm um 23,5 Millisekunden in C# mit absolut niedrigsten Qualität Optionen und nearest neighbour-sampling. Verwendet wurde die Funktion
graphics.DrawImage()basiert ein. CPU-Auslastung war auch %21.5.Immer "rgba byte-array" - Extraktion auf C# - Seite und senden Sie es an GPU-und Größenänderung in GPU und erste Ergebnisse zurück in ein Bild nahm von 6,3 Millisekunden und CPU-Auslastung war %12.7. Dies wurde mit einem %55 billiger gpu mit nur 320 Kerne.
Nur 3.73 X speedup Multiplikator.
Der limitierende Faktor dabei war, senden die extrahierten 20MB rgb-Daten (jpeg ist nur 2MB!) auf GPU. Das zeitaufwändige Teil war fast %90 Gesamtzeit, einschließlich C# - Seite byte-array Extraktion! Also ich gues es wäre etwa 30X Beschleunigung, zumindest wenn die Extraktion Teil kann man in GPU auch.
30X ist nicht schlecht.
Dann könnte man die pipeline die Extraktion Schicht mit dem Größenänderungs-Schicht zu verbergen Speicher kopieren Wartezeit, um noch mehr Geschwindigkeit! Dies könnte 40X-50X.
Dann erhöhen Sie die Qualität der Probenahme(wie z.B. Bikubisch, anstatt zum nächsten Nachbarn), haben Sie noch mehr Vorteile in der GPU-Seite. Hinzufügen eines 5x5-GAUSS-filter hat nur 0,77 milliseonds. CPU würde sich einige höhere Zeit oben auf, dass, vor allem, wenn die Gauß-Parameter benötigt werden, sind anders als C#.Net Umsetzung.
Selbst wenn Sie sind nicht zufrieden mit dem speedup-Verhältnis, Verschiebung auf " GPU " und einer "freien Kern" auf der CPU ist noch vorteilhaft für drängen mehr Arbeit für den server.
Nun fügen Sie die Tatsache, dass die GPU-power Verbrauch(30W vs 125W in diesem Beispiel), ist es viel vorteilhafter.
CPU könnte kaum gewinnen in
benchmarks, wenn beide Seiten laufen auf optimiert-codes, und Sie können immer noch auslagern Hälfte des arrays auf der GPU und schneller fertig mit CPU+GPU in der gleichen Zeit.
GPU ist nicht für non-uniform funktioniert. GPUs haben eine Tiefe pipelines, so stehen Sie nach einem stall, da der Verzweigung, dauert zu lange. Auch SIMD-Typ hardware zwingt, es zu tun, gleiche Sache auf alle workitems auf. Wenn ein workitem gilt eine andere Sache als die, die Gruppe, verliert er die Spur und fügt Blasen ganz SIMD pipeline oder einfach anderen warten auf sync-Punkt. So brancing wirkt sich sowohl auf die Tiefe und Breite pipeline Bereiche und machen es sogar noch langsamer als die CPU in einem perfekt chaotischen Zuständen.