News Intels „Knights Corner“ erreicht über 1 TFLOP/s

[FatFire]

So sehr Du Dir jetzt Mühe gibst und versuchst Dich amateurhaft rauszureden: Knights Corner ist eine Fließkommapumpe und damit sind Tesla & Co Konkurrenten und keine Ergänzungen. Wenn das Teil sonderlich gut mit Integeroperationen umgehen könnte, würden Sie mit Sicherheit dort mit den Werten prahlen. Tun sie aber nicht. Und würde auch keinen Sinn machen. Das Ding sollte mal eine Grafikkarte werden. Glaubst Du ernsthaft, diese Grafikkarte sollte mit ihren Integerwerten glänzen?

x86 macht keine Vorgaben dazu, ob ein Prozessor besser mit Integer- oder Fließkommabefehlen umgehen können muss, x86 macht auch keinerlei Vorschriften zur Architektur oder wie welcher Befehl umzusetzen ist. x86 gibt einzig und allein Befehle vor, bei denen klar definierte Ausgangswerte bei bestimmten Eingangswerten erzeugt werden müssen.

Gruß FatFire

 

[calluna]

@Lübke

Naja... die Kerne des Knights Corner sind recht einfach gehalten, ähnlich den Atoms. Die hohe Leistung wird durch die Vektor-Einheiten erreicht. Dieser Prozessor hat also ähnliche Nachteile (und Vorteile) wie die GPUs, er ist auf Durchsatz optimiert und wird wie die GPUs eine hohe Leistung bei großen homogenen Datenmengen haben.
Der Hauptunterschied ist eben (mal davon abgesehen, dass Knights Corner sein eigenes Betriebssystem hat), so wie ich das sehe, dass die Optimierungen für die Bearbeitung von Grafikdaten fehlen. Was ein Vorteil ist.

 

[Lübke]

@FatFire:

So sehr Du Dir jetzt Mühe gibst und versuchst Dich amateurhaft rauszureden

solche persönlichen angriffe kannst du dir gleich schenken. zumal deine beiträge wohl alles andere als hochgradig professionell sind.
entweder unterhalten wir uns vernünftig oder gar nicht.

x86-prozessoren können x86-befehlssätze verarbeiten, gpus können das nicht. das ist der springende punkt. ein cpu-kern kann weit komplexere operationen pro taktzyklus ausführen als ein shader. welcher supercomputer wird denn ausschließlich zur fließkommaberechnung benötigt? dazu würde es keinen so komplexen kern bedürfen. dass ein bd-kern eine höhere integerleistung hat als ein kc-kern ist ja schön und gut, aber ein opteron hat dafür auch "nur" 16 kerne, wärend ein knights corner ein fielfaches dessen hat. die cpus sind unterschiedlich, ja, aber es bleiben x86 cpus mit entsprechenden befehlssatzerweiterungen.

@calluna: die kerne sind meines wissens sogar noch primitver (basis soll der pentium 1 gewesen sein). sie sind stark abgespeckt worden und auf die computingrelevanten bestandteile reduziert. du hast schon recht, dass intel den spagat zwischen xeon und tesla versucht und sogesehen wären vermutlich bd-opterons die bessere ergänzung zu tesla...
aber wenn ich den gedanken mal weiterführe, ergibt sich für mich knights corner eher als "billige" alternative zu einem gpu-cpu-hybridsystem. auf beiden gebieten nicht ganz so leistungsfähig wie die hochspezialisierten chips, aber vielseitiger und (mutmaßlich) unterm strich sparsamer.

 

[theorist]

@Lübke: Durch ständige Wiederholung werden deine aufgeschnappten Weisheiten auch nicht richtiger. Die Intel Many Integrated Core Architecture basiert immer noch auf SIMD-Vektoreinheiten. Ok, das Konzept hat mit AVX inzwischen auch bei den x86-CPUs von AMD und Intel Einzug gehalten, aber Intels MIC (Knights Ferry, Knights Corner) geht ein ganzes Stück weiter und verzichtet dafür auf Schaltkreise, die für einen hohen Durchsatz bei seriellem Code sorgen.
Außerdem heißt x86 nicht, dass die CPU-Cores wahnsinnig komplexe Schaltkreise haben, um komplexe Befehle in einem Takt ausführen zu können. x86-CPUs werden schon seit einer halben Ewigkeit im Inneren als RISC mit Pipelining ausgeführt, ein Decoder sorgt für die Umsetzung der x86-Befehle in RISC-Befehle. Die meisten x86-Befehle können eben nicht in einem Takt abgearbeitet werden.

 

[Lübke]

du willst mir aber jetzt nicht ernsthaft erzählen, dass ein knights-korner kern mit einem shader vergleichbar ist, oder? Oô
dass ein knights corner nicht 1:1 mit einem core i7 oder bd vergleichbar ist, ist denke ich wohl jedem hier klar. dennoch ist es was anderes als es mit einer grundlegend anderen architektur (unified shaderarchitektur) gleichzusetzen. oder etwa nicht?

 

[theorist]

Was willst du jetzt mit Unified Shader? Ich dachte, wir sprechen über General-Purpose-Computing und nicht über Rasterizing im Sinne von Direct3D oder OpenGL?!

Unified Shader ist ein Modell für die programmierbare Verarbeitung von Daten, die beim Rasterizing anfallen. Also Farbwerte, Dreiecke, Koordinaten, etc.
Unified Shader sagt nichts darüber aus, wie eine Architektur für allgemeine Berechnung ausgelegt ist.

Nvidia beschreibt die eigene Compute-Architektur als Compute Unified Device Architecture (CUDA). Das hat rein gar nix mehr mit dem Unified-Shader-Modell aus Direct3D 10/11 zu tun.
Die Hardware an sich lässt sich je nach Verwendungszweck auf verschiedene Arten abstrahieren und wenn wir von GPGPU reden, ist der Begriff Unified Shader fehl am Platz.

Intels MIC-Architektur ist bezogen auf General-Purpose-Processing/Computing näher an aktuellen GPUs dran als an CPUs. Daran ändert auch der vorgeschaltete x86-Decoder nichts.

 

[Karre]

cuda ist nichts anderes, als ne andere beschreibung für unified shader, mit einem unterschied, das cuda eine programierschnittstelle dafür ist

 

[calluna]

@theorist

SIMD hat 1997 mit MMX in x86 CPUs Einzug gehalten, allerdings so richtig erst mit SSE.

Und Lübke hat nicht geschrieben, dass x86 bedeuten würde, dass x86 CPUs wahnsinnig komplexe Schaltkreise haben, sondern das "ein cpu-kern kann weit komplexere operationen pro taktzyklus ausführen als ein shader".

Das sind Sachen, die hier wohl auch jeder weiß, dass es x86 CPUs mit recht komplexen Schaltkreisen und weniger komplexen wie den Atoms gibt. Bei MIC wird auf Out-of-Order verzichtet. Bzw. sind es, wie Lübke ganz richtig gesagt hat, an das Design des P54C angelehnte Kerne.

Falls es jemanden interessiert: http://software.intel.com/en-us/articles/larrabee/

Interessant fand ich:

- Rasterization on Larrabee
- Larrabee: A Many Core x86 Architecture for Visual Computing

 

[FatFire]

solche persönlichen angriffe kannst du dir gleich schenken.

Kritik an Deiner mangelhaften Argumentationsweise ist bestimmt kein persönlicher Angriff. Aber netter Versuch mich zu diskreditieren. Und professionelle Beiträge in der Aufmachung erwarte ich auch nicht. Aber man sollte schon wissen, wovon man redet, wenn man sich in eine so komplexe Thematik einmischt.

welcher supercomputer wird denn ausschließlich zur fließkommaberechnung benötigt?

Eigentlich alle. Supercomputer fahren im Normalfall Simulationen (Wetter, Klima, Seismik, Marktprognosen, etc...) welche auf Wahrscheinlichkeitswerten basieren, die wiederum fast ausnahmslos Fließkommawerte sind.

Den Rest brauche ich ja wohl nicht mehr zu kommentieren. Anstatt Deine fehlerhaften Aussagen ständig zu wiederholen, solltest Du einfach mal anfangen Dich mit den Sichtweisen der Anderen oder der Thematik allgemein auseinanderzusetzen.
Ansonsten gilt nämlich:

entweder unterhalten wir uns vernünftig oder gar nicht.

Achte bei Deinen Beiträgen vielleicht mal mehr auf Qualität statt Quantität.

Gruß FatFire

 

[theorist]

@Karre: CUDA ist keine andere Beschreibung für Unified Shader, die beiden Begriffe haben nichts miteinander zu tun. NV hätte CUDA auch schon auf CineFX (GeForce FX bis GeForce 7) implementieren können. CUDA ist eine Abstrahierung der Hardware bezogen auf deren General-Purpose-Processing-Fähigkeiten, Unified Shader eine Abstrahierung der Hardware bezogen auf die Verarbeitung von Grafikdaten.

@calluna: Stimmt natürlich, SIMD in x86-CPUs gibts schon länger. AVX ist nur einen Schritt weiter gegangen und entspringt möglicherweise auch den Entwicklungen der Many-Integrated-Core-Architektur.
Der Satz von Lübke "ein cpu-kern kann weit komplexere operationen pro taktzyklus ausführen als ein shader" ist zum Einen sprachlich unpräzise (ein "Shader" ist eine Modellvorstellung und beschreibt keine GP-Hardware) und zum Anderen ein völlig hirnrissiger Vergleich, unter der Prämisse, dass man Shader mal großzügig als CUDA-Core (NV-Sprech) bzw. Stream-Prozessor (AMD-Sprech) interpretiert. Da vergleicht man MADD-ALUs mit einer kompletten CPU-Pipeline inkl. x86-Decoder und pauschalisiert einfach mal ungeachtet der Hardwareimplementierung.

 

[Karre]

@ theorist nein konnte nvidia nicht, weil erst mit der gforce8 unified shader architektur (also eine chiparchitektur) eingeführt wurde, die es erlaubt einen shader zu programmieren etwas bestimmtes zu tun

davor gab es pixelshader vertex shader vektor etc, die alle einzeln programiert werden mussten (und dann auch nur ihr jeweiliges spektrum abdecken konnten), was sehr sehr umständlich ist, da diese nacheinander arbeiten (also erst der shader, der x berechnet dann der der x berechnet usw.)

und seit gf8 reihe kann man dem shader (der nun also pixel, vertex und vektor kann) sagen was er berechnen soll .. und erst seither macht es überhaupt sinn eine gpu auch für andere zwecke als für grafikausgaben zu benutzen.

 

[theorist]

Soviel Unfug, dass ich es mir spare, das alles zu kommentieren. Nur soviel: GPGPU war schon lange vor der GeForce 8 und Unified Shader möglich. Das Folgende funktioniert auf Grafikkarten ab der GeForce FX und Radeon 9500: http://www.mathematik.uni-dortmund.de/~goeddeke/gpgpu/tutorial.html.

 

[Karre]

was verstehst du eigentlich nicht?
cuda ist ne programier schnittstelle für nvida unifiedshader.
ich hab nie behauptet das es davor kein gpgpu gab.

 

[theorist]

Wie oft denn noch, Unified Shader ist kein Begriff, der eine Hardwarearchitektur für General Purpose Processing beschreibt. Unified Shader entspringt dem Direct3D-Sprachgebrauch und ist eine Abstrahierung der Funktionsweise der Hardware speziell mit Bezug auf Grafikverarbeitung.
CUDA hat mit Shadern rein gar nix am Hut. Die Ausführungseinheiten für CUDA heißen CUDA-Cores.

/EDIT: Ich bin raus, bevor ich mich wieder über die Ignoranz von ein paar Leuten aufrege und unfreundlich werde.

 

[Karre]

nein .. ein shader ist eine recheneinheit Oo .. dabei ist es wurst, ob die grafik oder andere daten berechnet.

direct3d (directx) ist auch nur eine programierschnittstelle um diese anzusprechen
wie cuda eine ist
wie stream eine ist
wie opencl eine ist
wie opengl eine ist.

und knights bringt nun dank x86 native c/c++/c# usw. kompatibilität und somit mehr funktionensmöglichkeiten ..

 

[Lübke]

@theorist: ich hab das gefühl wir reden aneinander vorbei. nochmal zur situation: ich hatte gesagt, dass ich erwarte, künftig supercomputer mit einer mischung aus knights corner und tesla z. b. vorzufinden (calluna hat ja schon aufgezeigt, dass es wohl eher doch nicht so sinnvoll ist, von daher also hinfällig). FatFire hat behauptet, dass wenn dann knights corner und bulldozer gemischt würden. dazu hab ich geschrieben, dass ich knights corner für unwahrscheinlich halte, da die schnittmengen imho zu groß sind. damit meine ich nicht, dass knights corner und bulldozer identische integerleistung hätten oder sowas, sondern dass alles was mit ein bulldozer besser kann als eine gpu auch besser kann als ein knights corner, da dieser auch nur ein (primitiverer) x86 ist und seine stärke in vielen recheneinheiten liegt, was bei der gpu aber noch stärker der fall ist. es ergibt sich also für den knights corner neben einer anderen x86 cpu kein nennenswerter vorteil aus seiner architektur gegenüber einer gpu in simpler shaderarchitektur. ich hoffe das war soweit verständlich?
liege ich damit falsch?

 

[theorist]

Knights Corner ist ein Co-Prozessor, der als Alternative zu GPUs zu sehen ist. Knights Corner dürfte im Supercomputer-Einsatz vornehmlich mit Intel Xeons (Sandy Bridge EP, Ivy Bridge EP) gepaart werden.
Ob sich bei der Perf/Watt ein Vorteil gegenüber GPUs wie Kepler ergiebt, muss sich noch zeigen. Ein Vorteil von Knights Corner liegt in der Crosskompatabilität zu den Xeons und anderen x86-Prozessoren. Man kann einfach bestehenden Code nochmal durch den Intel-Compiler jagen und erhält auf Knights Corner lauffähige Programme. Das ist für Rechenzentren attraktiv, weil man den Kunden z.B. günstigere Rechenzeit anbieten kann, ohne dass der Kunde eine neue Programmierumgebung nutzen muss.

 

[Lübke]

ok dann bitte mal für mich zum verständnis: wenn man den knights corner "nur" als copro einsetzt, welchen vorteil kann er neben der x86-cpu noch gegenüber einer gpu ausspielen? oder bist du der ansicht, dass er noch gar nicht ausgereift ist und in dieser form noch nicht gegen die gpu antreten wird?

 

[FatFire]

FatFire hat behauptet, dass wenn dann knights corner und bulldozer gemischt würden.

Falsch!

Wenn man ein möglichst ausgeglichenes System haben möchte, wo sowohl Integer- als auch Floating-Point-Leistung gefordert sind, müsste man Knights Corner eigentlich mit Bulldozer zusammenpacken.

Das eigentlich kann man in dem Fall auch ruhig ersetzen durch theoretisch. Aber es ist klar, dass es so nicht kommen wird:
1) Intel wird eine Plattform Xeon+Knights Corner anbieten. AMD wird das wohl nicht unterstützen.
2) Es macht für Supercomputer in der Regel keinen Sinn beides gut zu können, da braucht man entweder Integer- oder Fließkommaleistung en Masse.

nein .. ein shader ist eine recheneinheit Oo .. dabei ist es wurst, ob die grafik oder andere daten berechnet.

Nein, ein Shader ist nur ein kleines Programm! Und korrekt betrachtet macht es sehr wohl einen Unterschied ob man Grafik oder andere Daten damit bearbeitet. Alleine schon, wenn man sich die Namensherkunft anschaut.

Gruß FatFire

 

[Karre]

namensherkunft?
ka .. ich red von hardwareshader .. sowas wie pixel oder vertex shader ...