GPGPU

mocad_tom

Admiral Special
Mitglied seit
17.06.2004
Beiträge
1.234
Renomée
52
Nvidia kann mit der Fermi C2050 einen Linpack-Score von 328 GFLOPS für sich verbuchen:
http://www.brightsideofnews.com/news/2010/5/19/cpu-beware-nvidia-tesla-linpack-numbers-analyzed.aspx

Mit dem Erscheinen des ATI Stream SDK v2.2 wird die Berechnung in Double Precision eingführt:
http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1278322413
Voraussetzung sind Karten mit HD5500 und neuer.
Damit müsste sich dann auch Linpack auf ATI-Karten bringen lassen.

Ich bin gespannt auf die Scores von ATI.
Als nächsten logischen Schritt bräuchte man jetzt noch ECC(sowohl Tesla als auch ATI haben kein ECC).

Aber die Werte der Tesla-Karten hören sich schon gut an:
Tesla C2050 328GFLOPS
Intel Core i7 980 Hexa-Core in 32nm 66GFLOPS

LINPACK ist keine Zahl wo man die Rechenpower aller Units einfach mal so aufaddiert - er bietet wenigstens ein quentchen Orientierung im Zahlendschungel.

Beim Cluster für die Goethe Universität können also die verbauten GPUs auch mit zum LINPACK-Score beitragen:
http://www.planet3dnow.de/vbulletin/showthread.php?t=381413
Allerdings muss man die angegebenen Werte noch mit etwas Abstand betrachten - ich glaube da hat man Äpfel, Melonen und Weintrauben zusammengezählt.

Mühsam ernährt sich das Eichhörnchen, wir kommen in die Nähe.

Grüße,
Tom
 
Mhm 5500 und DP?
Afaik schaltet AMD erst ab der 5800er Serie DP frei.
 
Beziehst du dich mit dieser Aussage auf dies?
http://ixbtlabs.com/articles3/video/spravka-r8xx-p7.html

All features of the GPU remain the same. Except for one important feature that has to do with GPU computations. As you may remember, the same units are used for 64-bit computations of double precision in previous GPUs, but the computing rate drops. However, according to official specifications published on the AMD's website, the RV840 Juniper does not support double precision calculations.

Hier steht aber im Kleingedruckten:
http://www.planet3dnow.de/photoplog/file.php?n=10164&w=o

AMD 7xx GPUs remain at OpenCL 1.0. Future OpenCL specification revision and/or optional extension support targets AMD Evergreen GPUs and above.

Was mir ein wenig Hoffnung lässt, dass DP dann doch auch auf den RV840ern läuft. In jedem Fall wird OpenCL greifbarer und gewinnt mehr und mehr an fahrt.
 
u.a. ja, aber auch die Tatsache das es nachweislich nicht geht [siehe steam@boinc mit DP (Gipsel)]
Ist DP ein muss von OpenCL 1.0 ? Und wenn ja, dann könnte es ja immer noch die CPU übernehmen. OpenCL ist doch so flexibel :)

Was mir ein wenig Hoffnung lässt, dass DP dann doch auch auf den RV840ern läuft. In jedem Fall wird OpenCL greifbarer und gewinnt mehr und mehr an fahrt.
Glaube ich nicht das DP aktiviert [ist es wirklich deaktiviert oder gar nicht vorhanden?] wird, da man sonst den 5800er das Wasser abgräbt. Das gleiche Spiel auch bei NV 8-(
 
... Als nächsten logischen Schritt bräuchte man jetzt noch ECC(sowohl Tesla als auch ATI haben kein ECC) ...
Sicher, dass in der GPGPU-Sparte die Teslas mit der neuen Fermi-Architektur kein ECC haben?

->
Die NVIDIA®-Tesla™-20-Serie wurde von Grund auf für Hochleistungsberechnungen entwickelt. Sie basiert auf der Grafikprozessor-Architektur CUDA der nächsten Generation mit dem Codenamen "Fermi" und unterstützt viele Funktionen, die für technische und geschäftliche Anwendungen unerlässlich sind. Das sind unter anderem ECC-Speicher für kompromisslose Genauigkeit und Skalierbarkeit, Unterstützung für C++ und die 8-fache Leistung bei 64-Bit-Gleitkommagenauigkeit, verglichen mit den Produkten, die auf die Grafikprozessoren der Tesla-10-Serie bauen. Die Grafikprozessoren der Tesla-20-Serie liefern die gleiche Leistung wie die neueste Quad-Core-CPU bei nur 1/20 des Stromverbrauchs und 1/10 der Kosten.
http://www.nvidia.de/page/tesla_computing_solutions.html

MFG Bobo(2010)
 
Zuletzt bearbeitet:
DP ist in OpenCL 1.0 und 1.1 nur optional.

DP wird hardwareseitig derzeit nur vom Cypress Chip bei AMD unterstützt.
 
Nvidia kann mit der Fermi C2050 einen Linpack-Score von 328 GFLOPS für sich verbuchen:
http://www.brightsideofnews.com/news/2010/5/19/cpu-beware-nvidia-tesla-linpack-numbers-analyzed.aspx
Das ist aber der Wert für SGEMM-Wert (Single Precision!) mit CuBlas 3.0. Kann man sehr schön hier nachlesen (allerletzte Folie).
Mit der noch nicht veröffentlichten CuBlas 3.1 Bibliothek sollen dann sogar ~410 GFlop/s drin sein (Seite 5), in Double Precison aber auch nur etwa 175 Gflop/s. Übrigens kann ein Cypress in SGEMM gute 2 TFlop/s und auch in DP ist er prinzipiell sehr konkurrenzfähig zu den Fermis. AMD müßte uns bloß mal mit einer entsprechenden Bibliothek beglücken.
 
Zuletzt bearbeitet:
Ich hab keinen besseren Thread dafür gefunden - daher hier.

AMDs Marketingmaschine läuft offenbar im Hintergrund weiter, auch wenn man kaum was davon mitbekommt.

"AMD Looks to Boost Fusion Ecosystem Through Investments"
http://www.pcworld.com/businesscent...ost_fusion_ecosystem_through_investments.html


Ich verstehe irgendwie nicht, warum dies jetzt erneut gemeldet wird. Die PM zu diesem "AMD Fusion Fund" stammt von Anfang Juni.

AMD Invests in the Future of AMD Fusion™ APU Technology
 
Ich verstehe irgendwie nicht, warum dies jetzt erneut gemeldet wird. Die PM zu diesem "AMD Fusion Fund" stammt von Anfang Juni. ...
Alles richtig, aber IDG ist der Verlag, der auch hinter den PR-Aktionen von AMD stützend im Hintergrund arbeitet. ;D

MFG Bobo(2010) Martin Bobowsky
 
Die grundsätzliche Frage ist einfach, wann AMD aufhört, GPGPU so stiefmütterlich zu behandeln...
 
Die begrenzten Ressourcen dürften voll und ganz auf den Start von Fusion ausgerichtet sein.

Bis dahin erwarte ich nicht viel. Wenn es ab da nicht deutlich voran geht, dann verliere ich auch den Glauben.


Alles richtig, aber IDG ist der Verlag, der auch hinter den PR-Aktionen von AMD stützend im Hintergrund arbeitet. ;D

MFG Bobo(2010) Martin Bobowsky

Das erklärt natürlich einiges!

Danke Bobo
 
Ich verstehe irgendwie nicht, warum dies jetzt erneut gemeldet wird. Die PM zu diesem "AMD Fusion Fund" stammt von Anfang Juni.

Mir kams auch bekannt vor, daher habe ich das Datum der von mir verlinkten Meldung gecheckt. Sie ist vom 6.Juli und täuscht Aktualität vor:

"Advanced Micro Devices is looking to invest in technology companies as it tries to build a hardware and software ecosystem around its upcoming Fusion processor, the company said on Tuesday."
 
Die letzten Abende habe ich mich jetzt noch weiter mit dem Thema beschäftigt.

Unter anderem bin ich auf die DGEMM und SGEMM-Scores von prunedtree im b3d-Forum gestossen:
Demnach schafft eine HD5870 ca. 2220 SGEMM und 510 DGEMM
http://forum.beyond3d.com/showthread.php?t=54842&page=3
Linpack liegt erfahrungsgemäß immer über dem DGEMM Wert, da hauptsächlich aus DGEMM + DTRSM Operationen besteht.

Analog dazu die Werte der Tesla C2050:
DGEMM= 175 Linpack=328

Dann noch ein ganz feines Schmankerl - und das könnte durchaus auch für den BD-Thread ganz interessant sein - ironischerweise von Dell:
http://www.delltechcenter.com/page/...What+could+Hybrid+PetaFLOPS+systems+look+like

Zuerst rechnet er mit den Werten des Tianhe herum und kommt auf ganz ordentliche Zahlen.(Ich sehe gerade er hat einen zahlendreher: 90,86 anstatt 80,96 - aber das Endergebnis stimmt wieder 149,225)
Die GPUs steuern also zur Gesamtperformance von Tianhe 413.875 TFLOPS, d. h. eine GPU steuert 81 GFLOPS für LINPACK bei.
Im Text steht auch drin, dass man die 4870 runtergetaktet hat - ausserdem nimmt der Autor richtigerweise an, dass durch den Infiniband Interconnect ein Teil der Rechenleistung verloren geht.
Alles in allem könnte es in die Richtung weisen.

Dann aber noch zu was anderem in dem Text - darunter stehen Performance-Schätzungen für die Jahre 2011 und 2013 für Intel und AMD.

AMD Magny-Cours 2010: CPU Performance per Node (GFLOPS) 362.11
Intel Sandy Bridge 2011: CPU Performance per Node (GFLOPS) 307.53
Intel 2013: CPU Performance per Node (GFLOPS) 615.07
AMD 2013: CPU Performance per Node (GFLOPS) 1511.42 :o :o
Wie krank ist der AMD 2013-Score.
Wenn wir davon ausgehen, dass der 2010er Wert von einem 4-Sockel-Magny-Cours mit 2,2GHz und 48 Kernen kommt, wie abartig muss Bulldozer abgehen.

Grüße,
Tom
 
Hmm, könnte es sich bei der 2013 CPU nicht schon um einen "vollintegrierten" Fusion handeln?
 
prunedtrees Score darf man glaub ich nicht so ernst nehmen, die Implementierung ist überoptimiert ^^
(super Leistung natürlich, aber nicht repräsentativ).
Bei Laytons Artikel muss man aufpassen, dass man Node-Leistung und CPU-Leistung bei Intel und AMD nicht 1:1 ins Verhältnis setzen darf. So wird beim 2013er Intel eine Node mit 2 Sockeln à 16 Kernen angesetzt, bei AMD aber mit 4 Sockeln à 24 Kernen.
 
Schonmal danke für das gerade rücken der Ergebnisse.
Er verrät also, dass der nächste Bulldozer auf einem Die 12 Int-Cores haben wird - ein MCM dann 24 Int-Cores

2013 vermutet er, dass ein 2 Sockel-BD 755 GFLOPS bringt, ein 2-Sockel Sandy Bridge 615 - immer noch gut.

Dann zu dem Prunedtree-Score - ich hoffe, dass AMD hier endlich mal aus der Hüfte kommt und etwas ordentliches auf die Beine stellt.
 
Er verrät also, dass der nächste Bulldozer auf einem Die 12 Int-Cores haben wird - ein MCM dann 24 Int-Cores

Er rät nur. Er nimmt einfach an, dass sich die Core Anzahl verdoppelt.
Zudem nimmt er an, dass der Takt nahezu gleich bleibt.
 
Nvidia hat den Quellcode für CUDA offengelegt.
Damit sollen auch AMD GPUs in den Genuss der CUDA Technik kommen.

Ich halte das für eine selbstbewusste Geste seitens Nvidia.8)
Eventuell ist das Nvidia GPU Design grundsätzlich besser für CUDA geeignet als andere Designs von z.B. AMD oder Intel. Wäre ja kein Wunder sondern läge eher auf der Hand.
Vielleicht gewann aber auch der OpenCL Ansatz an Fahrt, und Nvidia will durch die Veröffentlichung des Quellcodes CUDA weiter etablieren.
MfG
 
Ok, damit dürfte nun klar sein, dass sich CUDA auf dem absteigenden Ast befindet.
 
Ja, eigentlich ein kluger und logischer Schritt. OpenCL wird gerade durch IvyBridge gut an Fahrt gewinnen.
Nvidia behält ja die Zügel in der Hand, indem man nur Teile als OpenSource veröffentlicht. Damit kann man dann immer noch Bremsen einbauen wenn nötig.
Aber schön, dass nun alle Zugang zu CUDA haben, das macht einige Projekte deutlich interessanter. Wenn ich das richtig verstehe ist aber nicht alles OpenSource, sondern nur der Compiler. Schwieriger dürfte ein passender Treiber für AMD-GPUs sein.
 
Zuletzt bearbeitet:
Warum sollte AMD CUDA verwenden ? Sie haben CAL und OpenCL !

nVIDIA hat sicherlich den Compilercode veröffentlicht, damit CUDA auf mehr eigenen Platformen laufen kann - vorallem atypische OS!

Alles andere wird per OpenCL laufen - sobald Intel mal endlich OpenCL Support gebacken bekommt ... auf dem Grafikteil der CPUs.

OpenCL läuft ja immerhin auf allen CPUs mit SSE2 (AMD Treiber auch bei Intel CPUs) bzw. ab SSE41 (Intel Treiber)
 
Ich halte das für eine selbstbewusste Geste seitens Nvidia.8)
Eventuell ist das Nvidia GPU Design grundsätzlich besser für CUDA geeignet als andere Designs von z.B. AMD oder Intel. Wäre ja kein Wunder sondern läge eher auf der Hand.
Vielleicht gewann aber auch der OpenCL Ansatz an Fahrt, und Nvidia will durch die Veröffentlichung des Quellcodes CUDA weiter etablieren.
MfG

Natürlich sind NV GPUs besser für CUDA geeignet als die AMD Chips. Bisher haben die Radeons nicht mal eine ordentliche VM Architektur, welche für die in CUDA erlaubte Pointerarithmetik zwingende Voraussetzung ist. CUDA auf AMD kann also frühestens mit GCN kommen, den aktuellen Chips fehlen die technischen Grundlagen.
 
Zurück
Oben Unten