ruyven_macaran
Trockeneisprofi (m/w)
AW: AMD FX-670K: Erster FX-Prozessor für Sockel FM2(+) nicht das, was man erwartet hätte
Ggf. ist es bei den Netburst-Tests sogar noch mehr, das würde jedenfalls gut den Unterschied zwischen SSE und anderen Daten erklären: Die Anbindung ist zwar schön breit, aber die Ansteuerung arsch langsam und eine Auslastung deswegen nur bei großen Paketen halbwegs möglich.
Das ist in der Tat merkwürdig, schließlich ist Prescott ja auf die 6,4 GB/s des FSB limitiert.
Ich gehe auch davon auf, dass sie sehr viel von Excavator übernehmen werden. Wir haben jetzt brauchbare Decoder, mit der nächsten Runde kommen state-of-the-art SIMDs dazu, an den Integereinheiten gibt es afaik auch nichts auszusetzen. Der große Schwachpunkt (neben den Caches, die aber auch Teil dieses Problems sind) ist und bleibt das Modulkonzept. Das wird mit Excavator nicht angegangen, aber danach würde ich mit einer Reorganisation der bekannten Einheiten rechnen. Im Idealfall schmeißt AMD einfach die beiden Integerkerne zusammen (Haswell i5 führt ja vor, dass 4 Pipes pro Thread durchaus funktionieren), führt wieder einen großen Scheduler ein und sieht zu, was sich beim Cache machen lässt.
Jup, Core2 Benchmarks habe ich so schnell nicht wiedergefunden. Aber ich denke, es ist sicher, für neuere Intel-Architekturen eine mindestens so breite L2-Anbindung anzunehmen, wie sie mindestens seit Northwood verwendet wird. (iirc gab es auch da keine Verbesserung gegenüber Williamette, das heißt Intel ist beim Wechsel von P6 auf Netburst auch von 64 auf 128 Bit gewechselt.)
Ggf. ist es bei den Netburst-Tests sogar noch mehr, das würde jedenfalls gut den Unterschied zwischen SSE und anderen Daten erklären: Die Anbindung ist zwar schön breit, aber die Ansteuerung arsch langsam und eine Auslastung deswegen nur bei großen Paketen halbwegs möglich.
Übrigens auch geil, dass Prescott bei einem Thread nicht viel weniger RAM-Bandbreite liefert als K10, trotz deutlich schlechterer Voraussetzungen
Das ist in der Tat merkwürdig, schließlich ist Prescott ja auf die 6,4 GB/s des FSB limitiert.
Ich gehe auch davon auf, dass sie sehr viel von Excavator übernehmen werden. Wir haben jetzt brauchbare Decoder, mit der nächsten Runde kommen state-of-the-art SIMDs dazu, an den Integereinheiten gibt es afaik auch nichts auszusetzen. Der große Schwachpunkt (neben den Caches, die aber auch Teil dieses Problems sind) ist und bleibt das Modulkonzept. Das wird mit Excavator nicht angegangen, aber danach würde ich mit einer Reorganisation der bekannten Einheiten rechnen. Im Idealfall schmeißt AMD einfach die beiden Integerkerne zusammen (Haswell i5 führt ja vor, dass 4 Pipes pro Thread durchaus funktionieren), führt wieder einen großen Scheduler ein und sieht zu, was sich beim Cache machen lässt.
Jup, Core2 Benchmarks habe ich so schnell nicht wiedergefunden. Aber ich denke, es ist sicher, für neuere Intel-Architekturen eine mindestens so breite L2-Anbindung anzunehmen, wie sie mindestens seit Northwood verwendet wird. (iirc gab es auch da keine Verbesserung gegenüber Williamette, das heißt Intel ist beim Wechsel von P6 auf Netburst auch von 64 auf 128 Bit gewechselt.)
