thysol
BIOS-Overclocker(in)
Wieso sollte parallele Anwendungen schreiben auf einer GPU leichter sein als auf der CPU? Zumal der gleiche OpenCL "parallele" Kernel sowohl auf der CPU als auch auf der GPU laufen kann.
Winzip 16.5 mit OpenCL: Radeon-Beschleunigung im Test - Messbar mehr Leistung beim Zippen durch Grafikkarten?
- Ersteller PCGH-Redaktion
- Erstellt am
Wieso sollte parallele Anwendungen schreiben auf einer GPU leichter sein als auf der CPU? Zumal der gleiche OpenCL "parallele" Kernel sowohl auf der CPU als auch auf der GPU laufen kann.
Sehr schön... also ist nur die "maximum"-Einstellung nicht sonderlich sinnvoll und die Implementierung ist doch besser als anfangs gedacht. 
Arbeite mit OpenCL und du wirst es verstehen
PCGH_Carsten
Ex-Redakteur
Ja, nur frage ich mich, ob bei doppelter CPU-Last nicht sowieso auch eine 50%-Reduktion der Kompressionszeit drin wäre - zumal Radeon offenbar gleich Radeon ist, zumindest ab DX11 (mal sehen, ob ich noch irgendwo eine HD 5450 auftreiben kann, die ist nochmal halb so schnell wie die 6450.Sehr schön... also ist nur die "maximum"-Einstellung nicht sonderlich sinnvoll und die Implementierung ist doch besser als anfangs gedacht.
Killer-Tipp für Nvidia-User bis Winzip 17.0 kommt: Einfach eine 30-€-HD5450/6450 dazustecken und darauf dann OpenCL zum Zippen nutzen.
Also wenn ich hier die Zeit von WinRar mit 3:15 zu der von WinZip mit 12sek. in Relation setze, dann käme eine Steigerung um den Faktor 16 heraus und das ist sicherlich kein schlechtes Ergebnis.
Ein Leistungsplus um den Faktor 16 nur durch den Einsatz der Rechenkraft einer GPU ist nicht zu verachten.
Wenn dies nur konsequenter Weise auch in anderen Programmen umgesetzt würde, hätte man entlich mal wieder einen enormen Leistungssprung erzielt, so wie etwas die SSD´s bei den Festplatten.
Man stelle sich nur mal vor dies würde bei arbeits intensiver Software wie Video-/ und Bildbearbeitung genauso gut funktionieren, was dort an Zeitersparnis drin wäre, gerade im profesionellen Bereich. Oder bei uns in der Firma (kleiner Mittelständler) bei der Berechnung der CAD-Daten für die Maschinen, was damit eingespart werden könnte.
Da sag ich mal nicht schlecht Herr Specht.
Gruß
Ein Leistungsplus um den Faktor 16 nur durch den Einsatz der Rechenkraft einer GPU ist nicht zu verachten.
Wenn dies nur konsequenter Weise auch in anderen Programmen umgesetzt würde, hätte man entlich mal wieder einen enormen Leistungssprung erzielt, so wie etwas die SSD´s bei den Festplatten.
Man stelle sich nur mal vor dies würde bei arbeits intensiver Software wie Video-/ und Bildbearbeitung genauso gut funktionieren, was dort an Zeitersparnis drin wäre, gerade im profesionellen Bereich. Oder bei uns in der Firma (kleiner Mittelständler) bei der Berechnung der CAD-Daten für die Maschinen, was damit eingespart werden könnte.
Da sag ich mal nicht schlecht Herr Specht.
Gruß
Strauchdieb
Kabelverknoter(in)
Ich bin zu doof und sehe keinen link. Da steht nur einmal Produktbeschreibung und ansonsten finde ich nichts. Auf der Winzip Seite gibts nur 16.0 
doenertier84
PC-Selbstbauer(in)
Lol...auch wenn s 'nur' 30 € sind - da ich zippen nicht hauptberuflich mache werde ich wohl notgedrungen 3-4 mal im Monat anstatt 10 sek halt 30 sek warten ...die Pinkelpause übernimmt die Grafikkarte ja noch nicht 
Kondar
Volt-Modder(in)
interessant ja aber nützlich?
WinZip habe ich als sehr schlechten Packer im Gedächtnis.
WinRar, WinAce oder 7z waren bei deutlich besser was die Kompression angeht.
Abgesehen davon habe ich das Gefühl das man nur noch zum entpacken ein "Packer" braucht.
Ich archiviere schon lange nichts mehr gepackt.
WinZip habe ich als sehr schlechten Packer im Gedächtnis.
WinRar, WinAce oder 7z waren bei deutlich besser was die Kompression angeht.
Abgesehen davon habe ich das Gefühl das man nur noch zum entpacken ein "Packer" braucht.
Ich archiviere schon lange nichts mehr gepackt.
PCGH_Carsten
Ex-Redakteur
Und? Schonmal draufgeklickt?Ich bin zu doof und sehe keinen link. Da steht nur einmal Produktbeschreibung und ansonsten finde ich nichts. Auf der Winzip Seite gibts nur 16.0
thysol
BIOS-Overclocker(in)
Arbeite mit OpenCL und du wirst es verstehen
Das tue ich.
Mann muss nur 1 oder 2 Linien Code ändern das der selbe OpenCL Kernel auf der CPU ausgeführt wird. Daher wüsste ich jetzt gerne wieso du erzählst das es schwerer wäre parallelen Code auf der CPU zu programmieren?
Strauchdieb
Kabelverknoter(in)
Habe es nachher über Suchmaschine gefunden.
Meine Testergebnisse sagen Folgendes:
Für ein Archiv mit ca. 50 % Kompression und auf einer HD 6950
Zip spart bei Open CL ca. 38 % Zeit (Maximum)
Zipx spart bei Open CL ca. 34 % Zeit (best)
Zip ist ca. 10 % größer als zipx auf dieser Einstellung, benötigt per Open CL aber nur 23 Sek statt 2 Min 16 Sek ohne Open CL und mit zipx
7zip ist auf schnellster Einstellung noch 10 % kleiner als WinZip mit Maximum, benötigt aber 1 Min statt s.o. 23 Sek
7zip auf normaler Einstellung benötigt 1 Min 11 Sek, ist aber schon 20 % kleiner als Winzip mit Maximum
Wenn man 7zip und Winzip mit zipx vergleicht, ist Winzip unterlegen. (1 Min 11 Sek auf schnell bei 7Zip vs. 1 Min 24 Sek auf Winzip zipx und best und open cl; 7zip ist zudem noch 10 % kleiner)
Fazit:
WinZip mit Open CL eignet sich hervorragend dazu große Datenmengen SCHNELL und grob zu verpacken, z.B. für schnelle Backups. Das gelingt z.T. in einem Drittel der Zeit ggü. der schnellsten 7Zip Einstellung. Im direkten Kompressionsvergleich gegen 7zip taugt es wenig, wenn man über die Einstellung "schnellste" bei 7Zip hinweg geht. Dann hängt WinZip auch zeitlich mit Open CL hoffnungslos hinterher.
Um es auf die Spitze zu treiben. Das gleiche Archiv kann man auch mit Einstellung "schnellste" und Zip und Open CL erstellen. Dann steht 7Zip mit schnellster Einstellung mit 1 Minute gegen 14 Sekunden in WinZip. Das Archiv ist zwar deutlich kleiner (310 vs. 356 MB) aber auch sehr deutlich langsamer erstellt (Faktor 4 langsamer). Jeder der häufig 50 GB Daten für ein Backup verpacken muss, weiß was ich meine.
Meine Testergebnisse sagen Folgendes:
Für ein Archiv mit ca. 50 % Kompression und auf einer HD 6950
Zip spart bei Open CL ca. 38 % Zeit (Maximum)
Zipx spart bei Open CL ca. 34 % Zeit (best)
Zip ist ca. 10 % größer als zipx auf dieser Einstellung, benötigt per Open CL aber nur 23 Sek statt 2 Min 16 Sek ohne Open CL und mit zipx
7zip ist auf schnellster Einstellung noch 10 % kleiner als WinZip mit Maximum, benötigt aber 1 Min statt s.o. 23 Sek
7zip auf normaler Einstellung benötigt 1 Min 11 Sek, ist aber schon 20 % kleiner als Winzip mit Maximum
Wenn man 7zip und Winzip mit zipx vergleicht, ist Winzip unterlegen. (1 Min 11 Sek auf schnell bei 7Zip vs. 1 Min 24 Sek auf Winzip zipx und best und open cl; 7zip ist zudem noch 10 % kleiner)
Fazit:
WinZip mit Open CL eignet sich hervorragend dazu große Datenmengen SCHNELL und grob zu verpacken, z.B. für schnelle Backups. Das gelingt z.T. in einem Drittel der Zeit ggü. der schnellsten 7Zip Einstellung. Im direkten Kompressionsvergleich gegen 7zip taugt es wenig, wenn man über die Einstellung "schnellste" bei 7Zip hinweg geht. Dann hängt WinZip auch zeitlich mit Open CL hoffnungslos hinterher.
Um es auf die Spitze zu treiben. Das gleiche Archiv kann man auch mit Einstellung "schnellste" und Zip und Open CL erstellen. Dann steht 7Zip mit schnellster Einstellung mit 1 Minute gegen 14 Sekunden in WinZip. Das Archiv ist zwar deutlich kleiner (310 vs. 356 MB) aber auch sehr deutlich langsamer erstellt (Faktor 4 langsamer). Jeder der häufig 50 GB Daten für ein Backup verpacken muss, weiß was ich meine.
Zuletzt bearbeitet:
Und zack - schon ist das ganze Bremborium um OpenCL in WinZip eigentlich erledigt.
Wenn man schon heutzutage noch nen Packer verwendet gehts ja in der Hauptsache darum möglichst viel Speicher zu sparen, dieser Grund dürfte wohl die "Packzeit" an Wichtigkeit deutlich übertreffen.
Es hilft mir ja nicht wenn ich 30 Sekunden schneller ein 800MB ZIP-Archiv erhalte das dann nicht auf meinen Datenträger passt oder 5 Minuten länger zum Upload benötigt wo ich ansonsten ein 700MB 7Z-Archiv bekomme.
@thysol: Das ist einfach falsch. Die Aufgaben werden von den Shadern erledigt, welche darauf ausgelegt sind Dinge parallel zu erledigen.
Eine 7970 hat z.B. 2048 Shader und du wirst diesen Shader sicherlich nicht jedem einzelnen eine Aufgabe zuordnen, dass kann die Grafikkarte schon gut selber aufteilen. Beim der CPU sieht das schon anders aus. Du hast Threads, die man genauer zuordnen kann und dann erfolgt eine Abarbeitung - mal grob gesagt. Wenn du ein ganz kurzen, stink normalen Code kompilierst (cout in einer while schleife oder ähnlich), dann wirst du definitiv nur einen Kern ausnutzen können.
@Carsten: Das hängt ja nicht an dem Datenbus bzw. der Schnittstelle. Ob OpenGL/CL, man kann das ganze mal gut verdeutlichen:
@Beide: Bei OpenGL gibt/gab es die Fixed-Function-Pipeline - veraltet aber wird noch oft genug genutzt.
Würde man nun einfach nur ein Viereck rendern (per glBegin oder auch VertexArray - keine Displaylist oder VBO), so würde man bei jedem Frame die Informationen zur Grafikkarte schicken.
Was würde man sehen: Ein CPU Kern wird komplett ausgelastet sein (oder der CPU teilt es auf die Kerne auf -> Bei 4 Kernen wäre die CPU 25% ausgelastet) und die Grafikkarte hätte nichts zu tun. So eine Szene rendert ihr dann mit ein paarhundert frames aber das juckt die Karte nicht, ist ja nur ein Viereck aber der Aufwand für die CPU ist wesentlich höher.
Wer mir das nicht glaubt kann es gerne probieren. Simple OpenGL Programme, wo nur was billiges gerendert wird und auf der Fixed-Function-Pipeline beruht gibt es genügend und es wird dieser Effekt eintreten. Exakt so verhält es sich auch mit WinZip.
Die 7970 hat wie gesagt 2048 Shader zur verfügung.
Die Dateien waren ca. 7 GB groß und das komprimieren dauerte 168 - also knapp 3 Minuten.
Heißt, dass jeder Shader ungefähr 0,021 MB die Sekunde verarbeiten muss und das unter der Vorraussetzung, dass wirklich alles von der GPU übernommen wird (was ich allerdings nicht glaube). Nicht gerade viel oder?
thysol
BIOS-Overclocker(in)
So einfach ist das nicht. Wenn mann einfache Daten-parallele Dinge auf der GPU macht dann ist das super einfach und mann überlässt der GPU die aufteilung. Sobald mann aber Task-parallele Dinge macht sehe ich da wirklich keinen Unterschied zu CPUs. Zumal mann OpenCL Code auch auf der CPU ausführen kann.
Dein Beispiel Problem kann mann problemlos parallelisieren.
CPU Threads kann mann genauso gut zuordnen wie GPU-Threads auf Compute Units. Das die GPU innerhalb der Compute Units selber aufteilt ist natürlich klar, aber das macht die nur wirlich gut bei Daten-parallelen Kram.
Wieso sagst du ich wäre da falsch? Wie soll das auf der GPU einfacher sein wenn mann den gleichen Code auf der CPU ausführen kann? Selbst wenn mann CPU Multi-threading in einer klassischen Programmiersprache macht dann ist da kein grosser Unterschied zu GPU OpenCL.
OpenCL Kernel = CPU Funktion/Methode
Einziger Unterschied ist das OpenCL automatisch für dich die Daten aufteilt, beim CPU Multi-threading muss mann das manuell machen.
PCGH_Carsten
Ex-Redakteur
Exakt dieses dämliche Batching-Problem versuchen Compute-orientierte APIs wie OpenCL und DirectCompute ja zu verhindern. Sonst könnte man weiterhin Pixelquads rendern und Daten als Texture-Arrays repräsentieren lassen. Soweit mir bekannt, wurde erst mit DX11 Multithreaded-Rendering eingeführt - dass OpenGL es auch kann, glaube ich nicht, weiß es aber nicht 100% - sodass nun mehrere CPU-Kerne an der Render-Queue mitwirken können. Davor - bei deinem Beispiel mit billigen OpenGL-Programmen - war es, wie du sagst auf einen Kern beschränkt.
Damit haben wir es hier jedoch nicht zu tun, da die Auslastung grob von 25% (~zwei virtuelle Kerne) auf 50% (vier virtuelle Kerne) springt.
Skysnake
Lötkolbengott/-göttin
Carsten, ihr habt bei den APUs wohl eine geringere Performance mit der Nutzung von OpenCL, weil die Speicherbandbreite die ganze Sache limitiert.
Wenn man OpenCL nutzt, muss man aber erst mal die Sachen hin und her kopieren, und da das hier auch übern den RAM erfolgen muss, wiegt dass den Performancevorteil der schnelleren Berechnung wieder auf.
Taktet mal einfach den RAM hoch, dann sollte die APU auch schneller werden
Btw. Die Beschleunigung auf der dezidierten GPU kommt auch nur daher, dass man eben die dicke Speicherbandbreite auf der GPU hat. Damit kann man den Overhead aus dem Kopiervorgang wieder eleminieren.
Mir scheint das Ganze aber noch nicht so wirklich 100% ausgereift zu sein.
Wenn man OpenCL nutzt, muss man aber erst mal die Sachen hin und her kopieren, und da das hier auch übern den RAM erfolgen muss, wiegt dass den Performancevorteil der schnelleren Berechnung wieder auf.
Taktet mal einfach den RAM hoch, dann sollte die APU auch schneller werden
Btw. Die Beschleunigung auf der dezidierten GPU kommt auch nur daher, dass man eben die dicke Speicherbandbreite auf der GPU hat. Damit kann man den Overhead aus dem Kopiervorgang wieder eleminieren.
Mir scheint das Ganze aber noch nicht so wirklich 100% ausgereift zu sein.
PCGH_Carsten
Ex-Redakteur
mironicus,
Wie im Test angemerkt, haben wir es mit einem E-450 gegengecheckt.
Skysnake,
Ja, bei einer APU dürfte wirklich die seltsam umständliche Verbindung zwischen Grafik und CPU begrenzen. Ist aber nicht unsere Schuld, wenn hier Performance verschenkt wird - wir haben weder die Anwendung programmiert noch die Designentscheidungen für die APU getroffen.
Wie im Test angemerkt, haben wir es mit einem E-450 gegengecheckt.
Skysnake,
Ja, bei einer APU dürfte wirklich die seltsam umständliche Verbindung zwischen Grafik und CPU begrenzen. Ist aber nicht unsere Schuld, wenn hier Performance verschenkt wird - wir haben weder die Anwendung programmiert noch die Designentscheidungen für die APU getroffen.
boxleitnerb
Freizeitschrauber(in)
Wieso kommt ihr auf ca. 50%, hier im Thread wird aber von Faktor 4 bzw. Faktor 16 berichtet??
Skysnake
Lötkolbengott/-göttin
Das habe ich auch nicht behauptet
Es zeigt halt nur, das man nicht alles für jedes Problem verwenden kann. Manchmal macht es einfach keinen Sinn. Könnt ihr es aber vielleicht noch mit den SBs testen? Die haben ja einen Cache, und können auch besser mit dem CPU-Part kommunizieren. Eventuell bleibt da noch ein Plus am Ende übrig.
Die sollen einfach endlich mal den globalen Adressraum für GPU und CPU über OpenCL bringen, da profitieren gerade solche Anwendungen massiv von -.-
Ähnliche Themen
