Günstigste OpenCL kompatible Grafikkarte?

[vimar]

Welche ist die günstigste opencl graka derzeit? weiss das jemand hier?

 

[daybyter]

Ich weiss nicht, ob es _die_ günstigste ist, aber z.B. eine Radeon 5450 gibt es unter 30,- . Bringt aber auch keine grosse Leistung. Du musst dann halt auch Leistung / Stromverbrauch in Betracht ziehen.

 

[ATI-Freak]

Ich weiss nicht, ob es _die_ günstigste ist, aber z.B. eine Radeon 5450 gibt es unter 30,- . Bringt aber auch keine grosse Leistung. Du musst dann halt auch Leistung / Stromverbrauch in Betracht ziehen.

Sowas tut weh zu lesen. Habe mir vor ungefähr 5 Jahren eine "ATI/AMD Radeon HD4550" für damals noch 65€ geholt, und nun lese ich das die nächste Modelreihe nicht mal mehr die hälfte kostet.
Vielleicht liegt es auch nur an der Sonderform : CGAX-4552 (Club3D Radeon HD4550 LowProfile active-cooling), wobei diese selbst heute noch 40€ kostet.

Leistungsfähigkeit dieser Karte : Potal2 auf ULTRA bei 720p mit über 60FPS

 

[vimar]

naja ich habe derzeit eine geforce 6800 drin, und scheinbar wird da kein cuda/opencl(aparapi) unterstützt.

 

[vanny]

Ich hab mir mal ne GTX550 mit nem 1GB geholt und will nienie wieder ne billigkarte.
[EDIT]Naja ich musste mir auch noch ein neues Netzteil zulegen, das alte hatte es innerhalb von 2 Stunden zerlegt
Ich finde trozdem, das sich eine etwas hochwertigere Anschaffung lohnt.[/EDIT]

 

[daybyter]

Wenn Du was eigenes implementieren willst, läuft BrookGPU,GLSL und dieser Nvidia Compiler auf der 6800. Aber Du hast halt keine ints usw. 5450 hab ich hier,ist aber für bitcoin z.B.viel zu lahm.

 

[faetzminator]

Sowas tut weh zu lesen. Habe mir vor ungefähr 5 Jahren eine "ATI/AMD Radeon HD4550" für damals noch 65€ geholt, und nun lese ich das die nächste Modelreihe nicht mal mehr die hälfte kostet.

Was erwartest du?
Stell dir mal ein Auto vor. Da hast du gleich den Wertverlust von zig %, wenn du das erste Mal einsteigst und losfährst.
Ganz abgesehen davon, dass man einen Computer kauft, der die nächsten 2, 3, 4 Jahre überleben soll. Da kauft man nunmal mehr oder weniger aktuelle Teile, die ein Jahr später halb so teuer wären. Macht aber für mich überhaupt keinen Sinn, jedes Mal, wenn ich all paar Jahre wieder 1000 Euro in die Hand nehmen, rumzuflennen, wie schnell alles kein Wert mehr hat. Ich kenne Leute, die surfen heute noch auf einer ~10-12j Kiste. Wem es genügt...

 

[ATI-Freak]

Was erwartest du?
Stell dir mal ein Auto vor. Da hast du gleich den Wertverlust von zig %, wenn du das erste Mal einsteigst und losfährst.
Ganz abgesehen davon, dass man einen Computer kauft, der die nächsten 2, 3, 4 Jahre überleben soll. Da kauft man nunmal mehr oder weniger aktuelle Teile, die ein Jahr später halb so teuer wären. Macht aber für mich überhaupt keinen Sinn, jedes Mal, wenn ich all paar Jahre wieder 1000 Euro in die Hand nehmen, rumzuflennen, wie schnell alles kein Wert mehr hat. Ich kenne Leute, die surfen heute noch auf einer ~10-12j Kiste. Wem es genügt...

Ich bin mit meiner HD4550 ja auch noch voll zu frieden denn sie leistet ja das was ich von ihr verlange (Portal2). Was mich aber eher verwundert hat war das eben mein Model gerade mal 20€ billiger geworden ist, aber die 5450 um einiges mehr, und das über einen Zeitraum von 5 Jahren. Wie gesagt : kann auch wirklich an der Sonderform "low-profile" liegen. Solche Karten sind ja immer etwas seltener und teurer.

Und alle paar Jahre 1000€ für ein aktuelles System? Von dem was man über hat muss es reichen, aber was man sich alles erträumt wird für einige nur schwer bis gar nicht erreichbar sein. Wobei auch Systeme über 2000€ morgen technisch schon wieder veraltet sind.

 

[faetzminator]

Und alle paar Jahre 1000€ für ein aktuelles System? Von dem was man über hat muss es reichen, aber was man sich alles erträumt [...]

Wenn man alle 5 Jahre 1000 Euro für einen Computer ausgibt, dann hat man also ~17 Euro im Monat dafür ausgegeben. Andererseits sagt niemand was, wenn sich alle diese Applefreaks jedes Jahr das neuste iPhone zu einem überteuerten Preis kaufen. Vielleicht bin ich auch etwas gebrannt, die Schweiz hat weltweit die grösste Verbreitung der iProdukte...

Wobei auch Systeme über 2000€ morgen technisch schon wieder veraltet sind.

Man muss eben nur das zweitneuste und zweitbeste kaufen, dann zahlt man statt 2000 nur noch 1000.

 

[Marco13]

Ich hatte mir, kurz nachdem sie rauskam, die GeForce 8800 geholt, weil das eine der ersten war die CUDA vernünftig unterstützt hat (auch nicht die erste, aber zu diesem Zeitpunkt zumindest der Spec nach die aktuellste Version). Für jcuda.org - Java bindings for CUDA und jocl.org - Java bindings for OpenCL reicht sie, aber werde wohl bald updaten "müssen": Erstens, weil sie nicht die neueste "CUDA Compute Capability" hat, und ich damit einige Funktionen nicht nutzen und testen kann, und zweitens, weil ich ZWEI Grafikkarten will.

Sicher, "high end" ist immer unverhältnismäßig teurer als das zweitbeste. Aber wenn man eine Karte (mit akuellster Compute Capability) mit 1000 GFLOPS für 300€ oder eine mit 1100 GFLOPS für 500€ kaufen kann, tut's ja die billigere.

 

[vimar]

ich bin zwar bis dato noch nicht genügend informiert, für GPU berechnung habe ich diese bachelorarbeit (60 seiten) gelesen:

http://sv-en.bplaced.de/wordpress/wp-content/uploads/2011/12/Bachelorarbeit.pdf

und mich anschliessend für aparapi entschieden.
bis dato denke ich bei 3,3 Mio 128 dim Vektoren bei denen ich "nur" die euklidischen distanzen berechne dass es dort dennoch schneller geht. aber vermutlich muss ich da erstmal auf die schnauze fallen.

echt blöd dass meine gf 240 gt die wohl opencl unterstützt nicht auf meinem board funktioniert sondern nur die lächerliche gf 6800...

 

[daybyter]

Wenn Dir nur ein PCIe Adapter fehlt, dann musst Du mal im bitcointalk Forum gucken. Da werden immer wieder mal PCI -> PCIe Adapter günstig angeboten, weil die Leute da ja auch gerne mal 4 PCIe Karten im Rechner brauchen.

 

[Marco13]

Wie schon in http://www.java-forum.org/codeschni...jcuda-java-bindings-fuer-cuda.html#post898132 geschrieben: Wenn das ganze auf der GPU laufen soll, wird erstmal der Datentransfer zum Bottleneck. Es könnte trotzdem noch schneller sein, das muss man ausprobieren, aber sicher kein Vergleich zu rechenintensiven, echt datenparallelen Aufgaben, wo man durch die GPU durchaus mal zwei Größenordnungen schneller werden kann.
Aparapi an sich dürfte aber "auf jeden Fall" was bringen. Einerseits, weil man gezwungen ist, das ganze SO low-level (auf plain Arrays) zu implementieren, dass die meisten Overheads wegfallen und andererseits weil es im Zweifelsfall auf einem 4-core ja dann mit ~4 Threads parallel ausgeführt werden kann.

 

[daybyter]

Ich hab gerade so überlegt, wie man das günstig implementieren könnte.

In Brook hätte man die 128-dim Vektoren wohl erstmal in 32 float4 Variablen zerlegt. Dann evtl. 64 Eingabestreams deklariert (2 Vektoren), falls der Compiler da mitmacht. Und dann halt subtrahiert. Aber Brook unterstützt wohl keine Hardware-Multiplikation der Vektor-Elemente.

CGC kann das wohl besser, wie man hier sieht:

The Cg Tutorial - Chapter 3. Parameters, Textures, and Expressions

(Tabelle 3-4).

 

[Marco13]

Es ist nicht klar, welche Distanzen berechnet werden sollen. 3,3 Mio * 3,3 Mio wären ziemlich viele... Aber die Rechnung an sich ist eben nicht sehr aufwändig.

 

[daybyter]

Aber durch die Menge der Vektoren wird es halt wiederum sehr wichtig sein, bei der Berechnung die Hardware möglichst optimal auszunutzen. Und da hätte es mich halt mal interessiert, wie man die Operationen so zerlegt, dass die GPU möglichst optimal ausgenutzt wird. Also dass man im Idealfall halt z.B. Vertex- und Fragmentshader schön ausgelastet hält (so man noch keine unified Shader hat).

 

[Marco13]

Hmja, ich kenn' mich jetzt mit Shadern (allgemein, aber speziell für "GP"-Berechnungen) nicht wirklich aus - das alles irgendwie auf Texturen abbilden zu müssen, war ja der Krampf, der irgendwann zu den Sprachen wie CUDA und OpenCL geführt hat. Und da würde man das wiederum ziemlich pragmatisch so hinschreiben, wie man es auch in Java machen würde, wenn es auf rohen 1D-Arrays implementieren würde. Ein bißchen Hintergrundwissen zur Architektur und Arbeitsweise, wären nicht verkehrt, speziell könnte ich mir vorstellen dass man bei 128D-Vektoren was mit shared memory machen könnte, aber vermutlich würde sich auch das nicht wirklich lohnen, weil ... ja nur einmal ein Batzen floats gelesen, dann eine triviale Rechnung durchgeführt, und wieder ein Batzen floats geschrieben werden muss. Sooo viel Spielraum gibt's da wohl nicht...

 

[daybyter]

Es ist aber doch z.B. ein grosser Unterschied, ob ich 4x eine Float-Variable subtrahiere, oder eben 1x eine Float4 Variable.

 

[Marco13]

Ja, das kann schon einen (u.U. deutlichen) Unterschied machen. (BTW: Das Tutorial, wo dieser Schritt in Image Convolution Using OpenCL? - A Step-by-Step Tutorial (inklusive Performancevergleich) beschrieben wird, ist IMHO sehr gut, und zeigt einige wichtige Aspekte von OpenCL). Wie groß der Unterschied im konkreten Fall ist, ist schwer vorherzusagen, und hängt ggf. auch wieder von Architektur und Compiler ab. Man kann wohl davon ausgehen, dass float4 schneller wäre. Aber das teuere ist i.a. eher "der Zugriff auf den global memory an sich" (ca. 600 Takte latenz) - das Alignment der Daten ist bei OpenCL eh immer groß (128 bytes?) so dass das vielleicht gar nicht sooo ins Gewicht fallen würde. Müßte man mal ausprobieren.

 

[Marco13]

@vimar: Hab' mal angefangen, einen ""Microbenchmark" zu basteln. Beschreib' mal genauer, was da berechnet werden soll: Paarweise Distanzen zwischen X Vektoren mit Dimension Y, oder....?!

 

[JohannisderKaeufer]

@Marco, der vimar versucht, wenn man die Posts aus der jüngsten Vergangenheit berücksichtigt, einen
K-Means Algorithmus umzusetzen.

Die Daten bestehen aus ca. 3Mio Vektoren mit der Dimension 128.

Dafür versucht er nun die 1000 besten 128-Dimensionalen-Centroiden zu finden.


Wenn dir K-Means nichts sagt:
Es werden hier 1000 zufällige Vektoren initial gewählt. Auch Centroiden genannt.

Nun berechnet man für jeden der 3Mio. Datensätze die euklidsche Distanz zu jedem dieser 1000 Vektoren und ordnet den Datensatz dem Vektor mit der kürzesten Distanz zu.

Hat man alle Datensätze einmal zugeordnet, dann wird aus allen einem Centroiden zugeordneten Vektoren die arithmetischen Mittel berechnet. Dies sind dann die Centroiden für den nächsten Durchgang, die die initial gewählten Vektoren ersetzen.

Dies macht man dann solange, bis sich die Centroiden nicht mehr großartig ändern.

 

[Marco13]

Ohja, KMeans hab' ich schonmal gehört Das ist dann schon eine andere Größenordnung als so ein Mini-Benchmark, also, da muss man sich ja nicht nur überlegen, wie man Distanzen berechnet, sondern auch wie der Ablauf "außen rum" am besten gestaltet werden kann. Aber ... mal schauen...

 

[vimar]

ok kurze zusammenfassung:

geht um meine bachelorarbeit:
content based image retrieval query by example, trainingsmenge entspricht derzeitigen 700 bildern, in jedem bild werden durch verschiedene algorithmen (sift, colorsift, surf) "spezielle punkte" in bildern entdeckt (ca 200-300 pixel im bild) die durch die algorithmen in 128 bzw 64 dimensionalen vektoren beschrieben werden. so komme ich auf 3,3 Mio Vektoren z.b. bei dem algo colorsift.

in dem sinne anschliessend clustern mit
k-Means-Algorithmus ? Wikipedia

wers nicht kennt, ich will diese ganzen vektoren in bereiche aufteilen, kann mir aussuchen wieviele bereiche, z.b. 500. zufällig werden am anfang dann 500 von diesen 3,3 Mio Vektoren ausgewählt(->Centroiden). nun werden von allen 3,3 Mio Vektoren die distanzen zu jedem Centroid berechnet (manhatten R^1 distanz). der centroid der den kürzesten abstand zu dem vektor hat, dem wird der vektor zugeteilt. irgendwann sind nun diese 3,3 Mio vektoren verteilt auf die centroiden, anschliessend wird pro bereich der mittelwertvektor berechnet und anschliessend abgeglichen mit dem (noch) derzeitigen centroiden des bereichs. für den fall dass es in einem oder mehreren bereichen dazu kommt (und dass ist so gut wie immer der fall) dass der errechnete mittelwertvektor nicht mit dem centroiden des bereichs übereinstimmt, wird der mittelwertvektor zum neuen centroiden, die ganzen bereiche werden aufgelöst, und die rechnung beginnt von neuem, also wieder 3,3 Mio Vektoren mit den nun neuen "centroiden" die vorher die mittelwertvektoren waren - also erneut distanznen berechnen - ist fast ne endlosschleife. irgendwann (nach 30 Stunden bei der datenmenge)
entsprechen die mittelwertvektoren in allen bereichen auf den centroiden in den bereichen und der algo ist abgeschlossen.

ich arbeite mit threads, hab nen quadcore, alle kerne laufen auf höchsttouren, hab den algo sogar schon so angepasst dass wenn weniger als 15 % der bereiche nur verändert wurden dass der algo "fertig ist" usw - und dennoch: 30 Std sind viel wenn man bedenkt dass es vllt mit der graka deutlichst schneller geht!

P.S.: hab seite 2 nicht gesehn, JohannisderKaeufer hats auf den punkt gebracht.

 

[Marco13]

Hmja, es gibt da ja etliche Optimierungen/Erweiterungen dazu. Den "trivialen" K-Means würde ich vielleicht bei Gelegenheit rein Interessehalber mit Java/OpenCL implementieren, um mal den Vergleich zu sehen. Websuchen nach "cuda OR opencl kmeans" oder so liefern ja viele Ergebnnisse, d.h. man kann davon ausgehen, dass das, was man da so ad hoc hinschreibt ziemlich "schlecht" ist, im Vergleich zu allem, was es schon gibt, aber ... zur Übung kann sowas ja nicht schaden.