AW: Bulldozer: Ex-AMD-Ingenieur sieht automatische Designprozesse für mangelden Performance verantwortlich
Ruyven, ich sag mal Jaein.
Du hast ja irgend einen Signalpfad, und bis das Signal durch die Pipelinestufe durch ist, musste halt warten. Je komplizierter die Stufe ist, desto länger brauch das Signal halt, bis es einen stabilen Pegel erreicht hat, und das Ergebnis am Ausgang anliegt.
Direkt durch mehr Transistoren kannste das nicht weg bekommen. Eher im Gegenteil, du machst das Problem nur noch schlimmer, da jeder Transistor ja wieder die Zeitspanne verlängert, bis das Signal anliegt.
Was du machen kannst ist die Funktion, die du in Hardware hast zu teilen, wenn Sie mehrere logische Funktionen enthält. Nehmen wir mal z.B. die Integer-ALUs.
Du hast zwei Funktionen. XOR und AND. Entweder du packst das in eine etwas kompliziertere Funktionseinheit, die eben beides kann, oder du baust zwei Stück, die eben nur das eine können. Wenn du beides in einem hast, musst du erst mal entscheiden, was brauch ich denn. Das dauert. Wenn du getrennte Hardware hast, kannste einfach beides schon mal ausrechnen und während dessen schauen, was du eben brauchst. Kostet halt mehr Energie.
Das ist halt immer die Entscheidungsfrage. Wo verwende ich extra Hardware um eine spezielle Aufgabe zu lösen, und wo fasse ich Sachen zusammen.
So kannste schon dann nochmal mehr Taktbarkeit raus holen, aber ob das Sinn macht muss man sich halt immer anschauen. Vor allem muss es ja über alle Stufen der Pipeline funktionieren. Man hat ja in jedem Modul/Funktionsteil eine eigene Laufzeit fürs Signal, und die müssen halt alle unter einen Hut gebracht werden. Das die Laufzeitunterschiede aber VERDAMMT gering sind, sieht man ja daran, dass eben der Chip bis 8 GHz und mehr geht.
Wenn das nicht alles sehr sehr gut aufeinander abgestimmt wäre, würde die CPU da gar nicht mehr laufen, weil eben laufend nur Blödsinn bei rauskommen würde, da eben die Ausganspegel noch nicht stabil sind. Dem ist aber eben nicht so. Daher hat BD ja auch kein Taktproblem. Klar er hat ein Effizientsproblem, aber das ist eben was anderes. Das hat mit dem Prozess zu tun, wie hoch das Ding taktet, und wie man eben Energie "verpulvert" für Sachen, die man nicht unbedingt brüchte. Daten z.B. einfach von A nach B zu schieben kostet halt auch schon einiges an Energie, wenn das in sehr großen Mengen passiert.
Also kurz um, BD schafft die Taktraten, die er soll locker, nur eben eventuell nicht innerhalb der TDP die man sich erhofft hat, wobei man da vielleicht um 10-20% vom Ziel entfernt ist. Soooo viel ist es ja jetzt auch nicht, wenn man bedenkt wie hoch er taktet. Von einem 5GHz Chip ist HOFFENTLICH niemand ausgegangen. Die Lehre hätte man eigentlich aus dem P4 schon ziehen sollen, dass das einfach nicht funktioniert....
Irgendwo muss da der Wurm im Design drin sein, entweder ein ziemlich ekliger Brocken, oder aber an verdammt vielen Stellen eben kleine Fehler/Unzulänglichkeiten, die sich aber halt dann in der Masse dann doch auswirken.
Auf SA ist das eigentlich ganz gut dargestellt. Keine Ahnung, ob es wirklich so ist, wie Charlie schreibt, aber denkbar ist es. Das Problem zu fixen ist dann aber halt nicht so einfach, weil man halt nirgendwo den dicken Gewinn aus einer Änderung zieht. Dafür hat man über einen längeren Zeitraum hin wohl das Potenzial noch wirklich viel aus der Architektur raus zu ziehen, man braucht aber halt einfach die Manpower dafür, die sich darum kümmert.
CRC kann man so ja z.B. schön machen 
