Via zeigt Quad Band Memory

[Gast]

(zwar englisch, aber seis drum:)
About a year and a half since we first wrote about it, VIA was finally demoing Quad Band Memory on a P4 platform at their booth. You'll want to read our tech article on QBM to understand more of how it works, but basically it offers twice the bandwidth of DDR using a phase shift of the clock signal to effectively achieve two DDR transfers per "clock."

http://www.anandtech.com/showdoc.html?i=2064&p=8

up

[Freakazoid]

ist doch nichts anderes als dualchann !?

[GloomY]

Original geschrieben von 3K
ist doch nichts anderes als dualchann !? Dualchannel mit einem Kanal ;)

Die Daten werden Zeit-multiplexed über einen 64 Bit Bus übertragen. Daher kann man auch von außen nicht sehr viel erkennen. Mehr als ein Foto wäre deshalb schon wünschenswert :)

[stav0815]

hm, is doch wie bei intel der Quad-Pumped FSB, d.h. es wird pro Flanke zwei signale übertragen und da ein Signal 2 Flanken hat 2x2=4

[Gast]

mehr info gibts hier:
http://www.quadbandmemory.com/

up

[Gast]

Beispiel:
http://www.quadbandmemory.com/images/work.jpg

up

[DanMan]

Hmm... tja.... leider hat QBM eigentlich keine richtigen Vorteile gegenüber DualChannel (außer, dass man eben nur einen Riegel braucht). Und da sich DualChannel durchgesetzt hat, wirds wohl keinen Chipsatz mit QBM mehr geben. Eigentlich schade, da QBM ja keine Lizengebühren kostet, und abwärtskompatibel zu normalem DDR ist. Es wären also wahrscheinlich keine Inkompatibilitätsprobleme aufgetreten. Naja...

DDR2 ist allerdings kein Argument, weil der 1. auch noch nicht erhhältlich ist, und 2. anfangs sogar langsamer als DDR1-DualChannel sein wird.

[Coda]

Ehm, das ganze kombiniert man natürlich mit Dual Channel, deshalb auch Quad Band Memory.

wirds wohl keinen Chipsatz mit QBM mehr geben
Natürlich wird es das. Glaubst du Via entwickelt das zum Spaß?

[DanMan]

Ehm, das ganze kombiniert man natürlich mit Dual Channel, deshalb auch Quad Band Memory.

Natürlich wird es das. Glaubst du Via entwickelt das zum Spaß?
Öhm, also DualChannel und QBM hat grundsätzlich erstmal nichts miteinander zu tun. Keine Ahnung was du mir da sonst sagen willst. :confused:

Und da es die QBM Technik bereits seit 2000 gibt, glaub ich nicht dran, dass doch noch ein Chipsatz kommt. Wenn doch, schön. Fehlen nur noch die RAMs.

Edit: Hab gerade gelesen (http://www.xbitlabs.com/news/memory/display/20040629105414.html), dass Kentron wohl DDR aufgegeben hat, da VIA immerwieder Rückzieher gemacht hat (hatte wohl immernoch Intel die Finger im Spiel). Darum haben sie jetzt angekündigt QBM auch für DDR2 rauszubringen. Diesmal mit dem Unterschied, dass die zusätzlichen Bauteile (PLL) direkt auf den RAMs untergebracht werden sollen - also nicht auf den Chipsatz angewiesen sind. Man will somit dem Kunden vor die Wahl stellen, und nicht die Chipsatzhersteller. Mehr dazu im Artikel.

[Coda]

Öhm, also DualChannel und QBM hat grundsätzlich erstmal nichts miteinander zu tun. Keine Ahnung was du mir da sonst sagen willst.
OMG. Man verwendet halt trotzdem 2 Kanäle, wendet aber auf jeden auch noch die Phasenverschiebung an = 4 fache Bandbreite, statt 2 fache.

[BlackBirdSR]

Bandbreite Bandbreite.. davon haben wir doch jetzt genug.
Wir wäre es mal mit mehr Takt? viel mehr Takt.
Die Bandbreite wird dann automatisch höher.. auch wenn das ziemlich egal ist.
Mehr Takt bitte...

[Endorphine]

Alle Jahre wieder ein neuer VIA-DRAM Typ :rolleyes: Kein JEDEC-Industriestandard, also keine Relevanz für den Massenmarkt. Wozu überhaupt drüber diskutieren? QBM-DRAM wird genau so in der Versenkung verschwinden wie VC-DRAM oder BEDO-DRAM etc.

Die Idee ist wieder mal nett, ich glaube aber eher an fully-buffered DIMMs mit JEDEC-Segen, als an einen Vorstoß einer kleinen Industrieallianz abseits der JEDEC. Auch wenn der Stillstand in der DRAM-Industrie weh tut, es führt kein Weg an der JEDEC vorbei, von Nischenmärkten mal abgesehen.

Zudem bietet QBM imho nicht genug Mehrwert, um die Nachteile aufzuwiegen. Es steht imho damit in bester Tradition zu SLDRAM, RL-SDRAM, VC-SDRAM, BEDO-DRAM etc. und wird wohl nie Bedeutung erlangen.

[DanMan]

OMG. Man verwendet halt trotzdem 2 Kanäle, wendet aber auf jeden auch noch die Phasenverschiebung an = 4 fache Bandbreite, statt 2 fache.
Nur wenn DualChannel im Spiel ist! Ansonsten wird nur ein Kanal genutzt! Ein QBM Riegel hat die gleiche Bandbreite wie 2 "normale" DDR-RAMs im DualChannel Betrieb. Schließlich findet die Phasenverschiebung und das Multiplexen auf einem Riegel, zwischen 2 Speicherbänken statt, und nicht über zwei Riegel verteilt. Das erhöht die Datenrate pro Kanal, und der Chipsatz kriegt davon nicht mehr viel mit. http://www.tecchannel.de/hardware/1147/9.html
Einer von uns beiden hat da bei DualChannel wohl irgendetwas falsch verstanden.



Was den Massenmarkt angeht zähle ich mich dort hinzu. Und im Gegensatz zu den anderen RAM-Technologien, die du da aufgezählt hast, Endorphine, hab ich von QBM Speicher immerhin schon gehört.

Und klär mich bitte einer auf was man am RAM noch verbessern kann ausser den Datendurchsatz (aka Bandbreite) (ist ernst gemeint, nicht zynisch).

[LOCHFRASS]

Und klär mich bitte einer auf was man am RAM noch verbessern kann ausser den Datendurchsatz (aka Bandbreite) (ist ernst gemeint, nicht zynisch).

Latenzen. Wenn Intel jetzt wirklich vom Netburst-Muell auf das wesentlich effizientere Pentium M Design umsteigt, besteht gar kein Bedarf mehr fuer diesen Bandbreiten-Wahnsinn.

[Endorphine]

Am RAM gibt es sehr viel zu verbessern. Die Latenzen treten bei (S)DRAM seit Jahren auf der Stelle, das parallele Interface von SDRAM behindert massiv die Integration und die Entwicklung in der gesamten IT-Industrie (dafür gibt's RDRAM oder fully buffered DIMMs). Dann wäre es auch vorstellbar, DRAM als Erfindung von Intel aus den 70ern mit den konstruktiven Nachteilen wie dem erforderlichen zyklischen Refresh ad acta zu legen. Hier kann MRAM Abhilfe bringen.

Und überhaupt - DRAM Zellen lassen sich in größeren multi-Megabit IC-Maßstäben kaum so hoch takten, wie es eigentlich für die Entwicklung von Controllern und Prozessoren erforderlich wäre. Die ganze IT-Entwicklung der letzten 20 Jahre wäre anders verlaufen, wenn DRAM nicht auf der Stelle treten würde. MRAM könnte die Wende bringen.

Edit: Und nicht zu vergessen - das JEDEC-Konsortium. (D)RAM ist ein austauschbares Massenprodukt, welches von vielen Herstellern produziert wird und kompatibel sein muss. Einer Entwicklung müssen deshalb alle Hersteller in der JEDEC zustimmen, sonst hat ein neuer (D)RAM-Typ keine Chance auf dem Massenmarkt. Gerade kleinere DRAM-Verbesserungen à la BEDO-DRAM, SLDRAM, VC-SDRAM und wie sie alle heissen kommen dann nie in den Markt, weil die Vorteile ggü. dem offiziellen Standard nicht gross genug sind, um die Nachteile der Inkompatibilität aufzuwiegen. Gegen eine kommerzielle RAM-Entwicklungsstelle, die sich über Lizenzen finanziert hat sich die gesamte Speicherindustrie erfolgreich zur Wehr gesetzt (Rambus). Die Hersteller zahlen lieber keine Royalties und lassen die Entwicklung um 10-15 Jahre den technischen Möglichkeiten hinterherhinken, als dass sie Speicher produzieren, die nicht in der JEDEC definiert wurden.

[Haarmann]

Endorphine

MoSyS 1T-SRAM hätte die Vorteile und hat geringere Herstellungskosten als RDRAM. Trotzdem jagen alle Gespenstern ala MRAM und FRAM (Davon reden ja alle seit 15 Jahren) und wie das Zeugs auch immer genannt wird hinterher. Soviel, wie da in die Entwicklung gesteckt wird, kann die Lizenz gar nicht kosten...
Ich glaube das hat ganz andere Gründe, denn ein besserer Speicher würde die CPU Hersteller auch ins Schwitzen bringen. Sie haben schlicht keine passenden Produkte parat.

Nachtrag

Bin mir sicher Du erinnerst Dich an die netten EDRAM...

[Muh-sagt-die-Kuh]

Endorphine
Ich glaube das hat ganz andere Gründe, denn ein besserer Speicher würde die CPU Hersteller auch ins Schwitzen bringen. Sie haben schlicht keine passenden Produkte parat.Jeder Hauptspeicher mit einer Latenz > 0 ist für die CPU ein Bremse....ich wüsste also nicht, was ein CPU Hersteller gegen besseren Hauptspeicher haben sollte.

[Haarmann]

Muh-sagt-die-Kuh

Nicht jede CPU reagiert gleich auf langsameren Speicher. Einfachster Vergleich ist doch ein trivialer Athlon XP mit SDR vs DDR, im Vergleich zu nem P4 mit SDR zu DDR.
Ich würde z.B. meine Wette auf die RISC Cores setzen, wenn man LL RAM einsetzen würde. X86 würd ich dann als gestorben bezeichnen.

Nachtrag zur Veranschaulichung...

Eine CPU mit X Pipelines steht teilweise/ganz still, weil ihr entweder die Daten ausgehen (dagegen kann idealer Speicher helfen) oder weil im Code Abhängigkeiten bestehen, die dies verhindern (dagegen hilft mir idealer Speicher nicht). Ich denke nun ists klar, was ich damit sagen wollte, wobei ich die Caches hier noch bewusst wegliess, denn dies ist eine andere Baustelle - auch eine, die auf DRAM basiert.

[Gast]

DDR2 ist allerdings kein Argument, weil der 1. auch noch nicht erhhältlich ist, und 2. anfangs sogar langsamer als DDR1-DualChannel sein wird.


DDR2 Ram ist sehr wohl erhältlich!

[BlackBirdSR]

Muh-sagt-die-Kuh

Nicht jede CPU reagiert gleich auf langsameren Speicher. Einfachster Vergleich ist doch ein trivialer Athlon XP mit SDR vs DDR, im Vergleich zu nem P4 mit SDR zu DDR.
Ich würde z.B. meine Wette auf die RISC Cores setzen, wenn man LL RAM einsetzen würde. X86 würd ich dann als gestorben bezeichnen.



Beim K7 liegt es zu Teilen am sehr großen L1 Cache, der das abfängt.
Zum Anderen ist der K7/8 stark Latenzabhängig, und da brachte DDR keine Verbesserung gegenüber SDR.
Der P4 braucht die höhere Bandbreite um die Latenzen zu maskieren, fürs Prefetching und um die Caches schnell genug zu füllen.

Was das mit RISC und x86 zu tun hat, will mir nicht einleuchten :confused:
Bei einem Cache-Miss geht es auch anderen Architekturen noch nicht viel besser.
SMT hilft zumindest etwas, Coarse Grained (V)MT kann schnell auf einen anderen Thread umschalten. Das lässt sich jedoch bei x86 auch erreichen.

[Haarmann]

BlackBirdSR

RISC Code (echter) ist massiv grösser als X86 und hätte eigentlich ne fixe Befehlslänge und kurze Ausführungszeiten. Das (nebst Anderem) machte das Verteilen auf viele Funktionseinheiten etwas einfacher. Da bei idealem Speicher ja nur noch der Flaschenhals "Verteilen" bliebe, sehe ich hier nen Vorteil für nen RISC System.

[BlackBirdSR]

BlackBirdSR

RISC Code (echter) ist massiv grösser als X86 und hätte eigentlich ne fixe Befehlslänge und kurze Ausführungszeiten. Das (nebst Anderem) machte das Verteilen auf viele Funktionseinheiten etwas einfacher. Da bei idealem Speicher ja nur noch der Flaschenhals "Verteilen" bliebe, sehe ich hier nen Vorteil für nen RISC System.

du machst es dir ja recht einfach *g*
idealer Speicher, Flaschenhals nur noch beim Issue/Scheduler, echter RISC Code ;)

Ich behaupte mal, dass es echte RISCs nicht mehr gibt. Ansonsten tun sich da noch sehr viele Flaschenhälse auf, das liegt nicht nur am Speichersubsystem.

[Muh-sagt-die-Kuh]

Muh-sagt-die-Kuh

Nicht jede CPU reagiert gleich auf langsameren Speicher. Einfachster Vergleich ist doch ein trivialer Athlon XP mit SDR vs DDR, im Vergleich zu nem P4 mit SDR zu DDR.
Ich würde z.B. meine Wette auf die RISC Cores setzen, wenn man LL RAM einsetzen würde. X86 würd ich dann als gestorben bezeichnen.Die ISA spielt in diesem Zusammenhang keine Rolle, da sich eigentlich alle ihre Schwächen CPU-intern auflösen lassen.
RISC Code (echter) ist massiv grösser als X86 und hätte eigentlich ne fixe Befehlslänge und kurze Ausführungszeiten. Das (nebst Anderem) machte das Verteilen auf viele Funktionseinheiten etwas einfacher. Da bei idealem Speicher ja nur noch der Flaschenhals "Verteilen" bliebe, sehe ich hier nen Vorteil für nen RISC System.Nach dem Decoder findest du in einer heutigen x86 CPU exakt diese Situation vor....

[Haarmann]

BlackBirdSR

Ich hab ja nie behauptet, dass es sowas Heute gibt. Denn diesen RISC CPUs fehlte es an "Peripherie". Ich meinte damit nen grundlegenden Vorteil bei idealem Speicher, der sich bei Speicherverbesserungen auswirken würde. Nur wir haben diese Verbesserungen ja gar nicht. Auch wird Dir sofort auffallen, dass dder Konzern mit der grössten Marktmacht offensichtlich kein Interesse hätte eine solche Neuerung einzuführen, weil er nicht gerade führend ist im RISC Bereich.
Verbilligt er nun mit seiner Marktmacht ne zu gute Speichertechnologie, könnte das nach Hinten los gehen ;).


Muh-sagt-die-Kuh

Wir haben Heute noch "UMA" Computer als PCs. Man könnte das auch abändern und den Speicher in Befehls und Datenspeicher unterteilen. Plötzlich wird ne fixe Befehlsgrösse da ganz sinnvoll. NX Bits brauchts dann auch keine mehr ;).

Dieser Decoder ist eben ein Hindernis in meinen Augen für ne optimale Verteilung.

Kleines Exempel, wie DRAM die CPUs beeinflusst. Cache hat Lines, weil ein Burst eben schnell ist und sich das im Schnitt rechnet jeweils gleich nen Block verschiebt... Dauert ja nicht viel länger als nur die benötigten Daten.

[DanMan]

Latenzen. Wenn Intel jetzt wirklich vom Netburst-Muell auf das wesentlich effizientere Pentium M Design umsteigt, besteht gar kein Bedarf mehr fuer diesen Bandbreiten-Wahnsinn.
Hmmm. OK.

Nur hat mir immernoch keiner erklärt, warum eine hohe Bandbreite schlecht ist, bzw. (alleine) nicht viel bringt? Je mehr, desto besser oder etwa nicht? Verhindern etwa die Latenzen, dass die hohe Bandbreite genutzt werden kann? Fragen über Fragen. :confused:

[Muh-sagt-die-Kuh]

BlackBirdSR

Ich hab ja nie behauptet, dass es sowas Heute gibt. Denn diesen RISC CPUs fehlte es an "Peripherie". Ich meinte damit nen grundlegenden Vorteil bei idealem Speicher, der sich bei Speicherverbesserungen auswirken würde. Nur wir haben diese Verbesserungen ja gar nicht. Auch wird Dir sofort auffallen, dass dder Konzern mit der grössten Marktmacht offensichtlich kein Interesse hätte eine solche Neuerung einzuführen, weil er nicht gerade führend ist im RISC Bereich.
Verbilligt er nun mit seiner Marktmacht ne zu gute Speichertechnologie, könnte das nach Hinten los gehen ;).Definiere "Peripherie" und werd mal etwas konkreter....Muh-sagt-die-Kuh

Wir haben Heute noch "UMA" Computer als PCs. Man könnte das auch abändern und den Speicher in Befehls und Datenspeicher unterteilen. Plötzlich wird ne fixe Befehlsgrösse da ganz sinnvoll. NX Bits brauchts dann auch keine mehr ;).Das Konzept nennt sich "Von Neumann Architektur", nicht "UMA". Vorteile hat eine Teilung, meiner Meinung nach, keine......sie bringt dafür eine nicht zu unterschätzende Inflexibilität mit sich. Und warum eine fixe Befehlsgröße bei einer Teilung Vorteile bringen soll ist auch nicht wirklich ersichtlich.Dieser Decoder ist eben ein Hindernis in meinen Augen für ne optimale Verteilung.Aha....und wieso?Kleines Exempel, wie DRAM die CPUs beeinflusst. Cache hat Lines, weil ein Burst eben schnell ist und sich das im Schnitt rechnet jeweils gleich nen Block verschiebt... Dauert ja nicht viel länger als nur die benötigten Daten.Das ist nicht der alleinige Grund für Lines.....sagt dir "räumliche Lokalität" etwas?

[BlackBirdSR]

BlackBirdSR

Auch wird Dir sofort auffallen, dass dder Konzern mit der grössten Marktmacht offensichtlich kein Interesse hätte eine solche Neuerung einzuführen, weil er nicht gerade führend ist im RISC Bereich.
Verbilligt er nun mit seiner Marktmacht ne zu gute Speichertechnologie, könnte das nach Hinten los gehen ;).


das ist alles sehr! weit hergeholt.
Die Sache hat für meich weder Hand noch Fuß, sorry.

Zumal hier schon einige technische Sachen angesprochen wurde, die man erstmal klären sollte bevor wir auch daran glauben, dass diese angeblichen "RISCs" so abschneiden wie du es postulierst.

[Endorphine]

Definiere "Peripherie" und werd mal etwas konkreter....Das Konzept nennt sich "Von Neumann Architektur", nicht "UMA". Die Trennung von Befehls- und Datenspeicher mit eigenen Bussystemen ist das Harvard-Modell, von-Neumann fasst beides zusammen.

[Haarmann]

DanMan

Die Bandbreite an sich ist nicht das Problem - da gilt eigentlich immer mehr ist nicht schlecht, aber ab ner bestimmten Latenz, wird sie egal wie hoch, nix mehr bewirken. Dann erscheint sie als völlig überflüssig.

Muh-sagt-die-Kuh

"Peripherie" für ne CPU is im Prinzip Vieles. Ich wollte damit einfach mögliche Brücken zu Speicher (Controller ist da mit drin inkl. der Caches) und anderen Chips/Geräten sehen. Früher wäre sogar die FPU mal Peripherie gewesen. Ich legs also etwas grosszügig aus.

Ich habs absichtlich "UMA" genannt, weil das Wort oft negative Erinnerungen weckt. "UMA" bringt imho bei nicht idealem Speicher nur Flexibilität - keinesfalls Geschwindigkeit.

Ein Decoder wird mich Zyklen kosten. In bestimmten Fällen wird das "längere" Abhängigkeiten erzeugen, als wenn ich keinen Decoder nutzen muss. In diesen Fällen werd ich ohne Decoder Vorteile haben.
Angenommen der Decoder frisst 5 Zyklen.Brauche ich 20 Zyklen zum berechnen eines bedingten Sprungs, muss ihn aber nach 15 Zyklen ausführen, dann kann ich im Schilf liegen. Liege ich das, verliere ich die 5 Zyklen im Minimum. Hätte ich keinen Decoder gehabt, der mir 5 Zyklen frisst, wäre kein Problem entsanden.
Soll nur veranschaulichen, was ich meine. Eine Stufe, die nicht da ist, erspart Arbeit und Probleme.

BlackBirdSR

Einfaches Exempel aus der "Praxis" - ein Itanium vs nen AMD64. Der AMD soll nen rund 3 mal kleineren Code nutzen (Daten sind nicht relevant) - das stand jedenfalls so zu lesen und ich setze diesen Fall für das Exempel einfach mal so. Der I-Cache eines Itaniums müsste daher für die gleiche Leistung 3 mal grösser und breiter sein. Das ist nicht "gratis" zu erlangen. Der Itanium übernimmt hierbei die Rolle des RISC Prozessors.

[BlackBirdSR]

Einfaches Exempel aus der "Praxis" - ein Itanium vs nen AMD64. Der AMD soll nen rund 3 mal kleineren Code nutzen (Daten sind nicht relevant) - das stand jedenfalls so zu lesen und ich setze diesen Fall für das Exempel einfach mal so. Der I-Cache eines Itaniums müsste daher für die gleiche Leistung 3 mal grösser und breiter sein. Das ist nicht "gratis" zu erlangen. Der Itanium übernimmt hierbei die Rolle des RISC Prozessors.

Der Itanium ist werder ein RISC Prozessor, noch würden jegliche Flaschenhälse bis auf die Ausführung verschwinden, wenn man den Speicher als Faktor eleminiert.
Ansonst hab ich wiedermal nicht kapiert was du mir sagen wolltest, sorry.

Dass mehr Cache nicht gratis ist, ist mir klar. Aber inwiefern macht das deine angeblichen RISCs überlegen, wenn der Speicher unendlich groß und schnell wäre?

[Haarmann]

BlackBirdSR

Ich zog den Itanium hinzu, weil der bekannt ist für seinen grösseren Code. Wenn ich 8 Operationen mit je 16 Bit Befehlslänge durchführen will, dann muss mir etwas diese auch liefern. Kriege ich das Gleiche bei ne anderen CPU in 4 Operationen a 16 Bit Befehlslänge hin, dann ist das die hälfte, die ich zuführen muss, selbst wenn der Decoder daraus wieder 8 machen würde. Bei idealem Speicher ists aber egal, denn ich leide ja nie unter Mangel. In den heutigen CPUs spielts aber ne Rolle, ob ich 8 oder 4 Befehle holen muss.

[Coda]

Nur wenn DualChannel im Spiel ist! Ansonsten wird nur ein Kanal genutzt! Ein QBM Riegel hat die gleiche Bandbreite wie 2 "normale" DDR-RAMs im DualChannel Betrieb. Schließlich findet die Phasenverschiebung und das Multiplexen auf einem Riegel, zwischen 2 Speicherbänken statt, und nicht über zwei Riegel verteilt. Das erhöht die Datenrate pro Kanal, und der Chipsatz kriegt davon nicht mehr viel mit. http://www.tecchannel.de/hardware/1147/9.html
Einer von uns beiden hat da bei DualChannel wohl irgendetwas falsch verstanden.
Das ist mir schon klar. Trotzdem kann man zusätzlich DualChannel benützen Oo

Was ist daran so schwer zu verstehen? Zwei Kanäle mit QBM. Das eine schließt das andere ja nicht aus.

[Muh-sagt-die-Kuh]

Muh-sagt-die-Kuh

"Peripherie" für ne CPU is im Prinzip Vieles. Ich wollte damit einfach mögliche Brücken zu Speicher (Controller ist da mit drin inkl. der Caches) und anderen Chips/Geräten sehen. Früher wäre sogar die FPU mal Peripherie gewesen. Ich legs also etwas grosszügig aus.Und wieso soll es einer RISC CPU daran fehlen? Das behauptest du zumindest weiter oben.... :confused:Ich habs absichtlich "UMA" genannt, weil das Wort oft negative Erinnerungen weckt. "UMA" bringt imho bei nicht idealem Speicher nur Flexibilität - keinesfalls Geschwindigkeit.Ob man den Speicher teilt oder nicht ist für die Geschwindigkeit ziemlich irrelevant. Konzeptionell spricht beispielsweise nichts gegen 2 Speichercontroller und 2 Speicherbänke bei einem logisch ungeteilten Speicher.Ein Decoder wird mich Zyklen kosten. In bestimmten Fällen wird das "längere" Abhängigkeiten erzeugen, als wenn ich keinen Decoder nutzen muss. In diesen Fällen werd ich ohne Decoder Vorteile haben.
Angenommen der Decoder frisst 5 Zyklen.Brauche ich 20 Zyklen zum berechnen eines bedingten Sprungs, muss ihn aber nach 15 Zyklen ausführen, dann kann ich im Schilf liegen. Liege ich das, verliere ich die 5 Zyklen im Minimum. Hätte ich keinen Decoder gehabt, der mir 5 Zyklen frisst, wäre kein Problem entsanden.
Soll nur veranschaulichen, was ich meine. Eine Stufe, die nicht da ist, erspart Arbeit und Probleme.Auch wenn deine Argumentation reichlich unpräzise und wirr ist, verstehe ich so halbwegs was du meinst....

Ja, ein Decoder kostet Pipelinestufen, die zu einer höheren Branch-Misprediction Penalty führen. Aber auch das lässt sich umgehen, Stichwort "Trace Cache".

[Haarmann]

Muh-sagt-die-Kuh

Ich unterscheide mal 3 Speicher - Idealer Speicher, Burstspeicher und Asynchroner nichtburstfähiger Speicher (naja es ist einfach nicht schneller als 2 Random Zugriffe). Heute haben wir den 2en, früher zT den ersten und je näher wir uns an den 3en begeben, desto mehr Vorteile müsste ein RISC wieder haben.

Vorne Weg - RISC sollte ja auch Pipelinestufen sparen, weil die Befehle weniger Komplex sein sollten. Das verstärkt den Vorteil nochmals. Weniger Befehle in der Pipeline ergeben bekanntlich auch weniger mögliche Abhängigkeiten.

Ich versuche mal zu zeigen, was ich meine mit getrenntem Speicher und seinen Vorteilen bei nicht idealem Speicher natürlich.
Setzen wir den Fall, dass ich 32 Bit Befehle und jeweils 64 Bit S+D Daten hab bei jedem Befehl, wie RISC sollte. Nun mache ich 3 Caches und 3 Speicherbusse. Ich werde zusätzlich dafür sorgen, per Compiler, dass immer aus jedem Bus maximal eine Information pro Befehl benötigt wird. Je kleiner nun die Latenz auf den Speicher ist, desto kleiner kann ich die Lines im Cache halten. Bei nem klassischen SRAM, das keinen Burstvorteil hat, also die alten Async Steichen, braucht man schon gar keine Lines mehr, weil schlicht kein Vorteil mehr da wäre - ob Burst oder Einzelabfrage ist dann Wurst -> kleinere Lines machen Sinn. Gleichzeitig weiss ich, dass wenn ich 8 Funktionseinheiten hab, meine Caches je genau 8 32 Bit resp 64 Bit Werte liefern können müssen. Ich kann alles auf genau dies auslegen und hab keine Unbekannten drin.
Bei nem CISC gibts Befehle, die nicht in dies einfache Schema passen und somit ist die benötigte Datenmenge eigentlich nicht mehr definierbar (Blockmoves z.B.). Das vereinfacht das Leben nicht wirklich. Das hab ich damit gemeint. Ich hoffe das ist nun klarer. Bei idealem Speicher gibts dies Problem ja gar nicht mehr. Man hat ja alle Daten immer sofort bereit.

Der Bursteffekt beim Speicher hat sich in den letzten Jahren verstärkt (mit DDR2 wird die Schere noch grösser) und siehe da, die RISC CPUs gerieten in arge Nöte. x86 konnte aufholen - vorbei die Alpha vs Pentium Zeit, wo der Alpha mit dem FX32 "Emulator" nen Pentium 66 zT schlagen konnte unter NT4.

P.S. Ich halte RISC trotzdem nicht für das Tollste... Aus meiner Sicht muss ein System gut zusammenarbeiten und ist nicht gleich der Summe seiner Teile.

[Quasar]

Haarmann ? (http://www.forum-3dcenter.de/vbulletin/showpost.php?p=2132474&postcount=96)

[Muh-sagt-die-Kuh]

Muh-sagt-die-Kuh

Ich unterscheide mal 3 Speicher - Idealer Speicher, Burstspeicher und Asynchroner nichtburstfähiger Speicher (naja es ist einfach nicht schneller als 2 Random Zugriffe). Heute haben wir den 2en, früher zT den ersten und je näher wir uns an den 3en begeben, desto mehr Vorteile müsste ein RISC wieder haben.

Vorne Weg - RISC sollte ja auch Pipelinestufen sparen, weil die Befehle weniger Komplex sein sollten. Das verstärkt den Vorteil nochmals. Weniger Befehle in der Pipeline ergeben bekanntlich auch weniger mögliche Abhängigkeiten.Im Decoder gibt es keine Abhängigkeiten.....und danach findest du in einer heutigen x86 CPUs RISC-artige Operationen.

Auch halte ich die absolute Anzahl an Abhängigkeiten für ein ziemlich mieses Maß....Ich versuche mal zu zeigen, was ich meine mit getrenntem Speicher und seinen Vorteilen bei nicht idealem Speicher natürlich.
Setzen wir den Fall, dass ich 32 Bit Befehle und jeweils 64 Bit S+D Daten hab bei jedem Befehl, wie RISC sollte. Nun mache ich 3 Caches und 3 Speicherbusse. Ich werde zusätzlich dafür sorgen, per Compiler, dass immer aus jedem Bus maximal eine Information pro Befehl benötigt wird."Dass immer aus jedem Bus maximal eine Information pro Befehl benötigt wird." Drück dich mal etwas präziser aus, den Sinn dieses Satzes kann ich mir auf jeden Fall nicht erschliessen.Je kleiner nun die Latenz auf den Speicher ist, desto kleiner kann ich die Lines im Cache halten. Bei nem klassischen SRAM, das keinen Burstvorteil hat, also die alten Async Steichen, braucht man schon gar keine Lines mehr, weil schlicht kein Vorteil mehr da wäre - ob Burst oder Einzelabfrage ist dann Wurst -> kleinere Lines machen Sinn.Kleinere Lines machen absolut keinen Sinn, das Stichwort lautet wieder "räumliche Lokalität".Gleichzeitig weiss ich, dass wenn ich 8 Funktionseinheiten hab, meine Caches je genau 8 32 Bit resp 64 Bit Werte liefern können müssen. Ich kann alles auf genau dies auslegen und hab keine Unbekannten drin.
Bei nem CISC gibts Befehle, die nicht in dies einfache Schema passen und somit ist die benötigte Datenmenge eigentlich nicht mehr definierbar (Blockmoves z.B.). Das vereinfacht das Leben nicht wirklich. Das hab ich damit gemeint. Ich hoffe das ist nun klarer. Bei idealem Speicher gibts dies Problem ja gar nicht mehr. Man hat ja alle Daten immer sofort bereit.Cache-Bandbreite stellt in heutigen Architekturen kein Problem dar.
Der Bursteffekt beim Speicher hat sich in den letzten Jahren verstärkt (mit DDR2 wird die Schere noch grösser) und siehe da, die RISC CPUs gerieten in arge Nöte. x86 konnte aufholen - vorbei die Alpha vs Pentium Zeit, wo der Alpha mit dem FX32 "Emulator" nen Pentium 66 zT schlagen konnte unter NT4.Die ISA der IBM Power CPUs ist so ziemlich das, was heute RISC am nächsten kommt....und langsame CPUs sind das ganz bestimmt nicht.

Was die Software Emulation angeht: Ein Itanium 2 mit Soft-x86 Emulation schlägt einen gleichgetakteten Xeon in SPECfp.

[Haarmann]

Muh-sagt-die-Kuh

Ich sagte nicht im Dekoder oder wollte das nicht sagen - ich meinte durch den Dekoder, da er weitere Stufen erzeugt, entstehen Abhängigkeiten. Offensichtlich haben sich intern diese RISC Like Kommandos bewährt - könnte ja sein, dass es nen Grund hat, den ich mal genannt hab.

Die Anzahl der möglichen Abhängigkeiten müsste das Auflösen dieser exponential erschweren, wenn mich da meine Mathematik des Händeschüttelproblems nicht verlässt. Von daher ists ein Hinweis auf den benötigten Aufwand.

Also ich will nicht, dass ein Befehl von Daten1 mal nen Zugriff will, sondern immer je einer von Daten1 und Daten2. Im Prinzip ein analoges Verfahren zum Anordnen bei X86 auf den passenden Wert. Sorgt dafür, das nicht alle Arbeit an einem Ort anfällt.

Kleinere Lines machen dann Sinn, wenn sich Lines nicht mehr lohnen. Beim heutigen "Burstspeicher" ists jedoch schon IO, wenn man nur 2 mal von Line XY liest. Das sparte bereits Zeit, auch wenn ich mir durch das füllen einer Line Zeit versaue beim ersten Zugriff. Wenn die Latenz sink bei gleicher Bandbreite, dann wird man auch die Lines eher wieder verkürzen wollen. Bei "Burstunfähigkeit" wirst Du sogar die Lines weglassen können, da es keinen Sinn mehr ergibt vom Aspekt der Geschwindigkeit her.
Cache Lines sind im Prinzip ein Glücksspiel - man hofft dabei zu gewinnen und schaut, dass die Chancen dazu gut stehen - ne Garantie drauf hat man aber nicht. Ein gezielt drauf abgestimmtes Testprogram, das eben nur einen Zugriff je Line ausfürt, würde benachteiligt bei grosser Linesize, weil viele Daten umsonst durch die Gegend wandern.
Es ist auch die Frage, was zuerst war - die Lokalität oder die heutigen Caches... Ich tippe mal auf Letzteres, denn die Compiler für die neuen CPUs erschufen imho diese Lokalität oft erst selber. Ein nicht P4 optimierter Code bringt nen P4 ja nicht grad zum Fliegen und das war nicht nur beim P4 so.

Ich sag ja nicht, dass IBM grottenschlechte CPUs macht, aber ich weiss, dass es keine echte RISC mehr ist, weil man einsehen musste, dass dies nix mehr bringt.
z.B. diese Blockmoves sollte man den Speicher ausführen lassen...

Ich sprach hier nicht vom gleichen Takt, denn der Itanium 2 wird den Takt des Xeons auch bei Heliumkühlung nicht erreichen können. Eine CPU ist auf "GHz" optimiert und die Andere nicht. Da wird die auf "GHz" immer schlechte Karten haben beim gleichen Takt und gleicher Technologiestufe.

P.S. Ich wollte ja schon lange mal nen PRG, das einem das Cacheverhalten analysiert...

[Muh-sagt-die-Kuh]

Muh-sagt-die-Kuh

Ich sagte nicht im Dekoder oder wollte das nicht sagen - ich meinte durch den Dekoder, da er weitere Stufen erzeugt, entstehen Abhängigkeiten. Offensichtlich haben sich intern diese RISC Like Kommandos bewährt - könnte ja sein, dass es nen Grund hat, den ich mal genannt hab.

Die Anzahl der möglichen Abhängigkeiten müsste das Auflösen dieser exponential erschweren, wenn mich da meine Mathematik des Händeschüttelproblems nicht verlässt. Von daher ists ein Hinweis auf den benötigten Aufwand.In µOps zerlegter x86 Code und nativer RISC Code sollten sich im Bezug auf die vorhandenen Abhängigkeiten sehr ähnlich sein....da gibt es keine Unterschiede bezüglich des Aufwands.
Also ich will nicht, dass ein Befehl von Daten1 mal nen Zugriff will, sondern immer je einer von Daten1 und Daten2. Im Prinzip ein analoges Verfahren zum Anordnen bei X86 auf den passenden Wert. Sorgt dafür, das nicht alle Arbeit an einem Ort anfällt."Im Prinzip ein analoges Verfahren zum Anordnen bei X86 auf den passenden Wert" Was meinst du denn damit? Alignment?Kleinere Lines machen dann Sinn, wenn sich Lines nicht mehr lohnen. Beim heutigen "Burstspeicher" ists jedoch schon IO, wenn man nur 2 mal von Line XY liest. Das sparte bereits Zeit, auch wenn ich mir durch das füllen einer Line Zeit versaue beim ersten Zugriff. Wenn die Latenz sink bei gleicher Bandbreite, dann wird man auch die Lines eher wieder verkürzen wollen. Bei "Burstunfähigkeit" wirst Du sogar die Lines weglassen können, da es keinen Sinn mehr ergibt vom Aspekt der Geschwindigkeit her.

Cache Lines sind im Prinzip ein Glücksspiel - man hofft dabei zu gewinnen und schaut, dass die Chancen dazu gut stehen - ne Garantie drauf hat man aber nicht. Ein gezielt drauf abgestimmtes Testprogram, das eben nur einen Zugriff je Line ausfürt, würde benachteiligt bei grosser Linesize, weil viele Daten umsonst durch die Gegend wandern.Korrekt, auch wenn ich den Begriff "statistisches Problem" vorziehen würde. Lines einer spezifischen Größe machen dann keinen Sinn mehr, wenn

t(line-fetch-from-memory) + #avg-line-accesses * t(cache-latency) >= #avg-line-accesses * t(data-fetch-from-memory)

gilt. Bei heutiger Technik wird dieses Situation allerdings nie auftreten.
Es ist auch die Frage, was zuerst war - die Lokalität oder die heutigen Caches... Ich tippe mal auf Letzteres, denn die Compiler für die neuen CPUs erschufen imho diese Lokalität oft erst selber. Ein nicht P4 optimierter Code bringt nen P4 ja nicht grad zum Fliegen und das war nicht nur beim P4 so.Die Lokalität, z.B. in der klassischen Form des Arrays oder von sequentiellem Maschinencode.

[Haarmann]

Muh-sagt-die-Kuh

Ja, ich würde X86 zu µOps mal frech als Form der Datenkompression bezeichnen wollen.

Ich glaube im Bezug auf die Lines sind wir uns einig, auch wenn wirs ev nicht gleich ausdrücken.

Für mich ists eben sehr befremdlich, dass es sich lohnen soll LOOPS auszurollen. Das ergibt aus meiner Sicht wirklich keinen Sinn, denn Loops waren ja kreiert worden, damit man nicht ausrollt ;).

[Haarmann]

Muh-sagt-die-Kuh

Was würdest Du eigentlich von "Pipelined" RAM halten? Freie Zugriffe mit jeweils n Takten Verzögerung meine ich mit diesem RAM Typ.

[CrazyIvan]

Muh-sagt-die-Kuh

Was würdest Du eigentlich von "Pipelined" RAM halten? Freie Zugriffe mit jeweils n Takten Verzögerung meine ich mit diesem RAM Typ.

Das würde IMHO die Latenz in unermessliche Höhen steigen lassen, sofern nicht die Taktfrequenz erhöht wird. Bei solcherlei zeitkritischen Aktionen wie dem Speicherzugriff kann ich mir Pipelining nur schwer vorstellen. Aber mal sehen, was M-s-d-K davon hält ^^

[Muh-sagt-die-Kuh]

Muh-sagt-die-Kuh

Was würdest Du eigentlich von "Pipelined" RAM halten? Freie Zugriffe mit jeweils n Takten Verzögerung meine ich mit diesem RAM Typ.Verstehe ich das richtig? Jeden Takt eine Adresse, also z.B. 0x0FFE, 0xCA14, 0x000A und nach n Takten Wartezeit bekomme ich jeden Takt ein Ergebnis gelifert......eine Architektur, wie ich sie mir bei RAM nur sehr schwer vorstellen kann.

In diesem Fall kommt es drauf an, wie groß die Verzögerung ist....ist sie groß, könnten evtl. noch Streaming-Anwendungen profitieren, der Rest würde gnadenlos verlieren. Ist sie niedrig hätte man in bestimmten Situationen Vorteile ohne sich Nachteile einzuhandeln.

[Haarmann]

CrazyIvan

Nicht zwingend

Muh-sagt-die-Kuh

Latenz ist immer so tief wie möglich zu gestalten. Mir gefällt aber die Idee vom deterministischen Standpunkt aus.

[CrazyIvan]

Haarmann,
mit Beitrag Nummer 9000 wäre es doch an der Zeit, ein wenig präziser zu werden ;)
Was meinst Du mit nicht zwingend? Bei Verzehnfachung der Taktfrequenz würde eine 5 stufige Pipeline eine halb so hohe Latenz haben wie vorher. Soweit ist mir das klar. Allerdings, wie stellst Du Dir das vor und was am Vorgang des Lesens/Schreibens in/aus dem RAM würdest Du als Pipelinestufen klassifizieren. Oder einfach ausgedrückt: Wie sähe die Pipe Deiner Meinung nach aus.

[Haarmann]

CrazyIvan

Wenn Du dem RAM ne Aufgabe stellst, dann antwortets zwar erst in n Takten, aber Du kannst, wie bei ner CPU, trotzdem jeden Takt ne Aufgabe stellen. Die heutigen RAM können das vom Prinzip her schon nicht. Die (DDR ist damit gemeint oder DDR2) können ja auch nichtmals schreiben und lesen gleichzeitig.

[CrazyIvan]

Na wie Pipelining funktioniert wusste ich schon. Das Problem besteht aber darin, dass eine Anforderung n-Takte in der Pipe verbleibt, bis hinten wieder was rauskommt. Das ist schlecht für die Latenz und ne geringe Latenz ist nunmal beim RAM der wichtigste Aspekt. Es sei denn, man vergrößert die nachgelagerten Caches ins unendliche. Da dies aber unwirtschaftlich ist, wird wohl auch niemand auf die Idee kommen, den Speicher zu pipelinen.

[Haarmann]

CrazyIvan

Schau Dir mal die Entwicklung an - jedesmal, wenn die Bandbreite nen Schub nahm, gibt die Latenz doch rauf und ned runter. Das 35ns EDRAM (15ns bei Folgezugriffen) blieb wie Blei liegen. Man gurkte lieber mit "schnellen" 60ns EDOs rum...