Pascal - GP100 - 2016 - 3D-Memory HBM, NVLINK, Mixed Precision

[y33H@]

Du meinst das von Stilli: http://www.heise.de/newsticker/meldung/Supercomputer-ARMv8-und-McKernel-3247993.html

[Skysnake]

Ja genau das meinte ich. Ich hoffe ich habe es richtig wiedergegeben. Ist leider etwas schwer verständlich für mich.

Ansonsten:
P100 Server in Q1/17 (https://www.semiwiki.com/forum/content/5911-nvidia-extends-their-datacenter-performance-lead-neural-network-computing.html)

Wann es dann wohl mal P100 für den Desktop geben könnte kann man sich wohl denken.

Meiner Meinung nach gar nicht. Auf jeden Fall nicht vor Q2, eher Q3/17.

Damit kann man sich wohl bezüglich P100 vs AMD Consumer-Vergleichen nur noch den Poppes wischen.

[Mancko]

Damit kann man sich wohl bezüglich P100 vs AMD Consumer-Vergleichen nur noch den Poppes wischen.

Die Vergleiche machen doch eh keinen Sinn. Nvidia ist bereits finanziell in der ausgezeichneten Lage sich hier unterschiedliche GPU Setups / Designs für die beiden Märkte leisten zu können. GP102 wird für den Consumer Bereich deutlich besser geeignet sein als P100 und er wird noch Luft nach oben lassen, denn der Prozess wird noch eine Weile halten müssen. Schöne Salami Taktik halt :)

[Skysnake]

GP102 wirste aber wohl auch nicht so schnell sehen. Wenn es dieses Jahr noch etwas wird dürfen wir denke ich ganz froh sein.

[Godmode]

GP102 wirste aber wohl auch nicht so schnell sehen. Wenn es dieses Jahr noch etwas wird dürfen wir denke ich ganz froh sein.

Wir gehen von Herbst/Winter aus. Zumindest Ailuros sagte was ähnliches, siehe GP102 Thread:

http://www.forum-3dcenter.org/vbulletin/showthread.php?t=573848

[Skysnake]

schaumer mal. Wäre auf jeden Fall sehr schön.

[Hübie]

Btw. Was man auch mal erwähnen sollte. Ich habe irgendwo einen Bericht über die StudentClusterCompetition auf der ISC gelesen. Da war wohl auch ein Team mit Power+Pascal am Start. Da hies es, das Team hätte große Probleme damit gehabt, das Beast in der Powerbeschränkung zu halten und wären nicht mal dazu gekommen alle Benchmarks zu compilieren... Leider ging man nicht näher darauf ein. Aber sowas lässt natürlich das Vertrauen in die Lösung wachsen... Äh.. NOT!

Meinst du das PT von Pascal oder von P8+? Haste da mal einen Link? Bisher ist noch nichts final und nach wie vor ist Pascal ein Intermezzo. Von PT-Probleme hörte ich bisher noch nichts im DGX-1.

Afaik hatten die Studenten GP104 und dieser ist, wie wir wissen sehr konservativ im PT gehalten...

[Mancko]

GP102 wirste aber wohl auch nicht so schnell sehen. Wenn es dieses Jahr noch etwas wird dürfen wir denke ich ganz froh sein.

Wozu auch. Aktuell hat man in dem Segment ein Alleinstellungsmerkmal, da keine Konkurrenz da ist. Wüsste jetzt also auch nicht wozu GP102 nun jetzt schon kommen soll. Mit Vega, davor oder kurz danach reicht völlig aus. Bis dahin ist man in dem Segment eh unangefochten.

[Dural]

Die Titan wird Garantiert noch dieses Jahr kommen. ;)

NV hat ja schon bestätigt das alle Pascal GPUs den Tapout hinter sich haben (ich glaub das war im März)

[Skysnake]

Gute Neuigkeiten. Supermicro bringt die P100 mit NVLink und x86. (http://insidehpc.com/2016/07/59392/)

P100 kann zwar nicht mit der CPU über NVLink kommunizieren, aber immerhin die P100 untereinander.

Ich bin mal gespannt, was der Preisunterschied wird. :)

[AffenJack]

Nur isses keine große Neuigkeit, Supermicro hat das Ding schon zum GP100 Launch im April gezeigt.

[Skysnake]

Wirklich? Ich hatte nur die Power Kiste bisher gesehen mit NVLink.

[AffenJack]

http://www.hardware.fr/news/14588/gtc-supermicro-premier-tesla-p100.html

Jo war x86, Power wird doch sowieso nur ne Niesche bleiben, auch wenn sie Marktanteile gewinnen. Der Großteil werden eh die x86 Kisten sein, wo die GPUs über Nvlink kommunizieren.
Power hat wenn dann in China ne gute Chance.

[Skysnake]

Das war aber meines Wissens nach nicht in den deutschen oder englischen Medien.

[AffenJack]

Das war aber meines Wissens nach nicht in den deutschen oder englischen Medien.

Doch, ich war nur zu fual zu suchen und nahm den ersten Link, sogar bei CB gabs ne Meldung dazu:

https://www.computerbase.de/2016-04/supermicro-high-end-gpu-server-mit-pascal-gpu-noch-dieses-jahr/

Bei Englischsprachigen genauso, das nun nicht jede Seite Serverlösungen interessieren sollte klar sein, aber ich kann nix dafür, wenn du die News überliest.

[Skysnake]

Die habe ich sogar kurz gelesen gehabt, aber das mit den NVLink eben überlesen, so das ich davon ausging, das es sich um die PCI-E Variante handelt.

Ich werde ja auch nicht dafür bezahlt das Zeug zu verfolgen sondern mache das nur aus Privatvergnügen, da ist es natürlich schon sträflich so etwas zu verpassen... :P

[Loeschzwerg]

Ich fand das Video trotzdem interessant, Supermicro hat schon ein paar tolle Sachen. Da könnte sich mein Arbeitgeber eine Scheibe davon abschneiden...

[mironicus]

Hat sich eigentlich irgendwas bei der H265-Encoding-Einheit bei Pascal verbessert? Produktiv nutze ich bereits die H265-Einheit von Maxwell-Karten mit dem Programm StaxRip. Ich habe noch keinen Vergleich im Internet sehen können, ob sich da qualitativ etwas verbessert hat.

Damit meine ich natürlich primär die Bildqualität der Hardwareenkodierung. Die war schon bei Maxwell sehr gut.

[Troyan]

Laut nVidia hat man die ersten GP100 Chips im November 2015 von TSMC erhalten:
https://blogs.nvidia.com/blog/2016/07/11/how-nvidia-built-dgx-1/

[N0Thing]

Laut nVidia hat man die ersten GP100 Chips im November 2015 von TSMC erhalten:
https://blogs.nvidia.com/blog/2016/07/11/how-nvidia-built-dgx-1/

Ich vermute mal, dass dies schon wirklich fertige GP100 Chips bedeutet. Laut dem Ingenieur aus deren Testlabor, der in einem Video seinen Arbeitsplatz präsentiert hat, haben sie ja sogar schon vor ein paar Monaten Testchips der 10nm Fertigung im Haus gehabt. Ist natürlich nicht das Gleiche, aber bis fertige Chips in 10nm zu erwarten sind, dürfe es ja noch recht lange dauern.

Nvidia scheint in Sachen Entwicklung, wirklich gut für die Zukunft aufgestellt zu sein.

[-/\-CruNcher-/\-]

Hat sich eigentlich irgendwas bei der H265-Encoding-Einheit bei Pascal verbessert? Produktiv nutze ich bereits die H265-Einheit von Maxwell-Karten mit dem Programm StaxRip. Ich habe noch keinen Vergleich im Internet sehen können, ob sich da qualitativ etwas verbessert hat.

Damit meine ich natürlich primär die Bildqualität der Hardwareenkodierung. Die war schon bei Maxwell sehr gut.

Und schon das du sie sehr gut findest reicht doch, weil den Schock das es eben weitab von gut ist verkraftet nicht jeder, es ist zweckmässig und kosteneffizient mehr aber auch nicht ;)

[Hübie]

Laut nVidia hat man die ersten GP100 Chips im November 2015 von TSMC erhalten:
https://blogs.nvidia.com/blog/2016/07/11/how-nvidia-built-dgx-1/

Die waren noch lang nicht final. ;) Aber es ist schon wirklich so, dass man da ein Projekt aus dem Boden stampfte und dies doch recht schnell ohne große Komplikationen durchführte. Daher frage ich mich immer wieder was AMD so lang an Polaris herumgedoktort hat. :confused:

@N0Thing: Das werden eher so etwas wie Tegra 6 / 7 sein.

[Skysnake]

Naja, ein Produkt das man nicht wirklich kaufen kann.

Das kann man nicht wirklich mit Polaris vergleichen. Ansonsten gibt es KNL auch schon seit letztem Jahr.

[Dural]

Aha pascal kann mam also nicht kaufen.

[Hübie]

Er meinte explizit GP100 ;) Und da musst du schon "Glück" haben. Probiers doch aus.

[mksn7]

Btw. Was man auch mal erwähnen sollte. Ich habe irgendwo einen Bericht über die StudentClusterCompetition auf der ISC gelesen. Da war wohl auch ein Team mit Power+Pascal am Start. Da hies es, das Team hätte große Probleme damit gehabt, das Beast in der Powerbeschränkung zu halten und wären nicht mal dazu gekommen alle Benchmarks zu compilieren... Leider ging man nicht näher darauf ein. Aber sowas lässt natürlich das Vertrauen in die Lösung wachsen... Äh.. NOT!

Laut Artikel gings da um ARM System. Power+Pascal waren auf der Student Cluster Competition (SCC) auf der ISC sicher keine dabei, ich war selbst dort. Die SCC Regeln für die SC schreiben vor, dass die Teams keine Hardware verwenden dürfen die zum Zeitpunkt der Competition nicht verfügbar ist bzw. die Hardware darf keinem NDA unterliegen, weil die Ergebnisse sonst nicht veröffentlich werden dürfen. Auf der SCC auf der SC wird man vielleicht einige P100 sehen, nvidia hat sich nicht ganz eindeitig geäußert.

Wer mit ARM zur SCC fährt, weiß dass er nicht gewinnen wird. Ich war selbst zweimal bei der SCC auf SC14 und SC15 dabei und hab mich mit dem spanischen Team, die 2015 das erste Team mit ARM waren, unterhalten. Einer der größten Hürden bei der SCC ist der dürftige Zustand vieler wissenschaftlicher Codes. Desto gewöhnlicher das System, desto höher die Chance das die Software baut und läuft. Also am Besten x86 und CentOS.

Die SCC spiegelt auch die ganze Acceleratorgeschichte ganz gut wieder: Für den Best Linpack Award super, für die Applications kann mans meist vergessen.

Edit: NVLink ist natsächlich nicht so die extreme Steigerung in der Bandbreite (k.A. wegen Latenzen), aber die mehreren (4) dedicated Links sind für all-to-all MultiGPU Datenaustausch schon sehr gut. (Mehr als 11.6 GB/s hab ich über PCIe auch nie gemessen, bei NVLink kommt da aber vielleicht auch nicht alles an). Ich hab bei nvidia eine Performanceprojektion für MultiGPU Radix Sort mit PCIe und NVLink gemacht, da ist der data exchange dann schon ein mehrfaches schneller, nicht zuletzt weil bspw. in einem 4 GPU System zwischen jeweils zweier Gruppen ein shared PCIe Link ist. In irgendwelchem NVLink Marketingmaterial gibts Graphen zum projizierten NVLink speedup, unter anderem meine Daten für MultiGPU Sort.

[Dural]

Das war auf seine Aussage von wegen nicht mit Polaris vergleichbar bezogen. ;)

[scully1234]

haben wir eigentlich schon nen Volta Thread?


Volta steigt auch mit TSMCs 16nm FinFET in den Ring mit ''dramatischer'' Effizienzverbesserung

http://www.fudzilla.com/news/graphics/41122-nvidia-volta-is-16nm-finfet

[Ailuros]

Die waren noch lang nicht final. ;) Aber es ist schon wirklich so, dass man da ein Projekt aus dem Boden stampfte und dies doch recht schnell ohne große Komplikationen durchführte. Daher frage ich mich immer wieder was AMD so lang an Polaris herumgedoktort hat. :confused:

@N0Thing: Das werden eher so etwas wie Tegra 6 / 7 sein.

Der Text im link ist verdammt deutlich:

Engineers begin the painstaking process of “bringing up” the first samples of Pascal from the chip fab, or factory.

Fuer diejenigen die nicht wissen was mit "bring up" gemeint ist:

https://en.wikipedia.org/wiki/Integrated_circuit_development

After a design is created, taped-out and manufactured, actual hardware, 'first silicon', is received which is taken into the lab where it goes through bringup. Bringup is the process of powering, testing and characterizing the design in the lab. Numerous tests are performed starting from very simple tests such as ensuring that the device will power on to much more complicated tests which try to stress the part in various ways. The result of the bringup phase is documentation of characterization data (how well the part performs to spec) and errata (unexpected behavior).

haben wir eigentlich schon nen Volta Thread?


Volta steigt auch mit TSMCs 16nm FinFET in den Ring mit ''dramatischer'' Effizienzverbesserung

http://www.fudzilla.com/news/graphics/41122-nvidia-volta-is-16nm-finfet


Ich hab's heute gelesen aber es sitzt irgendwie nicht. Wenn man sich die versprochene Leistungssteigerung fuer Volta in NV's roadmap ansieht, kann ich mir momentan einfach nicht vorstellen wie all das in 16FF+ passen soll. GP100 hat schon 15.3Mrd. Transistoren in 610mm2 gequetscht. Um wieviel soll denn die Effizienz pro Transistor genau steigen? :confused:

[scully1234]

, kann ich mir momentan einfach nicht vorstellen wie all das in 16FF+ passen soll. :confused:

vor allem das man in heutiger Zeit ,noch alleine durch die Architektur selber, ''dramatische'' Effizienzgewinne verbuchen kann, ohne einen Shrink...

Das Rad neu erfinden wird man wohl schwer koennen

[Godmode]

vor allem das man in heutiger Zeit ,noch alleine durch die Architektur selber, ''dramatische'' Effizienzgewinne verbuchen kann, ohne einen Shrink...

Das Rad neu erfinden wird man wohl schwer koennen

Man sah ja von Maxi auf Kepler, dass doch noch einiges geht, selbst mit der gleichen Fertigung. Ob man das mit Volta nochmal wiederholen kann, bezweifle ich allerdings auch stark.

[scully1234]

Wo waere denn da noch ein Hebel zum ansetzen?

HPC Ballast raus werfen ist wohl nicht moeglich beim Grossen, und zugeschnittene Chips fuer gewisse Anwendungsszenarien, hat man ja mehr oder weniger mit Pascal nun schon umgesetzt.


Wahrscheinlich geht Fud einfach aufgrund von stacked Ram von nem Sprung aus ,das duerfte aber auch nicht der Rede wert sein, um solche ueberzogenen Begrifflichkeiten zu waehlen

[Ailuros]

Wo waere denn da noch ein Hebel zum ansetzen?

HPC Ballast raus werfen ist wohl nicht moeglich beim Grossen, und zugeschnittene Chips fuer gewisse Anwendungsszenarien, hat man ja mehr oder weniger mit Pascal nun schon umgesetzt

http://images.anandtech.com/doci/7900/OldRoadmap.jpg

Roadmap aus der Vergangenheit als es noch keinen Pascal gab. Es geht hier um DP GFLOPs/W und Pascal hat die Stelle vom vorigen Maxwell eingenommen mit einer leichten Steigerung fuer Pascal (anstatt 12 wohl eher >16). Wenn Volta jetzt keine besonders grosse Steigerung im Bereich DP GFLOPs/W sehen wird koennte es vielleicht hinhauen, aber wohl eher mit einer ziemlich radikal neuen Architektur.

[Dural]

Ende 2017 dürfte 10nm locker bereit sein, zudem NV jetzt schon test chips in 10nm hat. Im moment sieht alles sogar so aus das wir 2018 schon mit 7nm chips rechnen können.

Nein, 16nm werden wir mit den grossen Volta sicherlich nicht sehen. Einzige Ausnahme: 10nm taugt wie schon 20nm für GPUs einfach nicht.

[Ailuros]

Ende 2017 dürfte 10nm locker bereit sein, zudem NV jetzt schon test chips in 10nm hat. Im moment sieht alles sogar so aus das wir 2018 schon mit 7nm chips rechnen können.

Nein, 16nm werden wir mit den grossen Volta sicherlich nicht sehen. Einzige Ausnahme: 10nm taugt wie schon 20nm für GPUs einfach nicht.

20SoCs taugt fuer alles nicht besonders und nicht nur fuer GPUs. Waehrend 20SoC erlaubt dass sie Packdichte gesteigert wird z.B. im Vergleich zu 28HPm TSMC, ist der Stromverbrauch leider immer noch zu laecherlich gross.

http://www.anandtech.com/show/9762/hisilicon-announces-kirin-950-huawei

http://images.anandtech.com/doci/9762/P1030606.jpg?_ga=1.238812544.1879829433.1453271737

Natuerlich kann es durchaus sein dass es bei 10FF wieder der Fall ist, aber es ging sowieso stets nur um GV100 fuer 10FF; alles andere darunter war sowieso anfangs nicht mit mehr als 16FF+ geplant.

[Ailuros]

Fuer technofreaks ist die erste Haelfte definitiv eine gute Lektuere: http://www.anandtech.com/show/10325/the-nvidia-geforce-gtx-1080-and-1070-founders-edition-review

Interessant auch wie sie FP16 in hw zwischen GP100 und allen GP10x cores behandelt haben.

[Sunrise]

Fuer technofreaks ist die erste Haelfte definitiv eine gute Lektuere: http://www.anandtech.com/show/10325/the-nvidia-geforce-gtx-1080-and-1070-founders-edition-review

Interessant auch wie sie FP16 in hw zwischen GP100 und allen GP10x cores behandelt haben.
Eher interessant finde ich die Tatsache, dass dieses Review das erste ist, dass aufzeigt, das der Name Pascal eigentlich Paswell hätte heißen müssen.

Prinzipiell ist das Ding Maxwell, etwas mehr DCC hier, anderer IMC, anderer Speicher, neues Platinendesign, aber statt 28nm TSMC auf 16nm FinFET TSMC und diese Reserven wurden in geringere Die-Fläche und mehr Takt bei relativ weniger Verbrauch pro Takt investiert.

Da wird einem auch sehr schnell klar, wie NV "Paswell" so schnell zwischen Maxwell und Volta einschieben konnte, warum NV so schnell hintereinander alle Chips veröffentlichen kann und warum der Maxwell-LineUp-Aufbau (GP106 +50% = GP104 +50% = GP102) kopiert wurde, der das umso schneller ermöglicht.

Vergleichbar mit Apples Twister (Pascal), der immernoch sehr stark auf dem grandiosen Cyclone (Maxwell) aufbaut.

Umso mehr wird einem auch klar, wie stark der Sprung mit Maxwell tatsächlich ggü. Kepler war. Sicher kein NV40, weil auch viel zu kurzlebig, aber doch ein ordentlicher Sprung nach vorne.

[SentinelBorg]

Gibt es eigentlich schon irgendwelche Hinweise auf einen kleinen Pascal, so Richtung GTX 1030? Ich hätte doch noch gerne in 2016 eine Single-Slot Graka mit HDMI 2.0 fürs Wohnzimmer. Oder hat Nvidia diesen Markt wegen den Fortschritten bei den Intel GPUs nun aufgegeben?

[iuno]

Gibt es eigentlich schon irgendwelche Hinweise auf einen kleinen Pascal
Sogar zwei ;p GP107 und 108, dafuer gibt es einen extra Thread: https://www.forum-3dcenter.org/vbulletin/showthread.php?t=574726

[SentinelBorg]

Sogar zwei ;p GP107 und 108, dafuer gibt es einen extra Thread: https://www.forum-3dcenter.org/vbulletin/showthread.php?t=574726
Ja, habe den Thread auch gerade entdeckt. Sorry 4 Spam :tongue:

[deekey777]

http://www.heise.de/newsticker/meldung/Nvidia-Quadro-P5000-und-P6000-Volle-Pascal-Power-fuer-Profis-3277110.html

[Ailuros]

http://www.heise.de/newsticker/meldung/Nvidia-Quadro-P5000-und-P6000-Volle-Pascal-Power-fuer-Profis-3277110.html

Wieso soll es ein GP100 mit GDDR5X sein und nicht einfach ein GP102?

[Sunrise]

http://www.heise.de/newsticker/meldung/Nvidia-Quadro-P5000-und-P6000-Volle-Pascal-Power-fuer-Profis-3277110.html
So langsam wird es echt wirr mit den Medien.

Die schreiben das alle so, als hätte GP100 mal eben noch ein GDDR5X-IMC on Board. Wofür soll sonst bitte GP102 gut sein?

[y33H@]

Falscher Thread, denn es ist ein GP102 und das NDA fällt zudem erst um 22:45 :usad:

[deekey777]

Wieso soll es ein GP100 mit GDDR5X sein und nicht einfach ein GP102?
Ich wahr mir unsicher, welcher GP es wirklich ist, aber heise verlinkt eben auf die Präsentation des GP100, daher habe ich hier gepostet.

GP100 für Quadro wäre wirklich unnötig. Oder braucht man auch dort die doppelte Genauigkeit?

[Ailuros]

GP100 für Quadro wäre wirklich unnötig. Oder braucht man auch dort die doppelte Genauigkeit?

Bis jetzt hatten high end Quadros durchaus volle DP Werte bis zu Kepler. Da die Dinger sogar teurer sind als Teslas kein Problem fuer ihre Margen. Diesmal eben nicht. Vielleicht veroeffentlichen sie naechstes Jahr eine high end Quadro die auf GP100 basiert, aber wenn dann auch nur um einen Wucherpreis dafuer zu verlangen mit irgendeiner ueberverrueckten Speichermenge.

[Skysnake]

https://www.hpcwire.com/2016/08/04/cray-forecast-chip-delays-market-slowdown-smoke/
The change in outlook was also driven by delays of three key third-party components — Broadwell, Knights Landing and Pascal — and the related impact of those delays both on getting systems built and deployed and on customer decision-making.

Es gibt also wirklich Lieferschwierigkeiten mit Pascal. Ich vermute wohl sogar mit der PCI-E Version. Mir wäre zumindest nicht bekannt, das CRAY die NVLink Version verbauen will.

Das KNL sich verzögert hat ist ja mehr als hinlänglich bekannt. Broadwell überrascht jetzt allerdings etwas.

[Hübie]

Habs mir zwar nicht durchgelesen, aber Lieferengpässe würden mich jedenfalls aus diversen Gründen nicht wundern. Die Hürden die man mit Fiji nehmen musste, muss auch ein GP100 in mindestens der selben Größenordnung nehmen.

[BlacKi]

ob pascal davon profitieren wird? http://www.pcgameshardware.de/Nvidia-Pascal-Hardware-261713/News/Samsung-schrumpft-GPU-auf-14-nm-1204498/

[iuno]

Was soll der Unsinn hier?
Es ist bekannt, dass Samsung GP107/8 fertigen soll. In der verlinkten Quelle steht auch nichts anderes als "Samsung would start making the next-generation GPUs using its 14-nanometre production technology before year-end".

Die News suggeriert stattdessen, dass bisherige Pascal Chips von 16FF+ auf 14 LPP "geschrumpft" werden sollen, das ist doch peinlicher Unfug. Weg damit

[uweskw]

PCGH Clickbait eben :rolleyes:

greetz
US

[y33H@]

Oha, das ist echt geil ... nicht :usad:

[nismod]

Selbst wenn Samsung die aktuellen Pascal Chips fertigen sollte und das ohne irgendwelche Ersparnisse oder Gewinne (Strom oder Größe), würden zumindest mal mehr Chips den Markt erreichen. Das sollte dann die Lieferbarkeit von 1060 und 1080 verbessern.

[Unicous]

Es wird gemunkelt, dass Samsungs Prozess etwas günstiger ist als TSMC. Die ohnehin schon "kleinen" Chips könnten dann im Vergleich noch geringfügig wenig schlanker sein als bei TSMC und das würde weiteres Einsparpotential bringen und die Marge erhöhen. Und das freut Nvidia sicherlich.:wink:

[Ailuros]

Es wird gemunkelt, dass Samsungs Prozess etwas günstiger ist als TSMC. Die ohnehin schon "kleinen" Chips könnten dann im Vergleich noch geringfügig wenig schlanker sein als bei TSMC und das würde weiteres Einsparpotential bringen und die Marge erhöhen. Und das freut Nvidia sicherlich.:wink:

Als Prozess beschreibt NV wie auch andere als faster but leakier; nach den gleichen gruenen Herren sollen keine Unterschiede zwischen 16FF+ und 14LPP bemerkbar sein.

NV hat ueber die vergangengen Jahre mehr als einen Seitensprung gehabt gegenueber TSMC, jedesmal um noch guenstigere Klausen in ihren Vertraegen zu erreichen.

[Unicous]

Und Apple hat auch schon öfter "gedroht" und ist dann doch zu Samsung (und zurück) gegangen. Ich sehe jetzt nicht, warum das lediglich eine in die Öffentlichkeit durchgestochene Drohung sein soll und Nvidia nur pokert. (natürlich unter der Voraussetzung, dass die Meldung aus Südkorea nicht erfunden ist)

Für mich macht das durchaus Sinn. Zumal "faster but leakier" kein Problem darstellen sollte, wenn man gar nicht nach hohen Takten schielt.:wink:

[Ailuros]

Es donnert schon seit einiger Zeit zwischen NV und TSMC wegen den zu kargen Kapazitaeten fuer 16FF+. Der Wechsel fuer 107/108 auf 14LPP (den wir im relevanten thread schon vor einiger Zeit meldeten) war eine relativ fruehe Entscheidung bei NV so dass es sie nur wenige Wochen mehr kostete fuer den Wechsel um selber genug resources dafuer zu finden da sie ein kleines aber zusaetzliches team dafuer brauchten.

Es gibt doch einen relevanten thread fuer 107/8 hier oder irre ich mich? Auf jeden Fall haben wir es schon seit einiger Zeit besprochen. Ich hatte schon damals das muerbe Gefuehl dass sie vielleicht auf 107/8 weniger extravagante Frequenzen haben werden im Vergleich zu den grossen 16FF+ Bruedern, aber die letzte Meldung deutet wohl aufs Gegenteil hin. Anders wenn die Dinger einen boost von 1600 haben als Beispiel dann hatten sie diesen auch so von Anfang an geplant.

[horn 12]

@
Warum war dann NV so viel zeitlicher unterwegs mit ihrer GTX 1080 / 1070
und schlussendlich mit der GTX 1060 6GB obwohl AMD sich einen monatelangen Vorsprung prognosizierte?
Wurde da seitens NV so extrem hoher Druck auf TSMC ausgeübt?

[reaperrr]

@
Warum war dann NV so viel zeitlicher unterwegs mit ihrer GTX 1080 / 1070
und schlussendlich mit der GTX 1060 6GB obwohl AMD sich einen monatelangen Vorsprung prognosizierte?
Wurde da seitens NV so extrem hoher Druck auf TSMC ausgeübt?
Würde sagen:
- bessere Geheimhaltung bei NV (Stichwort Zauba-Einträge).
- Polaris10 kam in Revision C7, üblich ist A1 oder A2. Hat also offenbar so viele Respins gebraucht wie schon lange kein Grafik-Chip mehr (von beiden Herstellern).

[Complicated]

Die News suggeriert stattdessen, dass bisherige Pascal Chips von 16FF+ auf 14 LPP "geschrumpft" werden sollen, das ist doch peinlicher Unfug. Weg damit
Ja sehr peinlich...

[Triskaine]

Würde sagen:
- bessere Geheimhaltung bei NV (Stichwort Zauba-Einträge).
- Polaris10 kam in Revision C7, üblich ist A1 oder A2. Hat also offenbar so viele Respins gebraucht wie schon lange kein Grafik-Chip mehr (von beiden Herstellern).

Das was GPU-Z als "Revision" ausgibt ist Unfug. C7 ist eine Hardware ID, keine Revisionsnummer. Die echte Chip Revision ist bei AMD seit Jahren im VBIOS kodiert. Hawaii z.B. ist Revision A0, Polaris 10 A1. Also gab es einen Metallspin. Wenn AMD mehr Respins gemacht hätte, wäre ein Launch Mitte 2016 unmöglich gewesen.

[Unicous]

Das wollte ich auch gerade schreiben, GPU-Z liest das einfach falsch aus, bei Polaris 11 steht da CF. ;)

Zumal das 3 baselayer respins und 7 metal layer revisions wären... das wären einfach mal zig Monate.:freak::freak::freak:

Edit

Bei einem Respin sind es 3-6 Monate... also 9-18 Monate.:freak: Revisions dauern ein paar Wochen bis zu einem Monat, iirc.

[Mancko]

Würde sagen:
- bessere Geheimhaltung bei NV (Stichwort Zauba-Einträge).
- Polaris10 kam in Revision C7, üblich ist A1 oder A2. Hat also offenbar so viele Respins gebraucht wie schon lange kein Grafik-Chip mehr (von beiden Herstellern).

Würde auch sagen bessere Geheimhaltung und vor allem Klappe gehalten und nicht wie AMD's Roy Taylor frühzeitig herumposaunt, zumal AMD hier Nvidia komplett unterschätzt hat. Wer zuletzte lacht, der lacht eben meißtens am Besten. Zudem glaube ich wirkt sich das deutlich größere R&D bei Nvidia aus. Prozesswechsel und auch neue Produkte gehen mittlerweile ganz gut vom Start weg. Huang hat im Call zu den Quartalszahlen dazu gesagt, dass sie hier Maßnahmen ergriffen haben um das zu verbessern seit dem Fermi launch m.E..

[Hübie]

Alles was vom Band läuft ist direkt verkauft. Man hat offenbar das supplychain management gestrafft und konnte dadurch einige Wochen sparen. Es sah eine ganze Zeit lang so aus als wäre AMD fast ein halbes Jahr voraus, aber das war ne Finte. Irgendwie sogar schade, muss ich sagen.

[Mancko]

Alles was vom Band läuft ist direkt verkauft. Man hat offenbar das supplychain management gestrafft und konnte dadurch einige Wochen sparen. Es sah eine ganze Zeit lang so aus als wäre AMD fast ein halbes Jahr voraus, aber das war ne Finte. Irgendwie sogar schade, muss ich sagen.

Jetzt werden sie halt daran gemessen. Selbst Schuld.

[Ailuros]

Alles was vom Band läuft ist direkt verkauft. Man hat offenbar das supplychain management gestrafft und konnte dadurch einige Wochen sparen. Es sah eine ganze Zeit lang so aus als wäre AMD fast ein halbes Jahr voraus, aber das war ne Finte. Irgendwie sogar schade, muss ich sagen.

Das originale Gefluester betraf etwas mehr als ein Quartal von dem was ich gehoert hatte. Zu dem Zeitpunkt bestanden vielleicht die Chancen fuer solch einen Unterschied, es hat sich eben NIE NV selbst off the record dagegen geaeussert. Warum auch?

[deekey777]

PCGH Clickbait eben :rolleyes:

greetz
US
Ist dir eine Paywall lieber?

Etwas Clickbait sollte schon sein.

[Hübie]

Das originale Gefluester betraf etwas mehr als ein Quartal von dem was ich gehoert hatte. Zu dem Zeitpunkt bestanden vielleicht die Chancen fuer solch einen Unterschied, es hat sich eben NIE NV selbst off the record dagegen geaeussert. Warum auch?

Deshalb sollte man auch immer die prise Salz dabei haben. Ich steigere mich da aber auch nicht mehr rein, muss ich zugeben. Klang aber sehr realistisch, was so kolportiert wurde. :D

[Troyan]

Nur weil AMD 6 Monate vorher (eigentlich sind wir ja fast schon bei 9 Monate für Notebooks) über ihre neuen Produkte redet und gleichzeitig Lügen über die Konkurrenz verbreitet, hat das nichts mit der Realität zu tun.

Sie waren nie "realistisch" bis zu ein halbes Jahr voraus.

[Ailuros]

Deshalb sollte man auch immer die prise Salz dabei haben. Ich steigere mich da aber auch nicht mehr rein, muss ich zugeben. Klang aber sehr realistisch, was so kolportiert wurde. :D

Teilweise weil auch keinem damals bewusst war dass AMD's Produkte spaeter als erwartet ankommen werden. Am Ende ist es auch so dass NV's "Meckerei" bei TSMC womoeglich auch um einiges geholfen hat. Denn ich kann mir fuer TSMC durchaus vorstellen dass sie so manches Risiko eingehen und sobald es von den alten Kunden endlich mal gerechtfertigt Stunk giebt, sie dann doch darauf eingehen.

Egal wie man es dreht, es ist durchaus KEIN Zufall dass NV ihre kleinen chips bei Samsung herstellt.

Der eigentliche schwarze Peter an der ganzen daemlichen Geschichte ist eher TSMC selber als AMD oder sonst wer. Und um ehrlich zu sein als NV wuerde ich TSMC auch einen Tritt in die Hoden verpassen wenn man versucht mich so zu verarschen. Ein Vertrag ist ein Vertrag und dieser muss eingehalten werden, wobei es mich als Kunden einen feuchten Dreck interessiert ob sie mit Apple oder Gott selber weitere Verpflichtungen haben....

[Hübie]

Na ja es dringt ja recht wenig über offizielle Kanäle nach außen. Das NV aber einen besseren Stand hat als viele andere Kunden sollte kein Geheimnis sein. Man beschäftige sich einfach mal mit Jensen als Person. ;)

[Ailuros]

Na ja es dringt ja recht wenig über offizielle Kanäle nach außen. Das NV aber einen besseren Stand hat als viele andere Kunden sollte kein Geheimnis sein. Man beschäftige sich einfach mal mit Jensen als Person. ;)

Als Person ist Jensen ein ziemlich cooler und grosszuegiger Typ und ja es ist ernst gemeint. Das macht ihn aber nicht immun (wie jeden anderen in so verantwortungsvoller Position) zu jeglicher Kritik wenn es mal falsche Entscheidungen geben sollte.

Wehe wenn ein CEO in solch einem Fall nicht den haertesten Druck ausueben wuerde, um dass zu bekommen was er durch einen Vertrag gesichert hat.

[HOT]

NV hat doch beim NV40 schonmal einen Ausflug unternommen.
Und es war folgerichtig, nicht nur mit TSMC zu rechnen, wenn Apple komplett dahin wechselt.
Bin mir aber sicher, dass bei Volta der Spuk dann wieder vorbei ist und alles business as usual abläuft.

[Sunrise]

TSMC wird schlicht zu teuer sein und diese Volumen nicht stemmen können, schon zwei gute Gründe Samsung zu wählen. Ob der Prozess jetzt hinsichtlich der Perf/W bzgl. Effizienz und maximalem Clock-Scaling etwas schlechter ist (ausgenommen bei der Flächenreduktion) interessiert nicht wirklich bei den ganz kleinen Chips, denn der Takt wird dort sowieso nicht bis ans Äußerste strapaziert werden. Warum also nicht.

Dass High-End GPUs und TSMC nicht wegzudenken sind, hat mit Low-End-GPUs soviel zu tun wie Äpfel mit Birnen.

Wäre TSMC in der schlechten Lage, ihre Anlagen unbedingt auslasten zu müssen (wie Samsung, aufgrund des Apple-Verlustes), dann ist NV auch bei den Low-End-GPUs wieder ganz schnell bei TSMC. Nur wird es dazu nicht kommen. TSMC investierte da viel zuviel in fortschrittliches Packaging, was sich Apple unbedingt sichern will und das für mehrere Jahre.

Volta wird und wurde bei TSMC mit ziemlicher Sicherheit schon längst gestartet und ist auf keiner anderen Fab dieser Welt, außer vielleicht Intel, denkbar. Volta wird für HPC sehr früh kommen und wahrscheinlich auch längere Zeit exklusiv bleiben. Es gibt aktuell absolut keine Gründe für NV, Pascal mit diesen unglaublich guten Margen abzulösen, außer vielleicht bei HPC. Selbst Vega wird daran wahrscheinlich nicht viel ändern können, da AMD da alles an Tricks aus der Kiste ziehen muss, um einem GP104 überhaupt annähernd gefährlich zu werden.

[Hübie]

Als Person ist Jensen ein ziemlich cooler und grosszuegiger Typ und ja es ist ernst gemeint. Das macht ihn aber nicht immun (wie jeden anderen in so verantwortungsvoller Position) zu jeglicher Kritik wenn es mal falsche Entscheidungen geben sollte.

Wehe wenn ein CEO in solch einem Fall nicht den haertesten Druck ausueben wuerde, um dass zu bekommen was er durch einen Vertrag gesichert hat.

Das war auch ohne Wertung gemeint. :smile: Aber er ist halt selbst Taiwanese. Daraus kann man sich ja was ableiten, wenn man nix über ihn weiß. :biggrin:

[iuno]

Im neuen "Parker"-Tegra bietet die auf Pascal basierende GPU HW Virtualisierung, die MD auch seit Tonga in GCN GPUs hat.

https://pics.computerbase.de/7/4/1/5/7/8-1080.39478480.png

Habe ich das nur verpasst oder wurde dazu bzgl. Pascal bisher noch nichts gesagt? Ansonsten sollte fuer die Server-Karten doch auch noch was kommen oder?!

[Triskaine]

GP100 Die Shot, frisch von der Hot Chips Konferenz:

https://pbs.twimg.com/media/CqevXGJXYAAVRw7.jpg

Ein SM braucht ~7,3 mm² (Polaris CU ~3 mm²), ein HBM2 PHY ~4,4 mm² (Fiji PHY ~10 mm²).

[Unicous]

Sieht aus wie ein sowjetischer Militärkomplex.

*SCNR

[iuno]

Ein sm hat ja doppelt so viele SP wie eine cu, kann fp16/32/64 um Verhältnis 4:2:1 und läuft mit deutlich höheren takten. Dafür finde ich es schon recht klein :uponder: wie waren die Größenunterschiede einzelner sm/cu denn in 28nm?

[Nakai]

GP100 Die Shot, frisch von der Hot Chips Konferenz:

https://pbs.twimg.com/media/CqevXGJXYAAVRw7.jpg

Ein SM braucht ~7,3 mm² (Polaris CU ~3 mm²), ein HBM2 PHY ~4,4 mm² (Fiji PHY ~10 mm²).

Du meinst pro 128 SP SM? Ich will nicht nachmessen. 64 SPs wären dann grob 3,65mm². Man ist nah beieinander (NV hat noch DP1:2 und DL-Zeug). NV hat es gut mit dem Takt hingekriegt. Von der Größe liegt man echt nah beieinander.
Es ist brutal wieviel NV für den Offcore und das Frontend aufbringt. Das sollte Vega auch bringen müssen.

[Triskaine]

Ein GP100 SM hat 64 FP16/FP32 ALUs, 32 FP64 ALUs, 256KB Register und belegt ~7,3 mm² in 16FF. Eine Hawaii CU mit 64 FP32/FP64 ALUs und ebenfalls 256KB Registern belegt grob ~7 mm² in 28HP. Wenn man den Unterschied in der Packdichte berücksichtigt ist es schon krass wieviel mehr Logik Nvidia in einem SM verbaut. Da braucht man sich nicht über die Auslastung von GCN im Gegensatz zu Maxwell/Pascal wundern.

EDIT: Wie unten erwähnt kann hier etwas nicht stimmen. Ein logischer 64 SP SM hätte dann ~ 3,65 mm², ganz so extrem ist das Unterschied also nicht.

[iuno]

Was wurde denn jetzt hier vermessen?
Erst hieß es, GP100 habe 60 SMs, dedizierte FP64 Einheiten, dann gab es dort Ungereimtheiten und jetzt steht hier wieder was von 30 SMs. Bin jetzt von 128 SP ausgegangen, ansonsten ist der Größenunterschied natürlich enorm.
Die Gigathread Engine ist auch riesig :eek:

[Triskaine]

Da scheint Nvidia sich selbst nicht so einig zu sein was denn jetzt genau ein SM ist. Wenn ein Layout "SM" Macro zwei logischen SMs entspricht relativiert sich der Unterschied GCN/Pascal natürlich wieder. Wäre nicht das erste mal das die schönen Blockdiagramme nur entfernt mit der Realität zu tun haben.

[Skysnake]

hm... Wenn ich mir den DIE-Shot so ansehe, dann sieht das fast so aus, als ob für jeden SM einzeln das placement and routing drübergelaufen ist. Das wäre schon echt richtig viel Aufwand. Wäre mir völlig Neu, das man so etwas macht.

Oder das Ding ist mal echt schlecht prepariert....

Ich seh nämlich auch nicht wirklich die Caches oder auch nur die PCI-E Treiber usw.

HBM2 sieht man einigermaßen, aber alles sehr schwer abzugrenzen, was was ist. Ist wohl eine relativ tiefe Schicht würde ich mal sagen.

EDIT:
Ich glaub das ist teilweise ein bullshot. Die haben die SM farblich hervorgehoben. Ich würde daher nicht ausschließen, dass das Ding sogar 36/72 SM hat. Btw. habe ich die PCI-E Treiber wohl gefunden, das sind 2x8 und 2x4 oben links. Dann müsste das darunter alles NVLink sein. Überraschend klein btw. Was mich allerdings stutzig macht ist, was das rechts noch an IO sein soll, bzw warum da an sich nicht wirklich viel ist. Bei HBM muss man auch aufpassen. Das man nicht die Crossbars mitzählt. Ich mach vielleicht heute Abend mal eine Einteilung.

[Gipsel]

Wenn hier jemand einen (kaputten) GP100 rumliegen hat, sollte er den vielleicht mal OC_Burner zuschicken. Zumindest sehen seine Bilder normalerweise deutlich besser aus :rolleyes:.

[Hübie]

Ich bemühe mich X-D Was nutzen die eigentlich am Desy?

[OC_Burner]

Gerne aber das trennen von Interposer und GPU könnte sich als schwierig erweisen. Bin mir nicht sicher ob Hitze (>400°C) ausreichen um die GPU sauber abzusprengen. Schleifen mitsamt Interposer dürfte möglich sein, sollte wenn möglich aber vermieden werden.

[Raspo]

Ich bemühe mich X-D Was nutzen die eigentlich am Desy?

Ich glaube mich zu erinnern, dass keine GPUs eingesetzt werden. War 2013 und 2015 zur langen Nacht der Wissenschaft zur Führung im Rechenzentrum.

Die sind aber immer noch nicht ganz fertig mit Umbauen.

P. S. Die Bandroboter in Aktion zu sehen war schon ziemlich geil.

[Skysnake]

Ich hab mich mal am DIE shot versucht, dann aber aufgegeben. Die Qualität ist einfach zu schlecht, bzw man ist zu weit unten.

Beim HBM Interface bin ich mir recht sicher, dass das die Blöcke sind zusammen mit den fetten Datenbussen ist das recht einfach zu sehen. Aber den L2 kann ich schon nicht mehr wirklich zuordnen. Ich denke das wird in der Bitte hocken, aber für mich sieht es eher aus, als ob das nicht die unteren Blöcke wären, sondern etwas weiter oben, so das der Commandprozessor dazwischen hockt. Sieht aber irgendwie verdammt groß aus. Ich habe jetzt aber keine Zeit für einen senety check über die Packdichte usw.

Das PCI-E Interface kann ich aber nicht wirklich zuordnen. Ich dachte erst, das wäre das oben Links, aber dann hätte man 24 statt 18 Lanes... Zudem fehlt mir dann eben noch der NVLink....

Das unter dem fettern "PCI-E" oder was das auch immer sein mag, könnten die Displayports usw sein. Dann wäre das ganz rechts eventuell NVLink. Sieht dafür aber wirklich extrem klein aus...

Bin da ehrlich gesagt etwas ratlos.

Könnte das oben links vielleicht NVLink sein? Es sind ja 4 Links. Dann hätte ein NVLink aber 6/12. Ich meine mich aber an 8 Lanes erinnern zu können. Und ich würde auch wieder vergeblich die PCI-E PHYs suchen....

[Hübie]

Mal abgesehen davon, dass man darauf eigentlich bestenfalls etwas erahnen kann mal meine Idee:

https://abload.de/img/dieshot_gp100_ideebouhm.jpg (http://abload.de/image.php?img=dieshot_gp100_ideebouhm.jpg)

Bei einigen Sachen wie ROPs bin ich mir unsicher.

[iuno]

Bei PCGH schreiben sie, dass das treppenfoermige Ding ein NVLink sein soll, was meiner laienhaften Meinung nach aber wenig Sinn ergibt (ausser dass es davon 4 gibt).

http://www.pcgameshardware.de/Nvidia-Pascal-Hardware-261713/News/GP100-Die-Shot-1205532/

Die haben das Bild auch in etwas besserer Quali

Könnte das oben links vielleicht NVLink sein? Es sind ja 4 Links. Dann hätte ein NVLink aber 6/12. Ich meine mich aber an 8 Lanes erinnern zu können. Und ich würde auch wieder vergeblich die PCI-E PHYs suchen....
1 NVLink = 2 sub-links
1 sub-link = 8 pairs
Quelle (https://devblogs.nvidia.com/parallelforall/inside-pascal/)

Koennte es auch sein, dass ein NVLink (16 Paare) fast gleich aussieht wie 8 PCIe Lanes (16 Paare), obwohl die Taktraten deutlich hoeher sind?
Dann koennten oben links die 4 NVLinks sein und darunter 2x8 PCIe Lanes...

Das ist aber komplett geraten, ich habe davon wenig Ahnung ;D

edit: hier nochmal zur Verdeutlichung hervorgehoben, was ich meine:

Links daneben noch einigermassen massstabsgetreu P10 (14 LPP)
http://i.imgur.com/Tv57SUY.jpg

[Hübie]

Hm. Sieht auch sinnvoll aus. Das Ding ist echt ein Rätsel. :|

[iuno]

Bist du sicher, dass so viel Flaeche auf den Cache geht? Ich haette die GTE deutlich grosser erwartet.

Wie schon gesagt habe ich wenig Ahnung. Nebenbei bin ich noch auf GK110 (http://www.3dcenter.org/dateien/abbildungen/nVidia-Kepler-GK110-Die-marked.jpg) und GM204 (https://cdn1.lockerdome.com/uploads/e6742da09a366e3882a9c46c24b5f6df850754e242d73f5d5e09fbe9c9186b92_facebook) (nur synthetisch) gestossen. Mir hat es nicht geholfen (ich blicke nicht mal bei dem GM204 Bild durch), aber vielleicht euch ;)

[Hübie]

Nö. Sicher bin ich nicht. Das sind die slices. Da siehst du so 32 Kästchen insgesamt und das macht 32 * 128 = 4096. So meine Idee.

https://abload.de/thumb/dieshot_gp100_ideecgu51.png (http://abload.de/image.php?img=dieshot_gp100_ideecgu51.png)

Kritzel da drin herum, vielleicht fällt dir was ein. Muss nun ins Bett - 6:45 klingelt der scheiß Wecker :mad:

[Foobar2001]

Das in der Mitte ist ganz bestimmt kein L2$. Der ist bei GPUs immer ziemlich versteckt weil ziemlich verteilt.

[Skysnake]

Hübie, also die Dreiecksstrucktur die du als ROBs bezeichnest sind Datenbusse.

Das ist eine ganz typische Struckture die sich dadurch regibt, das man auf jeder Lage nur horizontal ODER! vertikal routet, da man sich sonst immer wieder selbst blockiert. Wenn routet man nur auf den Poly und M1 in beide Richtungen, aber auch das versucht man wenn möglich zu vermeiden.

Der L2 ist normal verteilt, weil auch das Interface über den gesamten Rand fast verteilt ist. Hier würde das in der Mitte konzentriert aber durchaus Sinn machen. Einfach weil da nicht wirklich Platz ist für den L2.

Es könnte aber natürlich auch sein, dass der L2 unterhalb der Datenbusse liegt. Dafür bruchte man halt Ansichten aus mehreren Schichten...

[Hübie]

Die Fragezeichen hast du aber gesehen, ja? ;) Ich habe lediglich überlegt wo was sein könnte und es mal so markiert. Dass es so ist sagt keiner. Könnt euch ja mal dran beteiligen :P
Würde mich auch wundern wenn ROPs so aussehen würden und dazu ungleich groß.
@foobar2001: Beim GK110 sind die slices auch ziemlich zentral... Ist der L1$ nicht eher der versteckte und fragmentierte Kandidat, weil dieser viel näher an ALU/Scheduler sitzen muss?
Der L2 könnte auch zwischen den GPCs sitzen, aber im unteren Bereich haben wir keine Lücke. :|

[iuno]

Kritzel da drin herum, vielleicht fällt dir was ein. Muss nun ins Bett - 6:45 klingelt der scheiß Wecker :mad:
Könnt euch ja mal dran beteiligen :P
War dann auch schon weg.
Kann leider auch nicht mehr dazu beitragen ;p

[Hübie]

Also wer von draußen hier mitliest denkt auch nur: :facepalm:

Da werden ROBs eingebaut und die Hälfte wohl falsch markiert :biggrin:

[iuno]

;D
Naja die Haelfte kommt wohl hin ;p GPCs, TPC/SMs und HBM PHYs sind ja relativ klar. Hoffe dass fuer den Rest bald jemand mit Ahnung oder zumindest ein besseres Bild kommt ^^

[Skysnake]

Die Fragezeichen hast du aber gesehen, ja? ;) Ich habe lediglich überlegt wo was sein könnte und es mal so markiert. Dass es so ist sagt keiner. Könnt euch ja mal dran beteiligen :P
|
Kein Grund jetzt zickig zu reagieren. Es war einfach nur ein Hinweis ohne jedwede Wertung... :P

@Topic:
Wenn ich mir so die Folien bezüglich Power9 so anschaue, dann könnte man auf die Idee kommen, das P100 über gar keine dedizierten PCI-E PHYs verfügt, sondern das man Kombi-PHYs hat, die PCI-E 4.0 theoretisch können.

Nur mal so meine Vermutung.

[iuno]

Dasselbe hatte ich mir auch gedacht, als ich das gesehen habe (Slides z.B. bei CB (https://www.computerbase.de/2016-08/ibm-power9-prozessor/)), das haette auch zu meiner Raterei oben gepasst. Allerdings hat IBM beim P9 NVLink 2.0 ueber BlueLink und PCIe 4 doch weiterhin extra (s.S. 14). Auf dem die shot (s.4) ist PCIe und "Accelerator signaling" auch getrennt und sieht anders aus, soweit ich das feststellen kann..

[AffenJack]

@Topic:
Wenn ich mir so die Folien bezüglich Power9 so anschaue, dann könnte man auf die Idee kommen, das P100 über gar keine dedizierten PCI-E PHYs verfügt, sondern das man Kombi-PHYs hat, die PCI-E 4.0 theoretisch können.

Nur mal so meine Vermutung.

Da P100 PCI-E und 4xNvlinks gleichzeitig benutzt versteh ich nicht so ganz wie du darauf kommst. Nach deinem Gedankengang könnte man ja nur eins von beidem nutzen oder verstehe ich dich falsch?

[iuno]

Nein, er meint wohl, dass die PHYs so entwickelt wurden, dass sie beides koennen. Auf dem fertigen Chip ist ein PHY natuerlich trotzdem nur fuer eine Schnittstelle vorgesehen.

[Skysnake]

So nach der HOT-Chips wissen wir ja jetzt das Power9 nächstes Jahr kommen wird. Power8+ mit NVLink1 wird also nicht lange am Markt sein, bzw nicht über das Stadium von ein paar Developmentkisten hinaus kommen.

Das "lustige" ist ja, das in Power9 aber auch PCI-4 4.0 dabei ist, und das mit der gleichen! Anzahl an Links. Der Vorteil von NVLink rein bezüglich der Bandbreite liegt also bei 56% im Vergleich zu NVLink 2(!). Dafür handelt man sich aber eine propritäre Schnittstelle ein.

Wobei die ja an sich gar nicht so propritär ist CAPI next läuft ja über die gleichen PHYs. Wer hätte das nur gedacht?..... :rolleyes:

Ansonsten ist NVLink wohl relativ überhypt meiner Meinung nach, wenn ich mir anschaue, was wohl dabei rumkommt und welchen Aufwand man betreibt. Also rein auf die Bandbreite bezogen. Was die Latenzen anbelangt muss sich das noch zeigen, aber ich würde da keine! Wunder erwarten.

Was man anschauen muss ist, wie sich die Cohärenz über NVLink auswirken wird, und das man eben den Speicher direkt adressieren kann, wobei das mit PCI-E ja an sich auch geht, nur halt nicht cohärent. Aber auch da würde ich mir nicht zu viel versprechen, denn wenn man das wirklich nutzen will, wird die Performance wohl nicht so berauschend sein, wenn man es damit Vergleich expliziet schon vorher alle Daten asynchron zu kopieren, die man braucht. Aber ich lasse mich da gern positiv noch überraschen, aber wie gesagt, ich würde keine all zu großen Erwarten auflegen im Vergleich zu PCI-E 4.0 ansonsten wird man enttäuscht sein.

Denn ich gehe nicht davon aus, das es wesentliche Anzahl an Problemen gibt, bei denen PCI-e 4.0 ein richtiger bottleneck ist, NVLink dann aber nicht.

[Godmode]

In den aktuellen Treiberreleasenotes (http://us.download.nvidia.com/Windows/373.06/373.06-win10-win8-win7-desktop-release-notes.pdf) des 373.06er steht folgendes:

[372.70, GP100] FPS limiter broken in R370 drivers in windowed mode with high FPS.[1814275]

Kommt GP100 also doch noch als Geforce? Mit vollem Chip und 16 GB HBM2 wäre das doch eine würdige Titan X Black?

[Sunrise]

In den aktuellen Treiberreleasenotes (http://us.download.nvidia.com/Windows/373.06/373.06-win10-win8-win7-desktop-release-notes.pdf) des 373.06er steht folgendes:

[372.70, GP100] FPS limiter broken in R370 drivers in windowed mode with high FPS.[1814275]

Kommt GP100 also doch noch als Geforce? Mit vollem Chip und 16 GB HBM2 wäre das doch eine würdige Titan X Black?
Sieht für mich eher wie ein Schreibfehler aus, das sollte wohl GP102 heißen. Der Preis für so ein Ding ist nach wie vor zu hoch und NV wird die eher im Pro-Segment verkaufen, da hat sich rein garnicht geändert.

Zudem gibt es bereits die Quadro P6000 mit 24GB GDDR5X und GP102 im Vollausbau. Da ergibt GP100 im Desktop einfach garkeinen Sinn.

[Godmode]

Sieht für mich eher wie ein Schreibfehler aus, das sollte wohl GP102 heißen. Der Preis für so ein Ding ist nach wie vor zu hoch und NV wird die eher im Pro-Segment verkaufen, da hat sich rein garnicht geändert.

Zudem gibt es bereits die Quadro P6000 mit 24GB GDDR5X und GP102 im Vollausbau. Da ergibt GP100 im Desktop einfach garkeinen Sinn.

Die Zahl 0 ist aber weit von der Zahl 2 weg, also eher kein Typo

[Sunrise]

Die Zahl 0 ist aber weit von der Zahl 2 weg, also eher kein Typo
Es wäre ungewöhnlich, ja. Du kannst ja mal bei Blaire nachfragen, denn natürlich kann man wohl auch mit GP100 Spiele spielen, nur ist das für mich kein Zeichen, dass Desktop-GP100 kommt, aus den genannten Gründen.

[Tru]

Die Zahl 0 ist aber weit von der Zahl 2 weg, also eher kein Typo
Beim Nummernblock direkt übereinander :P

[Godmode]

Beim Nummernblock direkt übereinander :P

Und wer schreibt Zahlen im Fließtest mit dem Nummernblock? Nur jemand der kein 10-Finger-System beherrscht. Aber ja, theoretisch möglich.

[Hübie]

Geh mal von Typo aus ;);)

[Complicated]

Mich beschleicht langsam das Gefühl, dass NVLink bei IBM nicht weiter verfolgt werden wird.

Könnte durchaus sein, dass Nvidia mit seinem proprietären Standard hier den Anschluß verpasst hat wenn man sich die Mitgliederliste der beiden Konsortien anschaut, welche den offenen CCIX und GenZ Standard unterstützen.

http://www.golem.de/news/offener-interconnect-standard-gen-z-konsortium-will-mit-intel-konkurrieren-1610-123764.html
http://www.prnewswire.com/news-releases/ccix-consortium-triples-number-of-member-companies-and-announces-availability-of-specification-300342252.html

Zu IBMs eigenen CAPI 2.0 Interconnect, die offenen Standards und zusätzlich Nvidias Nvlink in den Power CPUs zu unterstützen erscheint mir nicht sinnvoll.

[Skysnake]

Naja, du hast schon mitbekommen, das NewCapi über die gleichen PHYs wie NVLink2 läuft?

Mir kommt das immer noch so vor, als ob nVidia Geld auf den Tisch gelegt hat, um ihren NAmen auf das Ding drauf pappen zu können...

[Foobar2001]

Oder sie nur kleinere Anpassungen fuer ihre eigenen Zwecke eingebaut haben aber kompatibel dazu bleiben.

[Skysnake]

Mag sein, aber das wird man nie herausfinden.

NVLink ist auf jeden Fall eine extreme Sau die durchs Dorf getrieben wird/wurde. Gerade der Vergleich zwischen NVLink und PCI-E 3.0 ist ziemlich beschönigend. Sobald NVLink am Markt verfügbar ist, wird es auch Power mit PCI-E 4.0 geben. Aber dann würden die Zahlen ja gar nicht mehr beeindruckend sein.....

NVLink löst meiner Meinung nach kein Problem wirklich. Weder Bandbreiten und vor allem nicht Latenzen... Was es einfacher macht ist halt die Softwareentwicklung, aber was bringts einem wenn nicht die nötige Performance rüber kommt... Naja, mal schauen wann jemand mit Zahlen aufschlägt.

[Hübie]

Keine Ahnung warum du seit Jahren versuchst alles schlecht zu reden was NV da macht. Persönliche Fede mit Jensen? :|

[Screemer]

Sind doch valide argumente. Der heilige gral als der nvlink von nv dargestellt wird ist er im vgl. zu pcie4 eben nicht zu sehen.

[Hübie]

Ja bei all den Meldungen kann man das objektiv sicher schon jetzt sehr gut beurteilen... NOT! :rolleyes:
PCIE 4.0 skaliert ebenfalls mit der Anzahl der PHYs. Wieviel Platz das nun mehr oder weniger im Vergleich zu NVLINK braucht vermag ich nicht zu urteilen, aber es wird mit Sicherheit einen Grund geben warum NV einfach mal so ein paar Millionen in eine properitäre Schnittstelle investiert. Kannst dir ja überlegen wie groß PCIE x64 wäre um vier Grakas mit hoher Bandbreite zu verbinden. An dem Argument ist erst Mal also gar nix valide, bis es belegt ist.

[Troyan]

PCIe 4.0 existiert nicht. NVLInk und Power 8 dagegen schon.

Eine selten dämliche Argumentation. Davon abgesehen haben nVidia und IBM schon NVLink 2.0 angekündigt.

Vielleicht sollte man als minderwissender Mensch nicht über Firmen urteilen, die mehr Erfahrung und Wissen in den Bereichen haben.

[Complicated]

Keine Ahnung warum du seit Jahren versuchst alles schlecht zu reden was NV da macht. Persönliche Fede mit Jensen? :|
Wieso? Wo rede ich etwas schlecht? Zumal ich mich immer freue wenn proprietäre Standards scheitern und Unternehmen die darauf setzen durch offene Konsortien ausgebremst werden. Ich bin eben an meinem Geldbeutel interessiert und nicht an dem der Aktionäre irgendwelcher IT-Unternehmen.
, aber es wird mit Sicherheit einen Grund geben warum NV einfach mal so ein paar Millionen in eine properitäre Schnittstelle investiert. Ja sie haben halt keine gehabt als einziger Player im HPC-Segment. Und offene Schnittstellen will Nvidia nicht nutzen. Also setzt man eben ein paar Millionen in den Sand regelmäßig - ist ja jetzt nicht neu für das Geschäftsmodell von Unternehmen die versuchen durch proprietäre Technik Quasi-Monopolist zu werden. Siehe Intel, Apple oder eben auch Nvidia. Irgendwo muss das ganze R&D Budget ja versenkt werden.
Eine selten dämliche Argumentation. Davon abgesehen haben nVidia und IBM schon NVLink 2.0 angekündigt.
Und wird in Volta GPUs verbaut sowie den Power 9 CPUs. Was darüber hinaus passiert ist wovon ich schrieb. GenZ und CCIX werden in 3-4 Jahren relevant. Ich bezweifle, dass NVLink das nach 2020 noch sein wird bei den Bewegungen in der Branche. Für diese Spekuklation habe ich eine valide Basis erbracht. Muss man ja nicht übereinstimmen.

[Troyan]

Du schreibst nur viele Buchstaben aneinander. Erstens unterstützt nVidia offene Standards wie PCIe 3.0 mit P100. Zweitens weiß niemand, wie sich der Markt nach 2018 entwickeln wird.

Fakt ist: NVLink 1.0 ist real. PCIe 4.0 dagegen nicht. Also komm einfach 2020 wieder.

[Skysnake]

PCI-E 4.0 ist realer als NVLink.

Du kannst ohne Probleme eine Mellanox Karte mit PCI-E 4.0 kaufen. Genau wie IP zur Implementierung in eigenen Chips. Bei NVLink musst du auf ein Power 8+ System + P100 von IBM+nVidia hoffen. Aber das kannste nicht wirklich kaufen, sondern die werden zugeteilt....

Und sobald man NVLink wirklich kaufen kann und nicht damit beglückt wird, bekommst du zwangsläufig PCI-E 4.0 dazu. Power9 bringt nämlich zwingend PCI-E 4.0 mit und zwar in einer ähnlichen Lane anzahl wie NVLink.

Wobei NVLink sich die PHYs mit CAPI Next teilt während CAPI2 sich die PHYs mit PCI-E 4.0 teil....

Und wenn man sich ein bischen ümhört, dann bekommt man auch durchaus mit, das zumindest die ersten Power8 + nVidia nicht der Brüller waren...

Bei Power8+ & NVLink muss man noch schauen, wie das läuft. Hier sollte man nämlich durchaus mal einen Blick auf die Ankündigung von nVidia werfen, dass sie mit GPUDirect Async jetzt sowohl Daten ALS AUCH! Controlcommandos direkt über die Mellanox Karte schicken ohne die CPU zu involvieren...

Es ist nämlich apriori gar nicht klar, das wenn man NVLink nutzt man nicht am Ende doch auch noch PCI-E benötigt. Da gab es vor einiger Zeit mal Folien, bei denen auch bei Power 8+ noch eine PCI-E Verbindung neben NVLink zur CPU gezeigt wurde.... Da ist also noch rein gar nichts klar, wie da wo was passiert und wie weit die an sich eigentlich mit der Entwicklung sind.

Fakt ist, sobald NVLink relevant wird (mit Power9 zusammen) gibt es eben zwangsläufig auch PCI-E 4 (eben durch den Power9). Man muss also immer die NVLink Lösung mit einer Potenziellen PCI-E 4.0 Lösung vergleichen, und da ist jetzt zumindest was die Bandbreiten anbelangt eben ein weitaus kleinerer Unterschied da, als suggeriert wird.

Was sicherlich deutlich besser gehen wird, wird die virtual SharedMemory Implementierung sein, allerdings habe ich da so meine Zweifel, dass das wirklich performant ist, wenn man das ernsthaft nutzt. An den Bandbreitenverläufen ändert sich daran ja nichts...

[StefanV]

Keine Ahnung warum du seit Jahren versuchst alles schlecht zu reden was NV da macht. Persönliche Fede mit Jensen? :|
Keine Ahnung, warum du seit Jahren versuchst alles schön zu reden, was nV da macht...

Skysnake ist nur sehr skeptisch, nicht par se nVidia feindlich, wie von dir angedichtet wurde, ganz im Gegenteil.

Nur sollte man inzwischen auch gemerkt haben, dass man nVidia niemals blind vertrauen darf und immer skeptisch denen gegenüber sein sollte...
Denn das, was Skysnake dort geschrieben hat, klingt durchaus sinnvoll und ist nachvollziehbar.

Darf man jetzt also nicht mal mehr nachvollziehbare Dinge erwähnen, wenn sie gegen nVidia sprechen??

Denn dass Werte, die das Marketing verwendet, sehr stark zu eigenen Gunsten geschönt sind (bei _ALLEN_ Unternehmungen) sollte eigentlich auch klar sein. Und entsprechend bewertet werden.
Warum macht man das bei nVidia, die sehr viel im Marketing Bereich unternehmen, denn nicht und glaubt denen einfach so? Ohne Priese Salz natürlich...
Insbesondere wo sie doch in der Vergangenheit gezeigt haben, dass man ihnen nicht allzu sehr trauen solte/darf...

[Screemer]

@hübie: ist dir der letzte beitrag von skysnake jetzt mit genügend vakiden argumenten gespickt? Ich hab das vorher schon genau so vrrstanden, denn das sind die bedenken die überall bzgl. Nvlink geäußert werden.

[Hübie]

@Complicated: Ich sag dir mal wie das läuft: Wenn ein Beitrag unter einem anderen ist bezieht dieser sich auf den vorangegangen. Wenn ich jemanden zitiere gilt mein Beitrag so lange dieser Person bis ein Absatz kommt oder ein anderes deutliches Zeichen. Wieso DU dich angesproch fühlst ist mir rätselhaft. Vielleicht sollte hier mal so eine Bot-Abfrage eingebaut werden. :rolleyes:

@StefanV: Weil es eben nicht immer so schlecht ist. Du bist in solche Dinge wenig bis gar nicht involviert wie man immer wieder feststellt. Kommst in einen Thread rein, verfasst negative Postings, gehst wieder. Fertig. Kannst du auch gerne machen, aber diskutieren geht anders.

@Skysnake: Sorry aber so eine Netzwerkkarte ist schon etwas gaaaanz anderes als vier GPUs. Also irgendwie hoffe ich dass du es nicht ernst meinst. ;) CAPI, PCIE und NVLINK sind signaltechnischt betrachtet ja recht ähnlich (LVDS). Also sind die PHYs eventuell ebenfalls ähnlich oder können teils für das jeweils andere genutzt werden. Die erste Generation ist ein Auftakt, aber du kannst dir gern ein DGX bestellen und bekommst den dann auch geliefert. In Deutschland gibt es jedenfalls ein System samt NVLINK und Beschwerden konnte ich nicht vernehmen. Netto 20-60 GB pro Sekunde ist nicht wenig. Stromspartechniken inklusive. Ich glaube PCIE 4.0 war einfach noch nicht spezifiziert als man erkannte dass man für HPC gesonderte Anforderungen, vor allem in Hinblick auf die DOE-Systeme, brauchte. Das weiß ich jedoch nicht genau.

@screemer: Reinige mal deine Tastatur oder schreibe langsamer. Grauenvoll...

[Leonidas]

Wieviel tragen die gegenseitigen Bias-Beschuldigungen zum eigentlichen Thema bei? Wenn ich hier reinsehen, hoffe ich eigentlich auf interessante Fakten und Anregungen ...


Zum Thema: Das NVLink schon da ist, hat was. Das es erst mit Power8 Sinn macht, der aber dann schon PCI-E 4.0 haben wird, auch was.

Grundsätzlich könnte NV auch etwas entwickeln, weil man sieht, das man in der aktuellen Situation in der Lage ist, eigene Technik gegen allgemeine Standards durchzudrücken. Sprich: Es muß technisch gar nicht besser sein - aber es gehört halt NV. Zumindest aus Sicht von NV ergibt dies IMO Sinn.

[Hübie]

Das driftet schon etwas in Richtung Alu-Hut ab. Kein Unternehmen wird sich so etwas aufbürden. Schon gar nicht ein so kleines Licht wie NVIDIA. Entscheidungen diesbezüglich haben ja eine Ursache und wenn jemand bei NV wirklich glaubt man könne auf die Art andere, deutlich weiter verbreitete, Standards verdrängen hießen die AMD (;D SCNR).
Es wird eher eine Notwendigkeit gegeben haben, als eine Intention die hier unterstellt wird.

[Screemer]

@

@screemer: Reinige mal deine Tastatur oder schreibe langsamer. Grauenvoll...
Das ist das super autokorrekt von dem uralt tablet, dass ich ab und an benutze. Habs auf dem sprung nicht noch mal gelesene. War ja in den zwei sätzen auch schwere zu verstehen. Vor allem da man von solche stilblüten andauernd gewohnt ist....

[Skysnake]

Vielleicht geht man ja davon aus das die rote Truppe,die keinen direkten Zugriff auf NVLink hat, irgendwann auch noch mal was geregelt bekommt (vorzugsweise mit Vega) ,und schleppt deshalb breitgefächerte Standards mit sich durch die Gegend:P

CAPI brauchen Sie für den FPGA Support usw. Das haben Sie gebracht und müssen es jetzt halt mitschleppen. Ist aber nicht wirklich schlimm, da man eben die gleichen PHYs nutzt wie für PCI-E 4.0. Man wird also wohl nur einen sehr kleinen Extraaufwand für den Support betreiben müssen.

AMD wird auch eher kein CAPI unterstützen, sondern CCIX, was wahrscheinlich dann eher über NEW CAPI aka NVLink laufen wird.


@Skysnake: Sorry aber so eine Netzwerkkarte ist schon etwas gaaaanz anderes als vier GPUs. Also irgendwie hoffe ich dass du es nicht ernst meinst. ;)

Stimmt, Latenzen sind bei GPUs ein deutlich kleineres Problem als bei Infiniband. Mal ganz davon abgesehen, das man mit den aktuellen EDR Mellanox Infiniband Karten an sich mindestens 25 GB/s an Bandbreite braucht, was weder 16x PCI-E 3.0 noch 8x PCI-E 4.0 liefern können. Die Dinger werden also ohne PCI-E 4.0 ausgebremst. Mal ganz davon abgesehen, dass die Gens mit höheren Geschwindigkeit bis 2019 kommen sollen. Damit haste dann selbst 16x PCI-E 4.0 direkt wieder als Flaschenhals. Daher gibt es ja inzwischen sogar Pläne (obs die schon zu kaufen sind weiß ich nicht, aber Mellanox hat schon auf einer Konferenz darüber gesprochen) das man Infinibandadapter bringt, die einen internen PCI-E Switch haben und dann 2x 16x PCI-E mit sich bringen....

Schau dir doch mal das tolle DX1 an. Das Ding hat 4 in Worten VIER Infinibandadapter, damit es mit Daten versorgt werden kann.... Dafür gehen also mal eben 48 PCI-E 4.0 Lanes weg...


CAPI, PCIE und NVLINK sind signaltechnischt betrachtet ja recht ähnlich (LVDS).

wie gesagt, Next CAPI ist genau das Gleiche wie NVLink. Das ist nicht so ähnlich, sondern das Gleiche. Was höchstens anders sein kann ist, das man etwas andere Einstellungen noch fahren kann für pre und post equalization, aber da beides neu ist gehe ich nicht davon aus, das es da auch nur den Kleinsten Unterschied gibt.


Also sind die PHYs eventuell ebenfalls ähnlich oder können teils für das jeweils andere genutzt werden. Die erste Generation ist ein Auftakt, aber du kannst dir gern ein DGX bestellen und bekommst den dann auch geliefert.

Du kannst es zwar Bestellen, aber du wirst keinen Bekommen. Ich hatte da neulich eine interessante Diskussion mit jemanden, der gerne so ein Ding haben will. Bekommt es aber nicht genau wie so manch anderer auch...


In Deutschland gibt es jedenfalls ein System samt NVLINK und Beschwerden konnte ich nicht vernehmen.

BOAH KRASS!!!11elf ein System....

Und jetzt lass mich mal Raten, das Ding wurde gestellt/gesponsort und nicht gekauft... Jetzt denk mal scharf nach, wie groß die Wahrscheinlichkeit ist, dass das Ding öffentlich als nicht gut bezeichnet wird. Es gibt mehr als nur eine Kiste in Deutschland bei mehr als nur einem Kunden. Und das Ding kommt mit nem schönen fetten NDA...


Netto 20-60 GB pro Sekunde ist nicht wenig.

20-60GB/s sind eine NULLAUSSAGE! da nicht genannt ist bei welcher Latenz und bei welchen Buffergrößen... Wenn du 20-60GB bei 1kB Buffern hinbekommst, dann ist das ziemlich gut. Wenn du das aber erst bei dutzenden MB hinbekommst, dann ist es ein ziemlich theoretischer Wert...

Und wie gesagt über die Latenz ist da noch rein gar nichts ausgesagt...



Stromspartechniken inklusive.

Du kennst die Power states von NVLink? Wie sind denn die Latenzen für den Wechsel zwischen den Power states? Und wieviel Power spart man im Interface dabei? Ach und wenn wir gerade dabei sind, dann weiste doch sicherlich auch, ob man ne CDR verwendet oder nicht.


Ich glaube PCIE 4.0 war einfach noch nicht spezifiziert als man erkannte dass man für HPC gesonderte Anforderungen, vor allem in Hinblick auf die DOE-Systeme, brauchte. Das weiß ich jedoch nicht genau.

Von PCI-E 4.0 konntest du dir schon IP kaufen, als es noch kein NVLink öffentlich gab. Mal ganz davon abgesehen, das Mellanox im "Massenmarkt" PCI-E 4.0 anbietet, während NVLink nicht käuflich ist....

NVLink ist nichts anders als CAPI, was sich wiederum an HT (PCI-E over HT) orientiert usw usf.

Da wurde das Rad nicht neu erfunden....

[Hübie]

Natürlich wurde das Rad nicht neu erfunden. Hat auch nicht mal NV mit ihren Übertreibungen versucht zu vermitteln. Es braucht eine Lösung für eben die Anforderungen (kleines Rack, Energieeffizienz und Bandbreite).
Du tust so als sei NVLINK scheiße. Ist es eben nicht. Und ja es gibt halt nur ein System. Ist ja nicht mein Gebaren. ;) Ich vermute es ist auf schlechte yieldrates und hoher Nachfrage an anderer Stelle zurück zu führen.

Edit: Es kann natürlich sein dass es mehrere DGX-1 gibt, ich weiß jedoch nur von einem definitiv. Aber was hinter den Kulissen von Atlas, Rheinmetall & EADS abgeht wissen wir jedenfalls nicht und werden so etwas auch nicht erfahren.

[Skysnake]

Hübie, eine Technik wird aber nicht dadurch geil, das jemand sich die Mühe macht und davon VIEL ein eine Box packt....

Die ganzen Interconnects sind eben nicht umstonst. Klar, wenn ich mit einer mikrigen Kiste auskomme, dann ist so etwas schon ziemlich pornös, wobei es auch heute schon mehr als genug Kisten mit 8/16 GPUs zu kaufen gibt. Oder schau dir doch mal eine SGI Altix an, wenn du wirklich auf große NUMA-Maschinen stehst. So was gibt es und wird auch eingesestzt, aber es skaliert halt nicht wirklich, vor allem nicht preislich.

Wenn jeman mit einer DXG1 auskommt, dann ist das schön. Allerdings würde ich mir dann mal echt Gedanken über meine Software machen. Denn mit nem Cluster wirste wahrscheinlich billiger auf mehr Leistung kommen, aber seis drum, um was es mir geht ist, das man nicht nur innerhalb der Box denken darf, sondern auch außerhalb, und da sieht man z.B. das man bei der DXG1 ja 4! Mellanox FDR Karten einplant...

Das sind 48 PCI-E Lanes und noch viel schlimmer, du brauchst 4 Ports am nem Switch... Nur mal so ein paar handwaving numbers: Man plant ca 25% der Systemkosten von Clustern für den Interconnect ein. Wenn du jetzt aber eine DXG1 als 4 nodes aus sicht des Netzwerkes) betrachtest, dann ist die Leistung pro Node auch nicht mehr so gewaltig. Was sinds dann noch? Ah ja 5-6 TFLOPs. Gut man kann beim Netzwerk wieder einiges einsparen, da ein node mit 4 Links besser ist als 4 nodes mit einem Link, wenn man nicht gerade einen FatTree bauen will.

Ich sag nicht, dass das Ding scheise ist, aber es ist gewaltig überhyped.

EDIT:
Ich schnmeis mich gleich weg. https://www.hpcwire.com/2016/10/14/opencapi-takes-on-pcie/

Wir halten mal Fest. New CAPI = NVLink, also IBM und NVidia.

OpenCAPI = IBM, MEllanox, AMD usw.

Ach und OpenCAPI = New CAPI ;D

Also OpenCAPI = NVLink ;D

hmm...

[scully1234]

AMD wird auch eher kein CAPI unterstützen, sondern CCIX, was wahrscheinlich dann eher über NEW CAPI aka NVLink laufen wird.


Im Artikel den du verlinkt hast ,wird mit keiner Silbe CCIX erwähnt, sondern explizit PCIe als Fundament fuer Open CAPI.

Und wer ist da mit im Konsortium aufgefuehrt?


Also ist das ''mitschleppen'' wohl auch so vorgesehen,fuer eben solche Partner, und ich lag wohl nicht so ganz verkehrt

PS: wo ist eigentlich mein Post hin?:confused:

[Skysnake]

Dann les bitte nochmals in ruhe den artikel. Die ZIELEN auf pcie-e und verwenden es nicht. OpenCAPI soll ja auch mit 25gbit laufen und nicht mit den 16 von pcie-e 4.0

[StefanV]

Ich schnmeis mich gleich weg. https://www.hpcwire.com/2016/10/14/opencapi-takes-on-pcie/

Wir halten mal Fest. New CAPI = NVLink, also IBM und NVidia.
OpenCAPI = IBM, MEllanox, AMD usw.
Ach und OpenCAPI = New CAPI ;D
Also OpenCAPI = NVLink ;D
hmm...
Also versucht nVidia mal wieder aus 'nem offenen Standard was eigenes zu basteln und einzuzäunen, wie sie es schon mit der VESA adaptive Sync Spec, die ja schon seit einiger Zeit im eDP Protokoll drin war, gemacht haben...

[uweskw]

.

.......Grundsätzlich könnte NV auch etwas entwickeln, weil man sieht, das man in der aktuellen Situation in der Lage ist, eigene Technik gegen allgemeine Standards durchzudrücken. Sprich: Es muß technisch gar nicht besser sein - aber es gehört halt NV. Zumindest aus Sicht von NV ergibt dies IMO Sinn.

Und genau hier beginnt die Aufgabe der Fachmedien. Den Konsumenten aufklären und vor den Nachteilen proprietärerer Software warnen. Auch wenn es vielen egal ist wenn es vermeinlich was umsonst gibt.

greetz
US

[Skysnake]

Also wenn man sich die neue Top500 anschaut, dann scheint die P100 nicht effizienter bezüglich R_Max/R_Peak zu sein. Das hätte ich jetzt ehrlich gesagt nicht erwartet.

PizDaint wurde btw. mit über 4k P100 ausgerüstet, allerdings mit der PCI-E Version. Damit dürfte DGX-1 Saturn V bei nVidia selbst mit 125 Kisten a 8 P100 die größte Installation der Welt wohl sein mit NVLink.

[Godmode]

Also wenn man sich die neue Top500 anschaut, dann scheint die P100 nicht effizienter bezüglich R_Max/R_Peak zu sein. Das hätte ich jetzt ehrlich gesagt nicht erwartet.

PizDaint wurde btw. mit über 4k P100 ausgerüstet, allerdings mit der PCI-E Version. Damit dürfte DGX-1 Saturn V bei nVidia selbst mit 125 Kisten a 8 P100 die größte Installation der Welt wohl sein mit NVLink.

Effizienter gegenüber was? Oder meinst du das Missverhältnis zwischen R_Max und R_Peak?

Von den Systemen in den Top10 sind sie an erster Stelle was die TFlops/kW angeht.

https://abload.de/img/capturefassp.png

[Troyan]

Was?! Nach der Aufrüstung ist der Supercomputer 56% schneller und benötigt 25% weniger Strom. Das entspricht einer Effizienzverbesserung von rund 2x.

Aber stimmt schon, da hat sich nichts getan. :rolleyes:

/edit: nVidias eigener Supercomputer ist der effizienteste auf der Welt: https://blogs.nvidia.com/blog/2016/11/14/dgx-saturnv/
Erheblich effizienter als jedes andere System mit Kepler.

[iuno]

Ich finde die Effizienzsteigerung doch recht ordentlich. Allerdings muss man auch im Hinterkopf behalten, dass man hier noch gegen Kepler und GCN (obwohl kaum vertreten, aber immerhin bessere Effizienz als Kepler) antritt. Mir wuerde hoechstens zu denken geben, dass bisher keiner ausser Nvidia selbst in einer richtig grossen Anlage NVLink benutzt.

[Troyan]

OEM Systeme mit entsprechenden Mainboards werden erst Q4/Q1 ausgeliefert. NVLink gibt es zur Zeit nur in der nVidia-Box.

[mksn7]

P100 wird in der nächsten Liste stärker durchschlagen. In dieser Liste gehört das Rampenlicht ganz den KNLs. Trotz aller Verzögerungen sind die einfach nochmal ein bisschen früher dran.

Beide scheinen aber recht änhliche Probleme zu haben, vom ersten funktioniereden Produkt zu guten Stückzahlen zu kommen.

Anekdote am Rande: Die Student Cluster Competition läuft grad wieder auf der SC, und es wird spannend wieviel Linpack die Studenten aus 3KW rausholen. Nachdem der Linpack die letzten Jahre bei ~8-10 TFlops (mit Kepler Hardware) stagniert ist, dürfte es da jetzt einen ordentlichen Sprung geben, weil mehrere Teams P100 und KNL dabei haben. Faktor 2-3 könnte da schon drin sein.

[Skysnake]

Effizienter gegenüber was? Oder meinst du das Missverhältnis zwischen R_Max und R_Peak?

Von den Systemen in den Top10 sind sie an erster Stelle was die TFlops/kW angeht.

https://abload.de/img/capturefassp.png
Meine Fresse, ist lesen wirklich sooooooo schwer, oder wird da bei einigen einfach gleich ein Beisreflex ausgelöst?

Ich hatte ja sogar am Anfang Efiizienz da stehen, dann die Formulierung aber geändert, weil ich schon damit gerechnet habe, das gleich eine Meute sich darin verbeist... Ich habe EXTRA! nicht "Effizienzbe züglich R_Max/R_Peak" geschrieben, sondern "effizienter bezüglich R_Max/R_Peak"....

Also nochmals. Da steht: "effizienter bezüglich R_Max/R_Peak"

Was werde ich da wohl meinen? Die Energieeffizienz? Wohl eher nicht oder?

Es ist halt so erstaunlich, dass die R_Max/R_Peak-Effizienz runter gegangen ist, wo man doch mit Kepler kein optimales Frontendhatte und daher Probleme existierten die ALUs auch mal wirklich auszulasten. Zumindest in Real-World-Applications. Mit Pascal hat man sich da eigentlich deutliche Verbesserungen versprochen. Aber so wie es aussieht ist dem halt nicht so. Vor allem was dramatisch ist, ist das es so Probleme bereits bei Linpack gibt, was EXTREM! gutmütig ist. Wenn man da nicht die volle Leistung raus holt, holt man es meist nie in echten Anwendungen. Deep Learning mag vielleicht anders sein, und noch gutartiger, aber die Welt ist NICHT nur Deep Learning.

BTW: Die reinen KNL Maschinen zeigen ein noch verherrenderes Bild. Die gurken bei 50% etwa rum....

[Godmode]

Mir war in diesem Zusammenhang (R_Max und R_Peak) nicht klar, dass man hier von Effizienz spricht, daher meine Nachfrage.

Hier noch ein Link für Interessierte was R_Max und R_Peak überhaupt ist: http://stackoverflow.com/questions/25979113/application-performance-vs-peak-performance/26012275#26012275

[MilesEdgeworth]

Interessant, danke für den Link! :up:

[scully1234]

Meine Fresse, ist lesen wirklich sooooooo schwer, oder wird da bei einigen einfach gleich ein Beisreflex ausgelöst?

Ich hatte ja sogar am Anfang Efiizienz da stehen, dann die Formulierung aber geändert, weil ich schon damit gerechnet habe, das gleich eine Meute sich darin verbeist... Ich habe EXTRA! nicht "Effizienzbe züglich R_Max/R_Peak" geschrieben, sondern "effizienter bezüglich R_Max/R_Peak"....

Also nochmals. Da steht: "effizienter bezüglich R_Max/R_Peak"

....

Titan K20
Rmax -------R Peak
17,590.0--- 27,112.5

Piz Daint P100

9,779.0----15,988.0

willst du uns mal erklaeren was da jetzt so dramatisch schlecht sein sollte?

Ich seh hier den Grund fuer das Haar in der Suppe keinesfalls auch nur irgendwie gerechtfertigt,zumal man die reine Effizienz fuer die erbrachten Real World Szenarios nunmal auch nicht ausklammer sollte bei der ganzen Betrachtung

Kannst du mal mit Zahlen eines Konkurrenten aufwarten der auch nur ansatzweise solch einen Monsterchip auf ein viel besseres Verhaeltniss gebracht haette (Tianhe Xeon PHI als Beispiel)????


Hinter der Software kackt der Baer, aber der Haufen den P100 da ablegt, scheint nicht unbedingt der schlechteste zu sein in dem Sektor

[Troyan]

rMAX wird weiterhin mit Linpack gemessen. Das kann, muss aber nicht die beste Anwendungen für GPUs sein.

Am Ende spielt es keine Rolle, da nVidia die rMAX Leistung mit einem deutlich geringeren Aufwand erreicht als die Konkurrenz.

[Hübie]

Einfach ignorieren. Skysnake kann es irgendwie nicht haben, wenn nVidia Erfolg hat bzw. etwas auf die Beine stellt (hartes Leben). Gleich kommt die Schallplatte, Jensen hätte dies und das versprochen, aber dann gebrochen. Ich versteh ihn einfach nicht. :rolleyes:

Afair war Keplers Schwäche nicht das Frontend sondern die Cache- und Registerspacegrößen welche nicht in Relation standen um 192 ALUs kontinuierlich zu füttern bzw. Ergebnisse abzulegen. Egal. Es gibt halt kaum etwas oder nichts besseres.
P100 wurde vorrangig für deep learning gebaut. Wurde mehrfach gesagt und wird mehrfach auf Konferenzen etc. gezeigt.

[scully1234]

Gleich kommt die Schallplatte, Jensen hätte dies und das versprochen, .

CEOs versprechen viel wenn der Tag lang ist, das ist beim geclonten weiblichen ''Jensen'' des Mitbewerbers nicht anders

Die klauen auch kleinen Kindern das Pausenbrot(oder die Lederjacken), wenn es Vorteile bringt=)

Der einzige Advantage an Jensen ist, er bringt seine Halbwahrheiten besser unters Volk, als sein weibliches Pentant

[Grenzgänger]

Titan K20
Rmax -------R Peak
17,590.0--- 27,112.5

Piz Daint P100

9,779.0----15,988.0

willst du uns mal erklaeren was da jetzt so dramatisch schlecht sein sollte?


Da der Dreisatz ja anscheinend aus der Mode gekommen ist, werde ich euch jetzt mal erklären, was Skysnake meint:

Wenn man Rpeak als 100% annimmt, erreicht K20 bei Rmax 64,88% von Rpeak, Piz Daint aber nur 61,16%. Für eine neue Architektur ist das nicht wirklich toll, würde ich mal sagen. Aber vielleicht sieht das durch die grünen Brillen ja anders aus, nicht wahr?

[Pottsblitz]

Wenn man Rpeak als 100% annimmt, erreicht K20 bei Rmax 64,88% von Rpeak, Piz Daint aber nur 61,16%. Für eine neue Architektur ist das nicht wirklich toll, würde ich mal sagen. Aber vielleicht sieht das durch die grünen Brillen ja anders aus, nicht wahr?
Man könnte aber auch den DGX SATURNV Cluster von NVIDIA selbst nehmen und kommt bei 4,896.5 und respektive 3,307.0 TFlops auf einen Faktor von 67,5%.

Oder ist das nicht genehm, weil dann NVIDIA plötzlich besser da steht? :freak:

edit: Hallo zusammen!

[iuno]

Hallo und herzlich willkommen ;)

Saturn V hat auch NVLink, also massiv mehr Bandbreite innerhalb eines Nodes und ist insgesamt deutlich kleiner. Der oben angesprochene Titan hat 18k Nodes, Piz Daint 5k und Saturn noch deutlich weniger, wenn die Zahlen noch stimmen. Verstaendlich, dass da die Skalierung abnimmt. Ich kann schon nachvollziehen, was Skysnake meint.

[Grenzgänger]

@Pottsblitz
Und du meinst, diese 3% sind jetzt genug, um Nvidia über den grünen Klee zu loben, wie es einige hier oft und gerne tun? Also, mir wäre das eindeutig zu wenig, vor allem, wenn man den Preis für diese Aufrüstung bedenkt.

[Skysnake]

Man könnte aber auch den DGX SATURNV Cluster von NVIDIA selbst nehmen und kommt bei 4,896.5 und respektive 3,307.0 TFlops auf einen Faktor von 67,5%.

Oder ist das nicht genehm, weil dann NVIDIA plötzlich besser da steht? :freak:

edit: Hallo zusammen!
Nein, man muss es mit der alten Installation von PizDaint vergleichen. Die werden da dann nämlich ähnlich gut optimiert haben, und kennen das System eben.

Und da sieht es eben so aus:
Der alte PizDaint kam auf 6271/7788,9 also 80,5% Effizienz R_Max/R_Peak. Da ist deutlich! besser als jetzt mit P100. Und das ist eben wie gesagt sehr sehr überraschend für mich. Das habe ich so nicht erwartet. Denn entgegen obigen, lag es eben nicht am Cachesystem usw. Man kann nur 2 DualWavefront gleichzeitig absetzen auf Kepler pro takt, brüchte aber 3 um die Hardware immer voll auslasten zu können.

Das ist mit Pascal nicht mehr so! zuzuüglich vielen anderen Verbesserungen, die eigentlich erwarten liesen, das man mehr als die 80% raus holen kann. Schaut euch mal manche CPU maschine an, die rennen teil bei >90% rum...

PS:
Ich hatte noch eine interessante Diskussion. die Q und P Parameter sind wohl recht wichtig. Wenn man da "schlechte" Werte erwischt, dann kann das schnell mal 10-20% Punkte!!!! ausmachen. Daher ist es auch nicht gut zwischen unterschiedlichen Systemen zu vergleichen, denn die Leute wissen halt unterschiedlich gut, wie man optimiert. Bei so einem System erwarte ich aber, das man da das letzte raus quetscht.

[Pottsblitz]

Und du meinst, diese 3% sind jetzt genug, um Nvidia über den grünen Klee zu loben, wie es einige hier oft und gerne tun? Also, mir wäre das eindeutig zu wenig, vor allem, wenn man den Preis für diese Aufrüstung bedenkt.
Ah, also 3% (relativ) langsamer ist also "nicht so toll", da wird ein Faß für aufgemacht, aber bei 3% schneller, da darf man nichts positives sagen, das ist "über den grünen Klee loben" ;D

Irgendwie höre ich Propellergeräusche

Ach und bezüglich der Aufrüstung:

PizDaint ist umgestellt worden von K20x. Damit lieferte er 6271.0 TFlops bei 1754 kW Leistungsaufnahme. Nach der Umstellung wurden daraus 9779.0 bei 1312 kW. Oder, wie unsere Dreisatzkünstler ja sicherlich nachvollziehen können: 64% Mehrleistung bei gleichzeitig gut 25% Energieeinsparung. Effizienzmäßig ist man also mehr als 100% besser geworden.

Also wenn sich das nicht lohnt - ich weiß ja nicht.

@iuno: Danke, rein von der Rechenleistung her ist SaturnV ca. 1/3 von Piz Daint, der wiederum knapp die Hälfte von Titan ist.

Entscheidend ist doch, was hinten raus kommt, und nicht, wie viele Nodes dafür notwendig sind. Oder?

[Achill]

[..]
Entscheidend ist doch, was hinten raus kommt, und nicht, wie viele Nodes dafür notwendig sind. Oder?

Es kommt auf die Frage an die man stellt:
- Effizenz bzgl. Peak/Watt?
- Effizenz bzgl. Real/Watt?
- Effizenz Real/Peak?
- ...

[Hübie]

Die Projektverantwortlichen würden stets damit antworten wie flexibel man mit Effizienz XY bleibt. Denn alles basiert noch auf Kompromissen. Wie gesagt wurde GP100 vorrangig für deep learning gebaut / designed. Und es will doch hier niemand ernsthaft abstreiten dass man x% mehr Leistung für y weniger Watt erhält, oder?

[Skysnake]

War die Energieeffizienz das Thema? Ich glaube nicht Tim....

Natürlich ist das Ding ziemlich Energieeffizient. Es ist aber schon verdammt erstaunlich, das man gerade mal 60-70% von Peak erreicht und das in einem Benchmark, der wirklich sehr sehr gutmütig ist und den man über zich Jahre totoptimiert hat.

Die 80% der GPUs waren bisher ja schon nicht soo der Brüller, weil man genau wusste, das in Real World Applications viel viel weniger als das erreichbar ist im Allgemeinen.

Die 50% von KNL sind bzw. ja noch viel katastrophaler... Wobei man sich da anschauen muss, was mit den zwei Speicherstufen noch erreichbar ist. Der DDR RAM + MCRAM ist halt wirklich eine ekelhafte angelegenheit, weil der DDR RAM halt immer noch so schnell ist, das es richtig weh tut, wenn man ihn nicht nutzt...

Ansonsten kann/muss man sagen, das es eben völlig unerklärlich ist, warum die Werte so beschissen sind was rein die Peak-Effizienz anbelangt. Rein von dem, was man bisher gesehen hat, war das NICHT! zu erwarten. Und nVidia hat wohl selbst hinter vorgehaltener Hand etwas anderes erzählt eine ganze Zeit lang. Ich bin da nicht der Einzige, der sehr überrascht ist bezüglich der niedrigen Peak-Effizienz.

Was aber natürlich gut ist, ist die Energie-Effizienz, wobei das nur für den Vergleich mit allen anderen gilt.

Wenn man sich die alten Roadmaps anschaut, dann hatten die mal für Pascal 36-48 GFLOPs/W versprochen für SGEMM. Sind wir gnädig und nehmen 36 und halbieren es für DGEMM, dann kommt man auf 19 GFLOPs/W. Das ist halt sehr sehr sehr weit weg von dem, was man jetzt zeigt. Da mag man hier und da noch einiges an Verlusten einrechnen, weil es halt kein reiner DGEMM ist, und man kann auch für DP etwas abziehen, aber keinen Faktor 2.

Und das Pascal vorrangig für Deep Learning gebaut/designed wurde, würde ich jetzt auch nicht unbedingt sagen. Wenn man das wirklich konsequent gemacht hätte, hätte man so manches runterkürzen können.

Die Frage ist halt eher, warum verkacken es gerade alle Hersteller ziemlich heftig? KNL ist ja eine echte enttäuschung von den Ergebnissen her...

K20 ist von 2012. Das muss man sich mal auf der Zunge zergehen lassen. Also nach 4 Jahren hat man die Effizienz um einen Faktor 2,1 gesteigert in Linpack. Wenn man das so weiterführt, hätten wir das Effizienzziel für Exascale erst irgendwann in 10-12 Jahren erreicht. Und das obwohl man jetzt HBM verwendet und NVLink eingeführt hat und an der Architektur wirklich was gedreht hat. Vor allem Dinge, wo man gedacht hat, das man die Peak Performance besser/leichter auf die Straße bekommt....

Das gute/schlimme daran ist halt, das Intel noch schlechter dasteht wie es gerade scheint. Omnipath scheint auch eher enttäuschend zu werden/sein.

Da muss man mal schauen, was mit Post-K von Fujitsu, Aurora von NEC und eben AMD wird. Das beste Gefühl habe ich da noch bei Post-K, was aber nicht heisen soll, das es gut ist. Ganz im Gegenteil.

Vielleicht überraschen aber auch noch die Chinesen, wobei man da halt wirklich schwer sagen kann, wie nutzbar die Kisten von denen sind. Da bekommste halt nicht wirklich Einblicke.

[Pottsblitz]

Es kommt auf die Frage an die man stellt:
- Effizenz bzgl. Peak/Watt?
- Effizenz bzgl. Real/Watt?
- Effizenz Real/Peak?
- ...
Realistisch weder noch.

Faktisch wird so eine Entscheidung aus einem Mehreck mit den Eckpunkten

- Rmax
- Leistungsaufnahme
- Preis

bestehen. Dazu noch weichere Faktoren wie Platz oder Kompatibilität mit vorhandener Software.

Aber was interessiert irgendwen, der einen Supercomputer kauft, das Verhältnis Rmax zu Rpeak? Technisch interessant vielleicht, aber sonst?


Pressemitteilung von Cray übrigens:
http://www.pcworld.com/article/3141449/hardware/cray-aims-for-the-500-petaflop-mark-with-xc50-supercomputer.html

Liest sich, als wäre er Umbau von Piz Daint noch nicht abgeschlossen ("In-system upgrades to Piz Daint are ongoing, and the supercomputer will be merged with another, called Piz Dora."), das würde natürlich die fragwürdige Rmax/Rpeak Verhältnisse erkären. Aktuell wohl ein Cray CX30, 40 und 50 Mix ;D

[Skysnake]

Das ist gar kein Nachteil. Der Teil der dazu kommt ist eine reine CPU Maschine. Den wird man für die Benchmarks wohl eh nicht verwenden. Der läuft wohl angeblich eh hauptsächlich auf der GPU und eher weniger auf der CPU.

Es gibt jetzt btw. den HPCG-Benchmark. Saturn V kommt da auf 1.6% Effizienz und der neue PizDaint ist gar nicht drin. Der alte hat aber auch 1.6% als Fraction of Peak erreicht. Da hat sich bezüglich der Effizienz leider rein gar nichts getan. Aber immerhin fällt die Effizienz nicht weiter :up: Was aber irgendwie auch verwunderlich ist, das man beim HPL so deutliche Verluste hinnehmen muss, bei HPCG aber immerhin die Effizienz halten kann. Der HPCG ist ja der weitaus anspruchsvollere Benchmark.

Ich würde sagen man kann den HPL als Bestcase und den HPCG als Worstcase ansehen. So 3-10% von Peak sind wohl für echte Anwendungen ein guter bis sehr guter Wert.

[mksn7]

Bei HPCG gehts ja nur um das Speichersubsystem. Und das scheint im HPCG eine ähnliche Effizienz zu haben wie Kepler vorher. Nachdem Flops/Byte recht ähnlich geblieben ist, gibts auch den gleiche HPCG ratio of peak.




Von der Student Cluster Competition gibts jetzt die Ergebnisse. Das Top Team mach 31.5 TFlops in 3KW und 8 P100s. Macht fast 4 TFlops/Karte oder 75%. Das ist natürlich ein viel kleineres System als die großen Cluster, von daher ist da ein bisschen weniger Verlust durch nicht optimales Scaling drin. Soweit ich weiß wurden die Karten da aber auch ein wenig im Stromverbrauch beschränkt, weil sie sonst das 3kW Powerlimit nicht eingehalten hätten.

Das Münchner Team mit 8 KNLs kommt (afaik) nur auf ~16TFlops. Bislang lag der Rekord, aufgestellt mit Keplerkarten, bei etwa 10 TFlop/s, in diesem Fall also ein Faktor drei bei der Energieeffizienz.


Das was der HPCG macht ist ja tatsächlich für viele Codes der zeitfressende Schritt, von daher ist der HPCG da representativer für echte Anwendungen. Die meisten Applications haben ihre arithmetische Intensität eher im Bereich vom HPCG als vom HPL. 3-10% wird wohl schon hinkommen. Die Effizienz als Anteil der Peak Flop rate auszurechnen macht da aber keinen Sinn, weil das nicht das relevante bottleneck ist.

[Skysnake]

Dem HPCG fehlt halt die Power Messung. Damit wäre er deutlich aussagekräftiger, aber was nicht da ist, kann man halt auch nicht bewerten und der HPCG hat schon so nur sehr wenige Teilnehmer...

Es ist wirklich schade, dass PizDaint mit P100 leider nicht mit drauf ist. Das hätte mich schon brennend interessiert.

Aber mal schauen, vielleicht bekomme ich son Ding ja mal zwischen die Finger.

[Entropy]

@Skysnake
wenn 80% Wirkungsgrad schlecht ist, welcher Wert wäre OK, und was ist daa Top System (und dessen Wirkungsgrad).

in 3KW und 8 P100s.
Ist das für das ganze System oder rein für die Beschleuniger? Wird die Leistugsaufnahme berechnet oder gelten die TDP?
Ich würde erwarten, dass CPU (vermutlich dual Xeon?) und das Netzteil 10%-20% ausmachen können, daher die Fragen.

[y33H@]

Der Piz Daint wurde für die Top500 nur mit 2/3 seiner Tesla P100 vermessen.

[Skysnake]

@Skysnake
wenn 80% Wirkungsgrad schlecht ist, welcher Wert wäre OK, und was ist daa Top System (und dessen Wirkungsgrad).

>90% sind für CPU Systeme an sich "normal". ~80% für Beschleuniger und alles darunter ist dann nicht mehr gut -> schlecht.

Man muss sich halt bewusst machen, das Linpack ein so ziemlich der BestCase ist. Klar, hin und wieder gibt es auch noch angenehmere Anwendungen/Probleme, aber die kannste wie die Stecknadel im Heuhaufen suchen.


Ist das für das ganze System oder rein für die Beschleuniger? Wird die Leistugsaufnahme berechnet oder gelten die TDP?
Ich würde erwarten, dass CPU (vermutlich dual Xeon?) und das Netzteil 10%-20% ausmachen können, daher die Fragen.
Es wird an der Steckdose gemessen. Und da SC sollte es wohl auch das amerikanische Netz sein, also eh etwas ineffizienter als mit unseren 230V.

Der Piz Daint wurde für die Top500 nur mit 2/3 seiner Tesla P100 vermessen.
Woher die Info?

Macht die Sache aber auch nicht besser, wobei Aries verdammt gut skaliert und Linpack eh nicht sonderlich auf den Interconnect geht. Man kann also erwarten, dass die Effizienz etwa gleich bleibt. Ändert also nicht wirklich etwas an den Aussagen bezüglich R_Max/R_Peak aber auch Energie-Effizienz.

[mksn7]

Lol, die Japaner haben den K-Computer grad von Platz 2 auf Platz 1 geschoben, indem sie den HPCG optimiert haben... Und Taihu Light sieht viel weniger beeindruckend aus im HPCG.

[y33H@]

Woher die Info?Nvidia und Top500.

[Entropy]

>90% sind für CPU Systeme an sich "normal". ~80% für Beschleuniger und alles darunter ist dann nicht mehr gutDanke für die Antwort. Sehr interesant.
Ich habe erwartet, dass Streamingprozossoren effizienter wären, weil sie besser Speicherlatenz verstecken können.

Sollte *GEMM nicht so langsam an das Limit der Caches stoßen?

[Skysnake]

Nein, das ist ja der Punkt, du kannst bei DGEMM sehr einfach Cacheblocking machen mit einem guten Reuse. Da musst du quasi nicht wirklich Latenzen verstecken können, weil das Problem an sich rechenintensiv genug ist. Die Beschleuniger sind da auch nur deswegen gut. Du kannst trotz der kleinen Caches/Registerfiles die Daten einfach oft genug wiederverwenden um einen signifikanten Anteil der Performance raus zu kitzeln.

Die DGEMM ist da durchaus etwas, was man nimmt/nehmen kann um zu entscheiden, wie die Caches aufgebaut sein müssen. Also mindestens!

Bei den neuen x86 muss man halt 64Byte aligned sein und L1 Cache blocking machen. Dann spuckt das Ding schon genug Bandbreite aus.

Bei Haswell kann der L1 z.B. 50% der Bandbreite liefern, die man für Peak braucht. So lange die Pipeline nicht leer läuft und man etwas in den Registern halten kann, was bei DGEMM locker geht, ist alles schick.

Da ist es auch etwas verwunderlich, dass die KNL Kisten nur 50% haben. Das ist wirklich schlecht. Ich habe aber keine Ahnung, woran das liegen könnte. Eventuell sind 2 512 Bit FPUs pro Core doch ein Problem.

[Entropy]

Nein, das ist ja der Punkt, du kannst bei DGEMM sehr einfach Cacheblocking machen mit einem guten Reuse. Da musst du quasi nicht wirklich Latenzen verstecken können, weil das Problem an sich rechenintensiv genug ist. Die Beschleuniger sind da auch nur deswegen gut. Du kannst trotz der kleinen Caches/Registerfiles die Daten einfach oft genug wiederverwenden um einen signifikanten Anteil der Performance raus zu kitzeln.
Weil Speicherladen mit O(n) und die Arbeit O(n*n) skaliert. Aber genau deswegen frage ich mich, ob das mit der Zeit nicht zum Trugschluss führt, nach all den Jahren in denen GPUs alles möglich gemacht haben um den Flop-Durchsatz zu steigern. z.B. hatten SMs beim G80 8 "Cuda Cores" mit 16 KB bzw 48 KB "shared", bei Pascal sind es 64 KB bei jedoch 64 "Cuda Cores"

Beim G80 hatten wir pro SM ca 10 GB/s und 43.2 GFlop/s (86.4 GB/s und 345 GFlop/s bei GTX8800, verteilt auf 8 SM) und 200 cycle latenz. Bei 32 KB Shared, wenn wir von zwei "source" Buffern ausgehen und das resultat direkt in dem Speicher schreiben, mit double buffering um reine "load" bzw "compute" Zeit zu überlappen, haben wir 2048 floats pro buffer, damit verarbeiten wir pro "Durchlauf"
- einen "source" Buffer lesen bei O(8192 Byte) == 0.763µs + 0.148µs
- n*n FMA/MADD berechnen bei O(2048*2048*2) == 194.181µs

Beim Pascal haben wir pro SM ca 12.9 GB/s und 189.4 GFlop/s (720 GB/s und 10600 GFlop/s bei 56SM). Die SM hat 64 "Cuda Cores" und 64 KB "shared-cache". Wenn die bisherige 4 cycle FMA Latenz für Pascal auch noch gilt, wären es 8!! Warps um vollen ALU-Durchsatz zu erreichen. Damit haben wir Blocks von 65536 / sizeof(float) / 8(Warps) / 2 ("source" Buffer): 1024
Ich weiss die Latenz bei P100 nicht, vorher war es ca 360 cycle Speicher + 120 cycle L2 miss bei ca 950Mhz.
- einen "source" Buffer lesen bei O(4096 Byte) == 0.296µs + ~0.5µs
- n*n FMA/MADD bei single O(1024*1024*2) == 11.073µs
- n*n FMA/MADD bei double bei O(512*512*2) == 5.536µs

Ich hoffe meine "Milchmädchenrechnung" ist nicht komplett falsch, ich bin kein Experte bei dieser Implementierung, hab das bisher nur einmal zum Spass implementiert.

Beim G80 war der Transfer nur 0.5% der ALU Zeit, beim Pascal 14% (bei double).
Theoretisch sollte die ALU-Arbeit die Load-Arbeit komplett verstecken, jedoch wird es Konflikte (gerade beim Start der Warps) geben. Die Chance zu Konflikten zur Laufzeit sollte, nach dem Geburtstagsparadoxon, dramatisch steigen. 8 Warps sind natürlich sehr gut um die Chancen ALUs auszulasten zu maximieren, aber die steigern im gleichen Zug das Konfliktspotential.


Bei Haswell kann der L1 z.B. 50% der Bandbreite liefern, die man für Peak braucht. So lange die Pipeline nicht leer läuft und man etwas in den Registern halten kann, was bei DGEMM locker geht, ist alles schick.

Da ist es auch etwas verwunderlich, dass die KNL Kisten nur 50% haben. Das ist wirklich schlecht. Ich habe aber keine Ahnung, woran das liegen könnte. Eventuell sind 2 512 Bit FPUs pro Core doch ein Problem.
Wieso 50% der Bandbreite?
Ich dachte gelesen zu haben, dass Intel die Bandbreite zum Cache verdoppelt hat um FMA3 voll bedienen zu können. 64 Byte Load und 32 Byte Store und der Throughput sollte doch 2 Cycle bei 2 Ports, somit 1 FMA/Cycle, sein. Hab ich da was falsch in Erinnerung?

[Skysnake]

Ja, es sind 2 AVX FMAs pro Takt bei Haswell und Broadwell. Bei Skylake (-E) bin ich mir nicht sicher. Die Kleinen wohl auch 2x AVX FMA pro Takt, aber Skylake-E hat ja AVX3.2 aka AVX512. Da weiß ich nicht was geht.

Ansonsten kann ich zu deiner Rechnung auf die Schnelle nichts sagen. DAs müsste ich erst mal durchhirnen.

Du solltest aber bedenken, das man an sich nicht erstmal alles lädt und dann alles berechnet. Sondern partiell lädt und berechnet, damit sich das überlagert. Das sind ja auch unterschiedliche Einheiten.

Bei den hochoptimierten DGEMM (z.B. MKL) verwendet man wohl auch prefetch usw usf. Da kann man wirklich nochmals einiges rausholen und an sich eigentlich Peak fahren.

[mczak]

Ja, es sind 2 AVX FMAs pro Takt bei Haswell und Broadwell. Bei Skylake (-E) bin ich mir nicht sicher. Die Kleinen wohl auch 2x AVX FMA pro Takt, aber Skylake-E hat ja AVX3.2 aka AVX512. Da weiß ich nicht was geht.

Die kleinen Skylake sind da tatsächlich gleich wie Haswell/Broadwell. Ich denke bei Skylake-E müsste das auch so sein, halt einfach doppelt breit. Weniger macht wohl wenig Sinn (und ganz schlecht fürs Marketing...), für mehr bräuchte man mehr Issue-Ports für SIMD-Ops (na gut es sind schon 3 aber der Dritte kann traditionell nicht wirklich "schwierige" Arithmetik, der hat schon genug zu tun mit allen Lane-Crossing Operationen...). Kann ich mir kaum vorstellen, das wäre dann nicht mehr wirklich ein Skylake-Kern.

[Entropy]

Ja, es sind 2 AVX FMAs pro Takt bei Haswell und Broadwell. Dann sind die 64 Byte/Cycle von den Caches echt eventuell zuwenig. Ich ging vom halben Throughput aus.
Kommen die trotzdem auf die 90% dem theoretischen TFlop/s? Dann müssen Sie ehrlich alles aus den Registern rausholen, bin ehrlich beeindruckt.

Ansonsten kann ich zu deiner Rechnung auf die Schnelle nichts sagen. DAs müsste ich erst mal durchhirnen.Kann ich verstehen, es hatte mich nur gepackt das durchzurechnen, weil deine Aussage, dass Pascal unerwartet schlechte Effizienz hat mich neugierig macht weshalb das so ist.

Du solltest aber bedenken, das man an sich nicht erstmal alles lädt und dann alles berechnet. Sondern partiell lädt und berechnet, damit sich das überlagert. Das sind ja auch unterschiedliche Einheiten.
Bei den hochoptimierten DGEMM (z.B. MKL) verwendet man wohl auch prefetch usw usf. Da kann man wirklich nochmals einiges rausholen und an sich eigentlich Peak fahren.hab mir mal http://asg.ict.ac.cn/dgemm/dgemm_nv.html angesehen.
Prefetching scheint einen Hauch langsammer zu sein als Double-Buffering, vermutlich sehr Architekturabhängig. Leider haben Sie die beste Verbesserung mit dem "Instruction scheduling" bekommen, wovon sie nichts erläutern wollen.

[Entropy]

Die kleinen Skylake sind da tatsächlich gleich wie Haswell/Broadwell. Ich denke bei Skylake-E müsste das auch so sein, halt einfach doppelt breit. Weniger macht wohl wenig Sinn (und ganz schlecht fürs Marketing...), für mehr bräuchte man mehr Issue-Ports für SIMD-Ops (na gut es sind schon 3 aber der Dritte kann traditionell nicht wirklich "schwierige" Arithmetik, der hat schon genug zu tun mit allen Lane-Crossing Operationen...). Kann ich mir kaum vorstellen, das wäre dann nicht mehr wirklich ein Skylake-Kern.
Skylake sagte, dass die bisherigen Ports vom Cache unterversorgt sind. (64 Byte/Cycle bei 2 FMA3 die 128 Byte verarbeiten könnten). Würden mehr Ports nicht noch weiter am Cache limitieren?
AVX3 braucht dann erstmal auch eine Cache Verbreitung.

Macht 128 Byte/s noch Sinn auf 64Byte Cache-Lines? Ich würde erwarten, dass das nur die "cache miss rate" steigert, weil doch eine von beiden Cache-Lines nicht vorhanden sein könnte.
Mit 128 Byte Cache-Lines würde alles an Verwaltung halbiert werden, vielleicht könnte dann die Assoziativität verdoppelt werden?

[fulgore1101]

Für wann in etwa ist denn mit dem Pascal Refresh zu rechnen? Wie sind da die Erfahrungswerte aus der Vergangenheit bezüglich refresh von Nvidia?

[Skysnake]

Kann ich verstehen, es hatte mich nur gepackt das durchzurechnen, weil deine Aussage, dass Pascal unerwartet schlechte Effizienz hat mich neugierig macht weshalb das so ist.

Wie schon mal gesagt, überrascht es mich NUR, weil eben Kepler die unschöne Sache mit den 2 Wavefronts sheduler aber 3 Wavefronts an ALUs hatte. Das geht auf die Effizienz. Bei Pascal ist das halt nicht mehr so, und man hat allgemein die REgister verbreitert usw usf.

Man hat einen Rückgang der DGEMM R_Max/R_Peak Effizienz einfach nicht erwarten können. Da hätte ich sogar Geld darauf gewettet, dass das nicht passieren wird...

Man wird jetzt halt warten müssen, ob man herausbekommt, wo dann der Pferdefuß versteckt ist. Ich habe auf jeden Fall keine Idee!

[mczak]

Skylake sagte, dass die bisherigen Ports vom Cache unterversorgt sind. (64 Byte/Cycle bei 2 FMA3 die 128 Byte verarbeiten könnten). Würden mehr Ports nicht noch weiter am Cache limitieren?
Klar, ein weiterer Grund wieso das wohl keinen Sinn macht :-).

AVX3 braucht dann erstmal auch eine Cache Verbreitung.

So ist es im Prinzip müssten das dann 2x512bit Load und 1x512bit Store sein damit man da dieselben Verhältnisse hat wie bei Haswell-Skylake.

Macht 128 Byte/s noch Sinn auf 64Byte Cache-Lines? Ich würde erwarten, dass das nur die "cache miss rate" steigert, weil doch eine von beiden Cache-Lines nicht vorhanden sein könnte.
Mit 128 Byte Cache-Lines würde alles an Verwaltung halbiert werden, vielleicht könnte dann die Assoziativität verdoppelt werden?
Die Cache Line Size ist schon seit Ewigkeiten 64Byte (seit Pentium M...). Eine solche Aenderung würde imho auch eher zu einem neuen Kern passen. Ich denke das Problem dabei wäre dass das für SIMD-Code wohl durchaus Sinn machen würde, aber für den "normalen" Skalarcode wäre das wohl weniger effizient.
Es sind aber immer nur 512bit Transfers, das passt also schon noch.

[Skysnake]

Ein Problem ist wohl auch, das man nicht vom L2 in den L1 schreiben kann und gleichzeitig Daten aus in den L1 von den Registern packen kann.

Ich bin selbst darüber gestolpert, dass der L2 nur 32 Byte/cycle liefert, wenn man ein L2 Cache blocking macht für stream obwohl er eigentlich 64 Byte/cycle liefern können sollte...

Der reale Peak liegt wohl irgendwo bei run 48 Byte/cycle. mehr wurde wohl noch nicht erreicht. Es gibt dazu auch einen Post von Dr. Bandwidth im Intel Dev Forum.

[mczak]

Der reale Peak liegt wohl irgendwo bei run 48 Byte/cycle. mehr wurde wohl noch nicht erreicht. Es gibt dazu auch einen Post von Dr. Bandwidth im Intel Dev Forum.
Fragt sich natürlich ob das bei Skylake-E nicht verbessert wurde, das würde doch durchaus Sinn machen - wenn am einen Ende der L1 doppelt so viele Daten liefern kann, und am anderen Ende sogar auch das Speicherinterface aufgebohrt wurde (auf 6 Kanäle) würde es doch durchaus Sinn machen alles dazwischen (also L1<->L2<->L3<->Memory) auch schneller zu machen. Wobei man da wohl auch am Ringbus (bzw. Ringbussen sind ja mehrere) schrauben müsste.

[Godmode]

Ich bin immer noch gespannt, ob wir das Ding im Jahr 2017, doch noch auf einer Consumerkarte sehen werden, natürlich mit stark eingeschränkter DP Leistung.

[mksn7]

Bei KNL ist die niedrigere Effizienz einfach erklärt: KNL ist Dual Issue, und kann gleichzeitig zwei VPU instructions pro Takt. Jeder Takt, in dem keine VPU instruction geissuet wird ist verlorene Effizienz. Und irgendwann muss man eben mal Addressen berechnen, inc's test's und jump's usw. machen. Knights Corner war auch Dual Issue, aber nur eine VPU instruction pro Takt. Da konnte man neben den VPU instructions sämtliche ALU instructions verstecken die man brauchte. Da war es viel einfacher 100% Effizienz zu erreichen (unter den richtigen Vorraussetzungen).

Bei Pascal... evtl. zuwenig ALU Power für Addressberechnung? Ist ja nur RISC, da kann man nichts in die komplexen Addressmodi verschieben wie bei KNL/x86. Soweit ich weiß, ist Integer Multiplikation nicht so stark, v.a. 64bit.

[Ailuros]

Ich bin immer noch gespannt, ob wir das Ding im Jahr 2017, doch noch auf einer Consumerkarte sehen werden, natürlich mit stark eingeschränkter DP Leistung.

Da Du die DP Leistung verstaendlicherweise abhakst (gleiches gilt auf fuer FP16), bleibt dann fuer eine hypoethetische GP100 desktop SKU genau welches Kaufargument gegenueber GP102 uebrig? Ich erinnere dass PCIe P100 bei nur 1303MHz boost die 250W erreicht.

[fulgore1101]

Für wann in etwa ist denn mit dem Pascal Refresh zu rechnen? Wie sind da die Erfahrungswerte aus der Vergangenheit bezüglich refresh von Nvidia?


Ist das hier der falsche Thread für meine Frage? Falls ja, wo wäre sie besser aufgehoben?

[AffenJack]

Ist das hier der falsche Thread für meine Frage? Falls ja, wo wäre sie besser aufgehoben?

Eher in einem der Threads für die kleineren Pascals bzw GP102. Das ist ja nur noch der HPC/Deap Learning Chip. Aber um deine Frage zu beantworten, es ist nichtmal klar ob ein Refresh kommen wird. Was wohl sicher ist, ist dass ein GP102 unter der Titan kommen wird und das höchstwahrscheinlich in Q1. Aber ob man den Rest überhaupt refresht wird auch von der Konkurrenzsituation abhängen. Bei Kepler hat man das gemacht, bei Maxwell hat mans gleich gelassen und die GPUs 18 Monate laufen lassen. Wenn man es macht, dann wird das bis Mitte nächsten Jahres passieren, sonst ist der Abstand zu Volta zu gering(Anfang-Mitte 2018)

[Godmode]

Da Du die DP Leistung verstaendlicherweise abhakst (gleiches gilt auf fuer FP16), bleibt dann fuer eine hypoethetische GP100 desktop SKU genau welches Kaufargument gegenueber GP102 uebrig? Ich erinnere dass PCIe P100 bei nur 1303MHz boost die 250W erreicht.

Ich finde das Ding halt technisch interessant. Sind die 250W auf SP oder DP bezogen, weil normalerweise braucht SP deutlich weniger Strom.

[Ailuros]

Ich finde das Ding halt technisch interessant. Sind die 250W auf SP oder DP bezogen, weil normalerweise braucht SP deutlich weniger Strom.

Dass P100 eigentlich nur fuer HPC und co. geeignet ist entwertet es technisch ja auch nicht; es ist eben um einiges weniger geignet fuer eine desktop SKU wie je zuvor.

NV gibt selber 250W TDP fuer die PCI-e P100 an, und dabei gilt diese fuer maximal entweder 9.34 TFLOPs FP32 oder 4.67 TFLOPs FP64:

https://devblogs.nvidia.com/parallelforall/inside-pascal/

Mit 30% mehr die area (610 vs. 471mm2) bzw. 40% mehr Transistoren (15.3 vs. 11b) kann ich mir nicht vorstellen dass es je einen Fall geben koennte wo GP100 ein besseres perf/W ratio haben koennte als ein GP102 unter 3D. Titan X Pascal hat einen boost von 1531MHz fuer seinen 250W TDP (mit gleicher Anzahl an Einheiten).

[Spasstiger]

GP100 dürfte wegen der höheren Speicherbandbreite bei gleichem GPU-Takt schneller sein als GP102. Perf/Watt nimmt sich vermutlich nichts. Den Ballast durch HPC-Features macht GP100 durch den effizienten HBM wett.

[aufkrawall]

Du bist in der Endverbraucher-Praxis nicht nennenswert bandbreitenlimitiert.

[fondness]

Perf/Watt nimmt sich vermutlich nichts. Den Ballast durch HPC-Features macht GP100 durch den effizienten HBM wett.

Da sagen die 300W TDP bei deutlich weniger Takt aber was anderes.

[Spasstiger]

Ich hoffe, dass es irgendwann möglich sein wird, GP100 und GP102 taktnormiert gegeneinander in Bezug auf die Spieleperformance und Perf/Watt antreten zu lassen. Funktioniert der Geforce-Treiber auf Tesla? Die Bildausgabe könnte man auf den IGP umleiten.

Da sagen die 300W TDP bei deutlich weniger Takt aber was anderes.
Die Variante mit deutlich geringerem Takt und PCIe hat 250 Watt TDP: http://images.nvidia.com/content/tesla/pdf/nvidia-tesla-p100-PCIe-datasheet.pdf

P.S.: Wer möchte bestellen? http://geizhals.de/pny-tesla-p100-pcie-tcsp100m-16gb-pb-nvtp100-16-a1501119.html

[Ailuros]

GP100 dürfte wegen der höheren Speicherbandbreite bei gleichem GPU-Takt schneller sein als GP102. Perf/Watt nimmt sich vermutlich nichts.

Na dann viel Spass genug Faelle zu finden wo einem heutigen TitanX mit 480 GB/s die Bandbreite zu knapp wird unter 3D, wenn ueberhaupt einen einzigen.

Den Ballast durch HPC-Features macht GP100 durch den effizienten HBM wett.

Eben nicht. Bei gleicher Anzahl von Einheiten und gleichem TDP taktet GP102 schon heute um 17% hoeher als ein GP100@250W und es wuerde mich auch verdammt ueberraschen wenn das erste in Echtzeit auch weniger verbraucht, denn die zusaetzlichen 30% die area auf dem zweiten verschwinden leider nicht und beinflussen nach wie vor den Verbrauch.

Klar erreicht ein GP102 nicht die 732 GB/s eines PCIe P100, was er aber genau damit anfangen wuerde unter 3D momentan ist die Frage.

[Kriton]

GP100 mit 16 GB HBM2 im März:

https://www.golem.de/news/quadro-gp100-nvidia-steckt-schnellsten-chip-in-eine-workstation-karte-1702-126003.html

[iuno]

Schoen, also baut Samsung jetzt wohl 8Hi Stacks. Interessant finde ich auch die NVLink Bruecke.
Aber GP100 ist dort immer noch beschnitten. Die Teslas werden bestimmt auch noch aktualisiert werden, vielleicht kommt dort dann doch noch der Vollausbau.

[Gipsel]

Schoen, also baut Samsung jetzt wohl 8Hi Stacks.Das kann schon sein, allerdings sind die nicht auf der Karte. Vier 4Hi-Stacks sind genug für die 16GB. ;)

[iuno]

lol ist schon spaet :facepalm: :redface:
aber warum wird es dann noch herausgestellt?

[Godmode]

Schoen, also baut Samsung jetzt wohl 8Hi Stacks. Interessant finde ich auch die NVLink Bruecke.
Aber GP100 ist dort immer noch beschnitten. Die Teslas werden bestimmt auch noch aktualisiert werden, vielleicht kommt dort dann doch noch der Vollausbau.

Das mit der Brücke finde ich auch interessant, weil man hier doch öfters las, dass NVLink über eine Brücke eher unwahrscheinlich ist.

[Skysnake]

Ja das ist auch sehr erstaunlich, zumal die Tesla auch KEIN! NVLink besitzt bei der PCI-E Version.

Interessant wäre jetzt mal zu sehen, wie die Bridge aussieht und vor allem was sie auch kostet. Man braucht auf jeden Fall schon mal 2 davon für 80GB/s und man kann auch nur 2 Slots überbrücken.

Und selbst mit diesen zwei Brücken kann man gerade mal 2 von 6 NVLinks einer P100 mit der Mezzanine Karte benutzen. Da sieht man schon, dass das nicht ganz ohne ist. Mehr Brücken bekommste da nämlich auch nicht mehr wirklich gut unter.

EDIT:
Anandtech zeigt Bilder von den NVLink Kontakten: http://www.anandtech.com/show/11102/nvidia-announces-quadro-gp100

Das sieht schon ziemlich breit aus. Mit Glück würde man vielleicht noch einen dritten Link drauf bekommen, aber mehr is nicht.

[Complicated]

Mit der NVLink-Brücke kann Nvidia wenigstens die GPU<->GPU Kommunikation auch auf x86 Systemen nutzen, ohne den Support der CPU.

Ist allerdings schon etwas Unrund das ganze IMHO. Kaum Geschwindigkeitsvorteil und weniger VRAM als die P6000. Allerdings könnten hier mal Tests zeigen ob der geringere VRAM tatsächlich durch die höhere Bandbreite relativiert werden kann. In manchen Benches ist die Banbreite ja für schnellere Performance verantwortlich.

War hier vielleicht ursprünglich 8-Hi HBM2 geplant mit 32 GB? Wichtig natürlich hier die DP-Leistung, damit hebt sie sich sicherlich ab.

[y33H@]

32 GB waren mal geplant, ja.

[Troyan]

Mit der NVLink-Brücke kann Nvidia wenigstens die GPU<->GPU Kommunikation auch auf x86 Systemen nutzen, ohne den Support der CPU.

Nonsense. NVLink funktioniert immer unabhängig von der CPU zwischen Grafikkarten. :rolleyes:


Ist allerdings schon etwas Unrund das ganze IMHO.

P100 bietet mehr Bandbreite und mehr Speicher als Vega. Scheint ziemlich rund zu sein.

[Skysnake]

Mit der NVLink-Brücke kann Nvidia wenigstens die GPU<->GPU Kommunikation auch auf x86 Systemen nutzen, ohne den Support der CPU.

Ist allerdings schon etwas Unrund das ganze IMHO. Kaum Geschwindigkeitsvorteil und weniger VRAM als die P6000. Allerdings könnten hier mal Tests zeigen ob der geringere VRAM tatsächlich durch die höhere Bandbreite relativiert werden kann. In manchen Benches ist die Banbreite ja für schnellere Performance verantwortlich.

War hier vielleicht ursprünglich 8-Hi HBM2 geplant mit 32 GB? Wichtig natürlich hier die DP-Leistung, damit hebt sie sich sicherlich ab.

Ja, noch interessanter wäre aber noch, mal ein paar Games auf der P6000 und der GP100 laufen zu lassen. Ich befürchte, dass die GP100 nicht wirklich schneller sein wird. Das würde die Befürchtungen/Ansichten einiger hier bestätigen. Inkl meiner eigenen.

EDIT:
Troyan bist du dir da wirklich ganz sicher?

[Thunder99]

Eine Seite hatte das doch schon verglichen, meine ich :confused:

[Troyan]

Troyan bist du dir da wirklich ganz sicher?

Es funktioniert natürlich unabhängig von der Integration in der CPU. nVidias Pascalbox verwendet Intel-CPUs und verbindet alle 8 GPUs über NVLink.

Und ob Hynix in den nächsten zwei Monaten noch 8GB Stacks produzieren kann, ist fragwürdig. Die gezeigten Samples hatten nur 8GB und eine Bandbreite von maximal 512GB/s.

[Complicated]

Nonsense. NVLink funktioniert immer unabhängig von der CPU zwischen Grafikkarten.
Und wenn NvLink über PCIe 16x genauso schnell ist, warum hat man es dann erst erfunden? Du siehst schon warum eine PCIe GPU eine Extra Brücke braucht um SCHNELLER als der PCIe Bus zu sein, oder? Auch zwischen den beiden GPUs. Nonsens ist die Funktionsfähig zu bezweifeln wenn es um maximale Bandbreite geht - niemand hat gesagt es funktioniert nicht über PCIe, doch ist der Mehrwert dabei quasi nicht vorhanden. Wobei das ja Nvidia noch nie abgehalten hat wenn man GSync betrachtet.

[Skysnake]

Es funktioniert natürlich unabhängig von der Integration in der CPU. nVidias Pascalbox verwendet Intel-CPUs und verbindet alle 8 GPUs über NVLink.

Und ob Hynix in den nächsten zwei Monaten noch 8GB Stacks produzieren kann, ist fragwürdig. Die gezeigten Samples hatten nur 8GB und eine Bandbreite von maximal 512GB/s.
Der Treiber muss es auch unterstuetzen.

Da hatten wir aber aneinander vorbei geredet. Du meintest, dass das Interface nicht in der CPU sein muss.

[pixeljetstream]

Quadro GP100:
+ nvlink (2 links, pro link 40 GB/s)
+ double
+ HBM
+ 2x fp16
+ register file & SM verhältnis zu CUDA cores ist feiner
GP100: 256 KB pro SM mit 64 CUDA cores, 10 SM per GPC
GP10x: 256 KB pro SM mit 128 CUDA cores, 5 SM per GPC
- clock < Quadro P6000 (das wirkt sich auch auf alle fixed function units wie frontend, rasterizer usw. aus)
- weniger "CUDA cores" und texture units als Quadro P6000

Wenn die Pluspunkte relevant sind, kann die Karte ordentlich zulegen, aber dazu müssen diese Positionen auch wirklich durchgehend das bottleneck sein.

https://images.nvidia.com/content/pdf/tesla/whitepaper/pascal-architecture-whitepaper.pdf
http://international.download.nvidia.com/geforce-com/international/pdfs/GeForce_GTX_1080_Whitepaper_FINAL.pdf

[Niall]

Ich werfe mal die Benches der Chaosgroup Labs in die Runde.

Chaosgroup Labs Benchmarks (https://labs.chaosgroup.com/index.php/rendering-rd/v-ray-gpu-benchmarks-on-top-of-the-line-nvidia-gpus/)

GP100 x 2, GP100, P6000, P5000, P4000, M6000, Titan X (Pascal)

[Hübie]

Netto Bandbreite von NVLINK:

[root]# ./bandwidthTest --memory=pinned --device=0
[CUDA Bandwidth Test] - Starting...
Running on...

Device 0: Tesla P100-SXM2-16GB
Quick Mode

Host to Device Bandwidth, 1 Device(s)
PINNED Memory Transfers
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 33236.9

Device to Host Bandwidth, 1 Device(s)
PINNED Memory Transfers
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 32322.6

Device to Device Bandwidth, 1 Device(s)
PINNED Memory Transfers
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 448515.9

Result = PASS

[Screemer]

seh ich das richtig und es bleiben bei 4 Lanes mit P100 von den offiziellen 160GByte/s nur noch knapp 66 GByte/s dublex übrig mit NVlink 1? Wie kommen bitte 450GB/s Device->Device zustande?

[mksn7]

Das ist nur ein Device, Device->Device ist also ein Copy im VRAM. Deswegen die Bandbreite des HBM, was etwa hinkommt.

Es sind vielleicht nur zwei Links zwischen Host und Device.

[Hübie]

Es sind 80 hin und 80 zurück. Davon sind je zwei Cluster á 20 GB/s und je ein Cluster mit 40 GB/s wovon eben durchschnittlich 35 GB/s ankommen. 450 sind direkt über die Brücken auf kurze Distanz ohne CPU. Power9 bringt NVLINK 2.0 mit sich.

[Screemer]

Das ist nur ein Device, Device->Device ist also ein Copy im VRAM. Deswegen die Bandbreite des HBM, was etwa hinkommt.

Es sind vielleicht nur zwei Links zwischen Host und Device.
die p100 ist mit aber mit 160GB/s angegeben und sollte auch mit 4 Links laufen. Selbst wenn es 2 wären, dann sind das doch glatt mal ~20% unter den angegeben Werten von NV.

@hübi: von den 80gb/s in/out bleiben jeweils 35gb/s. was ist daran noch geclustert? verstehe den satz den du geschrieben hast grad nicht so ganz.

[Hübie]

die p100 ist mit aber mit 160GB/s angegeben und sollte auch mit 4 Links laufen. Selbst wenn es 2 wären, dann sind das doch glatt mal ~20% unter den angegeben Werten von NV.

@hübi: von den 80gb/s in/out bleiben jeweils 35gb/s. was ist daran noch geclustert? verstehe den satz den du geschrieben hast grad nicht so ganz.

Mit ie bitte, so viel Zeit muss sein. :smile:

Habe mich da wohl undeutlich ausgedrückt. Also ein Link besteht aus (2*20)+40 GB/s und auf jeder Seite können bidirektional Daten gesendet bzw empfangen werden. Von den 2*20 kommen 2*18 an, von den 40 sind 35 GB/s netto Datenrate. In der Summe also 71 von 80 GB/s.

[Screemer]

@hübie(sovielzeitmusssein): das lässt sich aus obigen Daten aber nicht ablesen. Laut spec von NV hat jeder link 20gbit und ist vollduplex. Davon gibts bei Tesla p100 4 Stück mit insg. 80gb/s. Warum soll das noch mal geclustert sein?

[Hübie]

Dann musst du mir wohl einfach glauben. :D Das Interface ist gesplittet. Es gibt so ein Bild wo man vier GPUs und zwei Power8 sieht, dass ganz gut veranschaulicht, warum es so geteilt ist.

[Entropy]

Netto Bandbreite von NVLINK:

[CODE]
Danke, das ist interesant mal Werte aus der Realität zu sehen!
Wie schnell ist das RAM auf dem system?

[Hübie]

Glaube 2666. Bin gerade beschäftigt. Kann dir das nachher sagen. In wie fern spielt der denn da rein (ernst gemeinte Frage)?

[mksn7]

450 sind direkt über die Brücken auf kurze Distanz ohne CPU. Power9 bringt NVLINK 2.0 mit sich.

Die Links zwischen zwei GPUs sind doch nicht schneller? Dass ist doch der Output von tool das im CUDA SDK dabei ist, oder? Bei Device-to-Device redet da eine einzelne GPU mit sich selbst, also copy im RAM.

Hier der Output vom gleichen Tool auf einer Maschine mit einer einzelenen K20m:

Device to Device Bandwidth, 1 Device(s)
PINNED Memory Transfers
Transfer Size (Bytes) Bandwidth(MB/s)
33554432 147871.1

Die 148GB/s sind genau das was man auf einer K20m mit ECC als Copy Bandbreite bekommt. Die 450GB/s haben also nichts mit NVLINK zu tun.


Dann musst du mir wohl einfach glauben. Das Interface ist gesplittet. Es gibt so ein Bild wo man vier GPUs und zwei Power8 sieht, dass ganz gut veranschaulicht, warum es so geteilt ist.

In dem Fall wäre eine übliche Konfiguration dass jede GPU einen Link zu jeder anderen GPU end einen zu einer CPU hat. Wieviele GPUs hatte das System, von dem die Messergebnisse sind?

Edit: Bei den samples ist auch 'topologyQuery' und 'p2pBandwidthLatencyTest' dabei. Die wären auch sehr interesant... p2pBandwidthLatencyTest spuckt so Sachen wie:

Bidirectional P2P=Enabled Bandwidth Matrix (GB/s)
D\D 0 1
0 149.03 10.45
1 10.44 149.06

Auch wieder ein System mit zwei K20m mit PCIe 2.0

[Hübie]

Ja zugegeben konnte ich den Wert nicht zuordnen und dachte dann wird halt hoch getaktet (dev-to-dev) oder es wird falsch gemessen. :D Was du da sagst ergibt aber mehr Sinn vor allem da mir nun auffällt dass es eine GPU war.

[mksn7]

Ok dann ist die p2pBandwidth matrix auch nicht so spannend...

[Skysnake]

Ach ne real hat man weniger Bandbreite als nvidia suggeriert...

Aber der interessante Teil fehlt. Schaut nämlich mal wie groß der Buffer ist. Das sind einige MB...

Schaut euch das mal bei KByte und ein paar Bytes an. DAS sind interessante Größen

[Hübie]

Ja als wäre es bei irgendeinem Protokoll anders. :rolleyes: Verstehe immer noch nicht warum stets vehement dagegen angehst wenn NV mal eine Lösung bringt. Das es nicht das Ultimo darstellt sollte doch klar sein, aber für die vielen kleinen HPCs im Hause von Unternehmen und Institutionen ist es besser als alles andere in puncto Flexibilität der Softwareanpassungen, Zugänglichkeit und Produktivität.

[Skysnake]

Wie gesagt messen mal die Bandbreite mit KByte und Byte für Pcie und nvlink dann sprechen wir nochmals drüber

[Skysnake]

Nach der neuen TOP500 und dem Update von PizDaint habe ich nochmals die Effizienzwerte ausgerechnet

Peak Efficiency:
alt: 61,16 %
neu: 77,35 %

Power Efficiency:
alt: 7,45 TFlops/kW
neu: 8,62 TFlops/kW

Das hat sich also beides deutlich verbessert. Da hat man wohl nochmals einiges an Arbeit reingesteckt, um die Peak-Efficiency zu steigern, wodurch man auch die Power Efficiency in der Regel steigern kann.

Bei der Peak-Efficiency ist man jetzt auch etwa im Bereich von den alten K20x Karten. Also kein Fail mehr, aber man hätte sich doch mehr versprochen. Zumal jetzt ja wirklich Zeit war den Code weiter zu optimieren für die Maschine. Wenn man bedenkt, was Pascal an Verbesserungen mitbringt, die eigentlich die Peak-Efficiency steigern sollten ist das irgendwie schon sehr ernüchternd....

Aber immerhin erreicht man wieder die Peak-Efficiency der alten Gen. :up:

[Hübie]

LINPACK ist hier eher das falsche Maß, da der Benchmark sehr auf DP-Performance geht. HPCG ist hier eher "the way to go":

HPCG exercises data movement to a much that greater extent than HPL, and is therefore much more challenging to the memory subsystem. And given that memory is often the bottleneck on modern supercomputers, HPCG can be much more indicative of real application performance. If you glance through the HPCG rankings, it’s immediately apparent the large difference between HPL and HPCG performance.

Quelle (https://www.top500.org/news/k-computer-comes-out-on-top-in-hpcg-supercomputing-benchmark/)

GK110 stand da ziemlich gut im Linpack da, weil genügend DP-Performance vorhanden ist. Aufgrund des relativ stagnierenden Bedarfs an FP64 ist eben die HPL-Performance auch nicht in dem Maße angestiegen, wie man es erwartet. Setz dich mal an so eine Kist von damals mit CX30 und nun die CX50 mit dem gleichen workload...

Klar CUDA macht hier auch noch mal was aus, daher ist ein direkter Vergleich schwierig. Deine Papierrechnerei in Ehren, aber ist nicht so relevant. :D

[Skysnake]

Das ist durchaus relevant, weil man nicht nur durch das Geld limitiert ist, welches man ausgeben kann, um die Kisten zu kaufen, man muss auch genug Geld für den Betrieb haben, also Kühlung usw. Und es gibt auch immer wieder sites, bei denen es halt keine Option ist, x MW mehr an Anschlussleistung bereit zu stellen, damit der nächste Rechner halt größer wird....

Und das DP an Relevanz verloren hat, würde ich definitiv nicht sagen. Ich habe noch keinen Code ausm HPC-Bereich gesehen, der nicht praktisch ausschließlich auf FP64 setzt.

Das es bei dem ganzen DeepLearning etc geraffel anders aussieht, von mir aus. Aber das generiert im HPC-Umfeld nicht DIE Nodestunden....

Wenn du dir mal anschaust, wofür die Förderung in PRACE etc raus geht, dann kannste dir eigentlich recht sicher sein, dass das alles mit FP64 läuft.

Fragt sich also, wer da an der Realität vorbei plant/schaut.

PS: Bei Google, Amazon, Fracebook etc. kann es GANZ anders aussehen, aber im HPC Bereich, für den die TOP500 relevant sind, ist es eben NICHT so.
PPS: Der HPCG testet halt mehr die Speicherbandbreite als die Peak Flops. Oder war es der Graph500 der am ende vom Tag mehr oder weniger ein Stream benchmark ist? Erinnere mich gerade nicht mehr.

[Hübie]

Ich sagte es stagniert. Steht sogar da. Fast jeder workload fordert es, aber es steigt nicht signifikant an. Zumindest nicht bis Anfang 2016.

[dildo4u]

Introducing faster GPUs for Google Compute Engine P100/K80


https://cloudplatform.googleblog.com/2017/09/introducing-faster-GPUs-for-Google-Compute-Engine.html