Archiv verlassen und diese Seite im Standarddesign anzeigen : Intel - Larrabee (der Spekulationsthread)
Seiten :
1
2
3
4
5
6
7
8
[
9]
Duplex
2010-09-17, 21:16:45
ich denke aber, dass Intel durchaus das ein oder andere aus diesem Projekt gelernt hat.
was den nun? gute aussichten oder schlechte aussichten ;)
kurzgesagt Totgeburt oder Erfolg, halbes zählt nicht.
Sollte eines Tages Nvidia nicht mehr sein, dann wird Intel die Leute auch sicher mit astronomischen Gehältern locken.
Nvidia wird nicht zulassen das Intel etwas abbekommt, wenn dann würde später AMD wenn es den Finnaziel gut gehen würde ein Angebot an Nvidia machen (dazu muss erstmal der Wert von Nvidia runter gehen) wenn AMD & nvidia eine Firma wären, hätte Intel niemals eine Chance im GPU Markt, kein anderer Hersteller hat das zeug dazu!
Nvidia wird nicht zulassen das Intel etwas abbekommt, wenn dann würde später AMD wenn es den Finnaziel gut gehen würde ein Angebot an Nvidia machen (dazu muss erstmal der Wert von Nvidia runter gehen) wenn AMD & nvidia eine Firma wären, hätte Intel niemals eine Chance im GPU Markt, kein anderer Hersteller hat das zeug dazu!
Schade, dass sich Nvidia und Intel anfeinden, anstatt zusammen zu arbeiten.
Wie lecker könnte Sandy Bridge und Ableger erst sein, wenn man zusammengearbeitet hätte bzw. Nvidia die GPU für Sandy Bridge gebaut hätte ;)
;D
Ailuros
2010-09-18, 10:08:29
In der Tat ist Larrabee aber auch ein schönes Beispiel dafür, dass Geld nur in gewissem Maße Brainpower und langjährige Erfahrung ersetzt.
Sollte eines Tages Nvidia nicht mehr sein, dann wird Intel die Leute auch sicher mit astronomischen Gehältern locken.
Larabee's eigentliches Problem war nicht auf engineering Basis sondern eher auf der Seite vom Management oder anders denjenigen die Entscheidungen treffen.
Wenn Dir ein engineer vergebens zeigen will dass X eine Schnappsidee ist und Du willst trotz allem mir nichts dir nichts mit dem Kopf durch die Wand hilft jegliche "Erfahrung" auch nichts mehr.
"I just think it is impractical to try to do all the functions in software in view of all the software complexity. And we ran into a performance per watt issue trying to do these things," said Thomas Piazza, the director of graphics architecture development at Intel architecture group, at an event during Intel Developer Forum, reports Techradar web-site.
http://www.xbitlabs.com/news/video/display/20100916220540_Intel_Unlikely_to_Release_Larrabee_As_Discrete_Graphics_Processor _Company.html
Als viele von uns darauf deuteten in der Vergangenheit waren wir wohl alle die Deppen des Dorfs. Unter vielem anderem ein rasterizer ist spott-billig in hw als das eine Beispiel von vielen und x86 Logik nahm auf high end Varianten bis zu 30% ein waehrend es bei den kleineren Varianten immer noch 10% war. Ein Brummer von 600mm2 unter 45nm? Errrr.....
Wenn alle cores voll ausgelastet wurden konnte sie die Temperaturen bzw. Abwaerme nicht mehr kontrollieren.
Zwar schwer vergleichbar aber NV's Probleme der letzten Zeit sind auch nicht so weit entfernt von der vorigen Vereinfachung. Als ich im Sommer 2009 mit einem NV Kerl privat in Echtzeit plauderte stand er mir ein dass es ihm nie vorgekommen ist dass ein engineer "nein" gesagt hat als er fuer den Zusatz von kernel X anfragte.
Was heisst den ueberhaupt genau "Erfahrung"? Ich bin "erfahren" ergo kann bei mir nichts schieflaufen oder eher ich lerne konstant dazu und passe mich an jegliche sich wendende Realitaet dementsprechend an?
Die software Architektur ist nur schlecht gewesen.
1.Man muss sich nur überlegen, dass die mit einem oldschool super optimierten HLine rasterizer anfingen.
2.Und was viele GPUs heutzutage als Teil vom Shader machen, z.B. interpolator Berechnungen, wollten die im Rasterizer machen der schon das bottleneck war. Da hab ich bei offline Renderern besseres gesehen.
3.Deferred Rendering, bei den Datenmengen die dabei rauskamen (z.B. Crysis Vertexcount/Frame der bei 6Mio+ sein kann, das sind locker 64MB vertexdaten die mehr Bandwidth kosten als der Framebuffer), dabei optimieren alle mit Z-Pass schon für beste Occlusion. Da weiss man nach dem ersten Frame-Dump, dass man mit Deferred keine Ananas gewinnt.
4. Vector Einheiten die auf 16floats als 4lanes ala 4float abarbeiten, aber ohne dot usw. einfach nur dummer Overhead, der total schlecht beim runtime shader Compiler einschlägt und Silicon kostet. Mit ein wenig rumfragen bei den anderen Architektstudios bei Intel wären sie mit etwas angekommen wie beim G80, was auch immer beim optimieren für SSE vorgeschlagen wird: SOA.
5. Viel zu kurze Latenz bei der Hardware, auf kosten der Register. Stattdessen sollte die Latenz ruhig 100cycle sein mit unmengen von registern. Statt Hyperthreading, lieber alle in ein Registerset. Statt der Texture Fetch Unit die man mit viel Aufwand programmieren muss, lieber eine direkte intrinsic die Texturen sampled, mit genug registern ist auch egal wenn das lange Latenzen hat, selbst bei in order.
Es tut mir echt leid um die softwarerasterizer-Welt, mit besseren Design Goals gebe es gute Chancen daraus ein Produkt zu machen. Aber es sieht aus wie ein fun Projekt von Leuten die Kumpels bei Intel hatten.
Das man etwas gutes hinbekommt wenn man die richtigen Design Goals verfolgt hat der Atom gezeigt, ... ach :usad:
Gasti
2010-09-19, 22:26:33
Der Atom ist im eigentlich angepeilten Markt der MIDs bisher auch ziemlich erfolglos.
Das Netbook hat ASUS erst erfunden als es den Prozessor schon gab...
Was Das mit Larrabee zu tun hat verstehe ich auch nicht wirklich.
der Larrabee Kern ist ein umgebauter Pentium...
noch ein Larabee Thread http://www.planet3dnow.de/vbulletin/showthread.php?t=343270
Der Atom ist im eigentlich angepeilten Markt der MIDs bisher auch ziemlich erfolglos.
Das Netbook hat ASUS erst erfunden als es den Prozessor schon gab...
Was Das mit Larrabee zu tun hat verstehe ich auch nicht wirklich.
Eigentlich wuerde der eee pc, zum damaligen Preis von $199, schon lange vor dem Atom beworben und die ersten hatten auch einen Celeron, erst dann hat intel eine Atom geliefert.
Ich denke das war auch das zielsegment vom Atom.
Gasti
2010-09-19, 23:28:28
Eigentlich wuerde der eee pc, zum damaligen Preis von $199, schon lange vor dem Atom beworben und die ersten hatten auch einen Celeron, erst dann hat intel eine Atom geliefert.
Ich denke das war auch das zielsegment vom Atom.
Sry aber sicher nicht als Konzept für die Entwicklung des Atoms erdacht wurde und das lobt der Gast von vorhin was ich zusammen mit dem Rest seines Posts nicht nachvollziehen kann.
3.Deferred Rendering, bei den Datenmengen die dabei rauskamen (z.B. Crysis Vertexcount/Frame der bei 6Mio+ sein kann, das sind locker 64MB vertexdaten die mehr Bandwidth kosten als der Framebuffer), dabei optimieren alle mit Z-Pass schon für beste Occlusion. Da weiss man nach dem ersten Frame-Dump, dass man mit Deferred keine Ananas gewinnt.
LRB ist kein deferred Renderer. Es ist ein Tile Based Renderer. Und die 64MB sind ein Witz bei >100GB/s Bandbreite.
4. Vector Einheiten die auf 16floats als 4lanes ala 4float abarbeiten, aber ohne dot usw. einfach nur dummer Overhead, der total schlecht beim runtime shader Compiler einschlägt und Silicon kostet. Mit ein wenig rumfragen bei den anderen Architektstudios bei Intel wären sie mit etwas angekommen wie beim G80, was auch immer beim optimieren für SSE vorgeschlagen wird: SOA.
Das war SOA. Es werden bei LRB immer 4 Quads, also 16 Pixel zusammen geshaded.
5. Viel zu kurze Latenz bei der Hardware, auf kosten der Register. Stattdessen sollte die Latenz ruhig 100cycle sein mit unmengen von registern. Statt Hyperthreading, lieber alle in ein Registerset. Statt der Texture Fetch Unit die man mit viel Aufwand programmieren muss, lieber eine direkte intrinsic die Texturen sampled, mit genug registern ist auch egal wenn das lange Latenzen hat, selbst bei in order.
Geht halt mit x86 schlecht. 100 Takte ist aber selbst für eine GPU sehr übertrieben.
Larrabee ist am x86-Overhead und am fehlenden fixed function Rasterizer gestorben. Aber so bescheuert war das Konzept auch nicht.
LRB ist kein deferred Renderer. Es ist ein Tile Based Renderer. Und die 64MB sind ein Witz bei >100GB/s Bandbreite.Erst binning, dann rasterizing -> deferred.
anders macht es imagination auch nicht.
Und du hast den Punkt verpasst, intel sprach davon das die TBDR machen weil es cache freundlicher ist den Framebuffer in Tiles zu haben, dabei verbraten die weitaus mehr Performance zum Laden der Vertex daten.
Und wenn 64MB ein witz sind, sind die Framebuffer noch weit aus mehr ein Witz.
Das war SOA. Es werden bei LRB immer 4 Quads, also 16 Pixel zusammen geshaded.Nein, schau dir die paper an, es gab swizzlemasks usw., sodass pro Lane ein Pixel geshaded wurde und du 4Pixel pro Pipe hattest.
wozu sonst swizzlemasks? Sag mir nicht die andere Software braucht das so dringend dass man deswegen die SIMD16 verkompliziert hat.
Geht halt mit x86 schlecht.das hat nichts mit x86 zu tun.
100 Takte ist aber selbst für eine GPU sehr übertrieben.Es gibt einige die weit aus mehr latenz haben/verstecken, weil sie genau so texture sampling als Instruktion haben/hatten. Das high-level bild das man hier immer sieht ist nicht was intern verbaut ist.
Larrabee ist am x86-Overhead und am fehlenden fixed function Rasterizer gestorben. Aber so bescheuert war das Konzept auch nicht.
x86 ist weniger dramatisch als man denkt, deswegen hat intel ja so eine alte Architektur als basis genommen. Ein Atom kann auch sparsam laufen trotz x86 und die SIMD16 instruktionen sind alle im neuen Format encoded. Aber nochmals, dramatisch ist das ganze nicht, zwei instruktionen pro Takt bei vielleicht 1.6Ghz kann man auch bei x86 problemlos decoden.
Ich denke auch nicht, dass der Rasterizer an sich schuld ist, es ist eher die Dummheit die daraus ein Bottleneck machte, fine-grain Sample generierung kann man auf die Fragmentpipelines schieben und ohne Binning braucht man auch nicht x-mal Tri-Setup und Rasterisierung machen.
Erst binning, dann rasterizing -> deferred.
anders macht es imagination auch nicht.
Unter Deferred Rendering versteht man eigentlich, dass man zuerst die Occlusion berechnet und dann nur das sichtbare schattiert.
Intel macht das nicht. Sie rendern immer noch in den Tiles wie ein IMR.
Und du hast den Punkt verpasst, intel sprach davon das die TBDR machen weil es cache freundlicher ist den Framebuffer in Tiles zu haben, dabei verbraten die weitaus mehr Performance zum Laden der Vertex daten.
TRB. Und ja ich weiß um was es geht.
Und wenn 64MB ein witz sind, sind die Framebuffer noch weit aus mehr ein Witz.
Die 64MB werden einmal geschrieben und dann pro Tile gelesen. Die anfallende Bandbreite ist ein Witz gegenüber dem was Framebuffer und Texturen verursachen.
Du kannst doch nicht von der Datenmenge auf die Bandbreite schließen :ugly:
Nein, schau dir die paper an, es gab swizzlemasks usw., sodass pro Lane ein Pixel geshaded wurde und du 4Pixel pro Pipe hattest
Nö. Da bin ich mir ganz sicher, dass die Branch-Granularität bei LRB 16 war. Ich such dir das auch gerne raus.
Das Swizzling ist wichtig für die anderen Teile der Pipeline.
das hat nichts mit x86 zu tun.
Natürlich hat das was mit x86 zu tun. Das hat nunmal nur 16 Register.
Es gibt einige die weit aus mehr latenz haben/verstecken, weil sie genau so texture sampling als Instruktion haben/hatten. Das high-level bild das man hier immer sieht ist nicht was intern verbaut ist.
Texturing und Loads können so lange dauern ja. Das ist bei LRB über die TMUs aber auch nicht anders.
Ailuros
2010-09-20, 09:02:41
Larabee ist so viel ein deferred renderer durch den Treiber wie alle anderen IMRs auf dem Markt. Wenn bei einer Applikation ein unshaded pass von einem shaded pass gefolgt wird, dann rendert der Treiber von LRB natuerlich auch deferred.
Streng genommen ist er auch kein tile based renderer denn es gibt keinen Schimmer an hw Unterstuetzung bzw. Logik fuer tiling in LRB. Von mir aus kann der Treiber parallel in einem diagonalem Universum berechnen, aber ein reiner TBR ist es auch nicht unbedingt.
Erst als LRB offiziell storniert wurde fand ich heraus dass Intel kein dediziertes Treiberteam fuers LRB Projekt hatte. Es haette das gleiche Treiberteam wie fuer GenX sein sollen. GenX hat hw tiling das bisher nie richtig gelaufen ist und deren Team haette sw tiling perfekt auf die Beine gestellt? :rolleyes:
Das Treiberteam war ein anderes. Sie hatten unter anderem Michael Abrash von RAD, und der weiß was er tut.
Von dem was in den Papers stand kann man ihnen auch wirklich keine Unfähigkeit vorwerfen. Der Softwarerenderer war im Rahmen der Möglichkeiten wirklich genial.
Ailuros
2010-09-20, 13:54:17
Das Treiberteam war ein anderes.
Dann hat mich der Intel engineer angelogen in Echtzeit und ich war auch nicht alleine im chat.
Sie hatten unter anderem Michael Abrash von RAD, und der weiß was er tut.
Tja nur ist so ein Projekt wohl weit entfernt von einer hypothetischen "one man show".
Von dem was in den Papers stand kann man ihnen auch wirklich keine Unfähigkeit vorwerfen. Der Softwarerenderer war im Rahmen der Möglichkeiten wirklich genial.
Genial waere er gewesen wenn er die unterliegende hw nicht ueberfoerdert haette (mal brutal vereinfacht). Ein balancierte GPU Architektur besteht weder nur aus theoretisch guter sw oder nur aus theoretisch guter hw sondern einer feinen Balance der beiden.
Dann hat mich der Intel engineer angelogen in Echtzeit und ich war auch nicht alleine im chat.
Dein Problem ist die Interpretation.
Tja nur ist so ein Projekt wohl weit entfernt von einer hypothetischen "one man show".
Schon klar, aber er hatte die Zügel in der Hand. Und ein guter Mann an der Spitze ist was Engineering angeht generell fast am wichtigsten.
Genial waere er gewesen wenn er die unterliegende hw nicht ueberfoerdert haette (mal brutal vereinfacht). Ein balancierte GPU Architektur besteht weder nur aus theoretisch guter sw oder nur aus theoretisch guter hw sondern einer feinen Balance der beiden.
Ansichtssache.
Ich behaupte ja auch nicht, dass Larrabee keine Sackgasse war. Aber an der Softwarearchitektur lag es sicher nicht. In Hardware hat man halt einige Fehlentscheidungen getroffen, allen voran x86 und zu wenig Fixed Function.
Das Treiberteam war ein anderes. Sie hatten unter anderem Michael Abrash von RAD, und der weiß was er tut.
Michael Abrash, der an Quake mitprogrammiert hat :)
Ailuros
2010-09-20, 15:42:37
Dein Problem ist die Interpretation.
Ich hatte eine langwierige Debatte ueber LRB und sagte selber dass es dafuer ein eigenstaendiges Treiber-team gibt. Ohne jetzt Namen zu nennen sprang der Intel Kerl in die Debatte ein und sagte dass sie nie mehr als ein Treiber-team hatten. Als ich sicherheithalber nachfragte ob er damit meint dass das chipset (GenX) und LRB das gleiche Treiber-team haben sagte er "I think I should know where my office is located...". So und jetzt interpretier es Du demzufolge besser.
Schon klar, aber er hatte die Zügel in der Hand. Und ein guter Mann an der Spitze ist was Engineering angeht generell fast am wichtigsten.
Tut mir leid aber das Resultat selber beweisst haushoch dass es eben NICHT ausreicht.
Ansichtssache.
Ich behaupte ja auch nicht, dass Larrabee keine Sackgasse war. Aber an der Softwarearchitektur lag es sicher nicht. In Hardware hat man halt einige Fehlentscheidungen getroffen, allen voran x86 und zu wenig Fixed Function.
Aendert es was am eigentlichen Resultat? Nein. Mir nuetzt ein genialer sw renderer gar nichts wenn die unterliegende dafuer bestimmte hw nicht zu 100% mitspielt.
Es kann sein dass ich ein generelles Interpretations-Problem habe aber wenn mir jemand sagt dass wenn die pipelines voll ausgelastet wurden sie die Hitze nicht mehr kontrollieren konnten, bestaetigt es mir indirekt auch die obrige offizielle Aussage:
I just think it is impractical to try to do all the functions in software in view of all the software complexity. And we ran into a performance per watt issue trying to do these things.
Und wir beide meinen auch im Grund nichts brutal unterschiedliches. Zu hohe sw Komplexitaet und zur gleichen Zeit zu wenig fixed function hw, zeigen genau das eigentliche Problem an. In dem Fall erwarte ich von jeglichem erfahrenem engineer (egal ob sw oder hw engineer) ein fruehzeitige Einsicht dass es irgendwo zu viel des Gutem war mit der ganzen sw Komplexitaet. Ein wirklich genialer sw renderer wuerde auch nicht zu "genialem" Stromverbrauch fuehren und ueber 11 chip-Revisionen das eine motherboard nach dem anderem explodieren lassen.
Alles natuerlich "Interpretations-Affaere" ;)
Gasti
2010-09-20, 15:58:45
Wenn Es so sein sollte, dann kann man dem SW-Renderer wohl kaum unterstellen, dass Er die Hardware "zu gut" auslaste. Dann ist es ein HW-Problem und natürlich die grundsätzliche Entscheidung praktisch alles in SW zu rechnen.
Ailuros
2010-09-21, 08:20:08
Wenn Es so sein sollte, dann kann man dem SW-Renderer wohl kaum unterstellen, dass Er die Hardware "zu gut" auslaste. Dann ist es ein HW-Problem und natürlich die grundsätzliche Entscheidung praktisch alles in SW zu rechnen.
Ein IHV entwickelt wohl schwer getrennt sw und hw und wenn beide fertig sind probiert die beiden zusammen aus. Zumindest von einem Punkt aufwaerts muss es sich um parallele Entwicklung der beiden handeln denn ich kann mir schwer vorstellen dass Intel als Beispiel zuerst den sw renderer entwickelte und dann erst mit der hw Entwicklung angefangen hat oder genau umgekehrt.
Ich bleibe bei meiner Meinung dass Intel's groesstes Problem war dass sie zu buerokratisch verpflastert sind und Marketing bzw. Management-Fritzen einfach ihre Finger in Affaeren gesteckt haben ohne die Meinung der eigentlichen Profis zu beruecksichtigen. Ich will ernsthaft bezweifeln dass z.B. zumindest die hw engineers das x86 Zeug leichten Herzens befuerwortet haben.
Uebrigens sind die Barrieren IMO zwischen einem sw und hw engineer nicht so gross in Echtzeit wie sich manche vorstellen wollen. Zwar hat jeder sein eigenes Arbeitsfeld aber ein hw engineer der keinen blassen Schimmer von sw hat und auch umgekehrt, ist im Grund fuer den Job nicht geeignet. Ich wuerde liebend gerne erklaert bekommen wie ein engineer z.B. einen jeglichen Algorithmus entwickelt ohne ein sehr gutes Verstaendnis von beiden Welten zu haben.
Die 64MB werden einmal geschrieben und dann pro Tile gelesen. Die anfallende Bandbreite ist ein Witz gegenüber dem was Framebuffer und Texturen verursachen.Pro Tile 64MB lesen, statt ein "bisschen" Framebuffer, das steht in schlechtem Ratio.
Du kannst doch nicht von der Datenmenge auf die Bandbreite schließen :ugly:
Wenn die Frequenz des Lesens gleich ist, kann ich aufgrund der Datenmenge zumindestens vergleichen.
Nö. Da bin ich mir ganz sicher, dass die Branch-Granularität bei LRB 16 war. Ich such dir das auch gerne raus.Du hast vergessen die Latenz der Instruktionen einzubeziehen. Wenn sie eine nach der anderen abarbeiten würden, dann gebe es so einige Stalls, gerade am Anfang beim Lesen der Inputwerte und am Ende wenn alles aufeinander aufbaut um die finale Pixelfarbe auszugeben.
Deswegen arbeiten sie soviel Pixel gleichzeitig ab, wie Vektorunitbreite x Latenz ist, das machen alle so, so kommt die Warpbreite bei NV zustande.
Wenn du das gut machst, brauchst du nichtmal Transistoren zu verbauen die diese RAW Hazards mit Stalls verhindern, denn es ist von der Architektur her 100% sicher bei den meisten Instruktionen.
Bei denen wo es nicht sicher ist switched man den Fragmentblock/Warp (war beim LRB nicht der Fall, aber NV macht das sicherlich so).
Das Swizzling ist wichtig für die anderen Teile der Pipeline.
Wenn man Gathered read hat, braucht kein Teil der Pipeline swizzling, alles kann man mit SOA abarbeiten, dass das bei SSE usw. nicht so beliebt ist liegt einfach am aufwand erstmal SOA zu erstellen, aber das Problem hast du nicht bei LRB. Du kannst 16Vertices, 16Fragments, 16Trianglesetups, 16Geometryunits abarbeiten und braucht kein Swizzling.
Oder welchen Teil der Pipeline ignoriere ich der verschleissfreier in SOA ist?
Natürlich hat das was mit x86 zu tun. Das hat nunmal nur 16 Register.
Diese sind irrelevant bei der ganzen Grafikarbeit, worauf es ankommt sind die vektoreinheiten. Wenn alles sowieso hinter einem Treiber versteckt ist, kann Intel ohne Probleme, so wie es bei allen GPUs ist, das Binary in ein besseres Format bringen, aber das war ihnen keine Rede wert, die Vektoreinheiten haben Zig mal mehr transitoren als der Pentium und da ist der Instruktionsdekoder komplett egal.
Texturing und Loads können so lange dauern ja. Das ist bei LRB über die TMUs aber auch nicht anders.
Ja, aber es ist irgendwie unsinnig zig Instruktionen zu verbrennen um einen Texturefetch zu triggern. Es ist unsinnig Posteffects mittels TMUs-Fetches zu machen, wenn man Direkt mit den Vektoreinheiten die Buffer bearbeiten kann.
Bei sowas wie Bloom idlen die Vektorunits (und die kann man dann locker verwenden um z.B. float lerps zu berechnen statt das in TMUs mit viel Transistoren zu machen in der Vektor-idle-time), bei soas wie Tonemapping oder Colorgrading kann man mit einem normalen Read auskommen und die TMUs idlen.
GPUs sind nunmal so gebaut um sowenig Transistoren zu verschwenden wie es nur irgendwie geht und alles zum Latenzverstecken einzubauen was man nur denken kann, und das wissen wir alle sicher zumindestens seitdem gewisse GPUs langsammer wurden wenn sie nicht genug Fragments gleichzeitig abarbeiten konnten, weil sie nicht genug register hatten ;)
Bei Intel sehe ich nicht die kleinste Anstrengung verschleiss zu vermindern. Angefangen bei der Softwarearchitektur.
Tja nur ist so ein Projekt wohl weit entfernt von einer hypothetischen "one man show"
Genial waere er gewesen wenn er die unterliegende hw nicht ueberfoerdert haette (mal brutal vereinfacht). Ein balancierte GPU Architektur besteht weder nur aus theoretisch guter sw oder nur aus theoretisch guter hw sondern einer feinen Balance der beiden.
Ich denke auch, dass Abrash ein netter Kerl ist, er ist eindeutig genug motiviert und ergeizig um den besten Assembler code zu schreiben den eine Hardware erlaubt.
Aber es sieht schlichtweg aus als fehle es an Analyse der Konkurenz um wirklich eine Architektur (und damit meine ich Software+Hardware) zu erstellen die Effektiv ist. Es reicht nunmal nicht aus einen low level Rasterizer zu erstellen der mit dem effektivsten Assembler geschrieben ist. Wenn der das Bottleneck sein soll, muss die gesammte Architektur angepasst werden, und nicht nur der "inner loop".
Pro Tile 64MB lesen, statt ein "bisschen" Framebuffer, das steht in schlechtem Ratio.
Es werden nach und nach die Tris gelesen während gerastert wird und die 64MiB sind für das ganze Bild. Ein Tile braucht natürlich weniger Speicher.
Das würde nichtmal eine CPU limitieren mit ihrer viel geringeren Speicherbandbreite.
Wenn die Frequenz des Lesens gleich ist, kann ich aufgrund der Datenmenge zumindestens vergleichen.
Ist sie aber nicht. Nichtmal ansatzweise.
Fahr dich doch nicht so auf den Framebuffer fest. Der Großteil der Bandbreite kommt bei einem TBR von den Textur-Fetches und Load/Store.
Du hast vergessen die Latenz der Instruktionen einzubeziehen.
Das hat damit überhaupt nichts zu tun. Es sind 4x4 Pixel die parallel durch die Programme gehen. Das steht in jedem Material das Intel dazu rausgegeben hat:
We chose a 16-wide VPU as a tradeoff between increased computational density and the difficulty of obtaining high utilization for wider VPUs. Early analysis suggested 88% utilization for typical pixel shader workloads if 16 lanes process 16 separate pixels one component at a time, that is, with separate instructions to process red, green, etc., for 16 pixels at a time
Diese sind irrelevant bei der ganzen Grafikarbeit, worauf es ankommt sind die vektoreinheiten. Wenn alles sowieso hinter einem Treiber versteckt ist, kann Intel ohne Probleme, so wie es bei allen GPUs ist, das Binary in ein besseres Format bringen, aber das war ihnen keine Rede wert, die Vektoreinheiten haben Zig mal mehr transitoren als der Pentium und da ist der Instruktionsdekoder komplett egal.
Das x86 Instruction Encoding hat aber nur begrenzt Platz, außer man macht die Instructions noch viel Größer.
Ja, aber es ist irgendwie unsinnig zig Instruktionen zu verbrennen um einen Texturefetch zu triggern. Es ist unsinnig Posteffects mittels TMUs-Fetches zu machen, wenn man Direkt mit den Vektoreinheiten die Buffer bearbeiten kann.
Bei sowas wie Bloom idlen die Vektorunits (und die kann man dann locker verwenden um z.B. float lerps zu berechnen statt das in TMUs mit viel Transistoren zu machen in der Vektor-idle-time), bei soas wie Tonemapping oder Colorgrading kann man mit einem normalen Read auskommen und die TMUs idlen.
Um das zu vermindern gibt es mehrere Workgroups gleichzeitig auf einem auf einem der Pentium-Cores, nämlich vier soweit ich weiß. Das ist aber wirklich etwas wenig.
deekey777
2011-09-23, 13:57:22
Dell und Intel ergattern Auftrag für 10-Petaflops-Superrechner (http://www.heise.de/newsticker/meldung/Dell-und-Intel-ergattern-Auftrag-fuer-10-Petaflops-Superrechner-1349147.html)
Ab November entsteht am Texas Advanced Supercomputing Center (TACC) in Austin ein neues Rechenzentrum, das ab 2013 den 10-Petaflops-Supercomputer Stampede beherbergen soll. Hauptpartner sind Dell und Intel: Dell produziert mehrere tausende "Zeus"-Server mit je zwei 8-Core-Xeons der kommenden Baureihe E5 (Sandy Bridge-EP) sowie 32 GByte RAM. Die CPU-Kerne liefern zusammen 2 PFlops. Die restlichen 8 PFlops bringen "Knights Corner"-Steckkarten: Diese Verkörperung der Many Integrated Cores-(MIC-)Architektur von Intel ist eine Fortentwicklung des Larrabee, an dem Intel seit 2006 arbeitet. Zurzeit liefert Intel den Knights-Corner-Vorläufer Knights Ferry an einige Entwickler aus.
Oder gleich einen neuen Thread für Knights Corner?
Gibt ja sogut wie keine Informationen bisher. Ich bin z.B. gespannt, ob das Ding weiterhin TMUs haben wird.
Screemer
2011-09-23, 16:56:08
knights corner ist dann also der nachfolger der knights ferry karten?
Skysnake
2011-09-23, 22:22:48
Ja war so vom Werdegang her:
Larrabee->Ferry Knights->Knights Corner(->MIC)
Ist wirklich Ferry Knights und nicht Knights Ferry ;) zumindest soweit ich mich erinnere.
Larrabee ist Knights Ferry.
Felixxz2
2011-09-24, 00:57:53
Naja nicht wirklich, AFAIK ist Knights Ferry zwar eine Weiterentwicklung innerhalb des Larrabeeprojekts, aber eine wirkliche Larrabee Karte unter dem Codenamen hat Intel nie öffentlich gezeigt. Es gab nur die Meldung, dass Intel mit starkem OC es geschaft hat, den Chip über 1 TFLOPs zu hieven und das in einer Zeit wo AMD/nVidia die 1 TFLOPs schon mit Standarttakt geknackt hatten und sogar noch zusätzliche Hardwareeinheiten hatten. Deswegen wurde das Teil dann ja auch eingestampft.
Naja doch. Knights Ferry ist Larrabee ohne Display-Ausgang. Der Chip ist der gleiche.
Ailuros
2011-09-25, 08:56:51
Naja nicht wirklich, AFAIK ist Knights Ferry zwar eine Weiterentwicklung innerhalb des Larrabeeprojekts, aber eine wirkliche Larrabee Karte unter dem Codenamen hat Intel nie öffentlich gezeigt. Es gab nur die Meldung, dass Intel mit starkem OC es geschaft hat, den Chip über 1 TFLOPs zu hieven und das in einer Zeit wo AMD/nVidia die 1 TFLOPs schon mit Standarttakt geknackt hatten und sogar noch zusätzliche Hardwareeinheiten hatten. Deswegen wurde das Teil dann ja auch eingestampft.
Coda duerfte recht haben ausser man meint mit "weiter-Entwicklung" einen die shrink. Das eigentliche LRB Leistungsproblem lag weniger im GFLOP Bereich und mehr insgesamt im Desing fuer eine konkurrierende GPU vor Jahren, sonst wuerde heute und in der Zukunft ein jeglicher LRB Ableger auch nichts wert sein fuer HPC Maerkte. Knights Ferry MICs die fuer den Stampede Supercomputer geplant sind sind >50 core bei 22nm. Erstens eine sehr hohe Anzahl an cores mehr als beim originalen LRB und hoechstwahrscheinlich auch bei um einiges hoeheren Frequenzen unter Intel 22nm, denn der Abstand zwischen 45nm (LRB Prime) und 22nm ist auch ziemlich gross.
Skysnake
2011-09-25, 11:01:28
Tri-Gate wird da wohl noch dazu kommen.
Was Intel aktuell macht ist halt die Leistungsaufnahme drücken, und damit eben die Effizientz steigern, und genau DAS ist wichtig für den HPC-Bereich. Effizienz ist da das ausschlaggebende Wort.
Naja, und was für LRB spricht ist natürlich auch, das man keine GPU-Programmierer brauch, die den Code anpassen. Aus LRB sagen wir mal 80% der Leistung raus zu kitzeln, wird um ein vielfaches einfacher sein als bei einer GPU. DAS könnte auch ein Verkaufsargument sein.
Was bringt mir eine gewaltige theoretische Rechenleistung, wenn für mein Problem die Speicherbandbreite/Cachebandbreite/-größe limitiert, und ich die Leistung einfach nicht auf den Boden bekomme, bei einem anderen Produkt trotz weniger theoretische Leistung aber mehr auf den Boden bekomme.
Mit GCN und Kepler könnte sich diesbezüglich allerdings sehr vieles Ändern.
Intel steht sehr unter Zeitdruck. Sowohl ATI/AMD als auch nVidia haben das Problem erkannt, und arbeiten daran es zu lösen. Wenn Intel es nicht schafft endlich mal Karten in den Markt zu drücken und vor allem konkurrenzfähig zu sein, kann es sehr schnell passieren, das die von ihnen genannten Vorteile hinfällig sind.
Naja, und was für LRB spricht ist natürlich auch, das man keine GPU-Programmierer brauch, die den Code anpassen. Aus LRB sagen wir mal 80% der Leistung raus zu kitzeln, wird um ein vielfaches einfacher sein als bei einer GPU.
Seh ich völlig anders. Das schwierige daran sind die dafür nötigen, massiv parallelen Algorithmen, und da unterscheidet sich LRB nicht großartig von GPUs.
Auch muss man um die Leistung auszunutzen LRBni verwenden, und dann hat man wieder exakt die gleichen Probleme wie bei GPUs (Branch divergenz zwischen "Threads", Synchronisierungspunkte, etc.)
Manuelle Thread-Verwaltung mit SIMD-Programmierung ist zudem aufwändiger als das GPGPU-Model. Die einfachste Möglichkeit gescheite Performance aus LRB zu bekommen ist also genauso wie bei GPUs OpenCL, mit allen Vor- und Nachteilen.
Skysnake
2011-09-25, 15:05:48
die Algorithmen sind kein Thema. Die braucht man eh.
Mit was MIC läuft ist halt die Frage. MPI/OpenMP wäre genauso denkbar. Also MPI wird wohl eh eingesetzt. Beim Rest ist man ja ziemlich offen. MIC nutzt ja X86.
Anja, vielleicht erfahre ich dazu ja etwas demnächst ^^
die Algorithmen sind kein Thema. Die braucht man eh.
Das ist *das* Thema um Leistung aus einer Many-Core-Architektur "rauszukitzeln". Wie kommst du also zu dem Schluss, dass das bei Larrabee "viel einfacher" sein sollte?
Und selbst abgesehen davon, halte ich das für einen Trugschluss. Was am x86-Programmiermodell hilft dir denn da viel ggü. CUDA mit Compute Capability 2.0? (In Annahme, dass du 80% der Leistung verwenden willst, natürlich).
Einfach bisschen OpenMP in eine bestehende C-Software reinzuwerfen wird nicht funktionieren.
Wie gesagt, es ist sehr mühselig mit SIMD datenparallel zu programmieren in C/C++, weil man sich dauernd selber um die Branch-Divergenzen etc. kümmern muss. OpenCL/CUDA abstrahieren das komplett weg. Und ohne das, bekommst du keinen schnellen Code auf LRB hin.
Skysnake
2011-09-25, 15:31:50
es hilft einem, das man Programmierer hat, die seit Jahren für Cluster Software schreiben, von Cuda/OpenCL aber 0 Plan haben. Bei x86 musst du dich halt nicht um die Caches kümmern. Fermi geht da in die richtige Richtung, bei der hd5k/6k ist man dort aber noch nicht.
es hilft einem, das man Programmierer hat, die seit Jahren für Cluster Software schreiben, von Cuda/OpenCL aber 0 Plan haben.
Leute, die davon wirklich Ahnung haben, werden sich in OpenCL innerhalb von einer Woche eingearbeitet haben.
Und von was für Cluster-Software reden wir hier? SIMD optimiert oder nicht? Inwiefern SIMD optimiert? Peephole oder auch was die Datenstrukturen angeht (AOS vs. SOA)? Falls sie das datenparallel Konzept dahinter nicht verinnerlicht haben, werden diese Leute auch auf Larrabee Code schreiben, der höchstens einen Bruchteil der Performance ausschöpft.
Bei x86 musst du dich halt nicht um die Caches kümmern. Fermi geht da in die richtige Richtung, bei der hd5k/6k ist man dort aber noch nicht.
Sobald du Cache Cohärenz in einem performance kritischen Codeteil brauchst bist du ohnehin tot. Vor allem bei LRB.
Skysnake
2011-09-25, 16:21:18
du brauchst dir aber halt allgemein um weniger Gedanken machen, damit bleibt mehr Zeit für die kritischen Dinge übrig.
was du für Probleme mit SIMD siehst verstehe ich allerdings nicht. Das ist doch meist sehr intuitiv, einfach aufgrund der datenstrucktur/dem Problem gegeben.
du brauchst dir aber halt allgemein um weniger Gedanken machen, damit bleibt mehr Zeit für die kritischen Dinge übrig.
Dann hätte ich gerne mal ein konkretes Beispiel dafür.
was du für Probleme mit SIMD siehst verstehe ich allerdings nicht. Das ist doch meist sehr intuitiv, einfach aufgrund der datenstrucktur/dem Problem gegeben.
Ist es eben nicht. Der intuitive Ansatz ist es bspw. einen RGBA-Vektor in ein SIMD-Register zu laden und damit rumzurechnen. Das ist aber aus verschiedenen Gründen nicht der richtige Weg um schnellen Code zu bekommen.
Du willst pro Element im SIMD Register einen "Thread" ausführen, also bspw. die Farbberechnung für einen Pixel. Bei Sprüngen muss dann entsprechend maskiert werden etc. Damit hältst du deine Daten schön lokal beisamen im Cache und bekommst die höchste Auslastung der SIMD-Einheiten. Das macht OpenCL für dich automatisch. LRBni hat dafür auch entsprechende Befehlssatz-Eigenschaften.
Es hat schon seinen Grund, warum Intel so lange die Dot-Product-Instruction in SSE verweigert hat. Wer die braucht, programmiert falsch :tongue:
Skysnake
2011-09-25, 16:44:13
ja ich muss die Daten nicht explizit kopieren.
wer redet hier von rendersachen?
denk mal eher an fluid-Simulationen, wärme-platte, n-body-Simulation, Wettervorhersage usw.
da hast du immer die gleiche Struktur was die Sprünge angeht.
ja ich muss die Daten nicht explizit kopieren.
???
wer redet hier von rendersachen?
denk mal eher an fluid-Simulationen, wärme-platte, n-body-Simulation, Wettervorhersage usw.
Spielt keine Rolle, da gilt exakt das gleiche.
Ich glaube du verstehst mich gerade einfach nicht.
Skysnake
2011-09-25, 17:54:01
Na ich muss erst mal die Daten vom RAM auf die GPU kopiern, dann muss ich die Daten aus dem V-RAM in den shared Mem laden, (Fermi) bzw. von dort dann noch mal in den local Mem (ATI/AMD). Das sind halt Sachen, wo man Zugriffsmuster sich überlegen muss, und wie man das dann am geschicktesten macht mit prefetching, maximaler Ausnutzung der Cachegröße, welches Datenformat nutze ich, etc. etc. etc.
Bei ner x86 Architektur, werf ich das in den RAM, eventuell muss ich noch expliziet auf MIC kopieren, dann wars das aber. Gut ich muss mir die Sachen noch überlegen, wie ich die Datenlokalität maximiere, aber ich muss da nicht so viel von Hand implementieren. Die Caches sind halt transparent für mich als Programmierer. Das ist schon eine SEHR große Erleichterung. Falsche Datenzugriffe nämlich zu debuggen ist auf der GPU echt hässlich.....
deekey777
2011-11-16, 10:10:11
Supercomputer 2011: CPU mit "Many Integrated Cores" knackt 1 TFlops (http://www.heise.de/newsticker/meldung/Supercomputer-2011-CPU-mit-Many-Integrated-Cores-knackt-1-TFlops-1379625.html)
Knights Corner wird im neuen 22-nm-Prozess gefertigt; er dürfte in etwa gleichzeitig zu Nvidias Kepler-Version für HPC im dritten Quartal 2012 herauskommen. Kepler soll bei 1,3 Teraflops im DGEMM liegen. Bei den GPUs hängt die Performance aber sehr stark von der Matrixgröße ab, Intel ließ die Matrizen über verschiedene Blockgrößen laufen, um die "Unempfindlichkeit" von Knights Corner zu demonstrieren: Der Zeiger schwankte nur ein bisschen, blieb aber stets bei über 1 TFlops.
AnarchX
2011-11-16, 11:04:20
Über die GFLOPs pro Watt schweigt man sich wohl noch aus...
Ailuros
2011-11-16, 11:13:52
Über die GFLOPs pro Watt schweigt man sich wohl noch aus...
Bei 64 cores und Supercomputers ist es nicht der einzige Faktor. Perf/mm2 (egal ob 22nm denn es sind ja 64 cores) und auch perf/$.
Wenn man einen theoretischen MP64 Rogue cluster auf 1.5GHz takten wuerde, hat man fast 2x Mal so hohe SP TFLOP Raten.
Die Vektoreinheit ist 512 Bit breit; man munkelt, dass der Nachfolger Knights Landing sie möglicherweise auf 1024 Bit verbreitern wird.
Kann sein dass dann ein wahres 2:1 SP<-->DP Verhaeltnis moeglich ist.
deekey777
2011-11-16, 11:26:19
Über die GFLOPs pro Watt schweigt man sich wohl noch aus...
Für den Fall, dass KF mehr verbraucht als eine Grafikkarte: Den Mehrverbrauch wird man gern in Kauf nehmen, wenn dies mit einer deutlicher Flexibilität erkauft wird.
Ailuros
2011-11-16, 11:39:03
Für den Fall, dass KF mehr verbraucht als eine Grafikkarte: Den Mehrverbrauch wird man gern in Kauf nehmen, wenn dies mit einer deutlicher Flexibilität erkauft wird.
Dafuer braeuchte man einen Vergleich bei gleichen Matrixgroessen zwischen einer jeglichen zukuenftigen GPU und KF.
Ich hatte das Thema ja schonmal, aber meiner Meinung nach ist Larrabee für HPC eh gar nicht so viel flexibler, wie getan wird als CUDA 2.0.
Standard x86-Software ist dafür sowieso nicht zu gebrauchen.
Kann sein dass dann ein wahres 2:1 SP<-->DP Verhaeltnis moeglich ist.
Was hat da denn bei Larrabee gefehlt? Das hat mit der Breite aber eher nichts zu tun.
Ailuros
2011-11-16, 15:53:47
Was hat da denn bei Larrabee gefehlt? Das hat mit der Breite aber eher nichts zu tun.
Als Intel in der Vergangenheit "half rate" fuer DP behaupteten, meinten sie hoechstwahrscheinlich "half the vector width rate" da der ALU path "nur" 512bits breit ist. Wenn die diesen path jetzt doppelt so breit anlegen koennte ich mir leicht vorstellen dass sie vielleicht 2:1 anlegen wollen.
Spasstiger
2011-11-17, 01:30:28
Sollte man eigentlich nicht mal den Thread umbenennen in "Intel Many Integrated Core Architecture (http://www.intel.com/content/www/us/en/architecture-and-technology/many-integrated-core/intel-many-integrated-core-architecture.html)"? Larrabee ist ja eigentlich nur noch ein Teilkapitel des Threads.
Über die GFLOPs pro Watt schweigt man sich wohl noch aus...
Ja, dazu hab ich mir auch schon einen Wolf gesucht. Nichtmal zu Knights Ferry findet man konkrete Angaben. Ordentlich Abwärme produzieren die wohl schon mit 610 GFlops peak (dp): http://www.pcgameshardware.de/aid,814158/Cebit-2011-Cloud-Raytracing-mit-vier-Knights-Ferry-Karten-in-Aktion/Grafikkarte/News/.
Andererseits: Schon zwei GTX 480 @ SLI im offenen Aufbau empfand ich als Heizlüfter. Und in dem Demo-Rechner auf der Cebit werkelten vier Knights-Ferry-Karten.
Als Intel in der Vergangenheit "half rate" fuer DP behaupteten, meinten sie hoechstwahrscheinlich "half the vector width rate" da der ALU path "nur" 512bits breit ist. Wenn die diesen path jetzt doppelt so breit anlegen koennte ich mir leicht vorstellen dass sie vielleicht 2:1 anlegen wollen.
Hä? LRB hat 2:1 DP:SP. Da braucht man nichts ändern. Mit 1024 bit wäre es immer noch 2:1. Du brauchst halt zwei ALUs für eine DP-Op.
Ailuros
2011-11-17, 10:20:52
Hä? LRB hat 2:1 DP:SP. Da braucht man nichts ändern. Mit 1024 bit wäre es immer noch 2:1. Du brauchst halt zwei ALUs für eine DP-Op.
Ich hatte stets den Eindruck dass es Marketing-Geblubber ist und dank dem ALU path doch am Ende nur 4:1 rauskommt. Gibt es irgend einen Link bzw. Messung irgendwo der 2:1 auch wirklich bestaetigt? Denn das vorige kam direkt von deren engineering team.
uweskw
2011-12-03, 17:00:29
J
...... Nämlich MIC mit 1 TFlop/s bei DGEMM und gerade einmal 150W Leistungsaufnahme. Das müssen beide einfach übertreffen, ......
Bin ich der einzige der nur Bahnhof versteht?
Falls ja, hat jemand ne kurze Erklärung oder nen Link?
greetz
U.S.
Knuddelbearli
2011-12-03, 17:12:14
denke mal er meint
http://de.wikipedia.org/wiki/Mehrkernprozessor#Manycore-Prozessoren
Skysnake
2011-12-03, 17:24:23
Bin ich der einzige der nur Bahnhof versteht?
Falls ja, hat jemand ne kurze Erklärung oder nen Link?
greetz
U.S.
Ich mein das hier: http://www.heise.de/newsticker/meldung/Supercomputer-2011-CPU-mit-Many-Integrated-Cores-knackt-1-TFlops-1379625.html
Dagegen muss AMD und nVidia antreten. Die aktuellen nVidias schaffen grad mal 360 (380) GFlop/s bei DGEMM. Eine Verdoppelung der Leistungsfähigkeit würde also bei weitem nicht ausreichen, um gegen MIC bestehen zu können.
Wenn man jetzt noch bedenkt, das man eigentlich nicht damit gerechnet hat, dass das Ding so schnell wird wie GPUs, dafür aber deutlich leichter effizient zu programmieren sein wird, dann wirds ganz bitter....
Gab ja schon einige Meldungen zu MIC, das innerhalb weniger Stunden eine Portierung auf MIC möglich war. Mit GPUs haste eigentlich immer ein gefrickel, bis das Zeug so läuft wie du willst.
Knuddelbearli
2011-12-03, 18:09:39
naja dort steht aber auch kein Wort zum Verbrauch, und Größe des DIEs also abwarten und Tee trinken
Hugo78
2011-12-03, 18:38:12
@Skysnake
Wo steht da was von 150W?
Ich behaupte 22nm + Tri-Gate wird MIC überhaupt erst beherrschbar machen.
Skysnake
2011-12-03, 20:40:09
@Skysnake
Wo steht da was von 150W?
Ich behaupte 22nm + Tri-Gate wird MIC überhaupt erst beherrschbar machen.
Wurde auf der SC in Seattle von Intel genannt. Keine Ahnung, ob das irgendwo berichtet wurde, ich habs halt von jemanden, der dort war.
Hugo78
2011-12-03, 20:53:56
@Skysnake
Dann müssen alle anderen Reporter bei diesem sensationellen Detail gepennt haben und das kann ich mir nicht vorstellen.
Bei Knights Ferry blieb man jede Antwort in Punkto TDP schuldig.
Das letzte Bild vom 32nm Knights Ferry sah dann aber so aus.
http://www8.pic-upload.de/03.12.11/zg7p9qinfhnt.jpg
Jetzt waren das 32 Cores in 32nm.
Skysnake
2011-12-03, 21:36:28
@Skysnake
Dann müssen alle anderen Reporter bei diesem sensationellen Detail gepennt haben und das kann ich mir nicht vorstellen.
Bei Knights Ferry blieb man jede Antwort in Punkto TDP schuldig.
Das letzte Bild vom 32nm Knights Ferry sah dann aber so aus.
http://www8.pic-upload.de/03.12.11/zg7p9qinfhnt.jpg
Jetzt waren das 32 Cores in 32nm.
da ist aber auch kaum jemand, da es teuer ist wie sau.
die meisten schreiben halt voneinander ab.
irgendwo hatte es aber auch ne Redaktion geschrieben. kannst ja mal schauen, wenn du daran zweifelst.
Hugo78
2011-12-03, 23:43:24
kannst ja mal schauen, wenn du daran zweifelst.
Ja ist klar...
LovesuckZ
2011-12-04, 00:01:50
Es gibt überhaupt keine Aussage von Intel in Bezug auf den Stromverbrauch. Und die einzige relevante Aussage in Bereich HPC war über ein 10 Petaflops System im Jahr 2013. Keine Ahnung, wieso Intel wieder auf ein Podest gehoben wird, nachdem das ganze auch schon bei Larrabee mehr als nur scheiterte.
Skysnake
2011-12-04, 09:48:41
Ja ist klar...
guckst du hier, der redet z.B. von 150W- http://translate.googleusercontent.com/translate_c?hl=de&ie=UTF8&prev=_t&rurl=translate.google.de&sl=ja&tl=de&u=http://d.hatena.ne.jp/Gasyou/20111119/1321674338&usg=ALkJrhj_1yD_On17xk_yrdCwnu-nkfZ2lg#20111119fn1
Ich muss sagen, es war aber wirklich schwer zu finden. Stand wohl unter NDA und Intel hat den Leuten ganz kräftig auf die Finger gehauen :freak:
AnarchX
2011-12-04, 09:53:02
Steht da nicht eher, dass die S.2011 kompatible Version eine TDP von 130-150W haben sollte? Nicht unbedingt eine Aussage über den Verbrauch der 1TF-Demo-Version.
Skysnake
2011-12-04, 10:13:23
Es hieß aber wohl auf der Messe, das man die 1TFlop eben in der realen Anwendung DGEMM bei 150W erreicht haben soll. Dass das mit ner QPI-Version gewesen sein kann, klingt gar nicht so unrealistisch. Da müsste man nämlich nicht unbedingt den Energieverbrauch für den RAM mit rein rechnen, der ja schon auch ein paar Watt aus macht.
Trotzdem hört es sich für mich für zu wenig an, aber die Aussage gibt es halt. Ich hoffe ja, das es bald mal neue Infos zu MIC gibt und die nicht immer diese Geheimniskrämerei betreiben bei Intel.... Sonst sind die doch auch nicht so zugeknöpft...
Naja, vielleicht nach der Vorstellung der HD7k und der GTX600er Serie. Hoffen wir es mal.
PS: steht der Termin mit 5. Dezember jetzt eigentlich noch?
Wieviel Bandbreite liefert das Quad-Channel-Interface von Sockel 2011?
AnarchX
2011-12-04, 13:42:09
Ist wohl bis DDR3-1600 freigegeben: 51,2GB/s.
Dural
2011-12-04, 14:37:04
so wie ich Intel kenne hat die 1TF Version 300Watt gezogen, 150Watt ja klar...
wenn schon eine 32 Kern 32nm Version kaum sinn voll herzustellen ist, dürfte es bei 22nm und 64 Kerne nicht einfacher sein, eher das gegenteil wird der fall sein...
Skysnake
2011-12-04, 16:55:24
Ist wohl bis DDR3-1600 freigegeben: 51,2GB/s.
Das wäre aber arg wenig.
Man muss aber auch noch schauen, wie Sie QPI nutzen. Je nach dem wird dieser eben genutzt um den Durchsatz zu erhöhen, indem man die Daten verteilt. Da würde es dann etwas mehr werden. Im Optimalfall 12GB/s pro QPI-Link.
Ich tendiere aber am ehesten dazu, das Sie DRAM mit auf den Träger gepackt haben. Der HeatSpreader ist einfach GIGANTISCH. Kann mir kaum vorstellen, dass das so ein Monsterchip geworden ist.
dildo4u
2011-12-04, 16:58:38
so wie ich Intel kenne hat die 1TF Version 300Watt gezogen, 150Watt ja klar...
wenn schon eine 32 Kern 32nm Version kaum sinn voll herzustellen ist, dürfte es bei 22nm und 64 Kerne nicht einfacher sein, eher das gegenteil wird der fall sein...
Deshalb sind's keine 64 sondern was um 50.
Hugo78
2011-12-04, 17:08:50
Ich tendiere aber am ehesten dazu, das Sie DRAM mit auf den Träger gepackt haben. Der HeatSpreader ist einfach GIGANTISCH. Kann mir kaum vorstellen, dass das so ein Monsterchip geworden ist.
Du Knights Ferry schaut auch nicht viel kleiner aus.
http://www7.pic-upload.de/thumb/04.12.11/gnp3qmp1p6ld.jpg (http://www.pic-upload.de/view-12196530/1.jpg.html)
- http://www.computerbase.de/bildstrecke/30921/8/
http://www7.pic-upload.de/thumb/04.12.11/utjjctpe9om3.jpg (http://www.pic-upload.de/view-12196577/7.jpg.html)
- http://www.computerbase.de/bildstrecke/30921/7/
Knights Ferry hatte neben L1 und 2 auch noch 8 mb Cache, wenn Knights Corner jetzt 16mb hat dann wird das allein schon viel Fläche verbraten.
AnarchX
2011-12-04, 17:16:22
LRB@45nm war wohl um die 350mm² groß: http://www.forum-3dcenter.org/vbulletin
/showthread.php?p=7224565#post7224565
edit: >600mm²: http://www.forum-3dcenter.org/vbulletin/showthread.php?p=7225638#post7225638
Da sollte bei vergleichbarer Größe unter 22nm wohl deutlich mehr als 64 Kerne möglich sein.
Aber möglicherweise hat man hier ein paar Transistoren in die Pro-Watt-Leistung gesteckt und vielleicht auch den Cache stärker erhöht, sodass es 64 Kerne bei ~300mm² sein könnten.
On-Package-DRAM wäre natürlich ein nette Sache.
Mit 22nm und 64 Kernen sollte man doch unter der Die-Size von LRB1 liegen.
Deshalb sind's keine 64 sondern was um 50.
Ich kann mir nicht vorstellen, dass Intel in 22nm ein Problem hätte 64 Cores für die größte Version in ausreichenden Mengen zu fertigen.
dildo4u
2011-12-04, 17:30:24
Vieleicht sind ja 64 drauf und je besser die Yields werden um so weniger werden dafür als Redundanz benötigt.Jedenfalls ist in jeder News zu Knights Corner von ca 50 die Rede.
Ja, weil einer mal damit angefangen hat und jeder davon abschreibt.
AnarchX
2011-12-04, 19:19:19
Intel hat damit angefangen: http://scr3.golem.de/screenshots/1005/Intel_Knights_Corner/thumb480/DSC_1953.jpg ;)
Aber man spricht dort von >50, im Endeffekt wohl die 64 Kerne abzüglich Yield und dem Steuer-OS.
Hugo78
2011-12-04, 19:51:24
Was soll das überhaupt mit dem "Mini Linux"?
Ist das einfach nur ein PR Stunt und andere nennen sowas einfach Treiber oder welcher tiefere Sinn/Notwendigkeit könnte dahinterstehen?!
Skysnake
2011-12-04, 21:47:25
nein, das ist nicht nur PR.
Bei einer GPU oder sonstigen Erweiterungskarte, die du über PCI-E etc. anbindest, brauchst du immer ein Host-System (also eine CPU), welches das Device steuert.
Bei MIC ist das nicht so. Du kannst die CPU/Host-System einfach weg lassen, da du einfach auf MIC ein OS laufen lässt.
Wenn es die Sockel-Variante, wovon ich sehr sehr sehr stark aus gehe, wirklich gibt, dann brauchst du in einen Knoten keine CPU mehr rein packen, sondern einfach nur MICs und das wars.
Du kannst auch komplett andere MB-Layouts entwerfen etc.
Ailuros
2011-12-05, 15:46:12
Es sind uebrigens 64 cores in Knights Corner sonst wuerden sie nie 1 TFLOPs DP erreichen.
64 cores mit jeweils Vec16/core bei 1GHz.
Nighthawk13
2011-12-05, 16:09:29
Gibt's schon Informationen über das angepeilte Programmiermodell von Kinghts Corner?
Wird man als Programmierer einen Thread für...
a.) jeden CPU-Core programmieren, und die Vektorregister direkt ansprechen(vgl. CPU mit SSE)
b.) jede Vektorlane(aka Cudacore;)) programmieren, und Vektorarchitektur wird "versteckt" (vgl. GPU mit CUDA/OpenCL)
Für b.) müsste die Hardware GPU-mässig aufgebohrt werden für bedingte Sprünge(Lanemasking, Reconvergence Stack,...). Gab's dazu schon Infos?
del_4901
2011-12-05, 16:50:45
c.) functional Programming
Für b.) müsste die Hardware GPU-mässig aufgebohrt werden für bedingte Sprünge(Lanemasking, Reconvergence Stack,...). Gab's dazu schon Infos?
Hm? Das konnte sogar schon Knights Ferry soweit ich weiß.
Nighthawk13
2011-12-05, 18:36:13
Hm? Das konnte sogar schon Knights Ferry soweit ich weiß.
ActiveMask (aka Predication) ja, stimmt: http://www.stanford.edu/class/ee380/Abstracts/100106-slides.pdf. Zu dem Reconvergence Stack hab ich nix spezielles gefunden. Aber wenn ich drüber nachdenke, kann man den komplett in Software implementieren, in x86 gibts ja im Gegensatz zu Nvidias ISA schon nen Hardware-Stack.
Ja klar, dafür nimmt man halt den normalen x86-Stack.
deekey777
2012-06-18, 15:12:42
Da ist er wieder:
ISC12: Intel stellt HPC-Beschleuniger Xeon Phi vor (http://www.heise.de/newsticker/meldung/ISC12-Intel-stellt-HPC-Beschleuniger-Xeon-Phi-vor-1619632.html)
Und einen neuen Namen hat er auch. Aktuell nur 54 Kerne an, aber ein TFLOP DP-Leistung ist schon nicht schlecht.
john carmack
2012-06-18, 16:07:12
http://www.computerbase.de/news/2012-06/intel-stellt-knights-corner-als-xeon-phi-vor/
...., aber ein TFLOP DP-Leistung ist schon nicht schlecht.
na ich sag mal: geht so ...
AMDs 7970 schafft das auch (als Consumerkarte, ohne ECC) und die kommende
FirePro W9000 (mit ECC) folglich auch...
und beide sehr wahrscheinlich mit nem deutlich kleineren Chip...
Nvidia dümpelt z.Zt. mit iheren Teslas noch bei gut der Hälfte - aber das ändert sich ja hoffentlich bald mit dem GK110
(Oder hängt der Vergleich mit diesen Zahlen noch irgendwo?)
Gipsel
2012-06-18, 17:01:30
na ich sag mal: geht so ...
AMDs 7970 schafft das auch (als Consumerkarte, ohne ECC) und die kommende
FirePro W9000 (mit ECC) folglich auch...
und beide sehr wahrscheinlich mit nem deutlich kleineren Chip...
Nvidia dümpelt z.Zt. mit iheren Teslas noch bei gut der Hälfte - aber das ändert sich ja hoffentlich bald mit dem GK110
(Oder hängt der Vergleich mit diesen Zahlen noch irgendwo?)
Ja, Intel produziert die schon in 22nm, was im Prinzip eine ~60% höhere Packdichte gegenüber 28nm ermöglicht (ist aber schwierig so zu vergleichen, insbesondere zwischen verschiedenen Herstellern). Also bei gleicher Die-Fläche werden die Intel-Teile vermutlich deutlich mehr Transistoren besitzen (oder den Spielraum zumindest zum Teil für ein Tuning auf mehr Takt benutzen). Insofern sind 1 TFlop/s in 225W nicht wirklich doll zu nennen.
scheinbar ist es doch noch weniger:
"But we won't have to wait for November to hear about Linpack running on MIC machines. According to Intel's Rajeeb Hazra, Intel's GM of the Technical Computing group, they've been running the High Performance Linpack (HPL) benchmark on pre-production parts and have been able to achieve one teraflop on a single node equipped with a Knights Corner chip. That teraflop, by the way, is provided by the Knights Corner card plus the two Xeon E5 host CPUs, so the MIC chip itself is likely delivering something in the neighborhood of 700 to 800 gigaflops."
http://www.hpcwire.com/hpcwire/2012-06-18/intel_will_ship_knights_corner_chip_in_2012.html
Gipsel
2012-06-18, 17:42:27
scheinbar ist es doch noch weniger:
"[..] That teraflop, by the way, is provided by the Knights Corner card plus the two Xeon E5 host CPUs, so the MIC chip itself is likely delivering something in the neighborhood of 700 to 800 gigaflops."
http://www.hpcwire.com/hpcwire/2012-06-18/intel_will_ship_knights_corner_chip_in_2012.html
Okay, das schafft ein Tahiti dann wirklich schon. Aber HPL/DGEMM ist ja auch beinahe best case für GPUs (okay, für nV bisher nicht so ganz wegen zu kleiner Registerfiles). MICs Stärke soll ja sein, die Leistung auch bei etwas anspruchsvolleren Problemen etwas besser auf die Straße zu bringen. Mal sehen, ob das dann auch stimmt.
Edit:
Diese Zahlen stammen übrigens von pre-production Versionen, auf denen nur 54 Kerne aktiv waren. Auf der finalen Version soll es laut c't (http://www.heise.de/newsticker/meldung/ISC12-Intel-stellt-HPC-Beschleuniger-Xeon-Phi-vor-1619632.html) 62 aktive Kerne geben (zwei bleiben also aus, die mangelnde Ausbeute an voll funktionstüchtigen [und relativ großen] Dies dürfte beim noch recht neuen 22nm Prozeß der Grund dafür sein, ist aber zu verschmerzen).
Okay, das schafft ein Tahiti dann wirklich schon. Aber HPL/DGEMM ist ja auch beinahe best case für GPUs (okay, für nV bisher nicht so ganz wegen zu kleiner Registerfiles). MICs Stärke soll ja sein, die Leistung auch bei etwas anspruchsvolleren Problemen etwas besser auf die Straße zu bringen. Mal sehen, ob das dann auch stimmt.
Edit:
Diese Zahlen stammen übrigens von pre-production Versionen, auf denen nur 54 Kerne aktiv waren. Auf der finalen Version soll es laut c't (http://www.heise.de/newsticker/meldung/ISC12-Intel-stellt-HPC-Beschleuniger-Xeon-Phi-vor-1619632.html) 62 aktive Kerne geben (zwei bleiben also aus, die mangelnde Ausbeute an voll funktionstüchtigen [und relativ großen] Dies dürfte beim noch recht neuen 22nm Prozeß der Grund dafür sein, ist aber zu verschmerzen).
=> ok, dann ist man bei 900GFLO/s...
die Frage ist dann noch: liefen die "pre-production Versionen" schon auf dem beim Release geplanten Takt?
aber eine "Ghz Edition" 7970/ Firepro (wie sie beim Release von der XEON PHI ja mindestens verfügbar ist) hat ja wiederum auch 1000-1100GFLO/s (theoretisch)...
mboeller
2012-06-18, 19:38:23
scheinbar ist es doch noch weniger:
"But we won't have to wait for November to hear about Linpack running on MIC machines. According to Intel's Rajeeb Hazra, Intel's GM of the Technical Computing group, they've been running the High Performance Linpack (HPL) benchmark on pre-production parts and have been able to achieve one teraflop on a single node equipped with a Knights Corner chip. That teraflop, by the way, is provided by the Knights Corner card plus the two Xeon E5 host CPUs, so the MIC chip itself is likely delivering something in the neighborhood of 700 to 800 gigaflops."
http://www.hpcwire.com/hpcwire/2012-06-18/intel_will_ship_knights_corner_chip_in_2012.html
Also ~900 GFlops im Linpack bei 62 Kernen, oder?
Linpack benutzt aber doch AFAIK eine Mischung aus SP und DP - Code?
Gipsel
2012-06-18, 19:46:23
Also ~900 GFlops im Linpack bei 62 Kernen, oder?Der Takt der finalen Versionen ist die zweite unbekannte Größe.
Linpack benutzt aber doch AFAIK eine Mischung aus SP und DP - Code?Nein, alles DP (zumindest in dem Umfeld).
Skysnake
2012-07-30, 21:18:28
Hust hust ;)
http://extreme.pcgameshardware.de/user-news/229348-neue-bilder-von-xeonphi-pcb-denseformfactor-und-pci-e.html
Hoffe es gefällt ;D
ja gefällt :-)
5 GFLOP/W
16GB Speicher
512 bit Breite Speicheranbindung
=> u.a. die Speichermenge (wenn sie denn wirklich so groß ist) könnte ein Vorteil gegenüber GK110 sein...
Anfang nächsten Jahres wissen wir mehr :-)
Gipsel
2012-07-31, 11:03:49
Skysnake hat bei PCGH übrigens auch einen Direktlink zum DEEP-pdf reingestellt (http://www.deep-project.eu/SharedDocs/Downloads/DEEP-PROJECT/EN/Presentations/ISC12-Presentation-Lippert.pdf?__blob=publicationFile).
ja gefällt :-)
5 GFLOP/W
16GB Speicher
512 bit Breite Speicheranbindung
=> u.a. die Speichermenge (wenn sie denn wirklich so groß ist) könnte ein Vorteil gegenüber GK110 sein...
Anfang nächsten Jahres wissen wir mehr :-)
16GB sind auf den momentanen Versionen nie und nimmer drauf. Die gezeigten Karten sind zum einen nur einseitig bestückt und die größten käuflich erwerbbaren Chips haben nur 2 GBit. Man kommt also nur auf 4GB bei den gezeigten Samples, 8GB bei doppelseitig bestückten. Für 16GB muß man noch auf 4GBit-Chips warten.
Skysnake
2012-07-31, 13:42:33
Gipsel, den hab ich hier mit absicht nicht reingestellt, ich muss noch was schauen, und hier sind die Leute zu aufmerksam ;)
AnarchX
2012-07-31, 13:49:39
VR-Zone mit wohl genaueren Daten zu Core-Zahl und Taktraten:
http://vr-zone.com/articles/intel-xeon-phi-b0-stepping--the-knight-in-shining-armor-/16871.html
Ailuros
2012-07-31, 13:55:30
VR-Zone mit wohl genaueren Daten zu Core-Zahl und Taktraten:
http://vr-zone.com/articles/intel-xeon-phi-b0-stepping--the-knight-in-shining-armor-/16871.html
So bald ich den Author sah, gab es keinen Grund mir das Zeug durchzulesen.
Skysnake
2012-07-31, 14:13:10
Naja, so viel neues steht da eigentlich nicht drin. Wenn mans genau nimmt sogar rein gar nichts...
Wenn ich mich nicht verrechnet habe, reden die von 512kB L2. Sind doch aber nur 256kB oder?
Hier noch was von mir ;)
http://extreme.pcgameshardware.de/user-news/223036-intel-mic-wird-zu-xeonphi-update2-nur-pci-e-2-0-a.html
Das interessanteste war: Nur PCI-E 2.0 und weniger als 1TFlop/s in HPL bei knapp 225W Leistungsaufnahme.
Die Sachen in dem anderen Bericht können stimmen, oder gut geraten sein. Ich würde sagen sowohl als auch ;)
john carmack
2012-08-01, 14:48:49
http://www.computerbase.de/news/2012-08/exakte-details-zu-intels-xeon-phi-mic/
Skysnake
2012-08-01, 15:20:26
Nichts neues. Das sind nur die Infos aus der VR-Zone und meiner News in einer verwurstet...
Hat Knights Corner eigentlich noch TMUs?
Skysnake
2012-08-04, 11:52:32
Nicht das ich wüsste, aber das sagt nichts. Man muss sich ja darauf verlassen, was Intel einem erzählt, und die erzählen wenig...
Es gibt noch keinen Die-Shot, ja?
Skysnake
2012-08-04, 12:24:49
Nicht das ich jetzt wüsste, aber beschwören will ich es nicht.
del_4901
2012-08-04, 15:08:16
http://cache.gawkerassets.com/assets/images/4/2009/12/intel_scc_chip.jpg
Das koennte ein Prototyp gewesen sein.
AnarchX
2012-08-04, 15:29:25
Das ist der 48-Core-Single-Core-Cloud-Chip: http://www.dvhardware.net/news/intel_48_core_cpu_dec09_architecture.jpg
PDF: http://download.intel.com/pressroom/pdf/rockcreek/SCC_Announcement_JustinRattner.pdf
Aber für 3D-Visualisierungen auf dem MIC wären TMUs wohl nicht verkehrt, soviel Platz nehmen sie ja nicht weg.
Ailuros
2012-08-30, 12:08:53
Komisch dass noch keiner darauf verlinkt hat: http://semiaccurate.com/2012/08/28/intel-details-knights-corner-architecture-at-long-last/
Skysnake
2012-08-30, 17:53:09
Warum sollte man?
Wer bischen im netz sucht, findet sogar das Software-Packge zu KNC in der Alpha2. Da sollten einige Sachen mit drin sein. Errata fehlt aber z.b. mehr hab ich nicht nachgeschaut.
AnarchX
2012-08-31, 09:37:47
Gestiegene IPC:
http://www.techpowerup.com/img/12-08-30/intel_xeon_phi_hotchips_architecture_presentation_page_18.jpg
Um gegen GK110 zu bestehen, muss die Finale Version wohl noch einiges zulegen:
http://www.techpowerup.com/img/12-08-30/intel_xeon_phi_hotchips_architecture_presentation_page_05.jpg
http://www.techpowerup.com/171436/Intel-Reveals-Architecture-Details-of-Intel-Xeon-Phi-Co-Processor.html
Skysnake
2012-08-31, 10:36:12
Ähm die Daten stimmen aber nicht!
Wenn wir die aktuelle Top500 nehmen, dann steht da für #150 mit KnightsCorner ein Verbrauch von 100.8 kW und nicht von jedeglich 72.9kW. Und das Ganze dann bei 118.6 TFlop/s, was dann 1176.59 MFlop/s/Watt bedeuten würde.
Die Werte des Ati Clusters stimmen. Da hat man sogar einen recht effizienten genommen. Der Loewe CES ist deutlich ineffizienter als dieser hier, hat aber auch sehr viel mehr Rechenleistung, und setzt noch auf HD5k Karten, also auch schon etwas älter.
Der nVidia Cluster stimmt auch von den Werten her. Also nur der Intel Cluster wird mit 1381 statt 1176.59 angegeben. sagen wir 1177, dann sind das aber noch immer 17% zu viel.
Was soll so was?
StefanV
2012-08-31, 13:34:56
Was soll so was?
Na, die Daten, die du geschrieben hast, schauen halt doof aus. ;)
Und das is halt bisserl doof, wenn man auf eigenen Folien zugeben muss, dass die Mitbewerber besser wären.
Ähm die Daten stimmen aber nicht!
Wenn wir die aktuelle Top500 nehmen, dann steht da für #150 mit KnightsCorner ein Verbrauch von 100.8 kW und nicht von jedeglich 72.9kW. Und das Ganze dann bei 118.6 TFlop/s, was dann 1176.59 MFlop/s/Watt bedeuten würde.
Ist natürlich ein bedauerlicher Fehler.
y33H@
2012-08-31, 14:06:04
http://newsroom.intel.com/servlet/JiveServlet/download/5162-11511/Intel_Xeon_Phi_Hotchips_architecture_presentation.pdf
Gipsel
2012-08-31, 15:54:44
http://newsroom.intel.com/servlet/JiveServlet/download/5162-11511/Intel_Xeon_Phi_Hotchips_architecture_presentation.pdf
Was lernen wir daraus?
1.
Die erste bzw. zweite Larrabee-Variante (Knights Ferry) war offensichtlich höllisch schlecht, da Intel ja laut eigenen Angaben die taktbereinigte Performance eines Einzelkerns um im Schnitt >80% steigern konnte (ist allerdings eine single-threaded Angabe bei einem 4fach SMT-Kern :freak:).
2.
Intel ist ehrlich bei der Angabe mit dem jeweils zwischen zwei SP Slots geteilten DP Multiplier. Die nV-Angaben sind da im Vergleich ja immer eher nur sehr blumig.
3.
Trotz der langwierigen Erklärung und Selbstbeweihräucherung scheint der Ringbus bei einigen Aufgaben durch Kollisionen doch auch zu einem ernsthaften Bottleneck werden zu können, trotz der Verdopplung bei Knights Corner. Allerdings muß man zur Intels Ehrenrettung erwähnen, daß sich die GPUs bisher ein wenig vor den großen Caches drücken (die packen Crossbars vor wenige Tiles eines kleinen Caches) und ATI ihren Ringbus-Versuch beim R600 (übrigens gleiche nominelle Breite, 2 x 512 Bit) schleunigst wieder rausgeschmissen hat (und gegen Crossbars ersetzt). Die Skalierung des Ringbusses funktioniert offensichtlich auch nur, weil Intel die segmentiert hat (in 4 Teile?).
4.
Die Energieeffizienz ist zumindest beim HPC-Benchmark für die Top500-Liste trotz enormen Fertigungsvorsprung (22nm Intel vs. 40nm TSMC bei den beiden Vergleichssystemen mit AMD bzw. nV GPUs) offenbar nur durch einen "Fehler" besser. :|
Die erste bzw. zweite Larrabee-Variante (Knights Ferry) war offensichtlich höllisch schlecht, da Intel ja laut eigenen Angaben die taktbereinigte Performance eines Einzelkerns um im Schnitt >80% steigern konnte (ist allerdings eine single-threaded Angabe bei einem 4fach SMT-Kern :freak:).
Irgendwie stinkt das aber nach Fisch. Wie soll das gehen, wenn der Kern immer noch dual issue in-order ist?
Oder bezieht sich das eben darauf, wenn mehrere Threads laufen und damit die Einheiten besser ausgenutzt werden?
Gipsel
2012-08-31, 16:14:53
Irgendwie stinkt das aber nach Fisch. Wie soll das gehen, wenn der Kern immer noch dual issue in-order ist?
Oder bezieht sich das eben darauf, wenn mehrere Threads laufen und damit die Einheiten besser ausgenutzt werden?
Die Aussage ist explizit als für single-threaded gültig markiert (da steht: Ausführung auf einem Core mit einem Thread). Wie gesagt würde ich das eher andersrum interpretieren, nämlich daß die Angabe auf Unzulänglichkeiten der ersten Larrabee-Versionen hindeutet. Da gab es wahrscheinlich noch deutlich mehr Fallstricke, bei denen die Performance dann eingebrochen ist. Diese hat Intel jetzt beseitigt.
y33H@
2012-08-31, 17:00:46
Weder Performance noch Watt sehen für mich trotz 22 nm überzeugend aus. Und das bei der x-ten Generation :usad:
|MatMan|
2012-08-31, 17:08:44
Die Aussage ist explizit als für single-threaded gültig markiert (da steht: Ausführung auf einem Core mit einem Thread). Wie gesagt würde ich das eher andersrum interpretieren, nämlich daß die Angabe auf Unzulänglichkeiten der ersten Larrabee-Versionen hindeutet. Da gab es wahrscheinlich noch deutlich mehr Fallstricke, bei denen die Performance dann eingebrochen ist. Diese hat Intel jetzt beseitigt.
Wird da eigentlich die Vektoreinheit benutzt (steht nicht explizit da) oder ist das nur die Leistung der "normalen" CPU Kerne? Falls letzteres: wen interessiert das?
Skysnake
2012-08-31, 18:24:18
So was allgemeines zu den Daten.
Nicht falsch verstehen. Die können richtig sein, sind aber NICHT! die Daten aus den TOP500, wie es suggeriert wird. Sprich man hat halt weiter verbessert, oder neue Revisionen der Karten oder what ever verwendet.
Darum gings mir halt, an sich können die Werte aber für XeonPhi/KNC/MIC aber dennoch stimmen.
Weder Performance noch Watt sehen für mich trotz 22 nm überzeugend aus. Und das bei der x-ten Generation :usad:
Wie schon oft gesagt, der Vorteil liegt weniger in Perf/W sondern darin, das man mehr unterschiedliche Anwendungen beschleunigen kann, und eben sehr viel weniger Portierungsaufwand hat.
Dazu kommt halt noch, das so Sachen wie das Deep-Projekt eben mit GPUs (bis jetzt) nicht machbar sind.
EDIT:
Hach ist selective Wahrnehmung nicht was feines? ;D
Euch ist auch nicht aufgefallen, dass da in dem Link nicht Top500.org, sondern Green500.org steht oder???
Wenn man jetzt auf die Green500.org (http://www.green500.org/news/june-2012-green500-list-released?q=lists/green201206&green500from=1&green500to=100), statt auf die Top500.org (http://top500.org/list/2012/06/200) geht, ist das Intel System auch nicht auf Platz150 gelistet, sondern auf Platz 21 eben genau mit den hier genannten Daten.
Dazu mal noch ein kleiner Auszug aus dem Regelwerk der Green500:
Green500 List: In order to qualify for The Green500 List, a supercomputer must achieve performance at least as high as the 500th-ranked system in the current version of the Top500 List. The power reported with submissions to The Green500 List must be the power for achieving the performance reported to The Green500 List, but need not match the corresponding Rmax and power reports to the Top500 List. It is required that all the cores in the supercomputer be used for executing the HPL benchmark for a Green500 submission, unless fewer cores were used to report to the Top500 List, in which case that number is acceptable. It is also encouraged to submit both the Rmax power (see section 1.N) and the power at which the entire supercomputer operates at highest energy efficiency in terms of performance per watt. In short, if you wish to apply dynamic voltage and frequency scaling (DVFS) or some other methodology, which affects performance without dropping off the bottom of the Top500 List, and still using the entire machine, that is allowed.
2.2. Little Green500(beta): To be eligible for
Damit sind die Werte aus der Top500 dann auch fürn Poppes, denn das System muss nicht das Gleiche sein. Man muss nur schneller sein als das langsamste System in den Top500. Daher ist das Ding auch so viel langsamer sparsamer. Man hat wohl einen guten Teil des Clusters abgeschaltet, um Strom zu sparen und die Skalierung zu verbessern. Eventuell auch mehr XeonPhi/Node als bei der Top500.
Wahrscheinlich wurden auch einige Switches abgeschaltet, weil man weniger Nodes hatte, oder aber Switches voll bestückt hat, mit Leistungseinbußen im Peak, was hier aber egal ist.
Ich sagte doch, die Daten können stimmen, aber so wies den Eindruck macht stimmts halt nicht. Nur das halt der Eindruck von mir mit Top500 statt Green 500 falsch war :rolleyes:
Aber schon recht seltsam, was Intel da macht. Die anderen Systeme sind nämlich in der Top500 und der Green500 identisch. Da wird also wirklich aufs letzte getweakt, um gut da zu stehen im Ergebnis.
Gipsel
2012-08-31, 18:40:38
Wird da eigentlich die Vektoreinheit benutzt (steht nicht explizit da) oder ist das nur die Leistung der "normalen" CPU Kerne? Falls letzteres: wen interessiert das?
Die Nutzung der Vektoreinheit würde ich mal ganz stark vermuten. Das sind ja SpecFP2006-Benchmarks, davon sind viele ganz gut vektorisierbar. Außerdem hat Intel da schon bisher mit ihren Compilern einen ganz guten Stand (und normale CPUs benutzen dort natürlich auch ihre AVX-Vektoreinheiten, die inzwischen auch schon halb so breit sind, wie die von Larrabee).
offizielle Details zu Xeon-Phi:
http://www.computerbase.de/news/2012-09/intel-gibt-offizielle-technische-details-zu-xeon-phi-bekannt/
bzw:
http://newsroom.intel.com/servlet/JiveServlet/download/5162-11511/Intel_Xeon_Phi_Hotchips_architecture_presentation.pdf/
Gipsel
2012-09-03, 13:54:51
Das diskutieren wir schon eine Seite lang. ;)
Und den Link zur Intel-Präsentation gab es auch schon. (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=9446239#post9446239)
Ailuros
2012-09-12, 11:19:55
Ich sehe nichts besonder Neues in den diversen links zur Intel IDF aber das folgende Bildchen ist schon krass:
http://www.brightsideofnews.com/news/2012/9/11/intel-idf-2012-keynote-much-ado-about-nothing.aspx
http://www.brightsideofnews.com/Data/2012_9_11/Intel-IDF-2012-Keynote-Much-Ado-About-Nothing/DSC_0789.JPG
Die meissten wissen schon wie winzig small form factor SoCs sind, aber ein Bild wie dieses erzaehlt schon einiges mehr.
Ailuros
2012-09-17, 12:25:10
http://semiaccurate.com/2012/09/14/hard-numbers-for-knights-corner-leak-out/
Wer wollte "wissen" dass Phi weniger als 64 cores hat? ;)
Ronny145
2013-06-25, 21:45:36
http://s1.directupload.net/images/130625/x7zo2qzt.png
http://s7.directupload.net/images/130625/bsgo9w22.png
http://www.icsr.agh.edu.pl/~kito/Arch/arch1-1-4B-x86.pdf
Für Knights Landing sind laut Folie etwa 3 Tflops DP eingeplant.
http://s1.directupload.net/images/130625/x7zo2qzt.png
http://s7.directupload.net/images/130625/bsgo9w22.png
http://www.icsr.agh.edu.pl/~kito/Arch/arch1-1-4B-x86.pdf
Für Knights Landing sind laut Folie etwa 3 Tflops DP eingeplant.
damit wäre er ja ungefähr gleich auf mit Nvidias Maxwell :-)
dieser ist ja mit 14-16 GFLOPS/Watt DP Leistung von Nividia angegeben
bei typischen 225W folgt
14GFLOPS/Watt*225Watt = 3,15 TFLOPS DP
del_4901
2013-06-26, 00:00:01
damit wäre er ja ungefähr gleich auf mit Nvidias Maxwell :-)
dieser ist ja mit 14-16 GFLOPS/Watt DP Leistung von Nividia angegeben
bei typischen 225W folgt
14GFLOPS/Watt*225Watt = 3,15 TFLOPS DP
Ich glaube nicht das man das so einfach rechnen kann, weil nur ein kleiner Teil der Einheiten ueberhaupt DP rechnen kann.
Skysnake
2013-06-26, 09:27:32
Doch kann man so rechnen.
Es ist ja nur eine Angabe, wieviele Flops man pro Watt erreichen kann. Wie das erreicht wird ist scheis egal...
Es passt also schon sehr gut. Die Werte für KNC sehen MIR allerdings etwas seltsam aus. Also zu groß. Gibt ja durchaus anderslautende Dokus von Intel.
Gipsel
2013-06-26, 10:49:28
Ich glaube nicht das man das so einfach rechnen kann, weil nur ein kleiner Teil der Einheiten ueberhaupt DP rechnen kann.Wieso? Die SIMD-Einheiten rechnen alle DP, halt nur entsprechend der Vektorbreite von 512Bit mit der Hälfte der Flops im Vergleich zu SP. Ganz genau so wie bei allen Intel-CPUs (außer Atom).
Die Werte für KNC sehen MIR allerdings etwas seltsam aus. Also zu groß. Gibt ja durchaus anderslautende Dokus von Intel.Haben die nicht inzwischen auch eine Version mit 61Kernen und höherem Takt, die 1,23 TFlop/s kann angekündigt? Und auch eine Version, die etwas stromsparender zu Werke geht (also nicht mehr wie ein paar der ersten Versionen 300W zieht sondern sich mit <225W [oder noch etwas weniger bei etwas abgesenktem Takt] zufrieden gibt)? Dann könnten die GFlop/W-Werte schon irgendwie hinkommen.
Ist jemandem aufgefallen, dass bei Knights Landing AVX 3.1 steht?
Das deute ich so, dass Intel die Instruction-Sets von Desktop und Xeon Phi homogenisieren will. D.h. überall 512 bit Instructions. Die Einheiten haben sie ja in Haswell schon (2x256 bit MAD). Bloß Scatter/Gather fehlt usw.
Edit: Steht ja sogar AVX 3.2 bei Skylake.
AnarchX
2013-06-26, 11:02:42
32 FLOPs DP pro Core und MHz sind auf einer anderen Folie für 2015/Skylake angegeben.
Gipsel
2013-06-26, 11:04:31
Das deute ich so, dass Intel die Instruction-Sets von Desktop und Xeon Phi homogenisieren will. D.h. überall 512 bit Instructions.
Die Einheiten haben sie ja in Haswell schon (2x256 bit MAD). Bloß Scatter/Gather fehlt usw.Also wenn Intel keine Ahnung hat, womit sie die Dies in ihren deutlich kleineren Prozessen als bei der Konkurrenz vollkriegen, können die natürlich zwei 512Bit FMAs in ihren CPUs verbauen, auch wenn das oftmals vermutlich Verschwendung sein dürfte. Wenn man den Folien traut, soll aber genau das kommen.
Ganz allgemein: Aus Performance- bzw. Stromverbrauchssicht wäre es sicher besser, bei CPUs bei 2x256Bit FMA zu bleiben (höhere Performance bei CPUs mit tendentiell kleineren, latenzsensitiven Problemen als 1x512Bit) und bei Knights Landing 1x512bit zu verbauen (niedrigerer Stromverbrauch und ähnliche Performance zu 2x256Bit bei größeren, durchsatzorientierten Problemen). 512Bit-Instruktionen kann man auf CPUs ja trotzdem unterstützen (das gab es ja schon immer: SSE in 2 Takten auf 64Bit-Einheiten oder auch AVX auf 128Bit-Einheiten).
Also insgesamt sieht das tatsächlich etwas danach aus, als wenn Intel eventuell irgendwann die AVX#.#-Einheiten ähnlich wie bei der ursprünglichen Larrabee-Idee mit der Grafik betrauen will, so daß man da deutlich mehr Budget für die Vektoreinheiten der CPU-Kerne verbraten kann (weil die IGP zu einem großen Teil wegfällt). Also im Prinzip Larrabee nicht mit langsamen in-order-Kernen sondern den fetten CPU-Kernen. Ich bin der Meinung, intel kann das nur durchziehen, wenn sie sich sicher sind, ihren Prozeßfortschritt zu halten. Denn prinzipiell ist das aus Performance/Watt-Sicht nicht unbedingt die effizienteste Variante.
AnarchX
2013-06-26, 11:07:36
Vielleicht laufen die FMA-Einheiten nicht mehr mit vollem Prozessortakt oder werden für GPU-Aufgaben mitverwendet?
Gipsel
2013-06-26, 11:14:20
Vielleicht laufen die FMA-Einheiten nicht mehr mit vollem Prozessortakt oder werden für GPU-Aufgaben mitverwendet?Abgesenkter Takt wäre nicht gerade förderlich für die single-Thread-Performance (und wenn man halben Takt mit halben Latenzen bastelt, hat man keinen wesentlichen Stromverbrauchsvorteil aber einen Flächennachteil). Und die Nutzung als IGP ist durchaus möglich, aber meiner Meinung nach verschenkt man da ebenfalls Effizienz.
Was mich interessieren würde: Was plant intel genau mit dem "on package memory"? eDRAM wie bei Haswell GT3e (mit sagen wir mal 256MB statt 128MB) oder HMC?
Also insgesamt sieht das tatsächlich etwas danach aus, als wenn Intel eventuell irgendwann die AVX#.#-Einheiten ähnlich wie bei der ursprünglichen Larrabee-Idee mit der Grafik betrauen will, so daß man da deutlich mehr Budget für die Vektoreinheiten der CPU-Kerne verbraten kann (weil die IGP zu einem großen Teil wegfällt). Also im Prinzip Larrabee nicht mit langsamen in-order-Kernen sondern den fetten CPU-Kernen. Ich bin der Meinung, intel kann das nur durchziehen, wenn sie sich sicher sind, ihren Prozeßfortschritt zu halten. Denn prinzipiell ist das aus Performance/Watt-Sicht nicht unbedingt die effizienteste Variante.
Won't happen.
Skysnake
2013-06-26, 12:17:20
Ist jemandem aufgefallen, dass bei Knights Landing AVX 3.1 steht?
Das deute ich so, dass Intel die Instruction-Sets von Desktop und Xeon Phi homogenisieren will. D.h. überall 512 bit Instructions. Die Einheiten haben sie ja in Haswell schon (2x256 bit MAD). Bloß Scatter/Gather fehlt usw.
Edit: Steht ja sogar AVX 3.2 bei Skylake.
Klar wird man das im Laufe der Zeit anpassen wollen. KNC ist ja ähm.... reden wir nicht darüber, aber das Ding verursacht teilweise echt graue Haare....
Also wenn Intel keine Ahnung hat, womit sie die Dies in ihren deutlich kleineren Prozessen als bei der Konkurrenz vollkriegen, können die natürlich zwei 512Bit FMAs in ihren CPUs verbauen, auch wenn das oftmals vermutlich Verschwendung sein dürfte. Wenn man den Folien traut, soll aber genau das kommen.
Ganz allgemein: Aus Performance- bzw. Stromverbrauchssicht wäre es sicher besser, bei CPUs bei 2x256Bit FMA zu bleiben (höhere Performance bei CPUs mit tendentiell kleineren, latenzsensitiven Problemen als 1x512Bit) und bei Knights Landing 1x512bit zu verbauen (niedrigerer Stromverbrauch und ähnliche Performance zu 2x256Bit bei größeren, durchsatzorientierten Problemen). 512Bit-Instruktionen kann man auf CPUs ja trotzdem unterstützen (das gab es ja schon immer: SSE in 2 Takten auf 64Bit-Einheiten oder auch AVX auf 128Bit-Einheiten).
Naja, das ist halt die Frage, wie du noch "CPU" definierst. Stumpf Takt und Kernanzahl hoch jagen ist nicht sinnvoll. Wir sind einfach schon in einem Bereich, in dem man bereits eine so hohe Parallelität in den Problemen haben muss, um aktuelle CPUs aus zu lasten, das man sich die fehlende Flexibilität durch breitere Register/ISAs leisten kann. Es tut einfach nicht so sehr weh, wie immer und immer wieder die gleiche Kontrollogik mit rum zu schleppen...
Also insgesamt sieht das tatsächlich etwas danach aus, als wenn Intel eventuell irgendwann die AVX#.#-Einheiten ähnlich wie bei der ursprünglichen Larrabee-Idee mit der Grafik betrauen will, so daß man da deutlich mehr Budget für die Vektoreinheiten der CPU-Kerne verbraten kann (weil die IGP zu einem großen Teil wegfällt). Also im Prinzip Larrabee nicht mit langsamen in-order-Kernen sondern den fetten CPU-Kernen. Ich bin der Meinung, intel kann das nur durchziehen, wenn sie sich sicher sind, ihren Prozeßfortschritt zu halten. Denn prinzipiell ist das aus Performance/Watt-Sicht nicht unbedingt die effizienteste Variante.
Naja, definiere mal "Grafik".
Was machen denn die ALUs einer GPU, und was sind denn iGPUs in aktuellen CPUs ;)
Und wie sind die iGPUs von Intel inzwischen angeschlossen ;)
Eigentlich ist es relativ simpel. Um die Effizienz signifikant zu steigern, muss man entweder iGPUs nutzen, oder eben die Register massiv verbreitern. Wenn man letzteres macht, schleppt man aber im Prinzip Einheiten doppelt mit sich rum, wiel man sowohl in der iGPU als auch in der CPU das Gleiche Konzept verfolgt, nur eben in unterschiedlichen Ausprägungen.
Bei der iGPU separiert man alles örtlich, und muss die DAten jeweils quer über den Chip jagen, hat dafür aber kurze Wege innerhalb der CPU.
Bei den fetten Registern, werden die CPU-Cores größer und die Wege innerhalb länger, was auf die Performance drückt, man spart sich aber die im Vergleich extrem langen Wege quer über den DIE zur iGPU, wenn die iGPU quasi in die CPU wandert. Ein Problem ist natürlich auch noch die unterschiedlichen Ausrichtungen der FPU vs iGPU-ALUs, wo einmal Latenz und das andere mal Durchsatzoptimiert wird.
Abgesenkter Takt wäre nicht gerade förderlich für die single-Thread-Performance (und wenn man halben Takt mit halben Latenzen bastelt, hat man keinen wesentlichen Stromverbrauchsvorteil aber einen Flächennachteil). Und die Nutzung als IGP ist durchaus möglich, aber meiner Meinung nach verschenkt man da ebenfalls Effizienz.
Was mich interessieren würde: Was plant intel genau mit dem "on package memory"? eDRAM wie bei Haswell GT3e (mit sagen wir mal 256MB statt 128MB) oder HMC?
Ja durchaus, habe ich ja oben schon angesprochen.
Man muss sich aber auch wieder eins vor Augen halten. Wir haben Superskalare CPUs, und Intel setzt schon lange auf SMT....
Es wäre durchaus ein logischer Schritt bei reinen CPUs (EP/EX) massiv zu verbreitern, die FPU aber erstmal Latenzoptimiert zu belassen, also z.B. die breiten Register nur über besondere issuePorts zugänglich zu machen, wie dann auch gern mehr blockieren können.
Mit KNL hätte man ja noch beide Varianten da, einmal mit KNL die eher durchsatzoptimierte Variante und mit Skylake-E die eher Latenzoptimierte, wobei es auch sein kann, das man eben mit Skylake-E direkt schon alles integriert, und quasi die Knights sterben lässt, da Skylake-E oder dessen NAchfolger dann eben sowohl Latenz, als auch Durchsatzoptimierte IssuePorts hat, bzw eben sowohl als auch durchführen kann. Da gibt es ja unzählige Variantionsmöglichkeiten, wie man genau beide Bedürfnisse unter einen Hut bekommt.
Die Spannende Frage bleibt aber, was man mit S1150 macht.
Behält man da die iGPU als solche, um einfach effizent zu sein für den Mobile-Bereich, wo der DAtenaustausch zwischen CPU und iGPU nicht sooooo wichtig ist, wie im Computing bereich, oder lässt man die iGPU sterben?
Ich denke man wird das iGPU Konzept hier weiter zu verfolgen, AUCH! um notfalls was in der Hinterhand zu haben, falls die totale Verinigung von LArrabee und klassischer CPU in eine Sackgasse führt.
PS:
Wer hat denn so was schon vor Monaten/Jahr(en) aufgezeigt :tongue:
Ganz allgemein: Aus Performance- bzw. Stromverbrauchssicht wäre es sicher besser, bei CPUs bei 2x256Bit FMA zu bleiben (höhere Performance bei CPUs mit tendentiell kleineren, latenzsensitiven Problemen als 1x512Bit) und bei Knights Landing 1x512bit zu verbauen (niedrigerer Stromverbrauch und ähnliche Performance zu 2x256Bit bei größeren, durchsatzorientierten Problemen). 512Bit-Instruktionen kann man auf CPUs ja trotzdem unterstützen (das gab es ja schon immer: SSE in 2 Takten auf 64Bit-Einheiten oder auch AVX auf 128Bit-Einheiten).
Ich kapiers auch nicht ganz, was sie mit den lagen Vektoren wollen. Hans De Vries meinte beim angeblichen Quad-Thread AMD-Leak ja auch, dass man so ne große FPU kaum stetig mit Daten füttern könnte und 4 Threads deshalb schon Sinn machten.. Wäre bei 2x512bit FMAC Units sicherlich nicht anders. Mal schauen ob Intel dann Quad-SMT einführt.
Aber irgendwie geht das dann schon langsam in Richtung GPU. Bin da auch eher dagegen, lieber ne knackig schnelle CPU und nen lahmen Vektorprozessor/GPU als irgendnen Mischmasch.
Naja notfalls muss es halt ARM64 als "saubere" Architektur richten. :freak:
Ronny145
2013-06-26, 12:40:27
Was mich interessieren würde: Was plant intel genau mit dem "on package memory"? eDRAM wie bei Haswell GT3e (mit sagen wir mal 256MB statt 128MB) oder HMC?
Der edram ist das. Die Größe und alles andere ist nicht bekannt. Damit ließe sich viel Fläche versenken.
Neben der fortschrittlichen Fertigungstechnologie und der Funktion, wahlweise wie bisher als Co-Prozessor oder auch als echter Host-Prozessor für einen Mainboardsockel zu fungieren, wird man auf On-Package-Speicher, ähnlich dem kürzlich eingeführten EDRAM bei Haswell, zurückgreifen, um eine deutliche Leistungssteigerung zu ermöglichen.
http://www.computerbase.de/news/2013-06/neue-xeon-phi-und-ausblick-auf-14-nm-ableger-von-intel/
sondern verriet auch einige Details zur nächsten Version, die den Codenamen Knights Landing trägt. Der in 14-nm-Technik gefertigte Chip soll mit In-Package-Speicher versehen sein – möglicherweise ähnlich wie beim Haswell GT3e mit EDRAM. Er wird aber wohl über wesentlich mehr verfügen als die 128 MByte des Haswell. Über die externe Speicheranbindung hat Hazra noch nichts verraten, DDR4 gilt als heißer Favorit.
http://www.heise.de/newsticker/meldung/ISC-13-Intels-naechster-Xeon-Phi-fuer-Standalone-Betrieb-1891350.html
Skysnake
2013-06-26, 15:03:13
Ich kapiers auch nicht ganz, was sie mit den lagen Vektoren wollen. Hans De Vries meinte beim angeblichen Quad-Thread AMD-Leak ja auch, dass man so ne große FPU kaum stetig mit Daten füttern könnte und 4 Threads deshalb schon Sinn machten.. Wäre bei 2x512bit FMAC Units sicherlich nicht anders. Mal schauen ob Intel dann Quad-SMT einführt.
Aber irgendwie geht das dann schon langsam in Richtung GPU. Bin da auch eher dagegen, lieber ne knackig schnelle CPU und nen lahmen Vektorprozessor/GPU als irgendnen Mischmasch.
Naja notfalls muss es halt ARM64 als "saubere" Architektur richten. :freak:
Und welche Referenz hat er?
Er bezieht sich, in Anbetracht dieses Forum wohl auf Games.
Gamer müssen aber begreifen, dass Sie nicht mehr der Nabel der Welt sind bzgl Vorschub bei der Entwicklung neuer Technologien und höherer Performance.
DAs war mal so bis vor einigen Jahren, aber inzwischen ist die LEistung so hoch, das Games kaum noch von mehr Leistung profitieren.
Zudem steigt eben der Druck weiter die Effizienz zu steigern in den Bereichen, wo halt WIRKLICH! die LEistung auch gebraucht wird, sprich HPC.
Dort ist es aber kein Problem auch die langen Vektoren zu füllen. Und auch in BigData ist es kein Problem.
Also kurz um, überall wo man wirklich die Power auch braucht, ist es kein Problem.
Das die Gamer das auf der Strecke bleiben ist traurig, aber wohl unvermeidlich. :(
Also das Hans de Vries Gamer als Referenz hernähme bezweifle ich mal ganz stark. Ich dachte der Name sagt Dir was, ich hoffe Du verwechselst ihn gerade nicht mit einem PCGH-Redakteur ^^
Glaube da schon eher, dass er an HPC gedacht hat. Auf den GPus laufen doch auch mehrere Wavefronts gleichzeitig. Eben weil ein Thread nicht jeden einzelnen Takt entsprechende Berechnungen durchführt, HPC hin oder her. Oder hast Du ein konkretes Programmbeispiel, dass wirklich nonstop läuft@fullpower laufen kann? Das schaffen mMn nur künstliche Powerviren mit sinnlosen Berechnungen, aber keine Realprogramme.
Skysnake
2013-06-26, 16:58:14
Das GPUs viele Wavefronts usw haben liegt an was ganz! anderem. Die sind durchsatzoptimiert, und brauchen allein schon mehrere Threads um überhaupt ihre ALUs 100% theoretisch auslasten zu können, weil die Ergebnisse nicht schnell genug da sind...
Bzgl Hans de Vries, das ist doch der Redakteur einer Seite, mir fällt gerade nur nicht der Name ein, aber sonst?
Bzgl Auslastung noch. Bei CPUs ist das so ne Sache. Es kommt halt immer darauf an, wie viele Branches du hast, da dies eventuell deine Pipeline leer laufen lässt. Bei nahezu allen Problemen, die du über Matrizenoperationen lösen kannst, was so ziemlich alle interessanten sind, kannst du CPUs aber praktisch non stop voll auslasten. Also z.B. finite Elemente Systeme kann man da nennen in der Strömungssimulation usw usw usw.
Das mit den "Power"Viren ist nen bischen nVidia Bullshitbingo, das AMD dann auch noch aufgegriffen hat. Die gehen halt davon aus, das "normale" Programme im Consumerbereich, eben Games, es nicht schaffen die GPU wirklich dauerhaft aus zu lasten, weil die Shaderprogramme zu kurz sind usw usw.
Es ist aber relativ einfach mit GPGPU Programme zu schreiben, die sich im Bereich von FurMark bewegen bzgl der Leistungsaufnahme. Bei meiner kleinen Test-Suite hab ich ja ne 2D Wärmeverteilung/Platte implementiert, und erreiche damit fast die Werte von FurMark.
Meine 7970 drosselt auf jeden Fall, so lange ich nicht wenigstens 8-10% aufs Powertarget gebe. FurMark drosselt irgendwo ab +14% nicht mehr.
Und überall wo du GPUs ausgelastet bekommst, bekommst du CPUS gleich 10 mal ausgelastet ;)
Ronny145
2013-06-26, 17:04:52
Bzgl Hans de Vries, das ist doch der Redakteur einer Seite, mir fällt gerade nur nicht der Name ein, aber sonst?
http://www.chip-architect.com/mywork.html
Der war an Chipentwicklungen beteiligt.
Skysnake
2013-06-26, 17:53:28
Dann verwechsel ich den Namen gerade GRANDIOS mit jemand anderen ;D
Ah, mit ist jetzt auch wieder der Name der Website eingefallen. BrightSideOfNews oder so. Wie heist denn der dann? :ugly:
Bzgl "Auslasten" von breiten Registern kann ich die Aussage aber überhaupt nicht nachvollziehen.
Klar, im Consumerbereich wirds schwierig, entsprechenden Code zu finden, aber im HPC/BigData Bereich sollte das absolut kein Problem sein.
Eigentlich überall wo man Cluster einsetzt kann man auch alternativ die ISA einfach erweitern, so das breitere Instructionen drin sind.
Gerade GPUs verhalten sich ja mit ihren Wavefronts/Warps ja praktisch 1:1 wie mega breite Register.
EDIT:
:biggrin:
Ich hab grad bischen auf der Seite geschmöckert, und das Buch angeschaut, das er da schreibt.;D
Das ist ziemlich genau der Stoff, den ich mir meine Diplomprüfung über theoretische Physik reingepiffen habe ;D der Übergang zur Quantenmechanik ja auch drin ist.
Ich hab auch gerade festegestellt, das ich in der Vorbereitung mal die Klein-Gordon-Gleichung "hergeleitet" habe in ner Diskussion, wie denn das mit Massebehafteten Teilchen in der QM ist ;D
Irgendwie fühl ich mich jetzt aber als Freak, weil mir das Zeug absolut bekannt ist :ugly:
y33H@
2013-06-26, 18:30:23
BSN ist Theo Valich, Ex The Inquirer.
Skysnake
2013-06-26, 18:32:59
AH ja GENAU Theo Valich, der wars :D
Ich habs echt nicht mit Namen :(
Irgendwie fühl ich mich jetzt aber als Freak, weil mir das Zeug absolut bekannt ist :ugly:
Hahah, ich denke wir sind uns dann also einig, dass er eher nicht von Games redet, oder ? ;-)
Das bei BSN war der Type der zuvor beim Inquirer war und dort irgendnen Skandal mit photoshopped ATI/Nvidia-Grafikqualitätsbildchen hatte (wenn ich mich recht erinnere, irgendwas war da auf alle Fälle). Aber die Namen solcher Leute merk ich mir auch nicht ^^
Edit: Ach da stehts beim Impressum bei BSN: Theo Valich heißt der Type, niemand den man kennen muss ab und an kommen sie an ein paar nette NDA-PDFs, das wars. Ungefähr das gleiche Niveau wie Fudzilla.
Edit2: Zu spät ^^
Skysnake
2013-06-26, 18:52:13
Ja, mr sag BSN nur was, weil OBR mal ziemlich dummdreist was bei denen geklaut hat, was mir dann aufgefallen ist. Das wurde ne schöne news :biggrin:
Bzgl Ausrichtung von Vries kann ich nichts sagen.
Vor allem muss man aber auch schauen, von wann die Aussage war/ist. Ist die von ~2000 rum, wo man noch auf Singlecores rumgehangen ist, oder ist die aktuell?
Man muss ja bedenken, das wir dieses Jahr 12 Kerne mit AVX bekommen als astreine CPUs, und bald wohl auf die 16/20 Cores mit AVX(2) gehen werden. Da ist der Schritt dann zu nochmals breiteren Kernen nicht weit. Vor allem kann man sich so eben sparen den Kerncount nochmals ansteigen zu lassen für eine gewisse Zeit.
Man muss ja sehen, das Intel mit KNC bis zu 61 Cores mit den breiten Registern auf einem DIE hat, und das läust ja HEUTE! und wird auch genutzt. Warum sollte man das in 2-3 Jahren also nicht in ganz "stinknormale" CPUs packen können?
Man muss sich einfach von der Vorstellung verabschieden, sequenzielle Probleme noch großartig beschleunigen zu können. Da rennt man einfach gegen eine Wand.
Akkarin
2013-06-26, 19:17:14
Afaik wurde die Aussage im Zusammenhang mit dem Steamroller Dieshot getätigt, also vor nem Monat (?).
Skysnake
2013-06-26, 19:23:43
Dann frage ich mich ganz ehrlich, wie er darauf kommt.
Der "Erfolg" von XeonPhi zeigt ja, dass das nicht wirklich korrekt ist.
Akkarin
2013-06-26, 20:08:27
XeonPhi hat doch auch 4Threads/Core ?
Skysnake
2013-06-26, 20:32:13
Ja, das liegt aber an was anderem.
Ja, das liegt aber an was anderem.
Das wäre?:)
Das Posting gibts hier:
http://www.semiaccurate.com/forums/showpost.php?p=184500&postcount=927
Der betreffende Auszug:
The dual 6 cycle 256 bit FMA FP units "cry out loud" for more threads,
they will be idle and unused otherwise for most of the cycles since you
need 2x6=12 FP operations to go on simultaneously to fully utilize them.
Even with 4 threads that's still 3 FP operations in parallel per thread.
Datum: Ziemlich genau vor nem Monat.
Skysnake
2013-06-26, 23:38:33
Ok, jetzt versteh ich, warum er darauf kommt, das man mehr Threads brüchte.
The old 128 bit FMA units used the hardware more efficiently with two
cycles used per AVX operations but I guess one needs full 256 bit AVX
units to score well at these specially designed synthetic, but otherwise
pretty useless, benchmarks.
Er meint schlichtweg, das "niemand" derart viel AVX-Performance braucht. Für den gesamten Consumerbereich und auch für schlecht parallelisierbaren Code stimmt das auch durchaus. Sobald man aber in Finite Elemente usw geht, stimmt das halt nicht mehr.
Man macht da ein bischen den iGPUs halt Konkurrenz.
Das ist aber nicht unbedingt ein Problem, weil die nötige Parallelität eben immer noch deutlich niedriger ist als bei GPUs. Man nähert sich nur etwas an.
Das ist halt eine grundlegende Einstellung, was man für Code erwartet, und welche "Einschränkungen"/Limitierungen man alsvertretbar erachtet.
Klar, wenn man Code hat, der relativ I/O Bound ist, und allgemein viele Branches hat usw. Macht es sinn, wenn man ein SMT-Design hätte. Das Problem hier ist aber der hohe Aufwand, den man betreiben muss um SMT zu implementieren.
AMD kann nicht zaubern. Ich finde das verliert er hier etwas aus den Augen. Die Limitierung ist sicherlich von ihm richtig erkannt, aber für die Software, die man überhaupt auf den Einsatz von AVX trimmt, sollte normal so viel Parallelität schon von sich aus vorhanden sein, dass das eigentlich kein Problem darstellt.
Den Aufriss mit AVX oder auch SSE macht man ja eigentlich nur, wenn man wirklich relevante Zeit in parallelisierbaren Codebereichen verbringt. Und ich kenne eigentlich kein Problem, wo das jetzt der Fall wäre bei unseren heutigen High-End-CPUs, bei denen die parallelität dann nicht gleich gewaltig ist, so das man sogar sich Gedanken über den Einsatz von iGPUs machen kann.
Denn da wo es nicht so ist, da ist die Laufzeit auch meist nicht derart kritisch, als das man das letzte aus der Applikation raus holen müsste. Die CPUs sind einfach schnell genug.
@S940:
bzgl Threads:
Du kannst nur jeden zweiten Takt eine Instruktion vom gleichen Thread ausführen.
Du brauchst also min 2 Threads, um überhaupt die ALUs voll aus zu lasten.
Mit nur einem Thread würde da wie folgt aussehen wenn man sich die Takte anschaut, wobie _ für leere Pipelinestufe/clock ohne Befehl steht.
1_1_1_1_1_1_1_1_ usw
Mit 2 Threads läufts im Optimalfall so ab:
12121212121212121212 usw
Das ist aber nicht wirklich wahrscheinlich. Also ist man auf 4 Threads gegangen. 3 Wäre auch möglich gewesen, aber 3 ist keine 2^x Potenz, daher ist der Aufwand für 4 meist nicht viel größer als für 3. Also halt kleiner, deswegen nimmt man immer gern Zweierpotenzen.
Ansonsten gibts in KNC halt noch so ein paar Strickfallen, die es sinnig machen, das man 4 Threads verwendet. Das sind aber eher profane Sachen bzgl RAM usw. Da sind halt doch gewisse Latenzen da, die man mit mehr Threads einfach leichter verstecken kann.
Das hat aber an sich nichts mit der breite der Register zu tun, sondern mit dem konzeptionellen Aufbau von XeonPhi. Das geht jetzt aber zu sehr ins Detail. Da kann ich einfach nichts weiter dazu sagen, außer halt das ich nur empfehlen kann sich mal durch die paar hundert Seiten Doku durch zu beisen, und eventuell mal den Source-Code für den Treiberstack genauer an zu schauen ;)
y33H@
2013-06-26, 23:47:31
OBR hat übrigens dicht gemacht ^^
Skysnake
2013-06-27, 01:06:06
Ich weiß. Der hatte ja schon Monate lang nichts mehr gepostet. Vor paar Wochen bin ich dann mal wieder auf die Seite um zu schauen, ob er mal wieder irgend nen Stuss von sich gibt, und hab das dann gelesen. Und ja, ich konnte mir eine gewisse Schadenfreude nicht verkneifen :biggrin:
Vielleicht sitzt er ja für einen der "Späße" die er abgezogen hat mit Donanimhaber und auch BSN ja im Knast ;D Nein, das wünsch ich ihm nicht, aber wirklich wundern würde es mich irgendwie auch nicht. Das waren schon paar Kracher dabei, die mindestens am Rande der Legalität waren...
@S940:
bzgl Threads:
Du kannst nur jeden zweiten Takt eine Instruktion vom gleichen Thread ausführen.
Du brauchst also min 2 Threads, um überhaupt die ALUs voll aus zu lasten.
Mit nur einem Thread würde da wie folgt aussehen wenn man sich die Takte anschaut, wobie _ für leere Pipelinestufe/clock ohne Befehl steht.
1_1_1_1_1_1_1_1_ uswAch genau, danke, irgendwo hatte ich das schon mal gelesen.
Aber das kapier ich jetzt nicht:
Mit 2 Threads läufts im Optimalfall so ab:
12121212121212121212 usw
Das ist aber nicht wirklich wahrscheinlich. Also ist man auf 4 Threads gegangen. Wieso ist das nicht wirklich wahrscheinlich? Kann ich da nicht Deine Argumente von oben dagegen aufführen:
Für den gesamten Consumerbereich und auch für schlecht parallelisierbaren Code stimmt das auch durchaus. Sobald man aber in Finite Elemente usw geht, stimmt das halt nicht mehr.
...aber für die Software, die man überhaupt auf den Einsatz von AVX trimmt, sollte normal so viel Parallelität schon von sich aus vorhanden sein, dass das eigentlich kein Problem darstellt.
Bei 2 Threads ist Dein Argument akzeptiert, aber dann von 2 auf 4 Threads, ist das nicht die gleiche Argumentation wie beim potentiellen 4thread SR?
Ansonsten gibts in KNC halt noch so ein paar Strickfallen, die es sinnig machen, das man 4 Threads verwendet. Das sind aber eher profane Sachen bzgl RAM usw. Da sind halt doch gewisse Latenzen da, die man mit mehr Threads einfach leichter verstecken kann.
Klingt auch wieder eher nach de Vries' Argumentation. Latenzen-verstecken durch SMT ist bei ner dual 256bit FMAC-Unit sicherlich auch nicht verkehrt. Selbst wenn angeforderte Daten im L1 sind, dauerts 4 Takte bis das da ist, in der Zeit können schon wieder acht 256 FMAC-Ops in die 2 Pipes geschoben werden.
Das hat aber an sich nichts mit der breite der Register zu tun, sondern mit dem konzeptionellen Aufbau von XeonPhi. Das geht jetzt aber zu sehr ins Detail. Da kann ich einfach nichts weiter dazu sagen, außer halt das ich nur empfehlen kann sich mal durch die paar hundert Seiten Doku durch zu beisen, und eventuell mal den Source-Code für den Treiberstack genauer an zu schauen ;)Hehe, ja ich merks mir mal vor, Intel Dokus sind meistens ja auch recht gut und informativ :) Danke auf alle Fälle fürs Erklären.
Skysnake
2013-06-27, 14:06:50
Aber das kapier ich jetzt nicht:
Wieso ist das nicht wirklich wahrscheinlich? Kann ich da nicht Deine Argumente von oben dagegen aufführen:
Bei 2 Threads ist Dein Argument akzeptiert, aber dann von 2 auf 4 Threads, ist das nicht die gleiche Argumentation wie beim potentiellen 4thread SR?
KNC ist ein in-order Design ;)
Dazu kommt noch, dass du eben den Ringbus hast, auf den alle zugreifen, und dazu ja auch noch die Kommunikation zwischen den Kernen über den Ringbus laufen. Da macht es schon Sinn 4 Threads zu machen.
Eigentlich könnte man es ja auch "fast" als ein 2x2 Design sehen, wobei das natürlich nicht stimmt, man unterschägt dann ja die Auswahlmöglichkeit aus jeweils einem weiteren Thread.
Klingt auch wieder eher nach de Vries' Argumentation. Latenzen-verstecken durch SMT ist bei ner dual 256bit FMAC-Unit sicherlich auch nicht verkehrt. Selbst wenn angeforderte Daten im L1 sind, dauerts 4 Takte bis das da ist, in der Zeit können schon wieder acht 256 FMAC-Ops in die 2 Pipes geschoben werden.
Die Latenzen in BD sind aber niedriger als in KNC. Zudem ist es eben kein in-order-Design.
An was du da dran hängst ist eher der Durchsatz der Caches/Speicher, und der erhöht sich durch mehr Threads nicht.
Wenn würde ich eher die Caches breiter anbinden, oder vielleicht auch einfach die Statusregister verdoppeln, damit man mehr Registerrenameing machen kann, was dann natürlich die Caches entlastet.
Was aus meiner Sicht hier passen muss ist einfach die Anbindung des L1 und noch des L2. Wenn das wuppt, dann passt das. Branches sind zwar auch noch ein Problem, aber wo man AVX2 einsetzt sollte das keinen signifikanten Auswirkungen haben.
Hehe, ja ich merks mir mal vor, Intel Dokus sind meistens ja auch recht gut und informativ :) Danke auf alle Fälle fürs Erklären.
Naja, man erfährt schon einiges, aber die interessanten Sachen stehen natürlich nicht drin. Das ist aber bei allen Herstellern gleich....
Ronny145
2013-07-01, 14:13:03
Dass Knights Landing zweckmäßigerweise austauschbar in einen Xeon-Sockel passen wird, wollte Hazra noch nicht bestätigen – aber das taten für ihn dann einige OEM-Partner auf der ISC. Auch zum neuen x86-Kern wollte Hazra nichts verraten. Hier hört man schon seit längerer Zeit, dass Intel vom doch recht antiquierten Pentium hin zu aktuellem Atom wechseln wird, vermutlich mit einer dem Silvermont ähnlichen Out-of-Order-Architektur.
Zudem wird er mit Stacked-Memory im Package ausgestattet. Die Größe ist noch unbekannt, es dürfte sich wohl um ein oder mehrere GByte handeln. Die Bandbreite von In-Package-DRAM, so erfuhr man in anderen ISC-Sessions von Intel-Entwicklern, soll acht- bis zehnfach höher als bei externem Memory sein – das lässt einiges erhoffen.
http://www.heise.de/ct/artikel/Prozessorgefluester-1896864.html
Würde 1+ GB Edram nicht zu viel Platz einnehmen? Die 128 MB von Iris Pro sind ja auch schon rund 80 mm² groß.
Skysnake
2013-07-01, 14:15:50
Denk mal bei dem "eDRAM" an HMC. Das kommt schon hin.
AnarchX
2013-07-01, 14:59:09
Mit externem Speicher sind wohl die 256-Bit@1,6-2,1Gbps eines Xeon-Sockel gemeint und nicht die 512-Bit@5,5Gbps einer Xeon Phi Steckkarte?
Wobei ersteres eher moderat mehr wäre, während letzeres etwas zu hoch erscheint (>3 TB/s). :|
Spasstiger
2013-07-02, 01:45:38
Die Speicherbandbreite könnte sich auch auf ein GDDR5-Chippackage beziehen, also bei 6 Gbps mit 32 Bit Datenbreite z.B. 24 GB/s, was bei einem Faktor 10 realistischen 240 GB/s entspricht.
Daredevil
2018-05-14, 21:15:09
Da isses :> ( Funzt aber nicht... )
um-1fAVU1OQ
gravitationsfeld
2018-05-14, 22:03:27
Oh Gott, warum hab ich's angeklickt. Der Typ ist so ultra nervig und labert so einen Duennschiss. Jedes Mal.
PatkIllA
2018-05-14, 22:45:40
Oh Gott, warum hab ich's angeklickt. Der Typ ist so ultra nervig und labert so einen Duennschiss. Jedes Mal.
Dachte ich mir auch. Den ganzen Grafikkrams (unterschiedliches AA, prozedurale Texturen) den er nennt geht doch schon längst und die Shader sind doch flexibel einsetzbar. Mehre Anwendungen geht auch usw.
Und dann nicht mal nen Bild und die Karte nicht auseinander genommen.
Loeschzwerg
2018-05-15, 07:02:23
"First and only dedicated graphics card..." Was war dann Auburn aka i740?
Naja, der Rest war fast klar, die Karte muss erst gesondert initialisiert werden.
Bilder gibt es hier:
https://forum.beyond3d.com/threads/intel-larrabee-drivers-software.60287/
Sonyfreak
2018-05-15, 10:06:06
Dachte ich mir auch. Den ganzen Grafikkrams (unterschiedliches AA, prozedurale Texturen) den er nennt geht doch schon längst und die Shader sind doch flexibel einsetzbar. Mehre Anwendungen geht auch usw.Naja, das ist ein Youtube-Kanal für Leute, die nicht ganz so tief in der Materie sind. Er gibt halt Beispiele für mögliche Anwendungszwecke, die man auch als Laie halbwegs nachvollziehen kann.
"First and only dedicated graphics card..." Was war dann Auburn aka i740?Ja, das hab ich mir auch gedacht. Vermutlich meinte er in der neueren Computergeschichte ...
Naja, der Rest war fast klar, die Karte muss erst gesondert initialisiert werden.Was meinst du mit initialisieren?
mfg.
Sonyfreak
Loeschzwerg
2018-05-15, 10:42:42
Das Teil im Video ist ein Prototyp und Larrabee war vorrangig ein HPC Projekt mit Option für Grafikberechnung. Mehr als eine Basis Firmware (wenn überhaupt) ist auf der Karte (nach der Produktion) nicht vorhanden d.h. du musst der Karte erst einmal sagen was du von ihr erwartest (Grafik und/oder HPC... etc).
Die Karte fährt primär ein FreeBSD und lädt erst über den Treiber die entsprechenden DirectX bzw. OGL "Programme".
Bildausgabe beim Boot wirst du nur bei Karten haben die aus der entsprechenden Abteilung kommen.
Sämtliche Infos hat Linus vermutlich aus diesem alten Blog-Post von Tom Forsyth:
http://tomforsyth1000.github.io/blog.wiki.html#%5B%5BWhy%20didn%27t%20Larrabee%20fail%3F%5D%5D
Why didn't Larrabee fail?
TomForsyth, 15 August 2016 (created 15 August 2016)
Every month or so, someone will ask me what happened to Larrabee and why it failed so badly. And I then try to explain to them that not only didn't it fail, it was a pretty huge success. And they are understandably very puzzled by this, because in the public consciousness Larrabee was like the Itanic and the SPU rolled into one, wasn't it? Well, not quite. So rather than explain it in person a whole bunch more times, I thought I should write it down.
This is not a history, and I'm going to skip a TON of details for brevity. One day I'll write the whole story down, because it's a pretty decent escapade with lots of fun characters. But not today. Today you just get the very start and the very end.
When I say "Larrabee" I mean all of Knights, all of MIC, all of Xeon Phi, all of the "Isle" cards - they're all exactly the same chip and the same people and the same software effort. Marketing seemed to dream up a new codeword every week, but there was only ever three chips:
Knights Ferry / Aubrey Isle / LRB1 - mostly a prototype, had some performance gotchas, but did work, and shipped to partners.
Knights Corner / Xeon Phi / LRB2 - the thing we actually shipped in bulk.
Knights Landing - the new version that is shipping any day now (mid 2016).
That's it. There were some other codenames I've forgotten over the years, but they're all of one of the above chips. Behind all the marketing smoke and mirrors there were only three chips ever made (so far), and only four planned in total (we had a thing called LRB3 planned between KNC and KNL for a while). All of them are "Larrabee", whether they do graphics or not.
When Larrabee was originally conceived back in about 2005, it was called "SMAC", and its original goals were, from most to least important:
1. Make the most powerful flops-per-watt machine for real-world workloads using a huge array of simple cores, on systems and boards that could be built into bazillo-core supercomputers.
2. Make it from x86 cores. That means memory coherency, store ordering, memory protection, real OSes, no ugly scratchpads, it runs legacy code, and so on. No funky DSPs or windowed register files or wacky programming models allowed. Do not build another Itanium or SPU!
3. Make it soon. That means keeping it simple.
4. Support the emerging GPGPU market with that same chip. Intel were absolutely not going to build a 150W PCIe card version of their embedded graphics chip (known as "Gen"), so we had to cover those programming models. As a bonus, run normal graphics well.
5. Add as little graphics-specific hardware as you can get away with.
That ordering is important - in terms of engineering and focus, Larrabee was never primarily a graphics card. If Intel had wanted a kick-ass graphics card, they already had a very good graphics team begging to be allowed to build a nice big fat hot discrete GPU - and the Gen architecture is such that they'd build a great one, too. But Intel management didn't want one, and still doesn't. But if we were going to build Larrabee anyway, they wanted us to cover that market as well.
Now remember this was around 2005 - just as GPGPU was starting to show that it could get interesting wins on real HPC workloads. But it was before the plethora of "kernel" style coding languages had spread to "normal" languages like C and FORTRAN (yes, big computing people still use FORTRAN, get over it). Intel was worried its existing Xeon CPU line just weren't cutting it against the emerging threat from things like GPGPU, the Sony CELL/SPU, Sun's Niagara, and other radical massively-parallel architectures. They needed something that was CPU-like to program, but GPU-like in number crunching power.
Over the years the external message got polluted and confused - sometimes intentionally - and I admit I played my own part in that. An awful lot of "highly speculative marketing projections" (i.e. bullshit) was issued as firm proclamations, and people talked about things that were 20 years off as if they were already in the chip/SW. It didn't help that marketing wanted to keep Larrabee (the graphics side) and MIC/Knights/Xeon Phi (the HPC side) separate in the public consciousness, even though they were the exact same chip on very nearly the exact same board. As I recall the only physical difference was that one of them didn't have a DVI connector soldered onto it!
Behind all that marketing, the design of Larrabee was of a CPU with a very wide SIMD unit, designed above all to be a real grown-up CPU - coherent caches, well-ordered memory rules, good memory protection, true multitasking, real threads, runs Linux/FreeBSD, etc. Larrabee, in the form of KNC, went on to become the fastest supercomputer in the world for a couple of years, and it's still making a ton of money for Intel in the HPC market that it was designed for, fighting very nicely against the GPUs and other custom architectures. Its successor, KNL, is just being released right now (mid 2016) and should do very nicely in that space too. Remember - KNC is literally the same chip as LRB2. It has texture samplers and a video out port sitting on the die. They don't test them or turn them on or expose them to software, but they're still there - it's still a graphics-capable part.
So how did we do on those original goals? Did we fail? Let's review:
1. Make the most powerful flops-per-watt machine.
SUCCESS! Fastest supercomputer in the world, and powers a whole bunch of the others in the top 10. Big win, covered a very vulnerable market for Intel, made a lot of money and good press.
2. Make it from x86 cores.
SUCCESS! The only compromise to full x86 compatibility was KNF/KNC didn't have SSE because it would have been too much work to build & validate those units (remember we started with the original Pentium chip). KNL adds SSE legacy instructions back in, and so really truly is a proper x86 core. In fact it's so x86 that x86 grew to include it - the new AVX512 instruction set is Larrabee's instruction set with some encoding changes and a few tweaks.
3. Make it soon. That means keeping it simple.
NOT BAD. It's not quite as simple as slapping a bunch of Pentiums on a chip of course, but it wasn't infeasibly complex either. We did slip a year for various reasons, and then KNF's performance was badly hurt by a bunch of bugs, but these things happen. KNC was almost on time and turned out great.
4. Support the emerging GPGPU market. As a bonus, run normal graphics well.
PRIMARY GOAL: VIRTUAL SUCCESS! It would have been a real success if it had ever shipped. Larrabee ran Compute Shaders and OpenCL very well - in many cases better (in flops/watt) than rival GPUs, and because it ran the other graphical bits of DirectX and OpenGL pretty well, if you were using graphics APIs mainly for compute, it was a compelling package. Unfortunately when the "we don't do graphics anymore" orders came down from on high, all that got thrown in the trash with the rest. It did also kickstart the development of a host of GPGPU-like programming models such as ISPC and CILK Plus, and those survive and are doing well.
BONUS GOAL: close, but no cigar. I'll talk about this more below.
5. Add as little graphics-specific hardware as you can get away with.
MODERATE SUCCESS: The only dedicated graphics hardware was the texture units (and we took them almost totally from Gen, so we didn't have to reinvent that wheel). Eyeballing die photos, they took up about 10% of the area, which certainly isn't small, but isn't crazy-huge either. When they're not being used they power down, so they're not a power drain unless you're using them, in which case of course they're massively better than doing texture sampling with a core. They were such a small part that nobody bothered to make a new version of KNC without them - they still sit there today, visible on the die photograph as 8 things that look like cores but are slightly thinner. Truth be told, if KNC had been a properly graphics-focused part we would have had 16 of the things, but it wasn't so we had to make do with 8.
In total I make that three wins, one acceptable, and a loss. By that score Larrabee hardly "failed". We made Intel a bunch of money, we're very much one of the top dogs in the HPC and supercomputer market, and the "big cores" have adopted our instruction set.
So let's talk about the elephant in the room - graphics. Yes, at that we did fail. And we failed mainly for reasons of time and politics. And even then we didn't fail by nearly as much as people think. Because we were never allowed to ship it, people just saw a giant crater, but in fact Larrabee did run graphics, and it ran it surprisingly well. Larrabee emulated a fully DirectX11 and OpenGL4.x compliant graphics card - by which I mean it was a PCIe card, you plugged it into your machine, you plugged the monitor into the back, you installed the standard Windows driver, and... it was a graphics card. There was no other graphics cards in the system. It had the full DX11 feature set, and there were over 300 titles running perfectly - you download the game from Steam and they Just Work - they totally think it's a graphics card! But it's still actually running FreeBSD on that card, and under FreeBSD it's just running an x86 program called DirectXGfx (248 threads of it). And it shares a file system with the host and you can telnet into it and give it other work to do and steal cores from your own graphics system - it was mind-bending! And because it was software, it could evolve - Larrabee was the first fully DirectX11-compatible card Intel had, because unlike Gen we didn't have to make a new chip when Microsoft released a new spec. It was also the fastest graphics card Intel had - possibly still is. Of course that's a totally unfair comparison because Gen (the integrated Intel gfx processor) has far less power and area budget. But that should still tell you that Larrabee ran graphics at perfectly respectable speeds. I got very good at ~Dirt3 on Larrabee.
Of course, this was just the very first properly working chip (KNF had all sorts of problems, so KNC was the first shippable one) and the software was very young. No, it wasn't competitive with the fastest GPUs on the market at the time, unless you chose the workload very carefully (it was excellent at running Compute Shaders). If we'd had more time to tune the software, it would have got a lot closer. And the next rev of the chip would have closed the gap further. It would have been a very strong chip in the high-end visualization world, where tiny triangles, super-short lines and massive data sets are the main workloads - all things Larrabee was great at. But we never got the time or the political will to get there, and so the graphics side was very publicly cancelled. And then a year later it was very publicly cancelled again because they hadn't actually done it the first time - people kept working on it. And then a third time in secret a bit later, because they didn't want anybody to know people were still working on graphics on LRB.
So - am I sad Larrabee as a graphics device failed? Well, yes and no.
I have always been a graphics programmer. The whole "CPU architect" thing was a total accident along the way. As such, I am sad that we didn't get to show what KNC could do as a really amazing emulation of a GPU. But I am still hugely proud of what the team managed to do with KNC given the brief of first and foremost being a real highly-coherent legacy-compatible CPU running a grown-up OS.
Do I think we could have done more graphics with KNC? In terms of hardware, honestly not really. There's nothing I sit here and think "if only we'd done X, it all would have been saved". KNC was a hell of a chip - still is - I don't see how we could have squeezed much more out of the time time and effort budgets we had - we already had some features that were kicked in the arse until they squeezed in under the wire (thanks George!). Having 16 texture samplers instead of just 8 would have helped, but probably not enough to prevent us getting cancelled. We could certainly have done with another year of tuning the software. We could have also done with a single longer-term software effort, rather than 4-5 different short-term ones that the random whims of upper management forced upon us (that's a whole long story all by itself). I could also wish for a graphics-capable version of KNL (i.e. add the texture units back in), but honestly just imagine what people could have done in the five years since KNC shipped if they had allowed normal people to access the existing texture units, and write their own graphics pipelines - it would have been amazing! So my biggest regret is that we were forbidden from exposing the goodness that already existed - that's the thing that really annoys me about the whole process.
Even then, it's hard for me to be too morose when so many of my concepts, instructions and architecture features are now part of the broader x86 ecosystem in the form of AVX512. I'm not sure any other single person has added so many instructions to the most popular instruction set in the world. It's a perfectly adequate legacy for an old poly-pusher! And now I'm doing that VR thing instead. Maybe it all worked out for the best.
Sonyfreak
2018-05-15, 13:08:53
Verstehe. Danke für den sehr interessanten Text. Schade, dass nicht mehr aus Larrabee geworden ist. :frown:
mfg.
Sonyfreak
gravitationsfeld
2018-05-15, 16:27:18
Nichts daran ist schade, das Konzept war ein Rohrkrepierer. Die Leistung fuer die Stromaufnahme war absurd. Niemand braucht volle x86-Decoder in einer GPU.
Selbst Xeon Phi wurde aus gutem Grund beerdigt.
misterh
2018-05-16, 23:44:48
https://abload.de/thumb/82fd608b-0047-41a1-979iooa.jpg (http://abload.de/image.php?img=82fd608b-0047-41a1-979iooa.jpg)
schade dass ich damit nicht mehr rumspielen kann als in moment. :freak:
=Floi=
2018-08-19, 05:56:19
Warum wurde das für intel eigentlich so ein reinfall?
was war für die firmen der größte punkt das produkt nicht zu kaufen?
Skysnake
2018-08-19, 10:26:07
Ein Problem von KNC waren die zwei Speicherbereiche. Das hat eigentlich keiner wirklich benutzt. Zudem hat man aus dem HMC nicht die angedachte Bandbreite bekommen. Und an Bandbreite mangelt es eigentlich immer...
Dazu kommt noch das HMC dedizierte Read und write lanes hat. Typische Anwendungen machen aber 2R 1W oder lesen sogar noch viel mehr pro write da die writes im cache bleiben.
Damit sinkt der nominell Vorteil von HMC um Vergleich zu ddr4
Und der Intel Compiler hatte bis zum ic18 auch noch einige Macken.
Naja und Applikationen haben auch immer einen sequenziellen Anteil und die Cores waren halt da wirklich nicht so toll. Gerade MPI hat darunter schon auch ziemlich gelitten. Intel hat da ihre eigene Skalar-Erfolgsgeschichte eingeholt, die Ihnen auch mit Skylake etc Probleme macht.
Die ganzen Codes vektorisieren nicht mehr so wie zu ziehen der Vektor Rechner
Ailuros
2022-12-26, 05:19:50
Noch eine Leiche aus der Vergangenheit: https://www.fudzilla.com/news/56036-one-two-three-its-intel-s-second-gen-larrabee
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.