Intel bald auch mit OpenCL

[thysol]

@thysol

also bei folding@home ist meineswissens auch der opencl code auf nvidia optimiert... (bzw. der cuda code auf opencl umgebaut)

du hast in sofern recht, das der compiler, den amd bereitstellt, nicht so der hammer ist. aber das liegt nicht an den 5d shadern
ich kenn das phänomen, dass mein ion im laptop z.T. meinen cl code schneller ausführen kann als meine 4870 (gut, dazu kommt noch, dass die hd 4xxx nicht den kompletten opencl spezifikationen entsprechen).

Wenn ein 5D Shader einen Thread bearbeiten muss dann muss der einzelne Thread im optimalsten Fall in der Lage sein 5 verschiedene dinge parallel zu erledigen. Ein Beispiel waere das Arbeiten mit 5D Vektoren. Bei normaler Programmierung wird meistens nur eine SPU der 5 in einem Shader benutzt.

 

[FloW^^]

das problem soll recht gut mit calpp bzw cal++ umgangen werden können, da calpp den code dahingehend optimiert, dass die 5d-shader besser ausgelastet werden und zusätzlich noch die bit-align-fähigkeit der 5000er radeons genutzt wird (ohne manuelles rumpfuschen per IL).

hat halt den nachteil, dass es dann kein reines opencl mehr is, sondern n paar spezielle anpassungen an ati vonnöten sind.
aber der code sollte dann trotzdem noch ohne nachteile für nvidia laufen.
allein die bit-align-fähigkeit verleiht den 5000er radeons nochmal +90% speed. (~+35% für 4000er radeons)
wenn dann noch die 5d-shader maximal ausgelastet werden, würde eine GTX480 selbst gegen eine 5770er Radeon das nachsehen haben.

nvidia hat halt den vorteil, dass cuda-/opencl-code ohne anpassungen auf die hardware automatisch fast mit maximalem speed läuft.
sehr coderfreundlich...
dafür schlägt ati dann mit angepasstem code nvidia um längen.
sehr anwenderfreundlich...

bleibt halt jedem überlassen, was er lieber mag

ich als anwender finde ati besser

 

[Sheeep]

Wenn ein 5D Shader einen Thread bearbeiten muss dann muss der einzelne Thread im optimalsten Fall in der Lage sein 5 verschiedene dinge parallel zu erledigen. Ein Beispiel waere das Arbeiten mit 5D Vektoren. Bei normaler Programmierung wird meistens nur eine SPU der 5 in einem Shader benutzt.

Du brauchst sowieso hoch parallelen Code für GPUs, sonst machst keinen sinn.
Wenn du eine Worksize von 10.000 und mehr hast, sollte es eigentlich kein problem sein, damit 1600 SIMDs aufzulasten. das heißt die kannst das super in eine VLIW, wie sie bei ati's 5d shadern verwendet wird schreiben. das heißt, die 5d shader sind grundsätlich nicht das problem.

wie FloW^^ auch schreibt, es ist möglich den amd code anzupassen, damit der schneller läuft. das heißt, nicht die 5d shader sind das problem, sondern der compiler.


EDIT:
@thysol
Ich seh grad, du hast einen OpenCL benchmark geschrieben...
Verglich die ergebnisse mal mit einen mergesort der floats sortiert...
wenn du relativ viele floating point operationen hast, kommt trotz des compilers die brachiale rohleistung der evergreen (und auch der RV 770) zum vorschein...

es hängt also auch mit der aufgabe zusammen. aber generell würde ich für gpgpu auch einen fermi nehmen, nicht nur weil er meist deutlich schneller ist, sondern auch wegen der ecc rams, und weil cuda (noch) deutlich weiter ist als opencl...

EDIT2:

*ironieon* nochbesser, nimm mal einen geforce-fermi und dp^^. *ironieoff*

 

[Skysnake]

EDIT:
@thysol
Ich seh grad, du hast einen OpenCL benchmark geschrieben...
Verglich die ergebnisse mal mit einen mergesort der floats sortiert...
wenn du relativ viele floating point operationen hast, kommt trotz des compilers die brachiale rohleistung der evergreen (und auch der RV 770) zum vorschein...

es hängt also auch mit der aufgabe zusammen. aber generell würde ich für gpgpu auch einen fermi nehmen, nicht nur weil er meist deutlich schneller ist, sondern auch wegen der ecc rams, und weil cuda (noch) deutlich weiter ist als opencl...

Die 5800 hat halt ne verdammt hohe DP Leistung, die halt im Gegensatz zu der der GTX400er eben nicht beschnitten ist. Daher auch der große Vorteil der 5800er

Der ECC-RAM macht die Karte aber nicht schneller, eher sogar das Gegenteil, da ECC Ram langsamer ist, und wenn ich mich recht erinnere die Daten rest einen Takt später anliegen als ohne ECC. Der einzigste Vorteil ist halt, das du 1 Bit-Fehler korregieren und 2 Bit-Fehler zumindest nachweisen kannst (wenn ich mich recht erinnere mit den 2 Bit-Fehler). Das halt schon nen Vorteil wenn du 2 Wochen an was rumgerechnet hast und dann zerhaut dir nen 1Bit-Fehler die Rechnung. Das eigentliche Problem ist allerdings, das du dir ohne ECC nicht sicher sein kannst, ob du nicht eventuell auch nen Bit-Fehler hast, diesen aber garnicht merkst, sondern einfach nen falsches Ergebnis hast. Da hilft ohne ECC nur alles zweimal rechnen, und genau DANN stinkt halt jede Ati ab, weil die doppelte Rechenleistung haben sie halt nicht (wobei glaub mit SP hauts sogar fast hin) und selbst wenn, brauchen sie unterm Strich dann doch mehr Strom als die Tesla Karten, was auf Dauer dann halt einfach auch den Preisvorteil aufbraucht. Von den höheren Kosten für die Infrastruktur ganz zu schweigen.

EDIT2:

*ironieon* nochbesser, nimm mal einen geforce-fermi und dp^^. *ironieoff*

[/quote]
hab ich ja oben angesprochen

 

[Sheeep]

@Skysnake
das mit den ECC war auch genau so gemeint, wie dus beschrieben hast.
ist aber ein grund, für ne simulation oder so, ne fermi zu nehmen, oder?

Und die radeons gehen auch bei sp je nach eingesetzten algorithmus ohne ende ab...
was bei 2,7 (5870) vs 1.3 (gtx480) tflops nicht weiter verwunderlich ist.

trotzdem ist die 5870 selten tatsächlich doppelt so schnell wie die gtx480, bei bruteforce algorithmen kommt das manchmal hin... (davon abgesehen sind das ja theoretische werte)

EDIT:
(um mal nicht zuweit vom topic wegzukommen)
letztendlich bleibt zu hoffen, dass intel "aktiver einstieg" opencl vorrantreibt, und dass AMD mit der Southern/Northern Island sein gpu-computering verbessert...


EDIT2:
was mich noch interessieren würde: ist directcompute code auf der evergreen z.T. auch deutlich langsamer als auf der GF100?

 

[Skysnake]

Naja, man muss halt sagen das SDK von nVidia ist wohl deutlich besser als das von Ati. Die haben da einfach deutlich mehr Geld in die Hand genommen und die Entwickler stärker unterstützt.

Ich denke das ist auch so ziemlich der größte Schwachpunkt an Ati, wobei sie dort stark aufholen. Allein das erst for kurzem die FFT implementiert wurden ist eigentlich ne Schande, das brauchste in wissenschaftlichen Anwendungen eigentlich am laufenden Band, und wie wichtig gute Bibliotheken sind sieht man an Fortran. Hab mit den IT´lern in der Uni quatschen können und gefragt warum die noch immer Fortran verwenden, kam als Antwort: Fortran hat halt verdammt effiziente Bilbiotheken, die hochgradig optimiert sind und oft/teils in assembler geschrieben wurden um die maximale Leistung rauszuholen.

Hier seh ich auch ne RIESEN Chance für die Entwickler. Denn Intel wird Geld in die Hand nehmen, und nicht zu wenig um Leistungsstarke SDK´s zu entwickeln die wirklich das Letzte rausholen aus der Technik, und da OpenCL ziemlich portabel ist profitieren davon auch die anderen (zumal Intel ja verboten wurde das sie in ihrem Compiler andere Hersteller absichtlich schlechter hinstellen, da nicht alle Tuningoptionen verwendet werden).

Also ich freu mich richtig auf das was von Intel in diesem Bereich kommt.

 

[Sheeep]

@Skysnake

ich hab das mal getestet mit dem intel c compiler auf einen phenom...
klar, sse4.1 /4.2 kann amd sowieso nicht,
aber sse3 geht ohne probleme... die einschränkung konnte man umgehen.

ich hab x verschiedene compiler ausprobiert, borland, gnu, microsoft 2005 bis 2010...

keiner erzeugt auch nur annäherd so schnellen binärcode wie der von intel... auch auf einem amd prozessor und selbst dann, wenn du die auto-sse3 einschrängungen nicht umgehst...

deshalb tut die sperren dem user nicht wirklich weh, nur den benchmarks...

außerdem ist sie ja verboten worden, wie du schon sagtest.
aber wer das kontrollieren will

aber bei offener software ist es doch schwieriger, so etwas zu verstecken...
außerdem kann amd ja optimierungen von intel übernehmen...

 

[Skysnake]

@Skysnake

ich hab das mal getestet mit dem intel c compiler auf einen phenom...
klar, sse4.1 /4.2 kann amd sowieso nicht,
aber sse3 geht ohne probleme... die einschränkung konnte man umgehen.

ich hab x verschiedene compiler ausprobiert, borland, gnu, microsoft 2005 bis 2010...

keiner erzeugt auch nur annäherd so schnellen binärcode wie der von intel... auch auf einem amd prozessor und selbst dann, wenn du die auto-sse3 einschrängungen nicht umgehst...

Ich hab nichts darüber gesagt, wie der generierte Code für AMD´s im Vergleich zu anderen compilern ist

deshalb tut die sperren dem user nicht wirklich weh, nur den benchmarks...

Und genau das ist halt so ne Sache, wodurch Intel besser da steht in Benchmarks als es eigentlich sein sollte, und dadurch sich halt auch wieder besser verkauft. Ist halt so nen zweischneidiges Schwert, irgendwie kann man es ja auch verstehen, das man für nen Produkt für das man selbst wohl recht viel Geld in die Hand nimmt, auch eigentlich nicht die Konkurrenz supporten will, die selbiges halt nicht tut (mir ist zumindest nichts vergleichbares von AMD bekannt)

außerdem ist sie ja verboten worden, wie du schon sagtest.
aber wer das kontrollieren will

aber bei offener software ist es doch schwieriger, so etwas zu verstecken...
außerdem kann amd ja optimierungen von intel übernehmen...

Und genau da seh ich den Vorteil ^^ man kann sich Intels Erfahrung zu nutze machen

So noch ne kurze Randbemerkung. Ich find zwar Intel und nVidia mit ihrer Preispolitik etc nicht so knalle, aber man muss eins eingestehen, was Softwareentwicklung angeht in richtung compiler und Bibliotheken für Entwickler sind sie halt deutlich engagierter als AMD/Ati, wobei man sagen muss das diese in den letzten Monaten auch ziemlich dazu gelernt haben und da deutlich mehr machen, ich hoffe die gute Entwicklung in diesem Punkt hält da an!

Es ist halt einfach schade, das nen gutes Hardwareprodukt durch solche Sachen abgewertet wird

Anmerken muss man aber auch, das die PR-Abteilung bei denen auch einfach schläft -.- wenn man sich mal auf der AMD Seite umschaut findet man so viele krasse nützliche Tools das gibts garnet, hab z.B. vorher nen Tool gefunden um die Speicherauslastung der GPU anzuzeigen. Eigentlich hies es ja immer das geht auf ATI´s nicht, sondern nur auf nVidia. Da sieht man wieder mal das die ihr Produkt einfach schlecht verkaufen (aus PR sicht)

 

[Sheeep]

immerhin hat amd begonnen, sehr viele entwicklertools opensource zu machen oder opensourcetools zu nutzen, auch das ist eine chance.

und wenn intel bei opencl mitmacht ist das echt eine riesenchance...

 

[Sheeep]

das problem soll recht gut mit calpp bzw cal++ umgangen werden können, da calpp den code dahingehend optimiert, dass die 5d-shader besser ausgelastet werden und zusätzlich noch die bit-align-fähigkeit der 5000er radeons genutzt wird (ohne manuelles rumpfuschen per IL).

hat halt den nachteil, dass es dann kein reines opencl mehr is, sondern n paar spezielle anpassungen an ati vonnöten sind.
aber der code sollte dann trotzdem noch ohne nachteile für nvidia laufen.
allein die bit-align-fähigkeit verleiht den 5000er radeons nochmal +90% speed. (~+35% für 4000er radeons)
wenn dann noch die 5d-shader maximal ausgelastet werden, würde eine GTX480 selbst gegen eine 5770er Radeon das nachsehen haben.

Der CAL ist doch AMD eigen, wie willt du das auf nvidia laufen lassen?
und CAL ist ja auch nur der Layer um low-level-languages (ATI IL) auf einem "Streamprozessor" zu starten...
mir ist nicht ganz klar, wie du ein opencl programm dahingehend optimieren willt, dass es 5d shader besser nutzt, ohne IL zu verwenden.
Wenn das geht, würde mich die Optimierung echt interessieren... kannst das mal bitte genauer beschreiben...