AW: AMDs Bulldozer: Über 3,5 GHz inklusive 500 MHz per Turbocore, L3-Cache mit über 2,4 GHz?
Hmmh... Ist es nun nicht so wichtig, dass der Bulli kein HT hat, da er mit CMT genug leistet oder hätte man das vielleicht doch einbauen können um die Recheneinheiten effizienter nutzen zu können (oder wäre größerer Cache wichtiger und vom Platzverbrauch auch lohnender)?
Mit SMT hätte man die Recheneinheiten besser auslasten können.
Ob das pro Flächeneinheit sinnvoll gewesen wäre, hängt vom Zusammenspiel zwischen Software, Kern und ggf. sogar Sparmechanismen ab. Wenn die Software den Kern ohnehin schon voll auslastet (was außer Testprogrammen bislang keine gemacht hat) oder/und wenn die CPU-Leistung durch das Temperaturbudget limitiert ist, so dass man schlechte Auslastung vollständig durch Takt kompensieren kann, dann lohnt es sich ggf. nicht.
In Anbetracht der weiterhin positiven Wirkung bei Intel, inbesondere bei den Zweikernern, denke ich persönlich aber, dass es sich lohnen würde, solange genug Threads zur Verfügung stehen.
Damit wären wir beim markttechnischen Teil: "Wieviel Software unterstützt jetzt schon 16 logische Kerne?" gegen "Wieviel kostet die Entwicklung von SMT?". Ersteres ist im Enduserbereich quasi null, so dass nachvollziehbar ist, warum AMD sich die Entwicklung vorerst spart, auch wenn sie rein technisch attraktiv erscheint.
Ich hab' mal gelesen, dass Cache ab einer bestimmten Größe nicht mehr viel Sinn ergibt, aber anscheinend ist es doch besser als HT. Was ist denn nun richtig? Wieso?
Jeder einzelne Schritt in der Datenverarbeitung kann einen Leistungsgewinn bringen - aber wirkliche Fortschritte macht man nur, wenn man den Engpass bei der aktuellen Verwendung findet und behebt. SMT macht keinen Sinn, wenn die Recheneinheiten zu 100% ausgelastet sind. CMT macht keinen Sinn, wenn man nur einen Thread hat. Und mehr Cache macht nur dann Sinn, wenn er die Speicherzugriffe deutlich reduziert. Im Idealfall liegt der komplette Programmcode, der ständig gebraucht wird, im Cache vor, wärend die Daten, die von diesem Programm bearbeitet werden im RAM sind. Weniger Cache würde die Performance drastisch reduzieren (bzw. umgekehrt: Von weniger Cache ausgehend den Cache vergrößern), weil wärend jeder Berechnung Codeabschnitte aus dem RAM nachgeladen werden. Mehr Cache dagegen würde gar nichts bringen, wenn die Daten nicht komplett reinpassen und nur einmal benötigt werden: DIe CPU müsste weiterhin jeden Datensatz erstmal aus dem RAM laden, würden ihn dann verarbeiten (was sie mit weniger Cache genauso gut konnte) und schreibt die Daten danach wieder zurück in den RAM.
In der Realität ist der Übergang fließend, da ein Teil der Daten für spätere Berechnungen nochmal benötigt wird und weil Programme unterschiedlich groß ausfallen. (Pentium4s waren den AthlonXP in Spielen oft unterlegen, aber in Q3-Engine Spielen fast immer vorn, u.a. weil sie mehr Cache hatten.)
Weitere Gleichungen in dieser unbekannten ist die Geschwindigkeit der RAM-Anbindung und ihre Latenz. Wenn man die Daten ganz schnell aus dem RAM bekommt, bringt der Cache kaum noch Vorteile, gehen RAM-Zugriffe mit einer großen Wartezeit einher, lohnt er sich eher. (Siehe P4 vs. Athlon64)
Btw @ruyven_macaran: Woher weisst du das alles
?
Ich bin technisch interessiert und habe die Einfühung von SMT und von Multicore im Desktopbereich mitverfolgt. Der Rest ist ein bißchen Logik.
Aus welcher Not soll es denn entstanden sein? SMT ist alles andere als unwichtig, IBM verwendet es sogar schon in einer erweiterten Form bei der ein physikalischer Kern 4 Threads bearbeiten kann.
Nicht nur IBM. Sun hat vorgemacht, wie extrem effizient die Kombination aus mehrfachem SMT und platzsparenden in-order-Pipelines sein kann, wenn optimierte Software zum Einsatz kommt. Alle anderen machens nach.
Im Desktopbereich war aber schon ein bißchen Zwang im Spiel:
Die langsame Speicheranbindung der P4 im Vergleich zur Rechengeschwindigkeit des Kerns sorgte für viele Wartezeiten in den Threads, die schwerwiegenden Folgen falscher Sprungvorhersagen machte es attraktiv, ein Ergebniss zu berechnen und bis zu seinem Erhalt unabhängige Aufgaben anzunehmen und die hohe Verlustleistung erschwerte die Entwicklung eines Dual-Core (Schaltungstechnisch ein Kinderspiel bei einer FSB-Architektur), wärend fehlende Multithreadfähigkeit einen massiven Nachteil im Bedienkomfort darstellte.
@ ruyven_macaran
Die Module mit den vielen Int-Cores gehen ja bereits stark in die Breite (viele Threads gleichzeitig), dennoch braucht der 2te Int-Core pro Modul nur 12% mehr Die-Fläche. Jetzt noch SMT dazu, was bei Intel iirc 6% mehr kostet, würde den BD deutlich aufblasen.
Bist du sicher, dass Intel die 6% auf den gesamten Chip bezieht?
Iirc sind das 6% der Größe der Recheneinheit (und das sogar auf die winzigen Netburstkerne bezogen.?), also sehr wenig Silizium. AMDs 12% beziehen sich dagegen auf das Modul inklusive Cache und Anbindung - deutlich mehr also.
Beim Leistungsgewinn sollte man neben der unterschiedlichen Szenarien auch bedenken, dass SMT sich in gleichem Maße auf die (gerade für uns wichtige) SIMD-Leistung auswirkt. AMDs CMT Implementierung bringt da gar nichts. (jedenfalls wenn die Betrachtung wählt, der die 12% zu Grunde liegen, d.h. "was macht der zusätzliche Kern in Relation zum restlichen Modul - inklusive SIMD-Einheit?")
.
. Ansonsten versuch ich eig. nur einen Grund zu finden, warum AMD kein HTT bei seinen Bullis haben könnte 
...
.gif "sm_B-) :-)")
. Will einfach nicht kaputt gehen.
AMD64 3400+ 
.
