Nein, man möchte mehr Rechenleistung haben und dazu braucht man mehr Recheneinheiten. Intel nimmt eben alles 2x, während AMD nur ausgewählte Teile 2x nimmt.
Wobei das nicht 100% zutrifft zum aktuellen Zeitpunkt.
Ein Core2Quad ala Q6600 oder ähnlichem bestand noch aus zwei quasi vollwertigen Dualcore Core2Duo Prozessoren, die zusammen unter dem Deckel (Heatspreader) auf einem Träger gepackt wurden und welche sich über das damals noch übliche "Bussystem" unterhalten haben.
Heute sind zwar die Cores selbst quasi vollständig doppelt. Der Vorteil "echten" Quadcores ist aber, das man eben nur eine Speicheranbindung, nur einen shared Cache usw. braucht. 100% doppelt sind als nur die Cores selbst, aber bei weitem nicht alles.
Wirklich alles mal zwei genommen hat Intel z.B. bei den ersten Dual- und Quadcore Prozessoren. Da wurden ganz simpel gesagt einfach 2 CPUs zusammen geklebt. Klebt man einfach zwei Prozessoren zusammen, hat das aber bestimmte Nachteile, wenn das Betriebssystem diese nicht von "nativen Dualcores" unterscheiden kann.
Es gab/gibt z.B. Dualcore Prozessoren, bei denen sich die beiden Kerne bestimmte Zwischenspeicher (L2,L3 Cache) teilen.
Das hat den Vorteil, dass der eine Kern auf die Daten des anderen zugreifen kann und das Betriebssystem lustig die Aufgaben umverteilen kann, ohne dass die Daten aus dem Zwischenspeicher raus und in den Speicher der anderen CPU rein müssten.
Klebt man davon nun einfach zwei zusammen, hat man zwei Zwischenspeicher, die sich jeweils zwei Kerne teilen. Verteilt das Betriebssystem nun weiter lustig die Aufgaben ohne auf diesen kleinen Unterschied zu achten kann es zu Leistungseinbußen führen.
Es gibt also einen Unterschied zwischen dem einfachen zusammenkleben von Kernen und wirklich nativen Dual-/Quad-/Hexa-Core Designs.
Das ist aber zum Teil auch eine Sache der Anwendung, genau so wie du schon sagtest, des Betriebssystems. Dazu kommt, das auch nativ implementierte Designs an der Stelle gewisse Teile haben, die quasi exklusiv für den jeweiligen Teil arbeiten.
Das Problem, das das Betriebssystem an der Stelle die Arbeit von Kern zu Kern schubst, ist an der Stelle aber das geringste Übel. Will man das verhindern, kann man die Anwendung auf die Cores fixieren. Noch dazu ist es ggf. sogar von Vorteil, da eben idR eine Vielzahl von Threads gleichzeitig mehr oder weniger aktiv die CPU belasten. Bei mir laufen gerade über 1400 Threads zur gleichen Zeit. Stell dir vor, du hättest an der Stelle ein starres Konstrukt
Es bleibt dem Betriebssystem also fast gar nix anderes übrig, als die Arbeit von Kern zu Kern zu schieben, je nachdem, wo eben gerade was frei ist an Ressourcen.
Bei neueren AMD Prozessoren ist die Situation nun etwas anders und auch etwas schwieriger.
Einfach ausgedrückt:
AMD hat die Idee des HT weiter geführt und angefangen Bestandteile eines CPU Kerns doppelt zu verbauen, so dass es deutlich eher ein Zweikern als ein Einkern ist. Bestandteile, die nach Ansicht AMDs nicht ganz so wichtig sind für die meisten Aufgaben, sind nur einmal vorhanden und werden geteilt.
Ein solcher Zweikern wird von AMD Modul genannt und dem Betriebssystem als zwei normale Kerne präsentiert.
Von diesen Modulen "klebt" AMD nun mehrere zusammen und versieht sie mit einem weiteren gemeinsamen L3-Cache .
Das kann man so nicht sagen, AMD hat nicht HT (bzw. SMT, wie die "Technik" dahinter heist) weiter geführt, sondern man hat einen ähnlichen Ansatz mit gänzlich anderer Umsetzung genutzt, den es aber auch schon so bei ein paar CPU Modellen gibt/gab. Die "Technik" schimpft sich CMT und basiert darauf eben ein paar Teile eines Cores/Moduls zu verdoppeln/vervielfachen, wärend andere Teile geshared werden.
Übrigens präsentiert sich weder SMT noch CMT bei aktueller Implementation seitens Intel/AMD dem Betriebssystem als "echter" Kern. Das Problem ist eher, das Betriebssystem muss verstehen, was einem da vorgesetzt wird. In Sachen Hyperthreading (SMT) hat sich Microsoft nunmehr nach ca. 7 Jahren (die erste Hyperthreading CPU war ein 3,066GHz starker Penitum IV für den Sockel S478 von Ende 2002) mit Windows 7 durchgerungen, nativ zwischen einem Kern und seinem zugehörigen SMT Part zu unterscheiden.
Das Betriebssystem weis also um die Situation, das zwei Berechnungen auf einem Core langsamer sind als jeweils eine Berechnung pro Core. Und nutzt SMT erst dann aus, wenn die Anzahl der Cores ausgeschöpft ist, bzw. dann, wenn so viel Arbeit anliegt, das SMT quasi Vorteile bringen "muss" (durch die bessere Auslastung)
Das Problem dabei ist, dass diese Architektur so anders aufgebaut ist als bisherige, dass das Betriebssystem ohne spezielle Optimierung nicht das ganze Potential daraus schöpfen kann.
Der Grund dafür liegt unter anderem (ähnlich wie schon bei den zusammengeklebten DualCores) darin, dass das Betriebssystem nicht unterscheiden kann ob sich ein Kern im selben Modul befindet oder in einem anderen.
Verteilt das Betriebssystem dann fleißig Aufgaben um und legt zwei besonders "anstrengende" Aufgaben blöderweise ins selbe Modul bricht die Performance ein, da die Kerne in dem Modul sich bestimmte Dinge teilen müssen.
AMD vermarktet einen Prozessor, der aus vier Modulen besteht als 8-Kern Prozessor, was meiner Ansicht nach auch richtig ist, da es deutlich eher ein 8-Kern als ein 4-Kern ist.
Intel vermarktet einen Prozessor, der aus vier Kernen besteht als Quadcore, obwohl dem Betriebssystem durch HT 8 Kerne angezeigt werden. Meiner Ansicht nach auch korrekt, da das Ding eben deutlich mehr 4-Kern als 8-Kern ist.
Windows 8 kann diese Unterscheidung treffen, Windows 7 und älter hingegen nicht. Wie es bei Linux ausschaut, weis ich allerdings nicht...
So als extrem problematisch würde ich das ganze aber auch nicht einstufen, zumindest nicht so problematisch, wie es bei SMT der Fall ist/war. Da der wohl überwiegende Teil der Belastung über die Einheiten abgefackelt werden dürfte, welche auch doppelt vorhanden sind (pro Modul), was eben genau an der Stelle ansetzt, wo CMT besser skalieren soll und auch tut.
Das größere Problem an der Implementation von CMT ist einfach der Punkt, das bei gewissen alltäglichen Situationen nicht genügend Last erzeugende Aufgaben gleichzeitig anstehen, um den Skalierungsvorteil durch eben jene doppelten Einheiten pro Modul abzurufen. Und Stand heute ist es mit den aktuellen AMD CPUs an der Stelle nicht möglich, die gedoppelten Einheiten eines Moduls so zusammen zu fassen, das beim abarbeiten nur einer Aufgabe diese schneller abgearbeitet wird.
Bildlich verglichen bekommt man bei Intel aktuell eine Quadcore CPU mit vier fetten Rechenkernen, welche dazu (je nach Modell) noch die Möglichkeit bieten diese vier Cores durch SMT besser auszulasten, was nochmals ~15% mehr Performance rausquetscht. Teils mehr, teils weniger. Für letzteres benötigt man dann aber auch die doppelte Menge an Lasterzeugenden Aufgaben, welche zur gleichen Zeit laufen. Hat man diese nicht, bekommt man immernoch 100% Leistung der vier Einheiten.
Bei AMD bekommt man an der Stelle hingegen eine CPU, die nativ auf vier Paare von Rechenkernen aufsetzt. Und ihren Vorteil auch genau dann ausspielt, wenn alle acht Einheiten belastet werden. Erzeugt man hingegen nur Teilllast, greift das oben genannte, und man fällt an der Stelle zurück, einfach weil nur die hälfte der Einheiten belastet werden können. Durch den potentiell höheren Skalierungsgrad von CMT an der Stelle zieht zeitgleich der Nachteil bei nur Teilauslastung mit ins Haus.
Zum letzten, das ist Ansichtssache. Im Grunde ist das Modul von AMD eher ein "Core", der eben zwei Integer Einheiten sowie eine Gleitkomma-Einheit vereint. Auch wenn AMD hier marketingtechnisch was anderes behauptet und sich somit sogar selbst ins Bein schießt
Im Grunde nutzen beide Hersteller eine Technik, die es ermöglicht, auf einem Stück Basis, zwei Sachen mehr oder weniger gänzlich gleichzeitig laufen zu lassen. Bei Intel mit SMT skaliert der Spaß mit ~15%. Bei AMD mit teilweise über 60%. Beides hat Vor- sowie Nachteile. Was sich schlussendlich besser machen wird für jeden Einzelnen, wird sich zeigen. Ein pauschales Besser/Schlechter gibts ohne dedizierte Betrachtung der Anwendungen nicht.
