HT, wenn wir dabei bleiben, SMT ist eigentlich wesentlich mehr.
HT ist einfach nur in der Lage freie Plätze in der Pipeline zu nutzen, die ohne dessen Einsatz einfach rumidlen würden. Lastet man allerdings eine CPU voll aus, dann greift kein HT, weil es darauf angewiesen ist, dass noch verfügbare Resourcen da sind.
Volle Leistung = 100% (da kann HT nix machen)
Liegt allerdings ein Befehl vor, der nur 90% der Pipeline belegt, dann kann HT ggf. diese Plätze nutzen und diese Rechenpower nutzen.
Daher ist es auch so, dass HT bei bestimmten Anwendungen sogar Leistung kostet, da es nichts anderes macht wie 2 Threads auf einer klassischen singlecore CPU anzuführen, es knappst also Rechenzeit ab.
Das ist der Nachteil, daher ist es sehr von der Anwendung und den eingesetzen Befehlen abhängig ob HT überhaupt "Mehr"leistung (sie ist ja nicht mehr) generieren kann und dann, wieviel das eben ist.
SMT ist doch dennoch die Technik, Intel schimpft ihre Implementation ja mittlerweile auch SMT, nicht mehr wie beim P4 HT.
Aber sei es drum, in meinen Augen hat Intel sehr früh erkannt, das in so einer "simplen" Implementation viel Potential steckt. Denn rein aus Anwendungssicht zeigt sich in nahezu allen Fällen, das die Programmierer einer Software selbst immer "schlampiger" werden.
So zeigt sich auch in äußerst vielen Anwendungen und Benches, das SMT die "versprochene" Mehrleistung bringt, wenn mehr wie ein Thread auf einem Core läuft.
Der angesprochene ungünstige Optimalfall, das die Ressourcen so ausgelastet sind, das SMT nichts bringt, bzw. gar langsamer arbeitet bei zwei Threads auf einem Core, kommen aber wohl äußerst selten bis nahezu gar nicht vor.
Vor allem ist ja mittlerweile ein gängiges aktuelles OS auch in der Lage zu unterscheiden, das primär nur ein Threasd pro Cores mit Last belegt wird und erst danach der zweite Thread angefasst wird, wenn weite Arbeit anliegt.
Und klar ist es so, das durch SMT die Leistung von Thread 1 sinkt, wenn Thread 2 auf dem gleichen Core läuft. Aber es ist immernoch schneller als beide Threads sequenziel abzuarbeiten. Zumindest in 99% der Fällt, mit Ausnahme des Optimalfalls eben...
Wenn man einen 8 Module AMD gegen einen 8 Core Intel antreten läßt, dann kann der AMD eben doppelt so viel Rechenarbeit leisten (rein Designmäßig), braucht dafür aber auch mehr Fläche. Das klappt aber nur, wenn mehr als 8 Threads da sind. Aber dann skaliert das System (wenn 2x FPU) idealerweise mit 100%, während HT ggf. keine Mehrleistung generiert.
Im Grunde ist das genau die Theorie, die man daraus ableiten kann... In der Praxis ist es dann aber eher so, das bei 8 Threads in deinem Beispiel die Intel CPU schon 100% Leistung bringt, wärend die AMD CPU bei Int. Interaktionen nur ~50% der Leistung liefert. Und diese ~50% der Möglichen Leistung bei AMD sind dabei noch weit unter dem, was Intel mit 8 Threads zu liefern im Stande ist.
Erst bei 16 Threads liefert dir der AMD die beannte 100%. Wohingegen Intel bis zu 125% ausgibt.
Dabei sind die Zahlen absichtlich so gewählt. Ich hätte auch schrieben können bei AMD 100% mit 8 Threads und 200% mit 16 Threads, aber das wäre eben irgendwie nur die halbe Wahrheit
da 50% der Int. Einheiten ja brach liegen würde, bei 8 Threads.
Dazu kommt dann noch die Tatsache, das Intel für 8 Cores + SMT eine CPU braucht, wohingegen AMD für 8 Module im CMT Design eben zwei CPU DIEs zusammen packt (mit benannten Lizenznachteilen)
Intels Ansatz:
Nach Möglichkeit Ausnutzung brachliegender Bereiche in der Recheneinheit (hier benötigt man etwas mehr VerwaltungsDIE-Platz)
AMDs Ansatz:
Verringerung des DIE-Platzes durch doppelte Benutzung der Verwaltungseinheiten (2 Cores teilen sich diese Einheiten)
Wenn man das System weiterspinnt, besteht sogar die Möglichkeit das ganze weiter zu skalieren auf evtl 4 Cores.
Die Zusammenfassung 2er Cores und der gemeinsamen Einheit = Module
Und natürlich hat AMD ihre Startschwierigkeiten, wenn da so geklappt hätte wäre das wohl nen echtes Meisterwerk. Man darf nicht vergessen, dass sich ein solches Design maßgeblich von dem Unterscheidet, was man bisher kannte.
Ob man damit erfolgreich ist, wird sich zeigen. Sie müssen es eben schaffen, dass die Verwaltungseinheiten es ohne Verlußt schaffen beide Core zu füttern und sie müssen die Cores selber dahingehen optimieren, dass sie selber mehr IPC generieren.
Wie schonmal angesprochen, die Theorie ist zweifelsfrei gut. Die Praxis kränkelt aktuell noch. Das ganze optimal aufzuziehen ist zweifelsfrei schwer. Aber man darf auch nicht vergessen, das Intel ebenso nicht schläft und vor allem wohl viel viel mehr Ressourcen für die Entwicklung bereit hat. Und auch Intel tut sich lange schon schwer wirklich massive Sprünge in Sachen Leistung pro Thread zu bringen. Einfach weil irgendwann die Optimierungsluft dünner wird.
Rein auf IPC runter gebrochen liegt AMD immernoch sehr gut. Vor allem, IPC bezeichnet vom Namen her Instruktionen pro Takt. Aber nicht die Anzahl der Recheneinheiten, die daran beteiligt werden. Ein 8 Modul Bulldozer hat also durchaus ordentlich IPC Leistung. Genau so wie die Desktop vier Moduler diese haben. Nur spielt der aktuelle Workload, gerade im Desktop Bereich eben nicht auf absolutes Multithreading, sondern nutzt noch viel zu oft nur einen bis wenige Threads.
Meiner Meinung nach hätte auch AMD einfach den Phenom nehmen können und stur in der Architektur rumfrimeln können, bis sie mehr IPC haben. Man hat sich aber für diesen Weg entschieden.
Und klar, leider müssen sie das in den Desktopmarkt drücken, da kann man es sich nicht erlauben parallel 2 gänzlich verschiedene Architekturen zu designen. Das ist nicht wirtschaftlich, sofern denn der große Umbruch nicht ins verderben führt, das will man nicht hoffen.
Ob man damit lange gut gefahren währe, ist aber dann fraglich. Die Community rufte ja auch teils danach. Auf kurzfristige Sicht vllt OK, aber auf längere Sicht wohl die Sackgasse. Da bietet Bulldozer mehr Möglichkeiten für die Zukunft.
Vor allem, Phenom/Barcelona basiert im Grunde auf der K8 Architektur von 2003... Das ist verglichen daran horn alt. Und über die Zwischenschritte konnte man so extrem viel Pro Thread Leistung nicht rausquetschen. Ein Thuban X6 ist in Sachen Pro Thread Leistung so extrem viel besser nicht als die ersten K8 CPUs auf S940 damals bzw. S939 später.
Bei Intel sind an der Stelle die Sprünge (leider muss man wohl sagen) deutlich größer. Vom Pentium Pro über Pentium III über Pentium M über Core Solo/Duo über Core2Duo (in zwei Ausführungen) gab es da gewaltige Sprünge. Und Intel hat trotz lahmendem FSB und shared Memory Controller im Chipsatz deutlich den A64 K8 geschlagen. Dem Phenom II wird ja nachgesagt in etwa so fix zu sein pro Takt, wie die Core2 CPUs. Nur gabs eben danach noch zwei (zwar kleinere) Sprünge, die Bulldozer so nicht abfedern konnte...
2ndEDIT:
Die FPU ist 2x 128 breit, man kann also auf ihr auch kleinere FLOPs fahren und das dann doppelt, ist nur die Frage, wie oft man das eine oder das andere braucht.
3rdEDIT:
Unterm Strich will ich eigentlich auch nur sagen, dass man die Module schon fast als vollwertigen dual Core Chip sehen kann, eben mit der Einschränkung der FPU und evtl. in den davorgelagerten Einheiten(wenn diese ggf. nicht optimal laufen, das kann ich nicht beurteilen).
Das mit der FPU ist so ne Sache, wie gesagt, im Nachfolger soll es wohl wieder ne doppelte FPU geben pro Modul. Was dann wiederum fast nem echten Dualcore gleichkommen würde.
Die Zählweise ist aber so oder so von Generation zu Generation etwas verschieden. Vor dem Pentium 1 gabs ja nichtmal ne FPU in der CPU, es war trotzdem ein Core bzw. ein Prozessor
Übrigens, zum Thema SMT, das nutzt nicht nur Intel. Es gibt da noch ganz paar CPUs, die durch deutlich mehr wie "zweifach" SMT (wenn ich das mal so nennen darf) profitieren. Sogar Knights Korner bzw. besser bekannt als Xeon Phi oder auch Larrabee/LRB als nutzt vierfach SMT, wenn ich mich recht entsinne.
Die noch aktuelle Xbox (zweifach) soweit ich weis auch...
Der in meinen Augen riesige Vorteil von SMT zu CMT ist, das SMT die Möglichkeit bietet, mit nur einem Threads die Ressourcen ziemlich effizient auszunutzen. Und bei zwei Threads idR immernoch mehr Leistung bringt. Das ganze ohne die Fläche nenneswert zu erhöhen. CMT hingegen benötigt mehr Fläche, und benötigt zwingend die zwei Threads für optimale Auslastung.
Mal schauen was AMD machen kann, um diesem Umstand aus dem Weg zu gehen, die Ressourcen bündeln wäre ggf. eine Option, aber das könnte schwieriger werden als man so annimmt
Mal so eben auf nen Schnipp mit dem Finger wird das definitiv nix...
Stell mir bitte ein Intel System aus CPU und Mainboard mit AES-NI und IOMMU für ca. 300 Euro zusammen welches leistungsmäßig meinem Storageserver entspricht. Recht viel mehr hab ich im Januar diesen Jahres nämlich nicht dafür bezahlt!
Absolut unmöglich, Intel bietet lieder kein IOMMU
das bietet nur AMD.
Aber wie wäre es mit einem Xeon E3-1220 in Verbindung mit nem SM Brett?
Das kostete damals (Jan. 2012) ca. 340€ für Board + CPU. Leistungstechnisch so viel Unterschied ist nicht zum Bulldozer. Dafür bekommst du mit dem SM Brett ein echtes Serverboard. Genau so mit ECC Support, VT-x/d, AES-NI, und gar IPMI. Dazu Dual Intel GBit LAN...
~10% mehr für ne echte Serverkombo ist da nicht unbedingt verkehrt...
Wobei wir wieder bei den wirklich wichtigen Programmen wären. Ich musste bei dem X3850 System auch HT im Bios deaktiveren, da die Benchmarkwerte für AES und co. sonst unterirdisch schlecht wurden.
Wer definiert die Wichtigkeit von Programmen?
Du?
Ich glaube nicht... Aber worauf willst du überhaupt hinaus?
PS: auch der Vergleich hinkt etwas, welche Benches hast du denn ausgeführt und unter welchen Bedingungen? (OS, Programme?)
Das sagt mir jetzt was?
Das ich eine max. Power 240W CPU, welche nichtmal im Ansatz x86 Code ohne Emulation abarbeiten kann, und somit für einen mini Bruchteil des aktuellen Marktes aufgestellt ist, wo vorzugsweise hochoptimierter (in vielen fällen sogar selbst programmierter und hochoptimierter) Code ausgeführt wird, mit einer Eierlegenden Wollmilchsau Intel/AMD CPU vergleichen soll, welche für einen ganz anderen Markt gebaut wurde!?
Was soll an der Stelle eine Intel/AMD CPU anrichten? Der Vergleich macht keinen Sinn, wie ich eingangs schon beschrieb.
Das ist wie mit Grafikkarten. Eine CPU als Beispiel ein Xeon/Opteron der aktuellen Generation kann genau so den Programmcode einer Grafikkarte ausführen, wenn man ihm diesen vorsetzt. Dennoch wird der Prozessor nichtmal im Ansatz die Leistung einer halbwegs aktuellen Grafikkarte erreichen. Und selbst wenn man die gleiche Leistungsaufnahmeklasse betrachtet, bekommt man mit ~130W aus einer Grafikkarte weit mehr Leistung als aus einer CPU mit ~130W.
Es macht wie gesagt einfach einen Sinn so einen Vergleich zu führen. Aktuelle Intel/AMD CPUs haben sich über die letzten 20 Jahre hinweg als quasi Alleskönner etabliert. Für dedizierte Bereiche gibt es aber dedizierte Hardware, die auch dort deutlich fixer ist.
Intel hat ja schon angekündigt, eine Ethernet Schnittstelle in die CPU zu integrieren.
Inwiefern bietet Intel für jeden Bereich etwas an? Indem Sie weniger Speicherkanäle, deaktiverte AES-NI, VT-x usw. Funktionen und ECC-Ram support dann als "günstigere" CPU verkaufen?
Wenn du für die Sicherheit in einem Unternehmen verantwortlich wärst, würdest du nicht so reden. ssh, OpenVPN usw. sind auch innerhalb eines Unternehmens wichtig. Gerade in Zeiten der selbst mitgebrachten IT-Geräte wie Smartphones und co. Es gibt auch immer wieder mal größere Ciscos die das senden von Paketen von einem Vlan ins andere zu lassen ohne das ein Routing eingerichtet ist.
Toll, demnach hab ich auch Dualchannel schon in meinem Pentium 3 Server seit 10 Jahren drin. Da sind es auch zwei unabhängige FSB.
Du verkennst die Fakten. Intel bringt dir dediziert für den Desktop Bereich einen Prozessor, der eben genau die nötigen Funktionen für den Desktop Bereich bringt. Da braucht für gewöhnlich niemand ECC genau so wie VT-d ziemlich unnötig ist. Bestenfalls kann man VT-x aufführen. Aber auch hier ist die Nötigkeit ziemlich selten gegeben...
Bitte nicht von dir auf den ganzen Markt schließen. Spezielle Anforderungen wird man ggf. nur mit größeren Modellen gerecht.
PS: ich sagte übrigens nicht, das SSH/OpenVPN unwichtig ist. Ich sagte, das es auch ohne AES Hardwareunterstützung geht. Da die Softwareberechnung auch idR ausreichend fix arbeiten. Noch dazu bieten nicht alle Devices diese Hardwarebeschleunigung... Und der Speedvorteil ist in der Theorie zwar enorm, in der Praxis aber je nach Anwendung verpufft er. Beispiel: Thema HDD Verschlüsslung. Ob da nun 200MB/sec oder 50000MB/sec berechnet wer den können, was juckts mich wenn die HDD nur ~100MB/sec liefern kann!?
EDIT: mich würde aber interessieren, was du mit dem letzten meinst!?
Das würde bedeuten, das das Cisco Device nicht sauber arbeitet. Welchen Zusammenhang hat das aber mit dem genannten!?
