-
Ergibt 512GByte/s
Autor: HubertHans 19.05.15 - 16:35
Da sollte ein "theoretisch" davor stehen. In der Praxis setzen die Timings enge Grenzen. Da werden 512GByte/s schnell zur Haelfte oder vielleicht etwas mehr im Schnitt. Aber 512Gbyte erreicht man garantiert nicht pro Sekunde.
-
Re: Ergibt 512GByte/s
Autor: ms (Golem.de) 19.05.15 - 16:45
Das sind immer theoretische "up to"-Werte und zudem diverse Kompressionstechniken die effektive Bandbreite erhöhen.
Marc Sauter, Sr Editor
Golem.de -
Re: Ergibt 512GByte/s
Autor: Dhakra 19.05.15 - 16:45
HubertHans schrieb:
--------------------------------------------------------------------------------
> Da sollte ein "theoretisch" davor stehen. In der Praxis setzen die Timings
> enge Grenzen. Da werden 512GByte/s schnell zur Haelfte oder vielleicht
> etwas mehr im Schnitt. Aber 512Gbyte erreicht man garantiert nicht pro
> Sekunde.
Muss man das extra schreiben? Bei einer Karte wo es noch keinerlei offiziellen Praxiswerte gibt, ist das wohl logisch. -
Re: Ergibt 512GByte/s
Autor: Allandor 19.05.15 - 16:51
HubertHans schrieb:
--------------------------------------------------------------------------------
> Da sollte ein "theoretisch" davor stehen. In der Praxis setzen die Timings
> enge Grenzen. Da werden 512GByte/s schnell zur Haelfte oder vielleicht
> etwas mehr im Schnitt. Aber 512Gbyte erreicht man garantiert nicht pro
> Sekunde.
verglichen mit z.B. 200-250GB/s einer heutigen Grafikkarte ist es nach wie vor sehr viel mehr Bandbreite. Zudem dürften die Timings sogar besser sein und die latenzen aufgrund der kürzeren Wege niedriger. Also effektiv dürften von den 500GB/s mehr nutzbar sein als theoretische 500GB/s auf die alte externe Weise. -
Re: Ergibt 512GByte/s
Autor: TheBigLou13 19.05.15 - 17:24
Dhakra schrieb:
--------------------------------------------------------------------------------
> HubertHans schrieb:
> ---------------------------------------------------------------------------
> -----
> > Da sollte ein "theoretisch" davor stehen. In der Praxis setzen die
> Timings
> > enge Grenzen. Da werden 512GByte/s schnell zur Haelfte oder vielleicht
> > etwas mehr im Schnitt. Aber 512Gbyte erreicht man garantiert nicht pro
> > Sekunde.
>
> Muss man das extra schreiben? Bei einer Karte wo es noch keinerlei
> offiziellen Praxiswerte gibt, ist das wohl logisch.
Wenn man eh nichts dazu schreiben muss weil sie noch nicht draußen ist, kam man sich auch den ganzen Artikel sparen oder was? Natürlich sollte man ALLES erwähnen was relevant ist - dazu sind Nachrichten/Intormationen da. -
Re: Ergibt 512GByte/s
Autor: bla 19.05.15 - 23:38
Allandor schrieb:
--------------------------------------------------------------------------------
> verglichen mit z.B. 200-250GB/s einer heutigen Grafikkarte ist es nach wie
> vor sehr viel mehr Bandbreite. Zudem dürften die Timings sogar besser sein
> und die latenzen aufgrund der kürzeren Wege niedriger. Also effektiv
> dürften von den 500GB/s mehr nutzbar sein als theoretische 500GB/s auf die
> alte externe Weise.
Die Latenz aufgrund der Leitungslänge ist so gut wie vernachlässigbar.
Eletronen benötigen ca. 100ps um eine 2cm lange Leitung zu durchlaufen.
Bei einer längeren Leitung dauert es natürlich länger aber aufgrund des Wellencharakters des zu übertragenen Signals, ist das wie gesagt vernachlässigbar.
Um z.B. eine möglichst hohe Schaltgeschwindigkeit zu erreichen sind die Rise- und Fall-Times viel wichtiger.
Selbst Leitungslaufzeiten von 1ns (20cm lange Leitung) spielen keine Rolle.
Sind die Leitungen kürzer, dann fallen natürlich auch die parasitären Effekte niedriger aus. GDDR5 hatte aber nie das Problem niedriger Schaltgeschwindigkeiten. 7Gbit/s sind pro Leitung heute locker möglich. HBM wird zuerst wohl nur mit 1Gbit/s pro Leitung arbeiten. Interessant ist also, das man durch die kürzeren Leitungen, niedrigere Schaltgeschwindigkeiten und der niedrigeren Spannung weniger elektrische Leistung in den Leitungen verbräht.
Das HBM bei 4 Stacks mit 4096 Bit an die GPU angeschlossen ist, wirkt sich natürlich positiv auf die Übertragungsgeschwindigkeit aus. -
Re: Ergibt 512GByte/s
Autor: sg-1 20.05.15 - 01:09
TheBigLou13 schrieb:
>
> ...Natürlich sollte man
> ALLES erwähnen was relevant ist - dazu sind >Nachrichten/Intormationen da.
OT:
Sag das mal einschlägigen Medien,dass bei Nachrichten nicht nur einseitig berichtet werden darf,oder infos weggelassen werden, damit ein gewünschtes Bild entsteht bzw. suggeriert wird... -
Re: Ergibt 512GByte/s
Autor: HubertHans 20.05.15 - 08:18
bla schrieb:
--------------------------------------------------------------------------------
> Allandor schrieb:
> ---------------------------------------------------------------------------
> -----
> > verglichen mit z.B. 200-250GB/s einer heutigen Grafikkarte ist es nach
> wie
> > vor sehr viel mehr Bandbreite. Zudem dürften die Timings sogar besser
> sein
> > und die latenzen aufgrund der kürzeren Wege niedriger. Also effektiv
> > dürften von den 500GB/s mehr nutzbar sein als theoretische 500GB/s auf
> die
> > alte externe Weise.
>
> Die Latenz aufgrund der Leitungslänge ist so gut wie vernachlässigbar.
> Eletronen benötigen ca. 100ps um eine 2cm lange Leitung zu durchlaufen.
> Bei einer längeren Leitung dauert es natürlich länger aber aufgrund des
> Wellencharakters des zu übertragenen Signals, ist das wie gesagt
> vernachlässigbar.
> Um z.B. eine möglichst hohe Schaltgeschwindigkeit zu erreichen sind die
> Rise- und Fall-Times viel wichtiger.
> Selbst Leitungslaufzeiten von 1ns (20cm lange Leitung) spielen keine
> Rolle.
>
> Sind die Leitungen kürzer, dann fallen natürlich auch die parasitären
> Effekte niedriger aus. GDDR5 hatte aber nie das Problem niedriger
> Schaltgeschwindigkeiten. 7Gbit/s sind pro Leitung heute locker möglich. HBM
> wird zuerst wohl nur mit 1Gbit/s pro Leitung arbeiten. Interessant ist
> also, das man durch die kürzeren Leitungen, niedrigere
> Schaltgeschwindigkeiten und der niedrigeren Spannung weniger elektrische
> Leistung in den Leitungen verbräht.
> Das HBM bei 4 Stacks mit 4096 Bit an die GPU angeschlossen ist, wirkt sich
> natürlich positiv auf die Übertragungsgeschwindigkeit aus.
Natuerlich. Auf magische Weise reagiert RAM nun in Echtzeit und es treten keinerlei Latenzen auf. Ich frage mich langsam ob die Leute glauben, was sie da so alles schreiben. RAM hat Zugriffszeiten. Ende! Aus! Und die werden nicht durch magische Weise schneller, nur weils gestapelt wird und der Speichercontroller und der RAM enger zusammen sitzt. Solange SDRAM auf Refreshzyklen und wartezyklen fuer den Zugriff/ Auslesen und den Refresh basiert, sind es eben viele Nanosekunden, die floeten gehen. (Auch wenn auf dem Chip nur wenige Nanosekunden gelabelt sind, sind es real am Ende der Kette viel mehr. typischerweise das 10 Fache, mindestens. Speichercontroller & Co reagieren naemlich auch nciht in Echtzeit, sondern haben auch Wartezyklen) Das diese Art von Speicher auch eher auf Bandbreite optimiert ist, scheint auch keiner gecheckt zu haben. Die Kompression hilft auch nur, die verfuegbare Speicherbandbreite besser auszureizen. mehr nicht. Es wird nicht durch magische Weise auf einmal mehr, was physikalisch uebertragen wird. Also eben keine 512Gbyte/s. Und ja, das ist wichtig das zu erwaehnen. Denn die Angaben auf Arbeitsspeicher/ RAM allgemein sind rein theoretische "Bis zu" Werte. Weil man die Timings einfach weglaesst. Das nennt sich "Schoenen"
Und wo hast du bitte die 4096Bit her? Sry, aber so laeuft der Hase da nicht. Es sind 256Bit pro Stapel. Und 4096 wirst du so schnell nicht sehen. Die Grenzen werden sich wohl schon bei 2048Bit auftun. Denn alleine 4096 leitungen fuer den Speicher, dann noch die Anbindungen zum PCIe-BUS sowie die Grafikkartenausgaenge >> Das wird echt teuer...
4 mal bearbeitet, zuletzt am 20.05.15 08:25 durch HubertHans. -
Re: Ergibt 512GByte/s
Autor: naxus 20.05.15 - 08:47
> Die Latenz aufgrund der Leitungslänge ist so gut wie vernachlässigbar.
> Eletronen benötigen ca. 100ps um eine 2cm lange Leitung zu durchlaufen.
> Bei einer längeren Leitung dauert es natürlich länger aber aufgrund des
> Wellencharakters des zu übertragenen Signals, ist das wie gesagt
> vernachlässigbar.
> Um z.B. eine möglichst hohe Schaltgeschwindigkeit zu erreichen sind die
> Rise- und Fall-Times viel wichtiger.
> Selbst Leitungslaufzeiten von 1ns (20cm lange Leitung) spielen keine
> Rolle.
Falsch! Die Zeit und der Weg spielen eine entscheidene Rolle...
In den Bereichen in den sich die Takte heute bewegen kommt es auf jeden hundertsten
Millimeter an!! Als Beispiel, die aktuelle NV 970 hat einen Speichertakt von 3,5Ghz, das heißt zwischen zwei takten vergehen 0.28571 Nano sekunden. Desweiteren hast du dich verrechnet in Kupfer schaffen Elektronen 1cm/ns in leiterbahnen auf PC Platinen.
Denach schaffen die Elektronen bei einem Taktzyklus nur noch 2,8571 mm auf der Leiterplatine. Jetzt wisst ihr auch warum es bei PCs zu Bluescreens kommt wenn ihr zu viel am Ram takt der CPU schraubt, da schlichtweg ein bit zu spät ankommt. Gleiches bei einer Grafik karte, da kommt es im einzelfall zu pixelfehlern bis hin zum Grafikcrash.
lg
Naxus
1 mal bearbeitet, zuletzt am 20.05.15 08:49 durch naxus. -
Re: Ergibt 512GByte/s
Autor: ms (Golem.de) 20.05.15 - 10:13
Es sind 256 Bit pro DRAM-Chip, also 1024 pro Stack und ergo 4096 bei vier Stapeln (GPU-seitig).
Marc Sauter, Sr Editor
Golem.de -
Re: Ergibt 512GByte/s
Autor: TheSUNSTAR 20.05.15 - 11:09
HubertHans schrieb:
--------------------------------------------------------------------------------
> bla schrieb:
> ---------------------------------------------------------------------------
> -----
> > Allandor schrieb:
> >
> ---------------------------------------------------------------------------
>
> > -----
> > > verglichen mit z.B. 200-250GB/s einer heutigen Grafikkarte ist es nach
> > wie
> > > vor sehr viel mehr Bandbreite. Zudem dürften die Timings sogar besser
> > sein
> > > und die latenzen aufgrund der kürzeren Wege niedriger. Also effektiv
> > > dürften von den 500GB/s mehr nutzbar sein als theoretische 500GB/s auf
> > die
> > > alte externe Weise.
> >
> > Die Latenz aufgrund der Leitungslänge ist so gut wie vernachlässigbar.
> > Eletronen benötigen ca. 100ps um eine 2cm lange Leitung zu durchlaufen.
> > Bei einer längeren Leitung dauert es natürlich länger aber aufgrund des
> > Wellencharakters des zu übertragenen Signals, ist das wie gesagt
> > vernachlässigbar.
> > Um z.B. eine möglichst hohe Schaltgeschwindigkeit zu erreichen sind die
> > Rise- und Fall-Times viel wichtiger.
> > Selbst Leitungslaufzeiten von 1ns (20cm lange Leitung) spielen keine
> > Rolle.
> >
> > Sind die Leitungen kürzer, dann fallen natürlich auch die parasitären
> > Effekte niedriger aus. GDDR5 hatte aber nie das Problem niedriger
> > Schaltgeschwindigkeiten. 7Gbit/s sind pro Leitung heute locker möglich.
> HBM
> > wird zuerst wohl nur mit 1Gbit/s pro Leitung arbeiten. Interessant ist
> > also, das man durch die kürzeren Leitungen, niedrigere
> > Schaltgeschwindigkeiten und der niedrigeren Spannung weniger elektrische
> > Leistung in den Leitungen verbräht.
> > Das HBM bei 4 Stacks mit 4096 Bit an die GPU angeschlossen ist, wirkt
> sich
> > natürlich positiv auf die Übertragungsgeschwindigkeit aus.
>
> Natuerlich. Auf magische Weise reagiert RAM nun in Echtzeit und es treten
> keinerlei Latenzen auf. Ich frage mich langsam ob die Leute glauben, was
> sie da so alles schreiben. RAM hat Zugriffszeiten. Ende! Aus! Und die
> werden nicht durch magische Weise schneller, nur weils gestapelt wird und
> der Speichercontroller und der RAM enger zusammen sitzt. Solange SDRAM auf
> Refreshzyklen und wartezyklen fuer den Zugriff/ Auslesen und den Refresh
> basiert, sind es eben viele Nanosekunden, die floeten gehen. (Auch wenn auf
> dem Chip nur wenige Nanosekunden gelabelt sind, sind es real am Ende der
> Kette viel mehr. typischerweise das 10 Fache, mindestens.
> Speichercontroller & Co reagieren naemlich auch nciht in Echtzeit, sondern
> haben auch Wartezyklen) Das diese Art von Speicher auch eher auf Bandbreite
> optimiert ist, scheint auch keiner gecheckt zu haben. Die Kompression hilft
> auch nur, die verfuegbare Speicherbandbreite besser auszureizen. mehr
> nicht. Es wird nicht durch magische Weise auf einmal mehr, was physikalisch
> uebertragen wird. Also eben keine 512Gbyte/s. Und ja, das ist wichtig das
> zu erwaehnen. Denn die Angaben auf Arbeitsspeicher/ RAM allgemein sind rein
> theoretische "Bis zu" Werte. Weil man die Timings einfach weglaesst. Das
> nennt sich "Schoenen"
Latenz und Bandbreite sind doch aber zweierlei. Nur weil der Latenz physikalische Grenzen gesetzt sind heißt es nicht das diese sofort die Bandbreite begrenzt. Bei den 1,75GHz des DRAMs von den Folien schafft es Licht in einem Takt gerade mal 17cm weit, da braucht es also bei den großen Grafik-Speicher Anordnungen schon alleine einen "virtuellen" Takt bis ein Signal vom DRAM Chip zum GPU-Speichercontroler gewandert ist. Das ändert aber nichts daran das bei einmal angeschobenem Transfer die Bits dann schön mit jedem Takt reinpurzeln, und das ist wichtig um die Rechenwerke mit Daten zu füttern.
Die GPU-Architekturen selbst sind ja von Grund auf darauf ausgelegt Latenzen beim Speicherzugriff durch das Vorhalten unzähliger Threads zu überspielen. Wenn eine parallele Thread-Gruppe (32 Threads eines CUDA-Warps) Daten vom Grafikspeicher benötigt, was enorm viele Takte braucht, dann geht die Gruppe schlafen bis die Daten da sind und eine andere, deren Daten eingetroffen sind, kann stattdessen die Rechenwerke nutzen und weitermachen. Riesige Registerfiles machen es möglich. Müssen halt nur genug Thread-Gruppen da sein um einerseits jemanden zum Rechnen zu haben und anderseits genug das dem Speichercontroller nicht langweilig wird.
> Und wo hast du bitte die 4096Bit her? Sry, aber so laeuft der Hase da
> nicht. Es sind 256Bit pro Stapel. Und 4096 wirst du so schnell nicht sehen.
> Die Grenzen werden sich wohl schon bei 2048Bit auftun. Denn alleine 4096
> leitungen fuer den Speicher, dann noch die Anbindungen zum PCIe-BUS sowie
> die Grafikkartenausgaenge >> Das wird echt teuer...
Es sind wirklich 4096 Bit, 4x256Bit/Speicherchip*4 Stapel/GPU. Die Breite dieses Interfaces hat aber mit dem PCIe-BUS nichts zu tun, der wird nach wie vor mit seinem "Mini-Interface" mit dem Speichercontroller der GPU (oder des Interposers?) als Brückeninstanz kommunizieren.
Viel mehr stellt sich mir die Frage wie flexibel dieses breite Speicherinterface eigentlich ist. Bei NVIDIA kann ja eine Transaktion zwischen Speicher und GPU bis zu 128 Byte transportieren, was bezüglich der Bandbreite wohl das Optimum ist. 32 Byte gehen auch, nur dauern das eben wohl genauso lange.
-> wirkt sich das bei AMD auf den Coalesced Memory Access aus? Muss man da nun optimalerweise 512 Byte mit seiner Thread-Gruppe lesen? Bei einer Gruppengröße von 32 Threads wären das 16 Byte / Thread... Werden ggf. die Gruppen größer oder kann der Speichercontroller auch parallel mehrere 128 Byte Bereiche lesen oder machen die das eh ganz anders? -
Re: Ergibt 512GByte/s
Autor: HubertHans 20.05.15 - 11:43
TheSUNSTAR schrieb:
--------------------------------------------------------------------------------
> HubertHans schrieb:
> ---------------------------------------------------------------------------
> -----
> > bla schrieb:
> >
> ---------------------------------------------------------------------------
>
> > -----
> > > Allandor schrieb:
> > >
> >
> ---------------------------------------------------------------------------
>
> >
> > > -----
> > > > verglichen mit z.B. 200-250GB/s einer heutigen Grafikkarte ist es
> nach
> > > wie
> > > > vor sehr viel mehr Bandbreite. Zudem dürften die Timings sogar
> besser
> > > sein
> > > > und die latenzen aufgrund der kürzeren Wege niedriger. Also effektiv
> > > > dürften von den 500GB/s mehr nutzbar sein als theoretische 500GB/s
> auf
> > > die
> > > > alte externe Weise.
> > >
> > > Die Latenz aufgrund der Leitungslänge ist so gut wie vernachlässigbar.
> > > Eletronen benötigen ca. 100ps um eine 2cm lange Leitung zu
> durchlaufen.
> > > Bei einer längeren Leitung dauert es natürlich länger aber aufgrund
> des
> > > Wellencharakters des zu übertragenen Signals, ist das wie gesagt
> > > vernachlässigbar.
> > > Um z.B. eine möglichst hohe Schaltgeschwindigkeit zu erreichen sind
> die
> > > Rise- und Fall-Times viel wichtiger.
> > > Selbst Leitungslaufzeiten von 1ns (20cm lange Leitung) spielen keine
> > > Rolle.
> > >
> > > Sind die Leitungen kürzer, dann fallen natürlich auch die parasitären
> > > Effekte niedriger aus. GDDR5 hatte aber nie das Problem niedriger
> > > Schaltgeschwindigkeiten. 7Gbit/s sind pro Leitung heute locker
> möglich.
> > HBM
> > > wird zuerst wohl nur mit 1Gbit/s pro Leitung arbeiten. Interessant ist
> > > also, das man durch die kürzeren Leitungen, niedrigere
> > > Schaltgeschwindigkeiten und der niedrigeren Spannung weniger
> elektrische
> > > Leistung in den Leitungen verbräht.
> > > Das HBM bei 4 Stacks mit 4096 Bit an die GPU angeschlossen ist, wirkt
> > sich
> > > natürlich positiv auf die Übertragungsgeschwindigkeit aus.
> >
> > Natuerlich. Auf magische Weise reagiert RAM nun in Echtzeit und es
> treten
> > keinerlei Latenzen auf. Ich frage mich langsam ob die Leute glauben, was
> > sie da so alles schreiben. RAM hat Zugriffszeiten. Ende! Aus! Und die
> > werden nicht durch magische Weise schneller, nur weils gestapelt wird
> und
> > der Speichercontroller und der RAM enger zusammen sitzt. Solange SDRAM
> auf
> > Refreshzyklen und wartezyklen fuer den Zugriff/ Auslesen und den Refresh
> > basiert, sind es eben viele Nanosekunden, die floeten gehen. (Auch wenn
> auf
> > dem Chip nur wenige Nanosekunden gelabelt sind, sind es real am Ende der
> > Kette viel mehr. typischerweise das 10 Fache, mindestens.
> > Speichercontroller & Co reagieren naemlich auch nciht in Echtzeit,
> sondern
> > haben auch Wartezyklen) Das diese Art von Speicher auch eher auf
> Bandbreite
> > optimiert ist, scheint auch keiner gecheckt zu haben. Die Kompression
> hilft
> > auch nur, die verfuegbare Speicherbandbreite besser auszureizen. mehr
> > nicht. Es wird nicht durch magische Weise auf einmal mehr, was
> physikalisch
> > uebertragen wird. Also eben keine 512Gbyte/s. Und ja, das ist wichtig
> das
> > zu erwaehnen. Denn die Angaben auf Arbeitsspeicher/ RAM allgemein sind
> rein
> > theoretische "Bis zu" Werte. Weil man die Timings einfach weglaesst. Das
> > nennt sich "Schoenen"
>
> Latenz und Bandbreite sind doch aber zweierlei. Nur weil der Latenz
> physikalische Grenzen gesetzt sind heißt es nicht das diese sofort die
> Bandbreite begrenzt. Bei den 1,75GHz des DRAMs von den Folien schafft es
> Licht in einem Takt gerade mal 17cm weit, da braucht es also bei den großen
> Grafik-Speicher Anordnungen schon alleine einen "virtuellen" Takt bis ein
> Signal vom DRAM Chip zum GPU-Speichercontroler gewandert ist. Das ändert
> aber nichts daran das bei einmal angeschobenem Transfer die Bits dann schön
> mit jedem Takt reinpurzeln, und das ist wichtig um die Rechenwerke mit
> Daten zu füttern.
> Die GPU-Architekturen selbst sind ja von Grund auf darauf ausgelegt
> Latenzen beim Speicherzugriff durch das Vorhalten unzähliger Threads zu
> überspielen. Wenn eine parallele Thread-Gruppe (32 Threads eines
> CUDA-Warps) Daten vom Grafikspeicher benötigt, was enorm viele Takte
> braucht, dann geht die Gruppe schlafen bis die Daten da sind und eine
> andere, deren Daten eingetroffen sind, kann stattdessen die Rechenwerke
> nutzen und weitermachen. Riesige Registerfiles machen es möglich. Müssen
> halt nur genug Thread-Gruppen da sein um einerseits jemanden zum Rechnen zu
> haben und anderseits genug das dem Speichercontroller nicht langweilig
> wird.
>
> > Und wo hast du bitte die 4096Bit her? Sry, aber so laeuft der Hase da
> > nicht. Es sind 256Bit pro Stapel. Und 4096 wirst du so schnell nicht
> sehen.
> > Die Grenzen werden sich wohl schon bei 2048Bit auftun. Denn alleine 4096
> > leitungen fuer den Speicher, dann noch die Anbindungen zum PCIe-BUS
> sowie
> > die Grafikkartenausgaenge >> Das wird echt teuer...
> Es sind wirklich 4096 Bit, 4x256Bit/Speicherchip*4 Stapel/GPU. Die Breite
> dieses Interfaces hat aber mit dem PCIe-BUS nichts zu tun, der wird nach
> wie vor mit seinem "Mini-Interface" mit dem Speichercontroller der GPU
> (oder des Interposers?) als Brückeninstanz kommunizieren.
> Viel mehr stellt sich mir die Frage wie flexibel dieses breite
> Speicherinterface eigentlich ist. Bei NVIDIA kann ja eine Transaktion
> zwischen Speicher und GPU bis zu 128 Byte transportieren, was bezüglich der
> Bandbreite wohl das Optimum ist. 32 Byte gehen auch, nur dauern das eben
> wohl genauso lange.
> -> wirkt sich das bei AMD auf den Coalesced Memory Access aus? Muss man da
> nun optimalerweise 512 Byte mit seiner Thread-Gruppe lesen? Bei einer
> Gruppengröße von 32 Threads wären das 16 Byte / Thread... Werden ggf. die
> Gruppen größer oder kann der Speichercontroller auch parallel mehrere 128
> Byte Bereiche lesen oder machen die das eh ganz anders?
Tut mir leid es sagen zu muessen, aber du hast keine Ahnung.
Die Latenz bestimmt maßgeblich, wie hoch die maximal erzielbare Datenrate ist. Die 512GByte/s Angabe hier laesst die Zugriffszeiten komplett ausser Acht. Und auch wenn ein Burst Zugriff die Volle geschwindigkeit liefert, besteimmt die Latenz, wie oft so ein burst-Zugriff pro Sekunde ueberhaupt erfolgen kann. Die Pausen dazwischen druecken die Datenrate herunter. Latenz und Takt/ Busbreite/ Prefetch-Tiefe beeinflussen sich maßgeblich. Das die Hersteller immer gerne die Latenz aussen vorlassen (Wir reden hier ja noch nicht mal vom verwerfen nicht benoetigter Daten bei den genutzten prefetch-Tiefen welche erst einmal keine Rolle spielen) zeigt eben genau das. ist genauso wie Spannung und Stromsdtaerke. Beide Faktoren haengen zusammmen. Je niedriger die Latenz, umso naeher kommt man dem theoretisch Moeglichen, in diesem Fall 512Gbyte. Und da kannst du diskutieren wie du willst. Es ist untrennbar.
UND NEIN, ES SIND 1024Bit! LESEN! 4 mal 256 == 1024. Das schreibt ATI auch selber. Und das mit PCIe und Grafikausgaengen war auf die GPU selbst bezogen. Schon mal nen Sockel mit mehr als 4500 Pins gesehen? Ich glaube da bekommst du massiv Schwieriigkeiten... -
Re: Ergibt 512GByte/s
Autor: HubertHans 20.05.15 - 11:44
ms (Golem.de) schrieb:
--------------------------------------------------------------------------------
> Es sind 256 Bit pro DRAM-Chip, also 1024 pro Stack und ergo 4096 bei vier
> Stapeln (GPU-seitig).
Nein. Nach aussen hin bleiben es 256! Die Busbreite wird nicht durch Magie einfach so breiter!
Deswegen reden die auch von Channels! 8 x 128b
3 mal bearbeitet, zuletzt am 20.05.15 11:47 durch HubertHans. -
Re: Ergibt 512GByte/s
Autor: bla 20.05.15 - 12:59
@ HubertHans und @naxus:
Ich habe mich auf die Latenzen der Leitungen bezogen, die vorher erwähnt wurden und nicht auf die DRAM-typischen Latenzen.
Lustigerweise kann man ein Signal in eine Leitung schicken und während das Signal noch nicht am Ende der Leitung angekommen ist, ein neues Signal auf die Leitung geben.
Die Leitung darf natürlich nicht so lang sein, dass die parasitären Effekte das Signal so stark abschwächen, dass die Eingangspuffer auf der Empfangsseite nicht mehr schnell genug umschalten können.
Für die Elektronengeschwindigkeit hatte ich einen Verkürzungsfaktor von 2/3 angenommen, um die Rechnung etwas zu vereinfachen. -
Re: Ergibt 512GByte/s
Autor: bla 20.05.15 - 13:05
HubertHans schrieb:
--------------------------------------------------------------------------------
> ms (Golem.de) schrieb:
> ---------------------------------------------------------------------------
> -----
> > Es sind 256 Bit pro DRAM-Chip, also 1024 pro Stack und ergo 4096 bei
> vier
> > Stapeln (GPU-seitig).
>
> Nein. Nach aussen hin bleiben es 256! Die Busbreite wird nicht durch Magie
> einfach so breiter!
>
> Deswegen reden die auch von Channels! 8 x 128b
Guck dir das doch nochmal genauer an.
Ein Stapel bestehend aus 4 Chips besitzt laut Folie einen 1024Bit breiten Bus.
1024Bit sind 128Byte. 128Byte mal 1Gbps ergibt 128GByte/s Bandbreite pro Stapel.
Bei 4 Stapeln würde das eine maximale theoretische Bandbreite von 512GByte/s ergeben. -
Re: Ergibt 512GByte/s
Autor: TheSUNSTAR 20.05.15 - 13:24
HubertHans schrieb:
--------------------------------------------------------------------------------
> Die Latenz bestimmt maßgeblich, wie hoch die maximal erzielbare Datenrate
> ist. Die 512GByte/s Angabe hier laesst die Zugriffszeiten komplett ausser
> Acht. Und auch wenn ein Burst Zugriff die Volle geschwindigkeit liefert,
> besteimmt die Latenz, wie oft so ein burst-Zugriff pro Sekunde ueberhaupt
> erfolgen kann. Die Pausen dazwischen druecken die Datenrate herunter.
> Latenz und Takt/ Busbreite/ Prefetch-Tiefe beeinflussen sich maßgeblich.
> Das die Hersteller immer gerne die Latenz aussen vorlassen (Wir reden hier
> ja noch nicht mal vom verwerfen nicht benoetigter Daten bei den genutzten
> prefetch-Tiefen welche erst einmal keine Rolle spielen) zeigt eben genau
> das. ist genauso wie Spannung und Stromsdtaerke. Beide Faktoren haengen
> zusammmen. Je niedriger die Latenz, umso naeher kommt man dem theoretisch
> Moeglichen, in diesem Fall 512Gbyte. Und da kannst du diskutieren wie du
> willst. Es ist untrennbar.
Ich denke aktueller GDDR Speicher ist "quasi" Dual Port Memory um zwei parallele Speicheroperationen durchzuführen, also während der Burst-Response den zweiten Zugriff vorzubereiten, sodass dieser beinahe nahtlos an den laufenden Burst anschließen kann, sobald dieser eben fertig ist?
Sofern der Burst also länger ist als die Latenz sollte man doch, bissel Overhead außen vor, die Speicherbandbreite tatsächlich ganz gut ausreizen können. Dafür sprechen doch auch die CUDA Optimization Guides, da wird die Peak-Bandwidth doch auch zu (glaube) 91% erreicht. So fatal ist das also kaum...
> UND NEIN, ES SIND 1024Bit! LESEN! 4 mal 256 == 1024. Das schreibt ATI auch
> selber. Und das mit PCIe und Grafikausgaengen war auf die GPU selbst
> bezogen. Schon mal nen Sockel mit mehr als 4500 Pins gesehen? Ich glaube da
> bekommst du massiv Schwieriigkeiten...
Du musst es nicht nur lesen sondern auch noch den Text verstehen. Ein HBM Stapel hat ein 1024 Bit Interface (siehe Folie 9), und 4 von denen sind an der GPU angebunden, was auch erstmal gar nichts mit PCIe zu tun hat. Es wird auch nirgends behauptet das es da irgendwo einen Sockel mit 4500 Pins gibt, diese unzähligen Datenleitungen bleiben doch im Interposer, sind lediglich eine Direktverbindung zwischen Speicherstapel und GPU-Die (wo der Controller drin liegt). Der Sockel von dem gesamten Ding wird dann sogar viel weniger Pins als früher haben (die DDR-Leitungen fallen nun ja weg), das ist ja nun fast nur noch das Interface zum PCIe-Bus. -
Re: Ergibt 512GByte/s
Autor: HubertHans 20.05.15 - 13:25
bla schrieb:
--------------------------------------------------------------------------------
> HubertHans schrieb:
> ---------------------------------------------------------------------------
> -----
> > ms (Golem.de) schrieb:
> >
> ---------------------------------------------------------------------------
>
> > -----
> > > Es sind 256 Bit pro DRAM-Chip, also 1024 pro Stack und ergo 4096 bei
> > vier
> > > Stapeln (GPU-seitig).
> >
> > Nein. Nach aussen hin bleiben es 256! Die Busbreite wird nicht durch
> Magie
> > einfach so breiter!
> >
> > Deswegen reden die auch von Channels! 8 x 128b
>
> Guck dir das doch nochmal genauer an.
> Ein Stapel bestehend aus 4 Chips besitzt laut Folie einen 1024Bit breiten
> Bus.
> 1024Bit sind 128Byte. 128Byte mal 1Gbps ergibt 128GByte/s Bandbreite pro
> Stapel.
> Bei 4 Stapeln würde das eine maximale theoretische Bandbreite von
> 512GByte/s ergeben.
So ist er intern verschaltet. Das habe ich jetzt auch noch mal genauer gelesen. Das war an einigen Stellen im Netz zu dem Speicher nicht gerade offensichtlich zu sehen. Trotzdem waere ich mit 1024Bit pro Stapel vorsichtig. Ich denke das es sich auch hier eher um einen "theoretsichen" Wert handelt und die Uebertragung gemultiplext gehandhabt wird. Ich finde auch keine wirklich aussagekraeftigen Angaben dazu. ich kann mir nur schwer vorstellen, das alleine 4096 Datenleitung quer ueber die GPU zu den HBMs wandern. (In der Praxis erfordert das deutlich mehr) Die 8 x 128b sind auch ein hinweis darauf. Die 1024Bit sind also auch wieder nur ein Aufreisser. Waere genauso als wenn ich sagen wuerde, das DDR2 DIMMs 256Bit haetten, da ja gemultiplext wird.
Genaueres und vor allen Dingen: technisch neutral und ungeschoent, wird wohl erst spaeter kommen.
2 mal bearbeitet, zuletzt am 20.05.15 13:29 durch HubertHans. -
Re: Ergibt 512GByte/s
Autor: HubertHans 20.05.15 - 13:31
TheSUNSTAR schrieb:
--------------------------------------------------------------------------------
> HubertHans schrieb:
> ---------------------------------------------------------------------------
> -----
> > Die Latenz bestimmt maßgeblich, wie hoch die maximal erzielbare
> Datenrate
> > ist. Die 512GByte/s Angabe hier laesst die Zugriffszeiten komplett
> ausser
> > Acht. Und auch wenn ein Burst Zugriff die Volle geschwindigkeit liefert,
> > besteimmt die Latenz, wie oft so ein burst-Zugriff pro Sekunde
> ueberhaupt
> > erfolgen kann. Die Pausen dazwischen druecken die Datenrate herunter.
> > Latenz und Takt/ Busbreite/ Prefetch-Tiefe beeinflussen sich maßgeblich.
> > Das die Hersteller immer gerne die Latenz aussen vorlassen (Wir reden
> hier
> > ja noch nicht mal vom verwerfen nicht benoetigter Daten bei den
> genutzten
> > prefetch-Tiefen welche erst einmal keine Rolle spielen) zeigt eben
> genau
> > das. ist genauso wie Spannung und Stromsdtaerke. Beide Faktoren haengen
> > zusammmen. Je niedriger die Latenz, umso naeher kommt man dem
> theoretisch
> > Moeglichen, in diesem Fall 512Gbyte. Und da kannst du diskutieren wie du
> > willst. Es ist untrennbar.
>
> Ich denke aktueller GDDR Speicher ist "quasi" Dual Port Memory um zwei
> parallele Speicheroperationen durchzuführen, also während der
> Burst-Response den zweiten Zugriff vorzubereiten, sodass dieser beinahe
> nahtlos an den laufenden Burst anschließen kann, sobald dieser eben fertig
> ist?
> Sofern der Burst also länger ist als die Latenz sollte man doch, bissel
> Overhead außen vor, die Speicherbandbreite tatsächlich ganz gut ausreizen
> können. Dafür sprechen doch auch die CUDA Optimization Guides, da wird die
> Peak-Bandwidth doch auch zu (glaube) 91% erreicht. So fatal ist das also
> kaum...
>
> > UND NEIN, ES SIND 1024Bit! LESEN! 4 mal 256 == 1024. Das schreibt ATI
> auch
> > selber. Und das mit PCIe und Grafikausgaengen war auf die GPU selbst
> > bezogen. Schon mal nen Sockel mit mehr als 4500 Pins gesehen? Ich glaube
> da
> > bekommst du massiv Schwieriigkeiten...
>
> Du musst es nicht nur lesen sondern auch noch den Text verstehen. Ein HBM
> Stapel hat ein 1024 Bit Interface (siehe Folie 9), und 4 von denen sind an
> der GPU angebunden, was auch erstmal gar nichts mit PCIe zu tun hat. Es
> wird auch nirgends behauptet das es da irgendwo einen Sockel mit 4500 Pins
> gibt, diese unzähligen Datenleitungen bleiben doch im Interposer, sind
> lediglich eine Direktverbindung zwischen Speicherstapel und GPU-Die (wo der
> Controller drin liegt). Der Sockel von dem gesamten Ding wird dann sogar
> viel weniger Pins als früher haben (die DDR-Leitungen fallen nun ja weg),
> das ist ja nun fast nur noch das Interface zum PCIe-Bus.
Du vergisst den Cache. Der macht spaetestens seit der GTX280 ordentlich Dampf und erhoeht somit die gemessene effektive Datenrate. Was passiert, wenn kein Cache da ist, sehen wir aktuell an der GTX970. Da bleibt von der Geschwindigkeit nichts mehr uebrig, da die letzten 512Mbyte aus der Cachable-Area rauspurzeln. -
Re: Ergibt 512GByte/s
Autor: TheSUNSTAR 20.05.15 - 13:36
HubertHans schrieb:
--------------------------------------------------------------------------------
> bla schrieb:
> ---------------------------------------------------------------------------
> -----
> > HubertHans schrieb:
> >
> ---------------------------------------------------------------------------
>
> > -----
> > > ms (Golem.de) schrieb:
> > >
> >
> ---------------------------------------------------------------------------
>
> >
> > > -----
> > > > Es sind 256 Bit pro DRAM-Chip, also 1024 pro Stack und ergo 4096 bei
> > > vier
> > > > Stapeln (GPU-seitig).
> > >
> > > Nein. Nach aussen hin bleiben es 256! Die Busbreite wird nicht durch
> > Magie
> > > einfach so breiter!
> > >
> > > Deswegen reden die auch von Channels! 8 x 128b
> >
> > Guck dir das doch nochmal genauer an.
> > Ein Stapel bestehend aus 4 Chips besitzt laut Folie einen 1024Bit
> breiten
> > Bus.
> > 1024Bit sind 128Byte. 128Byte mal 1Gbps ergibt 128GByte/s Bandbreite pro
> > Stapel.
> > Bei 4 Stapeln würde das eine maximale theoretische Bandbreite von
> > 512GByte/s ergeben.
>
> So ist er intern verschaltet. Das habe ich jetzt auch noch mal genauer
> gelesen. Das war an einigen Stellen im Netz zu dem Speicher nicht gerade
> offensichtlich zu sehen. Trotzdem waere ich mit 1024Bit pro Stapel
> vorsichtig. Ich denke das es sich auch hier eher um einen "theoretsichen"
> Wert handelt und die Uebertragung gemultiplext gehandhabt wird. Ich finde
> auch keine wirklich aussagekraeftigen Angaben dazu. ich kann mir nur schwer
> vorstellen, das alleine 4096 Datenleitung quer ueber die GPU zu den HBMs
> wandern. (In der Praxis erfordert das deutlich mehr) Die 8 x 128b sind auch
> ein hinweis darauf. Die 1024Bit sind also auch wieder nur ein Aufreisser.
> Waere genauso als wenn ich sagen wuerde, das DDR2 DIMMs 256Bit haetten, da
> ja gemultiplext wird.
>
> Genaueres und vor allen Dingen: technisch neutral und ungeschoent, wird
> wohl erst spaeter kommen.
Ob du es dir nun vorstellen kannst oder nicht ist eigentlich einzig und allein dein Problem, die JEDEC hingegen hat HBM aber bereits 2013 als Standard JESD235 angenommen, inklusive der 1024 Datenleitungen... -
Re: Ergibt 512GByte/s
Autor: TheSUNSTAR 20.05.15 - 13:42
HubertHans schrieb:
--------------------------------------------------------------------------------
> Du vergisst den Cache. Der macht spaetestens seit der GTX280 ordentlich
> Dampf und erhoeht somit die gemessene effektive Datenrate.
Klar, bei einem Bandbreiten-Test wo auf der Grafikkarte paar GB Speicher von A nach B kopiert werden, ohne sie ein zweites mal anzuschauen, reißt ein Cache unglaublich viel.
> Was passiert,
> wenn kein Cache da ist, sehen wir aktuell an der GTX970. Da bleibt von der
> Geschwindigkeit nichts mehr uebrig, da die letzten 512Mbyte aus der
> Cachable-Area rauspurzeln.
Ganz anderes Problem.



