Windhund, K9, Was sagt der Teesatz? Wer petzt?
- Ersteller Bokill
- Erstellt am
- Status
Kannst du mir mal sagen was das soll? Ich hab dir das schon genug begründet...
Wenn du das nicht lesen willst - pech. Die Speicherlatenz beim Opteron liegt so ca. 20% über der vom A64, damit aber noch um Dimensionen geringer als zB. beim P4.
Und Leute - denkt mal nach! 128MB L3, was soll das werden? Die Power5 Module wo 8 Kerne mit 128MB L3 draufsitzen kosten so viel wie ein Kleinwagen, und in der Liga kann AMD mit dem K8 noch nicht wirklich mitspielen.
Hier werden die schönsten Sachen zusammengedichtet...
Hätte der K8 einen 2mal so schnellen Decoder wäre das mit dem Cache sicherlich angebrachter, weil eine wartende Ausführungseinheit dann wirklich die IPC drückt.
Aber momentan sind die Ausführungseinheiten garnicht das Problem, davon gibts mehr als genug für Integer, und ausreichend viele für Float.
Dementsprechend ist es auch kein (großes) Problem wenn wegen einer Operation mal etwas gewartet werden muss, solange wird einfach was unabhängiges gerechnet.
Momentan setzt der Decoder das Limit. Und dem ist es egal ob da irgendwelche Daten nicht da sind, der Decodiert die Anweisungen einfach - fertig.
Und dem wäre auch mit mehr Cache nicht geholfen, davon spuckt der nicht auf einmal 4 µOPs pro Takt aus.
Das Desing hat so auch seine Vorteile - also der schlechte Decoder ist nichtmal unbedingt schlecht.
Während der P4 ziemlich einbricht wenn der Code nicht ideal kommt, ist das beim K8 kein großes Problem.
Und da steckt ja auch überhaupt die Idee vom K7 dahinter, Ausführungseinheiten sind recht einfach zu implementieren und vergleichsweise billig - also gibt man dem K7 (damals in einer Zeit, wo man kaum auf für den K7 optimierten Code bauen konnte) viele Ausführungseinheiten und spart in gewisser Weise beim Rest.
Dazu noch ein gutes OoO damit die Einheiten auch was zu tun bekommen, aber beim Decoder muss man keine Kopfstände vollziehen.
Ergebnis ist ein ziemlich ausgewogenes Desing. Beim P4 gibts so einige Totsünden, die man tunlichst meiden sollte, weil sich die Leistung dann irgendwo zwischen ganz miserablen und absolut unbrauchbar einpegelt.
Genauso gabs beim P6 ein paar solcher Totsünden, der P4 hat dank der langen Pipeline natürlich noch mehr.
Mal von den üblichen Sünden abgesehen (die alle CPUs haben und die sich auch anders begründen lassen - DIV und MUL, bzw. IDIV und IMUL zB.) kann man beim K7 und K8 nicht viel falsch machen. Und der schluckt fast alles ohne murren, selbst Code für den P4 schluckt der K8 ohne nennenswerte Leistungseinbußen - umgekehrt sieht ein P4 ohne optimierten oder wenigstens halbwegs optimierten Code kein Land.
Und weil der K8 eben nicht großartig unter mangelnden Daten leidet, weil die Ausführungseinheiten garnicht das Problem sind, bringt ein größerer Cache auch nicht wirklich was.
Beim K7 war das noch ein bisschen anders, der hat eine fast 2mal so hohe Speicherlatenz - ewig kann sich der Kern natürlich auch nicht mit OoO behelfen, genauso wie der K8 mit Cache sicherlich auch noch ein oder 2% zulegen würde.
Aber unterm Strich lohnt es sich einfach nicht.
Würde AMD jetzt einen K8a mit 2 parallel arbeitenden Decodern rausbringen wäre das schon wieder völlig anders. Dann könnte man problemlos jede Ausführungseinheit auslasten, und jede stillstehende Einheit würde IPC kosten.
So ist es nunmal aber nicht, der K8 hat nur einen Decoder.
Jetzt hab ich wieder 'nen halben Roman geschrieben. Hat ungefähr 30 Minuten gedauert. Ich würd mich ja nicht aufregen, hätte ich einen Geldbaum - dummerweise hab ich keinen, und nach dem allgemein bekannten Grundsatz Zeit=Geld kann und will ich nicht jeden Satz den ich irgendwo schreibe begründen bis zum geht-nicht-mehr.
Wobei ich ja vorher imho schon ausreichend begründet hab...
Zuletzt bearbeitet:
HenryWince
Vice Admiral Special
- Mitglied seit
- 06.08.2003
- Beiträge
- 673
- Renomée
- 23
@moccad_tom
Realistisch betrachtet ist das Nonsens. Es gibt gibt es drei Fälle die man Betrachten muss:
1) Die angeforderten Daten liegen gar nicht im Cache von CPU2: Dann wird ein normaler Memoryzyklus vom Speichercontroller der CPU2 gefahren. => Kein "L3 Effekt"
2) Die Daten liegen als Kopie im Cache von CPU2: Dann wird ebenfals ein normaler Memoryzyklus gefahren (Was dann einen Read-Snoop Hit erzeugt worauf die Cachzeile in CPU 2 einfach auf "Shared" gesetzt wird). => Ebenfals kein "L3 Effekt".
3) CPU2 hat die Daten bereits geändert, aber den Cache noch nicht in den Hauptspeicher zurückgeschreiben: Nur in diesem Fall werden die die Daten vom Cache der CPU2 aus anstelle vom Haupspeicher geholt und es gibt sowas wie einen "L3 Effekt". Allerdings ist dieser Fall sehr selten -- welche Software verändert permanent Daten die von MEHREREN Prozessen benötigt werden?
BTW. Das AMD diesen Spezialfall optimierte hat andere Gründe. In Intel-Systemen wird erst das Datum aus dem Cache der zweiten CPU zurückgeschrieben und dann erneut gelesen (=> zwei Memory-Zugriffe).
Realistisch betrachtet ist das Nonsens. Es gibt gibt es drei Fälle die man Betrachten muss:
1) Die angeforderten Daten liegen gar nicht im Cache von CPU2: Dann wird ein normaler Memoryzyklus vom Speichercontroller der CPU2 gefahren. => Kein "L3 Effekt"
2) Die Daten liegen als Kopie im Cache von CPU2: Dann wird ebenfals ein normaler Memoryzyklus gefahren (Was dann einen Read-Snoop Hit erzeugt worauf die Cachzeile in CPU 2 einfach auf "Shared" gesetzt wird). => Ebenfals kein "L3 Effekt".
3) CPU2 hat die Daten bereits geändert, aber den Cache noch nicht in den Hauptspeicher zurückgeschreiben: Nur in diesem Fall werden die die Daten vom Cache der CPU2 aus anstelle vom Haupspeicher geholt und es gibt sowas wie einen "L3 Effekt". Allerdings ist dieser Fall sehr selten -- welche Software verändert permanent Daten die von MEHREREN Prozessen benötigt werden?
BTW. Das AMD diesen Spezialfall optimierte hat andere Gründe. In Intel-Systemen wird erst das Datum aus dem Cache der zweiten CPU zurückgeschrieben und dann erneut gelesen (=> zwei Memory-Zugriffe).
PuckPoltergeist
Grand Admiral Special
Glaube ich nicht. Du kannst ja mal diverse Applikationen mit -march=pentium4, -march=
pentium4m, -march=prescott oder -march=nocona übersetzen, und das dann auf einen K8 los lassen. Ich bin mir sicher, dass dir dann in diversen Situationen ein SIGILL (Illegal Instruction) um die Ohren fliegen wird. Das Problem hatte ich letztens auch, als ich auf einem Athlon mit -march=athlon-xp übersetzt habe.
Ja, weil du bei march auch SSE, MMX und 3DNow einschaltest wenn es die CPU kann.
Und die P4 können kein 3DNow.
Abgesehen von den Erweiterungen können sowohl P4, als auch K7 und K8 den 686 Befehlssatz - und der ist identisch.
Also wenn du das vergleichen willst, compilier die Sache so:
K7 vs. P4: -march=... -mno-sse2 -mno-3dnow
K8 vs. P4: -march=... -mno-3dnow
Von den SIMD abgesehen unterscheiden sich die Befehlssätze der CPUs nicht im geringsten, wäre schlimm, wenn es so wäre.
EDIT:
Ich hab gerad mal AMBiX mit -march=pentium4 -mno-sse2 auf meinen K7 losgelassen, lief wie erwartet alles problemlos.
Wenn der GCC Code auf eine CPU optimiert betrifft das das Scheduling und die genutzten Anweisungen, bei x86 gibt es viele Wege die zum Ziel führen - mal ist der eine schneller, mal der andere.
Beispiel 93*25
MOV EAX, 93
MOV EBX, EAX
SHL EBX, 4
MOV ECX, EAX
SHL ECX, 3
ADD EBX, ECX
ADD ECX, EAX
oder
MOV EAX, 93
LEA EBX, [EAX*8+EAX]
LEA EBX, [EAX*16+EBX]
Hängt von der CPU ab, was da schneller ist. Beides errechnet aber die selbe Sache.
Gehen würde auch ganz banal
MOV EAX, 93
MOV EBX, 25
IMUL EAX, EBX
Aber das wäre auf aktuellen CPUs schlicht zu langsam.
Ein 386 dagegen könnte durchaus das IMUL schneller abarbeiten als die beiden Varianten oben.
Was der K7 nun schneller macht weis ich nicht genau, die beiden LEAs dürften Vector Path sein.
Ich würd mal denken, dass der K7 das am liebsten mag:
MOV EAX, 93
LEA EBX, [EAX*16+EAX]
MOV ECX, EAX
SHL ECX, 8
ADD EBX, ECX
Wobei ich mir aber nicht sicher bin, wie negativ sich die Vector Path Geschichte auswirkt.
Zuletzt bearbeitet:
rkinet
Grand Admiral Special
L3 Perfromance
Nur, der Gallatin profitiert deutlich von seinem L3, obwohl nur ca. 6-8 GByte/s liefern kann. Unter Umständen hat Intel noch leistungsfähige Schreibpuffer im Einsatz, sodaß man vielleicht kurzzeitig und für kleine Datenhäppchen von 2* 6 GByte/s reden kann.
Natürlich ist die Latenzzeit eines L3 im Vergleich zum DRAM besser.
Auf den K8 übertragen hätte ein ähnlich leistungsfähiger L3 nur begrenzt Vorteile im Vergleich zum bereits vorhandenen DRAM-Zugriff bzw. DDR-II 667 ff (= 1* 11 GByte/s max.)
Packt es AMD außerdem beim 'Pazifica' / Virtualisierung die Tasks jeweils einigermassen spezifisch einem der beiden physikalischen Cores zuzuordene (= wenig Dublikate in den beiden L2) wäre eine moderate Vergrößerung der L2 (2* 1,5MB oder 2* 2MB) effektiver.
Besonders, wenn AMD beim L2 gerade inaktive Bereiche stromsparend runter schalten kann (was wir bereits 2005 bei den Mobilen sehen werden) können die auf L3 verzichten.
Allerdings, ab 4-fach Core und Cluster wirds dann eng mit der Datenanlieferung. Hier erscheint aber die externe Lösung, wie bei IBM, und dann gleich 64-128-256 MB L3 vernünftiger. Sowas verteuert die Herstellung zwar dann leicht ($50-$100), nur AMD müßte am DIE nur eine Ansteuerlogik für externen Cache integrieren und könnte diese dann wahlweise nutzen oder eben inaktiv für Budget-Server-CPUs lassen.
Bem: L3 onchip scheint auch andere Probleme zu haben. So verzichtet Intel ja beim Dual-Core Itanium auf einen shared-L3, obwohl so dies bei 2* 9MB wirklich sinnvoll erscheint.
Besonders interessant, da ja andere Modellreihen (P-M Nachfolger) sogar shared-L2 haben. Wahrscheinlich ist ein L3-shared onchip kaum noch schneller als ein externer L3.
Nur, der Gallatin profitiert deutlich von seinem L3, obwohl nur ca. 6-8 GByte/s liefern kann. Unter Umständen hat Intel noch leistungsfähige Schreibpuffer im Einsatz, sodaß man vielleicht kurzzeitig und für kleine Datenhäppchen von 2* 6 GByte/s reden kann.
Natürlich ist die Latenzzeit eines L3 im Vergleich zum DRAM besser.
Auf den K8 übertragen hätte ein ähnlich leistungsfähiger L3 nur begrenzt Vorteile im Vergleich zum bereits vorhandenen DRAM-Zugriff bzw. DDR-II 667 ff (= 1* 11 GByte/s max.)
Packt es AMD außerdem beim 'Pazifica' / Virtualisierung die Tasks jeweils einigermassen spezifisch einem der beiden physikalischen Cores zuzuordene (= wenig Dublikate in den beiden L2) wäre eine moderate Vergrößerung der L2 (2* 1,5MB oder 2* 2MB) effektiver.
Besonders, wenn AMD beim L2 gerade inaktive Bereiche stromsparend runter schalten kann (was wir bereits 2005 bei den Mobilen sehen werden) können die auf L3 verzichten.
Allerdings, ab 4-fach Core und Cluster wirds dann eng mit der Datenanlieferung. Hier erscheint aber die externe Lösung, wie bei IBM, und dann gleich 64-128-256 MB L3 vernünftiger. Sowas verteuert die Herstellung zwar dann leicht ($50-$100), nur AMD müßte am DIE nur eine Ansteuerlogik für externen Cache integrieren und könnte diese dann wahlweise nutzen oder eben inaktiv für Budget-Server-CPUs lassen.
Bem: L3 onchip scheint auch andere Probleme zu haben. So verzichtet Intel ja beim Dual-Core Itanium auf einen shared-L3, obwohl so dies bei 2* 9MB wirklich sinnvoll erscheint.
Besonders interessant, da ja andere Modellreihen (P-M Nachfolger) sogar shared-L2 haben. Wahrscheinlich ist ein L3-shared onchip kaum noch schneller als ein externer L3.
Ich glaub AMD wird sich jetzt erstmal mit großartigen Experimenten zurückhalten und sich mit dem K8 so wie er ist - und später als Dualcore - im Markt etablieren.
Jetzt noch einen L3 anzufrickeln (mehr ist es ja nicht, dafür müsste man den Memory Controller nochmal zerlegen) halte ich für zu fehlerträchtig.
Jetzt noch einen L3 anzufrickeln (mehr ist es ja nicht, dafür müsste man den Memory Controller nochmal zerlegen) halte ich für zu fehlerträchtig.
Dresdenboy
Redaktion
☆☆☆☆☆☆
Habe gerade einen passenden Kommentar gefunden:
Code:
# -march=<cpu-type> means to take full advantage of the ABI and instructions
# for the particular CPU; this will break compatibility with older CPUs (for
# example, -march=athlon-xp code will not run on a regular Athlon, and
# -march=i686 code will not run on a Pentium Classic.rkinet
Grand Admiral Special
hä ?
Der Dual-Core ist fertig und ohne L3.
Die 'Pazifica' Reihe (ab 2006) dürfte in der Endphase des Designs liegen und da hat AMD ja schon DDR-II (in einigen Modellen) bestätigt und das Gerücht zum Socket 1207 geht um.
Vielleicht hängt AMD -vgl. ATI RS480 - schnelles RAM optional an die CPU, daß dann eben L3 wäre.
Zur Erinnerung: Das K8-Konzept sieht bereits Zugriffe auf estrenes RAM vor, im Opteron auch verfügbar bzw. als Variante beim K8 / Zugriff von onboard-Grafikchips per HTr auf das CPU-Memory. AMD hat schon 90% des Weges für L3 erledigt, nur noch die Frage ob es sich rechnet.
rkinet
Grand Admiral Special
Original geschrieben von i_hasser
Ich meinte deinen Quad-Core.
Meiner ?
Das war einmal - AMD sprach am 12.11 von 4-fach und 8-fach in absehbarer Zukunft (also 2007/8 ff.) Dafür aber muß AMD bereits heute den neuen Socket für 'Pacifica' auslegen, wenn er dann auch schon kommt.
Man muss leider aufpassen, daß nicht inoffizielle AMD-roadmap und der Technologieplan von AMD vermischt wird. Intern dürfte AMD irgendwo bei 2010 liegen, nur fast fertige Designs spielen sich eher bei 2006/7 ab.
Mit IBM hat man ja bis Ende 2008 schon eine exakte Fertigungsplanung verabschiedet.
Zur Erinnerung: Zum Jahreswechel 2003/4 tauchten erste Infos zum E-Stepping auf, das tatsächlich jetzt zwischen Anfang 2005 und Mitte 2005 (Dual-K8 ) in die Läden kommt.
Wenn AMD beim simplen Stepping schon 1-1,5 Jahre vor der tatsächlichen Fertigung liegt, kann man sich bei anderen tiefgreifenderen Neuerungen eher 2-3 Jahre denken. Dies wird in den nächsten Jahren in Übereinstimmung mit der Fertigunsrealisierung dann umgesetzt.
Ich halte die Diskussion über L3-Cache für die anspruchsloseste Komponente im Zusammenhang von Innovation und Zukunftsentwicklung.
Schon dem Athlon K7 im Slot A Zeitalter sollte bei Gelegenheit dies zur Seite gestellt werden.
AMD Thunderbird kommt am 5. Juni
Micron entwickelt DDR-Chipsatz für Athlon
Micron Scimitar schon im März? und jetzt kommt`s
Und etwas epischer Prozessorgeflüster
Von Samuel, Samurai und Scimitar
1. Dies bedeutet, es hat schon Sinn L3 zu implementieren, nur halt bei den dicken Eisen.
2. Es scheint aber nachragig.
3. Andere können dieses auch für ihre Chipsätze implementieren.
4. Dank Horus, kann bei Mehrfachprozessorsystemen die Latenz zwischen den verschiedenen CPU nochmals verbessert werden.
5. Bisher hat sich AMD vieles von den Alphas abgeschaut. Ein L3 war auch bei EV-8 nicht zwingend vorgesehen. Gleichwohl war es aber möglich. Die Entwickler des Alphas schauten nach schnellsten I/O Verbindungen. Der EV-7 hatte mit RAMBUS das schnellste an Speichertechnologie, was möglich war. Und dieser RAMBUS war mit einem integrierten Speicherkontroller angebunden. Vor Hypertransport hatte der EV-7 eine ähnliche Systemverbindung. Zur damaligen Zeit brannte diese System alles andere weg.
-> Alpha schaute nach schnellen Systemverbindungen. Und schaute nach Rechenstarken Kernen.
L3 Kann "jeder" nachträglich reinfrickeln. Das sollten die Beispiele mit dem Speicherhersteller Micron verdeutlichen.
Nachtrag
@mocad_tom
). So weit ich dies in Erinnerung habe läuft derzeit der Statische RAM auf dem MCM des Power 5 mit halber Taktfrequenz siehe PDF Seite 42
Speicher und Cache haben unterschiedlichen Transistoraufwand.
Der Lohn bei Cache ist der wesentlich schnellere Zugriff. Die Megaherzangabe ist in diesem Falle eher eine Desinformation.
S-RAM (Static Random Access Memory)steht für statischen Speicher. Die Speicherinfos bleiben statisch im Speicher (Flip-Flop-Aufbau). Das kostet aber auch mehr Transistoren (Faktor häufig üblicherweise 6x ).
D-RAM (Dynamic Random Access Memory) ist der typische Arbeitsspeicher, für Grafikkarten, Speichermodule ... kurzum für alle möglichen Zwecke die vorrangig günstig sein sollen. Der Preis ist, dass beständig die Speicherzellen aufgefrischt (refresh) werden müssen, sonst ist der Speicherinhalt verschwunden. Der Refresh blockiert aber für eine gewisse Zeit den Zugriff.
MFG Bokill
Schon dem Athlon K7 im Slot A Zeitalter sollte bei Gelegenheit dies zur Seite gestellt werden.
AMD Thunderbird kommt am 5. Juni
Micron entwickelt DDR-Chipsatz für Athlon
Micron Scimitar schon im März? und jetzt kommt`s
Und etwas epischer Prozessorgeflüster
Von Samuel, Samurai und Scimitar
1. Dies bedeutet, es hat schon Sinn L3 zu implementieren, nur halt bei den dicken Eisen.
2. Es scheint aber nachragig.
3. Andere können dieses auch für ihre Chipsätze implementieren.
4. Dank Horus, kann bei Mehrfachprozessorsystemen die Latenz zwischen den verschiedenen CPU nochmals verbessert werden.
5. Bisher hat sich AMD vieles von den Alphas abgeschaut. Ein L3 war auch bei EV-8 nicht zwingend vorgesehen. Gleichwohl war es aber möglich. Die Entwickler des Alphas schauten nach schnellsten I/O Verbindungen. Der EV-7 hatte mit RAMBUS das schnellste an Speichertechnologie, was möglich war. Und dieser RAMBUS war mit einem integrierten Speicherkontroller angebunden. Vor Hypertransport hatte der EV-7 eine ähnliche Systemverbindung. Zur damaligen Zeit brannte diese System alles andere weg.
-> Alpha schaute nach schnellen Systemverbindungen. Und schaute nach Rechenstarken Kernen.
L3 Kann "jeder" nachträglich reinfrickeln. Das sollten die Beispiele mit dem Speicherhersteller Micron verdeutlichen.
Nachtrag
@mocad_tom
Sehr unwahrscheinlich
). So weit ich dies in Erinnerung habe läuft derzeit der Statische RAM auf dem MCM des Power 5 mit halber Taktfrequenz siehe PDF Seite 42Derzeit ist da demnach Statischer RAM bei knapp realen physikalischen! 1 GHz ... verdammt viel Holz vor der Hütte)
Speicher und Cache haben unterschiedlichen Transistoraufwand.
Der Lohn bei Cache ist der wesentlich schnellere Zugriff. Die Megaherzangabe ist in diesem Falle eher eine Desinformation.
S-RAM (Static Random Access Memory)steht für statischen Speicher. Die Speicherinfos bleiben statisch im Speicher (Flip-Flop-Aufbau). Das kostet aber auch mehr Transistoren (Faktor häufig üblicherweise 6x ).
D-RAM (Dynamic Random Access Memory) ist der typische Arbeitsspeicher, für Grafikkarten, Speichermodule ... kurzum für alle möglichen Zwecke die vorrangig günstig sein sollen. Der Preis ist, dass beständig die Speicherzellen aufgefrischt (refresh) werden müssen, sonst ist der Speicherinhalt verschwunden. Der Refresh blockiert aber für eine gewisse Zeit den Zugriff.
MFG Bokill
Zuletzt bearbeitet:
mocad_tom
Admiral Special
- Mitglied seit
- 17.06.2004
- Beiträge
- 1.234
- Renomée
- 52
Zum Glück kriegt man hier auch mal die Leute an die Strippe, die sich länger mit solchen Sachen befassen - da lass ich mir den "Nonsens" dann auch gefallen.
Hier wäre kein Hauptspeicherzugriff besonders gewinnbringend.
Wenn man solche Sachen nachgoogled kann es vorkommen, das 3 Treffer kommen, und dann meistens Powerpoint-Präsentationen für Presseleute.
gefunden hier
Der Speicher, der auf diesen Grafikkarten verwendet wird spielt durchaus in der Gewichtklasse eines Power5-L3-Cache-Moduls.
Der Opteron Skaliert sehr gut mit gutem Hauptspeicher.
Werde ich aber beauftragt:
Baue ein System mit möglichst schnellem und zugleich möglichst viel Hauptspeicher bei gegebenem Kostenrahmen.
Nun wird es schwierig, weil schneller Speicher ist teuer.
Ich sehe FB-DIMM so positioniert, das er sehr groß ist, dabei aber noch relativ günstig.
16Gbyte-FB-DIMM-Module wird es wohl schon zur Einführung geben.
Baut man heutzutage einen gewöhnlichen Arbeitsrechner - z. B. für einen Programmierer.
So bringt am allermeisten ein RAID-System - damit sticht man jeden A64FX55 aus.
Nun bringen 16GB Hauptspeicher wenig, wenn alles von der Festplatte aus geladen werden muss. Einem Datenbankserver ist das egal - der wird einmal gestartet, legt sich seinen Datenpool zurecht und werkelt dann drauf los - sind 16GB vorhanden - schön.
Ein Otto-Normal-Windows-User kann davon im moment noch nicht profitieren - alles zu Festplattenabhängig.
Aber Microsoft hat schon seinen Testballon gestartet, wie man diesen Flaschenhals weiten kann. In Windows PocketPC 2002 werden Programme nicht mehr beendet sondern nur in den Hintergrund geschoben. Solange bis der Hauptspeicher voll ist. Lange Ladezeiten finden nur direkt nach einem Reset statt. Ähnlich macht es das Desktop-Outlook, nur ein Vorbote dafür was kommen wird. Suspend-To-Ram und Suspend-To-Disk sind hier Schlüsselfeatures.
Mich würde es nicht wundern, wenn in einen FB-DIMM eine eigene Batterie integriert wird, um den Datenbestand zu halten - vielleicht eine Wiedergeburt der Solid-State-Disk - evtl. wird nicht DDR2-Ram für FB-DIMM eingesetzt sondern deutlich dichter gepackte Techniken. Der FB-DIMM-Controller ist zuständig für paralleles ansprechen mehrerer langsamer Speicherzellen - vielleicht sogar Flash-ähnliche-Techniken.
Grüße,
Tom
Wie sieht dieser Fall bei einem Dual-Core-Opteron aus?
Hier wäre kein Hauptspeicherzugriff besonders gewinnbringend.
Wenn man solche Sachen nachgoogled kann es vorkommen, das 3 Treffer kommen, und dann meistens Powerpoint-Präsentationen für Presseleute.
Profizocker stecken sich also zwei Kleinwagen in Ihren Rechner?
gefunden hier
Der Speicher, der auf diesen Grafikkarten verwendet wird spielt durchaus in der Gewichtklasse eines Power5-L3-Cache-Moduls.
Der Opteron Skaliert sehr gut mit gutem Hauptspeicher.
Werde ich aber beauftragt:
Baue ein System mit möglichst schnellem und zugleich möglichst viel Hauptspeicher bei gegebenem Kostenrahmen.
Nun wird es schwierig, weil schneller Speicher ist teuer.
Ich sehe FB-DIMM so positioniert, das er sehr groß ist, dabei aber noch relativ günstig.
16Gbyte-FB-DIMM-Module wird es wohl schon zur Einführung geben.
Baut man heutzutage einen gewöhnlichen Arbeitsrechner - z. B. für einen Programmierer.
So bringt am allermeisten ein RAID-System - damit sticht man jeden A64FX55 aus.
Nun bringen 16GB Hauptspeicher wenig, wenn alles von der Festplatte aus geladen werden muss. Einem Datenbankserver ist das egal - der wird einmal gestartet, legt sich seinen Datenpool zurecht und werkelt dann drauf los - sind 16GB vorhanden - schön.
Ein Otto-Normal-Windows-User kann davon im moment noch nicht profitieren - alles zu Festplattenabhängig.
Aber Microsoft hat schon seinen Testballon gestartet, wie man diesen Flaschenhals weiten kann. In Windows PocketPC 2002 werden Programme nicht mehr beendet sondern nur in den Hintergrund geschoben. Solange bis der Hauptspeicher voll ist. Lange Ladezeiten finden nur direkt nach einem Reset statt. Ähnlich macht es das Desktop-Outlook, nur ein Vorbote dafür was kommen wird. Suspend-To-Ram und Suspend-To-Disk sind hier Schlüsselfeatures.
Mich würde es nicht wundern, wenn in einen FB-DIMM eine eigene Batterie integriert wird, um den Datenbestand zu halten - vielleicht eine Wiedergeburt der Solid-State-Disk - evtl. wird nicht DDR2-Ram für FB-DIMM eingesetzt sondern deutlich dichter gepackte Techniken. Der FB-DIMM-Controller ist zuständig für paralleles ansprechen mehrerer langsamer Speicherzellen - vielleicht sogar Flash-ähnliche-Techniken.
Grüße,
Tom
rkinet
Grand Admiral Special
@Bokill , ich habe lange lässig an den Sinn von L3 geglaubt - aber Du hast wohl recht.
Ein schneller Pufferspeicher ist bestimmt für manches sinnvoll, aber er bremst die Cachelogik an der CPU auch wiederum aus.
Wahrscheinlich ist es sinvoller einen Cache an einen FBDIMM-Controller zu hängen und die CPU holt und schreibt 'gedankenlos' einfach bidirektional auf den Controller.
Im Prinzip wie bei einer Festplatte, deren Cache ebenso wirkt und herstellerspezifisch optimiert wird.
Die FBDIMM Hersteller könnten dann Cache und DRAM-Chips optimal aufeinander abstimmen, eben wie bei der Platte.
Die CPU-Hersteller könnten dann die CPU-interne Cachestrategie anhand des CPU-internen Taktes und der FBDIMm Spezifikation (mal 2* 10 GByte/s / mehrere Module parallel) optimieren. Der Aufwand für einen zusätzlichen FBDIMM-Controller wäre so wirtschaftlich sinnvoll und z.B. ein 16-64 MB-Cachechip gleich mit integrierbar in den Baustein - z.B. in einem 1 GByte Modul.
Shdow
Vice Admiral Special
wäre auch unsinnig wenn man einen integrierten memory controler hat da noch einen cache dazwischen zu hängen. da der cache ja dem ram gleichzusetzen ist...
Soll ich das mit dem lange befassen mal falsch verstehen?
Die Sache oben bezieht sich auf den K7, der hat Speichermäßig übrigens nicht so wirklich viel mit dem K8 gemein.
Wie war das doch noch? Der K8 ist die erste CPU, bei der bei zB. Seti die Rechenleistung und nicht mehr das Speicherinterface bremst. Dabei ging es da afair um eine 64 Bit Speicheranbindung, nichtmal 128 Bit.
Ein L3 Cache macht beim K8 einfach nicht so wirklich viel Sinn - da kann man nix dran ändern. Die IPC ist vom K7 zum K8 nach oben geschossen, ohne, dass sich was an den eigentlichen Flaschenhälsen geändert hat (Erläuterungen siehe oben, falls mir jetzt wieder irgendjemand mangelnde Argumente unterstellen will...).
Eine Verbesserung die viel bringen würde wäre zB. sowas wie der Trace Cache beim P4 - das würde den Decoder sehr stark entlasten.
Vom L3 dagegen hat der K8 einfach nix.
Die Sache oben bezieht sich auf den K7, der hat Speichermäßig übrigens nicht so wirklich viel mit dem K8 gemein
.Wie war das doch noch? Der K8 ist die erste CPU, bei der bei zB. Seti die Rechenleistung und nicht mehr das Speicherinterface bremst. Dabei ging es da afair um eine 64 Bit Speicheranbindung, nichtmal 128 Bit.
Ein L3 Cache macht beim K8 einfach nicht so wirklich viel Sinn - da kann man nix dran ändern. Die IPC ist vom K7 zum K8 nach oben geschossen, ohne, dass sich was an den eigentlichen Flaschenhälsen geändert hat (Erläuterungen siehe oben, falls mir jetzt wieder irgendjemand mangelnde Argumente unterstellen will...).
Eine Verbesserung die viel bringen würde wäre zB. sowas wie der Trace Cache beim P4 - das würde den Decoder sehr stark entlasten.
Vom L3 dagegen hat der K8 einfach nix.
rkinet
Grand Admiral Special
nein
FBDIMM liegt im Transferverhalten etwa wie PCIe oder HTr.
Und per HTr kann man sogar rel. performant onboard-Grafik betreiben (ATI RS480) oder eine Grafikkarte per PCIe auf DRAM zufreifen (ATI zukünftiges Budget-Konzept).
Die ATI schlägt übrigens Intel onboard, obwohl die ja direkt auf 128 Bit DRAM zugreifen kann (ist theoretisch sogar gut erklärbar).
Seriell macht da nichts, da die Bitrate weit über den Möglichkeiten der DRAMs liegt.
Bliebe also dabei - ein Cache direkt beim FBDIMM würde in Summe mehr bringen, als ein L3 bei der CPU. Zusätzlich 'trödelt' L3 im Vergleich zum L2 gewaltig, obwohl er ähnliche Transistoren wie der wesentlich schnellere L2 enthält.
Noch ein Trumpf-ASS: Es blieb unbemwerkt, aber Intel verabschiedet sich ja beim Xeon ja schon wieder vom L3 und nimmt zukünftig 2M-L2 bzw. 4M-L2.
Nur der Dual-Core IA64 bekommt L3, aber 'komischerweise' nicht shared, sondern weiterhin exklusiv für je einen der L2. Im Prinzip also kein echter L3 mehr, sondern ein großer, aber stromgünstig arbeitender Core-naher Cache der als reiner L2 (noch) niicht machbar wäre. Auch der Dothan-Nachfolger bekommt keinen L3, sondern shared L2.
Fazit: L3 = problematisches Design, und nicht der Favorit der CPU-Bauer.
FBDIMM könnte problemlos sogar schneller sein als der bisher per BUS angebundene RAM.
Seriell hat früher vielleicht langsam bedeutet, heute bedeutet seriell 'rattenschnell', weil die Technik dafür ausgereift ist.
Praktisch wäre es nicht das Problem ein Quadchannel Board mit FBDIMMs zu basteln. Bei den heute üblichen Datenraten würde das schlappe 12.8GB/s ergeben. Alles andere als wenig.
Und die Latenzen entstehen sowieso hauptsächlich im Speichermodul wegen der Taktumsetzung (und die Speicherbausteine selbst taktet man ja nur im Bereich von 100 bis 200MHz, selbst bei DDR2 - daher auch die hohen Latenzen bei DDR2).
Da könnte eine serielle Anbindung endlich die Wende bringen, weil die Datenleitungen nicht mehr so stark belastet sind und sich problemlos ein höherer Chiptakt bei gleicher Taktumsetzung (DDR 1:2, DDR2 1:4) realisieren ließe.
Sprich man könnte problemlos langsame Module und schnelle Module verkaufen. Das Problem bei DDR2 sind doch wieder nur die Datenleitungen, wesswegen man auch erstmal gemächlich vorranschreitet.
Von der Sache her ist der Speicherbus das einzige Konzept, das seit dem 8086 nicht geändert wurde - und das wird allerhöchste Zeit.
Seriell hat früher vielleicht langsam bedeutet, heute bedeutet seriell 'rattenschnell', weil die Technik dafür ausgereift ist.
Praktisch wäre es nicht das Problem ein Quadchannel Board mit FBDIMMs zu basteln. Bei den heute üblichen Datenraten würde das schlappe 12.8GB/s ergeben. Alles andere als wenig.
Und die Latenzen entstehen sowieso hauptsächlich im Speichermodul wegen der Taktumsetzung (und die Speicherbausteine selbst taktet man ja nur im Bereich von 100 bis 200MHz, selbst bei DDR2 - daher auch die hohen Latenzen bei DDR2).
Da könnte eine serielle Anbindung endlich die Wende bringen, weil die Datenleitungen nicht mehr so stark belastet sind und sich problemlos ein höherer Chiptakt bei gleicher Taktumsetzung (DDR 1:2, DDR2 1:4) realisieren ließe.
Sprich man könnte problemlos langsame Module und schnelle Module verkaufen. Das Problem bei DDR2 sind doch wieder nur die Datenleitungen, wesswegen man auch erstmal gemächlich vorranschreitet.
Von der Sache her ist der Speicherbus das einzige Konzept, das seit dem 8086 nicht geändert wurde - und das wird allerhöchste Zeit.
mocad_tom
Admiral Special
- Mitglied seit
- 17.06.2004
- Beiträge
- 1.234
- Renomée
- 52
@rkinet
Glaubst du das ATI, wenn FB-DIMM eingeführt wird, die HighEnd-Grafikkarten ohne Onboard-RAM verkauft, mit der Begründung die RAM-Anbindung ist so schnell.
Vielleicht ist ja der Bergriff L3-Cache nicht richtig von mir gewählt.
Nennen wir es sehr schnellen (in Sachen Latenzen) Lokalen RAM.
FB-DIMM spielt die Rolle des globalen RAM.
In Rechnertechnik haben wir ein Speicher-Oszi (war damals nur ein Praktikum) aufgebaut.
Eine VME-Rechner-Platine laß einen A/D-Wandler aus, schrieb die Werte in eine VME-Karte, die nur mit Speicher bestückt war. Die zweite VME-Rechner-Karte steuerte einen D/A-Wandler, der wiederrum die X- und Y-Koordinate eines Oszi-Bildschirms ansteuerte.
Es wurde gefordert, einen möglichst großen Zeitraum im Speicher abzulegen, deshalb auch der Zwang zur Speicherkarte, ansonsten hätten wir die Onboard-RAMs der VME-Prozessorkarten verwenden können.
Es war ein gezirkeltes Beispiel, aber der Prof wollte uns eben ein eng gekoppeltes System mit gemeinsamen Speicher aufs Auge drücken. Es war aber trotzdem wichtig die Daten zunächst in den lokalen RAM zu Sammeln, um sie dann in großen Happen auf die Speicherkarte zu schreiben - sonst hätte der VME-Bus wegen dem hohen Overhead zugemacht.
Grüße,
Tom
Glaubst du das ATI, wenn FB-DIMM eingeführt wird, die HighEnd-Grafikkarten ohne Onboard-RAM verkauft, mit der Begründung die RAM-Anbindung ist so schnell.
Vielleicht ist ja der Bergriff L3-Cache nicht richtig von mir gewählt.
Nennen wir es sehr schnellen (in Sachen Latenzen) Lokalen RAM.
FB-DIMM spielt die Rolle des globalen RAM.
In Rechnertechnik haben wir ein Speicher-Oszi (war damals nur ein Praktikum) aufgebaut.
Eine VME-Rechner-Platine laß einen A/D-Wandler aus, schrieb die Werte in eine VME-Karte, die nur mit Speicher bestückt war. Die zweite VME-Rechner-Karte steuerte einen D/A-Wandler, der wiederrum die X- und Y-Koordinate eines Oszi-Bildschirms ansteuerte.
Es wurde gefordert, einen möglichst großen Zeitraum im Speicher abzulegen, deshalb auch der Zwang zur Speicherkarte, ansonsten hätten wir die Onboard-RAMs der VME-Prozessorkarten verwenden können.
Es war ein gezirkeltes Beispiel, aber der Prof wollte uns eben ein eng gekoppeltes System mit gemeinsamen Speicher aufs Auge drücken. Es war aber trotzdem wichtig die Daten zunächst in den lokalen RAM zu Sammeln, um sie dann in großen Happen auf die Speicherkarte zu schreiben - sonst hätte der VME-Bus wegen dem hohen Overhead zugemacht.
Grüße,
Tom
Bei deinem Beispiel fehlt aber was - nämlich die Cache Line Size vom L2 Cache.
Die ist normalerweise schon so groß wie einige der gequantelten Speicherzellen von RAM (weis garnimmer wie groß wie waren![:]](https://www.planet3dnow.de/vbulletin/images/smilies/rolleyes.gif "Augen rollen (sarkastisch) :]")
... müssten so ein paar Bytes gewesen sein, glaub so um die 8). Von daher gibts heute keinen Overheat mehr.
Der existiert nur zwischen Recheneinheiten und L1 Cache. Der L1 fängt das dann schon komplett auf.
Und bei den wirklich weit verteilten Zugriffen (Adressen, die in verschiedenen Columns auf dem Riegel liegen) nutzt eben ein kleinerer Cache auch nicht viel, weil die Daten da nie alle reinpassen.
Ein großer Cache dagegen hat eine höhere Latenz bei Zugriffen, und damit hätte sich das Thema eh erledigt.
Die ist normalerweise schon so groß wie einige der gequantelten Speicherzellen von RAM (weis garnimmer wie groß wie waren
... müssten so ein paar Bytes gewesen sein, glaub so um die 8). Von daher gibts heute keinen Overheat mehr.Der existiert nur zwischen Recheneinheiten und L1 Cache. Der L1 fängt das dann schon komplett auf.
Und bei den wirklich weit verteilten Zugriffen (Adressen, die in verschiedenen Columns auf dem Riegel liegen) nutzt eben ein kleinerer Cache auch nicht viel, weil die Daten da nie alle reinpassen.
Ein großer Cache dagegen hat eine höhere Latenz bei Zugriffen, und damit hätte sich das Thema eh erledigt.
rkinet
Grand Admiral Special
nun, FBDIMM hat mit der GraKa wenig am Hut.
Die hängt an 2* 4 GByte/s PCIe x16, zukünftig vielleicht mehr.
Heutige Grakas arbeiten aber anders als der PC mit teurem DRAM, aber ohne sonstigem Cache.
ATI will alles, was weniger zeitkritisch ist, auch in dieses preiswerte RAM auslagern, dafür aber schnelleres RAM für lokale Prozesse der GraKa nehmen.
128, 256 oder gar 512 MB schneller GraKa-Speichert sind herausgeworfenes Geld.
Noch schlimmer, wenn man an Dual-GraKa Designs denkt, die fast alle Daten lokal doppelt halten müssen.
Könnte mir zukünftige Grakas vorstellen mit 4 GraKa Chips und je 64 MB lokalem DRAM zzgl. 0.5 bis 1 GB DRAM-Belegung. Bei einem zukünftigen 2 GB-PC nun kein Problem und kostengünstiger als 4* 512MB GDDR4 - oder ?
HenryWince
Vice Admiral Special
- Mitglied seit
- 06.08.2003
- Beiträge
- 673
- Renomée
- 23
@mocad_tom
> Wie sieht dieser Fall bei einem Dual-Core-Opteron aus?
> Hier wäre kein Hauptspeicherzugriff besonders gewinnbringend.
Genauso.
Prinzipieller Ablauf von Bus Snooping & MOESI beim K8:
- The home node starts accessing main memory and in parallel broadcasts the request to all the nodes via point-to-point messages
- The nodes individually snoop the request, take appropriate coherence actions in their local caches, and sends data (if someone has it in M or O state) or an empty completion acknowledgment to the requester; the main memory also sends the data speculatively
- After gathering all responses the requester sends a completion message to the home node so that it can proceed with subsequent requests (this completion ack may be needed for serializing conflicting requests)
> Wenn man solche Sachen nachgoogled kann es vorkommen, das 3 Treffer kommen, und dann meistens Powerpoint-Präsentationen für Presseleute.
Ja, leider
Kleiner Tipp gute Infos bekommt man auch von Fachverbänden wie z.B. <WERBUNG> IEEE </WERBUNG>. Im ernst, als Student rentiert es sich besonders deren Angebote wahrzunehmen. Zum K8 gab es in der März/April Ausgabe <Edit: letzten Jahres> des IEEE Micro einen guten Artikel der das Verwendete Cachecoherenz-Verfahren recht gut erklärt. Schau mal auf www.computer.org ob das nicht was für dich sein könnte.
> Wie sieht dieser Fall bei einem Dual-Core-Opteron aus?
> Hier wäre kein Hauptspeicherzugriff besonders gewinnbringend.
Genauso.
Prinzipieller Ablauf von Bus Snooping & MOESI beim K8:
- The home node starts accessing main memory and in parallel broadcasts the request to all the nodes via point-to-point messages
- The nodes individually snoop the request, take appropriate coherence actions in their local caches, and sends data (if someone has it in M or O state) or an empty completion acknowledgment to the requester; the main memory also sends the data speculatively
- After gathering all responses the requester sends a completion message to the home node so that it can proceed with subsequent requests (this completion ack may be needed for serializing conflicting requests)
> Wenn man solche Sachen nachgoogled kann es vorkommen, das 3 Treffer kommen, und dann meistens Powerpoint-Präsentationen für Presseleute.
Ja, leider
Kleiner Tipp gute Infos bekommt man auch von Fachverbänden wie z.B. <WERBUNG> IEEE </WERBUNG>. Im ernst, als Student rentiert es sich besonders deren Angebote wahrzunehmen. Zum K8 gab es in der März/April Ausgabe <Edit: letzten Jahres> des IEEE Micro einen guten Artikel der das Verwendete Cachecoherenz-Verfahren recht gut erklärt. Schau mal auf www.computer.org ob das nicht was für dich sein könnte.
mocad_tom
Admiral Special
- Mitglied seit
- 17.06.2004
- Beiträge
- 1.234
- Renomée
- 52
Habe aber bisher in einem Prozessor noch keinen Datenbus seriell gesehen. Serialisierung Deserialisierung kostet immer. Man kann auch parallele Bussysteme differenziell auslegen und höllisch schnelle Datenraten erreichen. Ist eine PCIe-Verbindung immer noch seriell, wenn man 16-Lanes verlegen muss, um diese Datenrate zu erreichen.
Aller allerhöchste Zeit
Hat jemand eine Simulation für die Speicherhierarchien zu Hause rumstehen. Das war in der Vorlesung schon immer ein heftiges Thema. Zu beachten:
Bandbreite Latenz Kostenaufwand Worst-Case-Szenarien bei Multi-Sockel-Systeme.
Was ich hier schreibe ist spekulativ, aber wie rkinet schon schreibt, muss man sich vor sehr viel kreativeren Konsolen-Architekturen in acht nehmen.
Genau das wolllte ich mit dem vorherigen Beispiel des Datenbankservers sagen. Es ist total überteuert den feinsten 16GB Overclocker-DDR500-Speicher in einen Datenbankserver zu stecken(abgesehen davon, das er nicht zertifiziert ist).
Grüße,
Tom
Das letzte Zitat ist nicht von mir .
Der Nachteil der serialisierung fällt denke ich mit 16 Lanes weg - da schwappen 2 Byte pro Takt durch, müsste reichen. Der Unterschied zur parallelen Übertragung ist, dass die Trennung der Daten schon weiter oben in der Hierarchie stattfindet. Die letztendlichen Datenleitungen laufen dann nicht mehr parallel, sondern eben jede für sich - das ist ja auch der große Vorteil von serieller Übertragung, dass man viel besser auf die elektrischen Eigenheiten der Leitungen eingehen kann und sogar im Betrieb die Signalflanken anpassen kann.
Damit fallen die aufwändigen Layoutprobleme weg, was eine wirkliche Erleichterung ist.
Übrigens kommt die serielle Verbindung schon bei so einigen Dualopteronsystemen zum Einsatz, wo die 2. CPU am HTr Link der 1. nuckelt und keinen Speicher bekommt. Performancemäßig ist das garnicht mal so schlecht wenn die eine CPU DualChannel bekommt - ich bin mir nicht mehr sicher, die zusätzliche Latenz liegt aber irgendwo im Bereich von 10 Takten.
Zum Vergleich: Ein ECC Speicherzugriff dauert in der Regel so um die 60 Takte.
. Der Nachteil der serialisierung fällt denke ich mit 16 Lanes weg - da schwappen 2 Byte pro Takt durch, müsste reichen. Der Unterschied zur parallelen Übertragung ist, dass die Trennung der Daten schon weiter oben in der Hierarchie stattfindet. Die letztendlichen Datenleitungen laufen dann nicht mehr parallel, sondern eben jede für sich - das ist ja auch der große Vorteil von serieller Übertragung, dass man viel besser auf die elektrischen Eigenheiten der Leitungen eingehen kann und sogar im Betrieb die Signalflanken anpassen kann.
Damit fallen die aufwändigen Layoutprobleme weg, was eine wirkliche Erleichterung ist.
Übrigens kommt die serielle Verbindung schon bei so einigen Dualopteronsystemen zum Einsatz, wo die 2. CPU am HTr Link der 1. nuckelt und keinen Speicher bekommt. Performancemäßig ist das garnicht mal so schlecht wenn die eine CPU DualChannel bekommt - ich bin mir nicht mehr sicher, die zusätzliche Latenz liegt aber irgendwo im Bereich von 10 Takten.
Zum Vergleich: Ein ECC Speicherzugriff dauert in der Regel so um die 60 Takte.
- Status
