Was bringt der neue E6650?

[Humptidumpti]

@Seppuku
Die Verbindung zwischen CPU und Chipsatz ist mit der Geschwindigkeit des FSBs getaktet und dann noch quadpumped. Also pro Takt können 4 Datenpakete da durchgeschleust werden.

Wenn die CPU aber garnicht soviel Daten verarbeiten kann, um den FSB auszulasten, ist es doch vollkommen wurscht, ob man da jetzt 266 oder 333MHz Takt hat. Zwar bringt der erhöhte FSB auch in anderen Bereichen leichte Vorteile, aber die wiegen den niedrigeren Takt nicht aus.

 

[Seppuku]

Bei SDRAM ist es ja so, dass der Prozessor bei einem Multiplikator von 11 nur alle 11 zyklen eine Anfrage stellen kann.
Die Berechnung pro Datensatz dauert jetzt z.b. 10 Zyklen. Der E6600 mit einem Multi von 9 darf also alle 9 Takte eine Anfrage stellen. Nach 9 Zyklen ist er aber noch nicht ganz fertig (braucht also noch einen). Die CPU ist jetzt zwar fertig, muss aber noch 8 Zyklen bis zur nächsten Anfrage warte.
Bei einem E6650 und einem Multi von 7 vergehen auch auch 10 Zyklen zu Berechnung aber er muss dann nur noch 4 auf die nächste Anfrage warten.
In speziell diesem (extra dafür konstruierten )Fall wäre ein E6650 schneller als ein E6600 (wenn man sich vorstellt, dass mehrere dieser Datensätze hintereinander berechnet werden müssten)

Wie gesagt, das gilt nur wenn es mit DDR genauso ist wie bei SDRAM. Weißt du wie es jetzt genau bei DDR aussieht?
Ist es dann so, dass der Prozessor alle Multiplikator/2 Zyklen Anfragen stellen kann?

 

[Humptidumpti]

Ich verstehe ehrlich gesagt nicht was du da schreibst. Was ich aber weis ist, dass der Multiplikator nichts mit irgendwelchen Anfragen des Arbeitsspeichers zu tun hat. Der Multiplikator ist lediglich für den CPU Takt zuständig. Auch bei Systemen mit SDRam.

 

[Seppuku]

Speicher und CPU werden ja nicht synchron getaktet.
Bei 1:1 kann die CPU jeden Takt eine Anfrage an den Speicher machen.
Bei einem Verhältnis von 1:2 (Speichertakt:CPU-Takt) kann er es nur alle 2 Takte.
Vielleicht kann man es sich so vorstellen, dass man 2 Trommeln hat und die können nur Daten austauschen, wenn sie gleichzeitig schlagen. Wenn jetzt die eine Trommel doppelt so schnell schlägt wie die andere, dann erhöhen sich ja die Anzahl der gemeinsamen Schläge nicht und die 2 Trommeln können nur alle "Schläge der schnellen Trommel"/2 Schläge kommunizieren. Die 2 wäre in diesem Fall der Multiplikator.

Aber genieße meine Aussage lieber mit vorsicht! Außerdem weiß ich nicht, ob das Trommelbeispiel wirklich so gut geeignet ist .

 

[Keita]

@Seppuku
Nach dieser Logik wäre ja eine CPU mit einem Multiplikator < 1... permanent mit dem Speicher im Zwiegespräch

greetings, Keita

 

[Seppuku]

Nicht die ganze Zeit. Wär halt nur andersherum.
Dann müsste der Speicher auf die CPU warten.
Aber wo gibt es einen Multiplikator von unter 1 (meine damit nicht den Speicherteiler)?

 

[Keita]

Du vergißt eine entscheidende Komponente bei deinen Überlegungen: den Cache. Der FSB ist viel zu träge, um ad hoc angeforderte Daten aus dem RAM zu holen oder wieder zurückzuschreiben, stattdessen nutzen aktuelle Architekturen ja zwei- und dreistufige Caches, die die benötigten Daten vorhalten. Der BSB ist dabei üblicherweise mit der gleichen Frequenz getaktet wie der Prozessorkern, so daß es nicht zu unnötigen Wartezyklen kommt.

greetings, Keita

 

[Seppuku]

Zugegeben, ich kenne mich in der Materie verhältnismäßig einfach zu wenig aus. Also nicht böse sein, wenn ich Blödsinn rede .

Aber ich sehe nicht wirklich einen Widerspruch, da dieses Phänomen doch immer auftritt, wenn 2 unterschiedlich getaktete Schnittstellen miteinander kommunizieren (in diesem Fall Speicher und CPU). Letztendlich limitiert doch dann die langsam getaktete Komponente, oder?

 

[Keita]

Wenn man alle Komponenten bis zum Limit ausreizen würde, wäre der Flaschenhals natürlich die Komponente mit der geringsten Leistungsfähigkeit, wobei der Takt nicht das Maß wäre, sondern der maximale Datendurchsatz. Bei den aktuellen Cache-Größen von 2 MB aufwärts dürfte es aber nur bei Applikationen mit extrem hohem Datenaustausch zw. CPU und RAM zu Engpässen an dieser Stelle kommen, i.d.R. dürfte das Limit durch die Rechengeschwindigkeit der CPU vorgegeben sein.
CPUs rechnen ja nicht einfach stur das durch, was ihnen vorgesetzt wird, denn dann kämen sie überhaupt nicht zu Potte, stattdessen versuchen sie mit Techniken wie Branch Prediction (Vorhersage, was als nächstes passieren könnte) oder Out of Order Execution (Optimierung der Reihenfolge von Operationen) "mitzudenken" und gewissermaßen in Vorleistung zu treten, im Grunde kann es also "in" der CPU gar nicht schnell genug sein, was sich natürlich nicht ohne weiteres realisieren läßt.

greetings, Keita