Erste Samples von San Diego [Archiv]

BUG

2003-11-07, 14:47:34

...das bringt dann aber imho nur was, wenn die Software drauf angepasst wird mehrere Sachen gleichzeitig zu verarbeiten was aber derzeit sogut wie nicht gemacht wird. Und selbst dann, erreicht man nich mal annähenrd die doppelte Performance (nichmal der P4), der AMD wird vieleicht bei +5% rumtümpeln was wohl in keinem Verhältnis zum Aufwand steht den Core HT Fähig zu machen, AMD wird irgendwann den MultiCore einsetzen, da dies wesentlich effizienter ist als einen zweiten CPU zu "emu/simulieren". HT is imho kein echtes SMT, das is imho nur ne Notlösung seitens Intel die langen Pipelines des P4 besser ausnutzen zu können (ja ich hatte schon ne HT CPU). Wenn es dem AMD helfen würde, dann würde AMD dies auch in die CPU einbauen.

cu
BUG

Endorphine

2003-11-07, 16:12:10

Ach Mensch BUG. SMT verspricht nicht die doppelte Leistung (wer erzählt nur solchen Unsinn?). SMT dient einzig und allein dazu, nicht ausgelastete Einheiten mit einem zweiten Task/Thread zu beschäftigen und somit den Durchsatz des Gesamtsystems zu erhöhen. NICHT die Leistung.

Des weiteren dient SMT mittelfristig dazu, den Weg zu ebnen für SMP-on-Die. Praktischerweise forciert es die SMP/SMT-Unterstützung bei den Softwareentwicklern ebenso, wie es einen sanften Übergang hin zu Multicore CPUs auf einem Die ermöglicht. SMT ist nur der Anfang einer vorgegeben langfristigen Entwicklung.

BUG

2003-11-07, 16:37:53

...mom, dass^^ war wohl von mir etwas "unglücklich" ausgedrückt. Ich wollte damit nicht sagen, dass sich durch HT oder SMT Systeme die Leistung verdoppelt oder ähnliches sondern nur das selbst beim P4 HT nich viel bringt (wobei das von Anwedung zu Anwendung ein wenig variiert) aber es bleiben nur wenige %. Ich wollte damit nur sagen, dass HT beim AMD wohl noch viel weniger bringen würde als beim P4 wieso sich die AMD Ing´s dazu entschlossen haben HT nicht in ihren CPU´s zu verwenden (Aufwand/Nutzen/Kosten).

HT is an sich schon ne nette Sache, aber eben nur wenns zur Arcitektur passt und bei AMD passt es wohl nicht sorecht.

cu
BUG

BlackBirdSR

2003-11-07, 16:56:36

Original geschrieben von BUG
...mom, dass^^ war wohl von mir etwas "unglücklich" ausgedrückt. Ich wollte damit nicht sagen, dass sich durch HT oder SMT Systeme die Leistung verdoppelt oder ähnliches sondern nur das selbst beim P4 HT nich viel bringt (wobei das von Anwedung zu Anwendung ein wenig variiert) aber es bleiben nur wenige %. Ich wollte damit nur sagen, dass HT beim AMD wohl noch viel weniger bringen würde als beim P4 wieso sich die AMD Ing´s dazu entschlossen haben HT nicht in ihren CPU´s zu verwenden (Aufwand/Nutzen/Kosten).

HT is an sich schon ne nette Sache, aber eben nur wenns zur Arcitektur passt und bei AMD passt es wohl nicht sorecht.

cu
BUG

Intel's Hyperhtreading ist SMT!

Zudem, woher willst du wissen, wieviel Leistungsplus der K7/8 Core aus SMT ziehen könnte?
Vielleicht haben sich die AMD Entwickler dagegen entschlossen, weil sie einfach keine fertige SMT Implementierung haben, die man nutzen könnte.

Man müsste erst aufwendig etwas entwickeln und auf den Core abstimmen. Zu spät um es dem K8 noch zu verpassen.

SMT ist zudem wohl eines der genialsten Features um den Durchsatz zu erhöhen. Der Aufwand ist vergleichsweise gering (Andere Architekturen brauchen für sowas mal schnell 6MB Cache *g*), die resultierende Leistung ganz ansehlich.

BUG

2003-11-07, 17:13:21

Original geschrieben von BlackBirdSR
Zudem, woher willst du wissen, wieviel Leistungsplus der K7/8 Core aus SMT ziehen könnte?

...^^ dito! ;D Und woher willst du es wissen? Man liest ja immer drüber, dass die Pipes beim P4 vieeeel länger sind als beim AMD weshalb sie nich immer voll ausgelastet werden. Ich kann hier auch verstehen, wieso Intel HT entwickelt hat bzw von vorn herrein auf HT gestetzt hat (zum Teil deaktiviert da noch in Entwicklung) damit der P4 Core effizienter genutzt werden kann.

Aber wenn man mal schaut, was HT beim P4 bringt kommt bei mir die Vermutung auf, dass es bei AMD noch viel weniger bringen würde da die Pipes schon recht effizient genutzt werden (Pro MHz Leistung deutlich höher).

Ich arbeite weder bei AMD noch bei Intel um genaueres sagen zu können, ich bin sogar ziemlich unbeholfen was die beiden CPU Arcitekturen angeht da ich mich damit zu wenig beschäftigt habe, aber solang mir keiner einen stichhaltigen "gegenbeweis" liefern kann bleib ich dabei. HT bringt bei der AMD Architekur nix (oder fast nix) bzw steht in keinem Verhältnis zum Aufwnad, Kosten oder Nutzen.

cu
BUG

Tesseract

2003-11-07, 17:13:28

Original geschrieben von BlackBirdSR
SMT ist zudem wohl eines der genialsten Features um den Durchsatz zu erhöhen. Der Aufwand ist vergleichsweise gering

die leistung, die du durch HT gewinnen kannst muss irgendwo brach "herumliegen"

der aufwand mag gering sein, aber eine technik wie HT untergliegt einer wichtigen bedingung: in der architektur müssen genug reserven übrig sein die genutzt werden können

die p4 architektur is dafür wie geschaffen (20 stufige pipe etc.) weil sie eher "ineffizient" ist

da wär es imho wesentlich sinnvoller die architektur gleich mehr zu parallelisieren und zB mehr FPUs und dergleichen zu verbauen

den wirklichen vorteil sehe ich in HT darin, dass das "dumme" OS (*zu M$ schau* ;)) etwas effizienter arbeiten kann als es sonst der fall wäre - unabhängig davon was die CPU an leistung bringt

BlackBirdSR

2003-11-07, 17:48:41

ich gebs auf ;D

AMD hats wohl tatsächlich geschafft, mit ihrer: unsere CPUs sind viel besser ausgelastet; Kampagne.

Ist mir zwar unverständlich, aber bitte.
Küren wir also den K7/8 zum IPC King, der locker 8 Befehle pro Takt ausführt, und vergessen mal die Sache mit dem Durschnitt bei 1.7-2 IPC.

Es lebe Propaganda :asshole:

Muh-sagt-die-Kuh

2003-11-07, 18:11:03

Original geschrieben von BUG
Aber wenn man mal schaut, was HT beim P4 bringt kommt bei mir die Vermutung auf, dass es bei AMD noch viel weniger bringen würde da die Pipes schon recht effizient genutzt werden (Pro MHz Leistung deutlich höher).Jede aktuelle CPU ist ziemlich ineffizient, das liegt schlicht und einfach daran, dass der ILP eines Threads begrenzt ist. Die niedrigere Pro-Mhz-Leistung eines P4 liegt nicht an geringer Auslastung sondern an niedrigerer Paralellität, im Gegensatz zum K7/8 hat er z.B. nur eine Multifunktions-ALU und eine FP-Unit mit gewissen Limitationen. Da das Design aber auf hohe Taktraten optimiert ist kommt es zu seiner Leistung.

Der K7 ist selbst ein "ineffizienter" Kern.

Das sieht man ganz einfach wenn man ihn mit dem K8 vergleicht: Gleiche Grundarchitektur, der K8 bietet "nur" effektiv niedrigere Speicherlatenzen und ein leicht verbessertes Front-End.....und trotzdem ist er bei gleichem Takt deutlich schneller.

Vom Optimum (Vollauslastung) ist er trotzdem noch weit entfernt.

Ich arbeite weder bei AMD noch bei Intel um genaueres sagen zu können, ich bin sogar ziemlich unbeholfen was die beiden CPU Arcitekturen angeht da ich mich damit zu wenig beschäftigt habe, aber solang mir keiner einen stichhaltigen "gegenbeweis" liefern kann bleib ich dabei. HT bringt bei der AMD Architekur nix (oder fast nix) bzw steht in keinem Verhältnis zum Aufwnad, Kosten oder Nutzen.

cu
BUG Wenn man keine wirkliche Ahnung hat sollte man sich mit Aussagen, die man nicht belegen kann, zurückhalten.

Muh-sagt-die-Kuh

2003-11-07, 18:15:46

Original geschrieben von Tesseract
die leistung, die du durch HT gewinnen kannst muss irgendwo brach "herumliegen"

der aufwand mag gering sein, aber eine technik wie HT untergliegt einer wichtigen bedingung: in der architektur müssen genug reserven übrig sein die genutzt werden können

die p4 architektur is dafür wie geschaffen (20 stufige pipe etc.) weil sie eher "ineffizient" istDiese Leistung liegt bei jeder aktuellen CPU rum.
da wär es imho wesentlich sinnvoller die architektur gleich mehr zu parallelisieren und zB mehr FPUs und dergleichen zu verbauenSchlechte Idee, die aus sequentiellem Code herausholbare Parallelität ist meist sehr begrenzt.den wirklichen vorteil sehe ich in HT darin, dass das "dumme" OS (*zu M$ schau* ;)) etwas effizienter arbeiten kann als es sonst der fall wäre - unabhängig davon was die CPU an leistung bringt Multithreaded Encoding / Rendering (so gut wie keine Datenabhängigkeiten zwischen den Threads) => HT bringt locker 20% mehr Leistung.

Tesseract

2003-11-07, 18:21:42

Original geschrieben von Muh-sagt-die-Kuh
Diese Leistung liegt bei jeder aktuellen CPU rum.

theoretische leistung: ja
das heißt aber nicht das diese auch nutzbar ist über techniken wie HT

intel hat für HT einiges im kern mehrfach ausführen müssen damit HT überhaupt in dem ausmaß funktionsfähig ist

du kannst eine superskalare CPU einfach nie zu 100% auslasten

Aquaschaf

2003-11-07, 18:23:55

Ist es denn überhaupt so schlimm, dass die CPU's recht wenig ausgelastet sind? Wäre dies anders würde sich doch sicher eine (deutlich?) höhere Abwärme ergeben, man könnte vielleicht CPU's nicht so hoch takten und hätte dann keinen so großen Vorteil von der hohen Auslastung.

Tesseract

2003-11-07, 18:28:53

Original geschrieben von Muh-sagt-die-Kuh
Multithreaded Encoding / Rendering (so gut wie keine Datenabhängigkeiten zwischen den Threads) => HT bringt locker 20% mehr Leistung.

sry, aber die 20% sind mir beim encoden relativ egal verglichen mit dem vorteil, den eine bessere threadaufteilung bringt - wenn man also parallel dazu weiterarbeiten will am pc

BlackBirdSR

2003-11-07, 18:38:38

Original geschrieben von Tesseract
theoretische leistung: ja
das heißt aber nicht das diese auch nutzbar ist über techniken wie HT

intel hat für HT einiges im kern mehrfach ausführen müssen damit HT überhaupt in dem ausmaß funktionsfähig ist

du kannst eine superskalare CPU einfach nie zu 100% auslasten

SM braucht nunmal Anpassungen, wo ist das Problem.
Und natürlich kann man niemals 100% des kerns auslasten. Aber ich sehe da keinen Zusammenhang mit der SMT Frage.

Wuge

2003-11-07, 18:48:51

ausführungsgeschwindigkeit hin oder her, fakt ist, dass multitasking mit HT spürbar besser läuft

ich möchte kein system mehr mit nur einer logischen/physikalischen cpu

Tesseract

2003-11-07, 18:49:18

Original geschrieben von BlackBirdSR
SM braucht nunmal Anpassungen, wo ist das Problem.
Und natürlich kann man niemals 100% des kerns auslasten. Aber ich sehe da keinen Zusammenhang mit der SMT Frage.

ich will damit sagen das bei 2 verschiedenen CPUs, die zB beide ~20% auslastung haben eine besser per SM ausgelastet werden kann als eine andere
eine bringst du dadurch auf zB 30%, die andere auf 21% (je nach aufbau)

ob letzeres sinnvoll ist wage ich anzuzweifeln

die frage ist also: wieviel leistung lässt sich per HT rausholen?
da AMD das recht dazu hätte (laut patent), aber weiterhin darauf verzichtet, nehme ich an das es bei ihrer architektur relativ wenig bringt

BlackBirdSR

2003-11-07, 18:53:40

Original geschrieben von Tesseract

da AMD das recht dazu hätte (laut patent), aber weiterhin darauf verzichtet, nehme ich an das es bei ihrer architektur relativ wenig bringt

nicht das schon wieder :(

Zeig mir das Patent, das AMD ein Recht auf Intel SMT gibt,
ich seh da nur Concurrent Multithreading.
Und wo steht, dass SMT = Concurrent Multithreading ist?

und selbst wenn es so wäre, was es nicht ist *g*
AMD müsste nicht nur den Core anassen, sie müssten erstmal eine SMT Implementierung entwickeln.
SMT an sich ist ja frei.. man müsste halt ein Konzept dafür haben.

Tesseract

2003-11-07, 19:01:43

Original geschrieben von BlackBirdSR
Zeig mir das Patent, das AMD ein Recht auf Intel SMT gibt,

was soll "intel SMT" denn sein? HT vom p4? was soll amd damit anfangen?

was willst du jetzt eigendlich hören?

Muh-sagt-die-Kuh

2003-11-07, 19:57:38

Original geschrieben von Tesseract
theoretische leistung: ja
das heißt aber nicht das diese auch nutzbar ist über techniken wie HTKannst du das bitte etwas genauer ausführen?Ich will damit sagen das bei 2 verschiedenen CPUs, die zB beide ~20% auslastung haben eine besser per SM ausgelastet werden kann als eine andere
eine bringst du dadurch auf zB 30%, die andere auf 21% (je nach aufbau)Und wieso kann dies deiner Meinung nach so sein?ob letzeres sinnvoll ist wage ich anzuzweifeln

die frage ist also: wieviel leistung lässt sich per HT rausholen?
da AMD das recht dazu hätte (laut patent), aber weiterhin darauf verzichtet, nehme ich an das es bei ihrer architektur relativ wenig bringtIch behaupte jetzt einfach mal, sie waren nicht in der Lage ein gescheite Implementation hinzubekommen und versuchen es durch diese Behauptung zu vertuschen. ;)

Endorphine

2003-11-07, 20:07:46

Original geschrieben von Muh-sagt-die-Kuh
Ich behaupte jetzt einfach mal, sie waren nicht in der Lage ein gescheite Implementation hinzubekommen und versuchen es durch diese Behauptung zu vertuschen. ;) Ich denke eher, dass bei AMD bereits alle Ressourcen in die 64-Bit Erweiterung und den K8 allgemein flossen. Als die Entwicklung begann war vielleicht (für AMD) auch der Trend zu SMP-on-die noch nicht so absehbar. SMT als Steigbügel dazu - darauf muss man auch erst einmal kommen :)

Allerdings kann man eines feststellen: von SMT kann jeder sofort profitieren (aktuelles OS à la Win2k3/XP oder Linux 2.6 vorausgesetzt), der höhere Durchsatz ist ja praktischerweise nicht nur bei modernen Multithreading Applikationen vorhanden, sondern auch bei Multitasking. Und von SMT profitiert man um so mehr, je weniger die einzelnen Tasks/Threads auf die Netburst-Architektur angepassten Code aufweisen.

Die 64-Bit Erweiterung bringt grundsätzlich erst einmal nur einen grösseren Adressraum. Und dafür benötigt es zwingend neue, noch zu schreibende OS und Anwendungen. Zudem hat niemand etwas davon, der jetzt noch locker mit 3,5 GiB an RAM auskommt.

betasilie

2003-11-07, 20:07:55

BUG und Tesseract werden immer gefragt, woher sie ihr wissen haben;
ich frage mich nun aber, woher die Leute ihr wissen haben, die behaupten, dass Intels HT auf die K7/8-Architektur anwendbar wäre.
Bevor man Leute auffordert Argumente für etwas zu bringen, sollte man selber erstmal Argumente auf den Tisch legen, bevor man Argumente fordert.

Endorphine

2003-11-07, 20:12:51

Original geschrieben von betareverse
BUG und Tesseract werden immer gefragt, woher sie ihr wissen haben;
ich frage mich nun aber, woher die Leute ihr wissen haben, die behaupten, dass Intels HT auf die K7/8-Architektur anwendbar wäre.
Bevor man Leute auffordert Argumente für etwas zu bringen, sollte man selber erstmal Argumente auf den Tisch legen, bevor man etwas behauptet. Es geht nicht um "Intels HTT", sondern um SMT allgemein. Niemand behauptet, AMD müsse lediglich ein paar Designteile des P4 per drag & drop in den K8 einfügen. Das Prinzip SMT (eine Technologie aus den 70ern) kann AMD aber genauso anwenden wie Intel. Sie müssen es nur implementieren.

Irgendetwas an der Richtung SMT wird AMD sowieso in das K8-Design einfügen müssen, wenn SMP-on-die realisiert werden soll. Wir reden hier ja um preisgünstige x86-Mainstream CPUs, nicht um IBM-Mainframe CPUs, wo eine CPU den Preis eines Kleinwagens kosten darf.

Tesseract

2003-11-07, 20:18:59

Original geschrieben von Muh-sagt-die-Kuh
Kannst du das bitte etwas genauer ausführen?
[...]
Und wieso kann dies deiner Meinung nach so sein?

weil die architekturen dafür viel zu verschieden sind - die ganze arbeitsweise ist total anders
natürlich kann es sein das 2 verschiedene architekturen durch SMT gleichviel beschleunigen können, das ist dann aber eher "zufall"

bei HT werden teile der CPU, die nicht in verwendung sind, anders genutzt sofern dies möglich ist - aber das ist es meistens nicht, sonst hätten wir eine 100%ige CPU auslastung
das müsste schon ein ziemlicher zufall sein wenn bei CPU A soviele zusätzliche einheiten verwendet werden können um auf eine ähnliche leistungssteigerung zu kommen wie CPU B durch die zusätzlichen erhält wenn A unf B die arbeit anders angehen

Original geschrieben von Muh-sagt-die-Kuh
Ich behaupte jetzt einfach mal, sie waren nicht in der Lage ein gescheite Implementation hinzubekommen und versuchen es durch diese Behauptung zu vertuschen. ;)

es ist sogar sicher so das sie nicht genug zeit hatten SMT in einer ähnlichen form wie beim p4 in den k8 einzubauen - keine frage
aber warum sollten sie es deswegen auch bei zukünftigen (architektonisch ähnlichen) ablehnen?

edit: da HT schon im willamette vorhanden war nehme ich mal an intel hat bei der ganzen entwicklung des p4 schon sehr darauf geachtet das möglichst viele einheiten "recyclet" werden können - und sind deswegen vermutlich auch einige kompromisse eingegangen

reunion

2003-11-07, 20:26:11

Original geschrieben von Endorphine
Ich denke eher, dass bei AMD bereits alle Ressourcen in die 64-Bit Erweiterung und den K8 allgemein flossen. Als die Entwicklung begann war vielleicht (für AMD) auch der Trend zu SMP-on-die noch nicht so absehbar. SMT als Steigbügel dazu - darauf muss man auch erst einmal kommen :)

Allerdings kann man eines feststellen: von SMT kann jeder sofort profitieren (aktuelles OS à la Win2k3/XP oder Linux 2.6 vorausgesetzt), der höhere Durchsatz ist ja praktischerweise nicht nur bei modernen Multithreading Applikationen vorhanden, sondern auch bei Multitasking. Und von SMT profitiert man um so mehr, je weniger die einzelnen Tasks/Threads auf die Netburst-Architektur angepassten Code aufweisen.

Die 64-Bit Erweiterung bringt grundsätzlich erst einmal nur einen grösseren Adressraum. Und dafür benötigt es zwingend neue, noch zu schreibende OS und Anwendungen. Zudem hat niemand etwas davon, der jetzt noch locker mit 3,5 GiB an RAM auskommt.

Sorry aber für SMT muss genauso vom Betriebssystem unterstützt werden wie 64-bit...

betasilie

2003-11-07, 20:29:53

Original geschrieben von Endorphine
Es geht nicht um "Intels HTT", sondern um SMT allgemein. Niemand behauptet, AMD müsse lediglich ein paar Designteile des P4 per drag & drop in den K8 einfügen. Das Prinzip SMT (eine Technologie aus den 70ern) kann AMD aber genauso anwenden wie Intel. Sie müssen es nur implementieren.

Ok, das will ich ja garnicht bestreiten.

Die Frage die sich stellt bleibt allerdings: Wieviel nutzen hätte die K7/K8-Architektur von SMT bei was für einem Entwicklungsaufwand?

Endorphine

2003-11-07, 20:32:51

Original geschrieben von reunion
Sorry aber für SMT muss genauso vom Betriebssystem unterstützt werden wie 64-bit... Dazu braucht es nur einen gewöhnlichen SMP Task-Scheduler (seit WinNT Standard, Linux seit 2.0). SMT-awareness ist sehr einfach zu realisieren, dazu reicht ein Patch des Schedulers aus. Für 64-Bit musst du sämtliche Anwendungen und das ganze OS neu aufsetzen. Auch alle relevanten Treiber, Protokolle etc. müssen neu geschrieben oder zumindest neu übersetzt werden. Der Aufwand unterscheidet sich um Potenzen.

Endorphine

2003-11-07, 20:36:20

Original geschrieben von betareverse
Die Frage die sich stellt bleibt allerdings: Wieviel nutzen hätte die K7/K8-Architektur von SMT bei was für einem Entwicklungsaufwand? Ja, die Frage stellt sich. Du bist aufgerufen, ein Tool für K7/K8 zu schreiben, welches den Performance Counter auswertet und die Einheitenauslastung in Echtzeit anzeigt. An die Arbeit :) Nur meckern is' nich, beta...

Etwas wie SMT ist btw. die Vorraussetzung für eine Entwicklung hin zu Multicore bzw. SMP-on-die. Alles andere wäre im x86-Markt unwirtschaftlich, da die Diegrössen sonst mit einem Mal sprunghaft in nie gekanntem Ausmaß anwachsen würden.

Tesseract

2003-11-07, 20:38:37

Original geschrieben von Endorphine
da die Diegrössen sonst mit einem Mal sprunghaft in nie gekanntem Ausmaß anwachsen würden.

wenn da nicht der cache wär, der allein einen großen teil des DIEs ausmacht

betasilie

2003-11-07, 20:42:13

Original geschrieben von Endorphine
Ja, die Frage stellt sich. Du bist aufgerufen, ein Tool für K7/K8 zu schreiben, welches den Performance Counter auswertet und die Einheitenauslastung in Echtzeit anzeigt. An die Arbeit :) Nur meckern is' nich, beta...

Etwas wie SMT ist btw. die Vorraussetzung für eine Entwicklung hin zu Multicore bzw. SMP-on-die. Alles andere wäre im x86-Markt unwirtschaftlich, da die Diegrössen sonst mit einem Mal sprunghaft in nie gekanntem Ausmaß anwachsen würden.
Hehe. So kompetent bin ich ja doch nicht, aber das weißt Du ja. ;) Ich lese bei diesem thema ja nur interessiert mit und merke das beide Seiten irgendwie keine echten Argumente für ihre Thesen haben.

Endorphine

2003-11-07, 20:53:16

Original geschrieben von Tesseract
wenn da nicht der cache wär, der allein einen großen teil des DIEs ausmacht Eben. Genau deshalb braucht man Mechanismen wie SMT, die eine sanfte weitere Steigerung der CPU-internen Parallelität ermöglichen und gleichzeitig das Problem der Auslastung beherrschen helfen.

SMT ist der erste Schritt, die Unterteilung in weniger abhängige redundant vorhandene parallel arbeitende Einheiten kann damit beginnen, ohne dass einfach unwirtschaftlich zwei diskrete Cores aneinandergeklatscht werden und man für eine CPU >20k EUR bezahlen muss:
http://www.theinquirer.net/images/articles/bluey.jpg

AMD hat diesen ersten Schritt noch vor sich.

Tesseract

2003-11-07, 20:56:03

Original geschrieben von Endorphine
AMD hat diesen ersten Schritt noch vor sich.

der speicherkontroller der k8 kann aber 2 "rechenkerne" mit einem gemeinsamen cache auf einem gemeinsamen DIE verwalten

die DIE größe steigt deswegen aber nicht um welten an, sondern etwa um 50%

die leistung ist HT natürlich bei weitem überlegen weil wir fast ein echtes dualsystem haben (daher auch mehr hitze und höhere kosten)

Endorphine

2003-11-07, 21:01:32

Original geschrieben von Tesseract
der speicherkontroller der k8 kann aber 2 "rechenkerne" mit einem gemeinsamen cache auf einem gemeinsamen DIE verwalten

die DIE größe steigt deswegen aber nicht um welten an, sondern etwa um 50%

die leistung ist HT natürlich bei weitem überlegen weil wir fast ein echtes dualsystem haben (daher auch mehr hitze und höhere kosten) Quellen?

Tesseract

2003-11-07, 21:23:02

war doch eh auf einigen seiten als news

arg, die seite wo ich den link hätte is grade down
ich schau mal ob ich den link händisch finde

pippo

2003-11-07, 22:03:14

@ Tesseract
AMD hat dahin noch garnichts gesagt, das sind alles nur Vermutungen, dass der Speichercontroller den Cache aufteilen kann. Ich geh zwar auch davon aus, aber bestätigt wurde von seiten AMD noch nichts.
Ich denke es wär sogar besser als ein normales Dualsystem, da die Latenzen der beiden CPU´s niedriger sind

Muh-sagt-die-Kuh

2003-11-08, 00:19:14

Original geschrieben von Tesseract
weil die architekturen dafür viel zu verschieden sind - die ganze arbeitsweise ist total anders
natürlich kann es sein das 2 verschiedene architekturen durch SMT gleichviel beschleunigen können, das ist dann aber eher "zufall"

bei HT werden teile der CPU, die nicht in verwendung sind, anders genutzt sofern dies möglich ist - aber das ist es meistens nicht, sonst hätten wir eine 100%ige CPU auslastungGehts noch ein bischen schwammiger? ;)

Wieso genau ist der K7/8 Kern deiner Meinung nach für SMT nicht gut geeignet?es ist sogar sicher so das sie nicht genug zeit hatten SMT in einer ähnlichen form wie beim p4 in den k8 einzubauen - keine frage
aber warum sollten sie es deswegen auch bei zukünftigen (architektonisch ähnlichen) ablehnen?Das habe ich auch nie behauptet, AMD wird diesen Weg irgendwann gehen müssen.edit: da HT schon im willamette vorhanden war nehme ich mal an intel hat bei der ganzen entwicklung des p4 schon sehr darauf geachtet das möglichst viele einheiten "recyclet" werden können - und sind deswegen vermutlich auch einige kompromisse eingegangen Was meinst du mit "einheiten recycelt" und welche Kompromisse siehst du hier?

Muh-sagt-die-Kuh

2003-11-08, 00:23:49

Original geschrieben von Tesseract
die DIE größe steigt deswegen aber nicht um welten an, sondern etwa um 50%50% können durchaus als "Welten" angesehen werden...der Yield geht bei solch einer Vergrößerung nämlich gut in den Keller ;)

betasilie

2003-11-08, 00:30:30

Original geschrieben von Muh-sagt-die-Kuh
50% können durchaus als "Welten" angesehen werden...der Yield geht bei solch einer Vergrößerung nämlich gut in den Keller ;)
Deswegen wird so ein Ding auch nicht in 0.15µ gefertigt.

Tesseract

2003-11-08, 01:02:06

Original geschrieben von Muh-sagt-die-Kuh
Gehts noch ein bischen schwammiger? ;)

was ist daran nicht zu verstehen?

HT ist kein unabhängiges element sondern steht in einem bezug zu den restlichen komponenten der CPU
die folgerung dass HT, wenn es auf der architektur A um x prozent schneller ist auf der architektur B auch x prozent bringen muss ist schlicht und einfach falsch wenn A != B

Original geschrieben von Muh-sagt-die-Kuh
Wieso genau ist der K7/8 Kern deiner Meinung nach für SMT nicht gut geeignet?

hab ich das behauptet?

Original geschrieben von Muh-sagt-die-Kuh
Was meinst du mit "einheiten recycelt"

einen zweiten thread auf der CPU bearbeiten

Original geschrieben von Muh-sagt-die-Kuh
und welche Kompromisse siehst du hier?

ich meine chipinterne optimierungen auf HT
zB aufteilungen der einheiten innerhalb des kerns
anordnung der leiterbahnen
platzeinteilungen
etc.

BlackBirdSR

2003-11-08, 08:54:36

Original geschrieben von Tesseract
was ist daran nicht zu verstehen?

HT ist kein unabhängiges element sondern steht in einem bezug zu den restlichen komponenten der CPU
die folgerung dass HT, wenn es auf der architektur A um x prozent schneller ist auf der architektur B auch x prozent bringen muss ist schlicht und einfach falsch wenn A != B

das sagt auch Keiner.
Aber du scheinst davon auszugehen, dass SMT dem K7/8 gar nichts bringen würde, bzw nur sehr wenig.

Dabei ist der K8 das beste Beispiel, wie wenig ausgelastet der K7 z.B war.
Gerade diesen beiden CPUs ist aufgrund der Ausführungseinheiten anscheinend noch eine Menge Potential versteckt.

Tigerchen

2003-11-08, 09:51:23

Original geschrieben von Endorphine
Dazu braucht es nur einen gewöhnlichen SMP Task-Scheduler (seit WinNT Standard, Linux seit 2.0). SMT-awareness ist sehr einfach zu realisieren, dazu reicht ein Patch des Schedulers aus. Für 64-Bit musst du sämtliche Anwendungen und das ganze OS neu aufsetzen. Auch alle relevanten Treiber, Protokolle etc. müssen neu geschrieben oder zumindest neu übersetzt werden. Der Aufwand unterscheidet sich um Potenzen.

Warum nur ist die SMP-Version von Quake 3 so langsam....
Wirklich alles so einfach?
Oder profierten die meisten Desktopanwendungen doch nicht so dolle von SMP/SMT?Für Word braucht man es ja auch nicht wirklich.
AMD hat recht da im Moment nicht allzu viel Energie dran zu verschwenden.Der typische Homeuser hat nur ein Problem.Die Spiele sind zu lahm.Und das Spiele in Zukunft alle auf Intel's HT aka SMT optimiert werden der glaubte weiland sicher auch an die Verwendung von MMX.Solange ich bei einem typischen Spiel erstmal alle limitierenden Features der Grafikkarte abschalten muß um die Vorteile von HT überhaupt wahrzunehmen ist mir der ganze HT/SMT/SMP-Kram ziemlich egal.

Ganon

2003-11-08, 10:23:47

Original geschrieben von Tigerchen

Warum nur ist die SMP-Version von Quake 3 so langsam....

Wie meinst du das? Meinst du Quake3-SMP bei einem SMT-System, oder generell?

@Endorphine

Naja! Der Power5 ist aber auch ein SMT-Prozessor.

Muh-sagt-die-Kuh

2003-11-08, 11:33:51

Original geschrieben von betareverse
Deswegen wird so ein Ding auch nicht in 0.15µ gefertigt. Die Strukturgröße hat relativ gesehen keine Auswirkungen, der Yield eines 50% größeren Kerns, egal in welchem Prozess, wird immer deutlich niedriger sein.

Muh-sagt-die-Kuh

2003-11-08, 11:42:05

Original geschrieben von Tesseract
was ist daran nicht zu verstehen?

HT ist kein unabhängiges element sondern steht in einem bezug zu den restlichen komponenten der CPU
die folgerung dass HT, wenn es auf der architektur A um x prozent schneller ist auf der architektur B auch x prozent bringen muss ist schlicht und einfach falsch wenn A != BDas weiss ich...ich will einfach nur, dass du diese Behauptung, von der du wohl ziemlich überzeugt bist, fundiert begründest.hab ich das behauptet?Explizit nein, implizit ja.ich meine chipinterne optimierungen auf HT
zB aufteilungen der einheiten innerhalb des kerns
anordnung der leiterbahnen
platzeinteilungen
etc. Der Routing- / Layout-Software ist es reichlich egal, ob sie einen SMT oder nicht-SMT Kern vor sich hat. ;)

Muh-sagt-die-Kuh

2003-11-08, 11:48:15

Original geschrieben von Tigerchen
Warum nur ist die SMP-Version von Quake 3 so langsam....
Wirklich alles so einfach?Weil sie vielleicht nur halbherzig implementiert wurde? ;)

Unabhängige Threads innerhalb eines Prozesses zu erzeugen ist nicht immer leicht, das stimmt....aber dafür gibts ja noch genügend andere Prozesse auf einem System.Oder profierten die meisten Desktopanwendungen doch nicht so dolle von SMP/SMT?Für Word braucht man es ja auch nicht wirklich.
AMD hat recht da im Moment nicht allzu viel Energie dran zu verschwenden.Der typische Homeuser hat nur ein Problem.Die Spiele sind zu lahm.Und das Spiele in Zukunft alle auf Intel's HT aka SMT optimiert werden der glaubte weiland sicher auch an die Verwendung von MMX.Solange ich bei einem typischen Spiel erstmal alle limitierenden Features der Grafikkarte abschalten muß um die Vorteile von HT überhaupt wahrzunehmen ist mir der ganze HT/SMT/SMP-Kram ziemlich egal.Der Desktop Markt ist nicht das einzig relevante.

Überleg dir mal, was SMT einem dauerhaft unter Last stehendem Server-Prozessor, der einen möglichst hohen Durchsatz erzielen soll, bringt...

GRiNSER

2003-11-08, 12:36:00

HyperThreading wird ja nicht unbedingt mit mehr Geschwindigkeit in Spielen beworben sondern damit, dass man mehrere Sachen gleichzeitig bei gutem Speed machen kann [sah man ja gut in intel präsentation damals bei der vorstellung von HT im vergleich zu einem P4 ohne HT...]

Hab grad was gefunden was für die Diskussion interressant sein könnte: implementing hyper-threading (http://www.arstechnica.com/paedia/h/hyperthreading/hyperthreading-4.html)

Ganon

2003-11-08, 14:39:31

Original geschrieben von Muh-sagt-die-Kuh
Weil sie vielleicht nur halbherzig implementiert wurde? ;)
[/SIZE]

Also auf dem Mac bringt es ungefähr 60% mehr Leistung.

Tigerchen

2003-11-08, 14:45:34

Original geschrieben von Ganon
Wie meinst du das? Meinst du Quake3-SMP bei einem SMT-System, oder generell?

@Endorphine

Naja! Der Power5 ist aber auch ein SMT-Prozessor.

Nun Endorphine sieht wohl die Zukunft in SMP.Und SMT ist nur ein Schritt auf diesem Weg.Und alles ist ganz easy.Läuft sofort spitze.Anders eben als bei AMD's 64 Bit wie er so schön ausführt.Da muß ja alles neu gemacht werden um 64 Bit nutzbar zu machen.
Und da hab ich mir eben das meines Wissens nach einzige x86 SMP-Spiel rausgegriffen um mal so zu zeigen daß SMP für den Desktoprechner vielleicht doch nicht "einfach so" gigantische Mehrleistung ohne jeden Aufwand bringt.Und außerdem beseitigt es nicht das Problem daß Anwendungen unter Windows nicht größer als 2GByte sein können.Klingt viel.Aber schon heute gibts Games wie Gothic 2 die 512MByte + virtuellen Speicher brauchen um gescheit zu laufen.Und Entwickler wie Marc Reim von Epic konnten es ja gar nicht erwarten die NextGen Unreal-Engine auf 64 Bit in Angriff nehmen zu können.

Tigerchen

2003-11-08, 14:51:12

Original geschrieben von Muh-sagt-die-Kuh
Weil sie vielleicht nur halbherzig implementiert wurde? ;)

Unabhängige Threads innerhalb eines Prozesses zu erzeugen ist nicht immer leicht, das stimmt....aber dafür gibts ja noch genügend andere Prozesse auf einem System.Der Desktop Markt ist nicht das einzig relevante.

Überleg dir mal, was SMT einem dauerhaft unter Last stehendem Server-Prozessor, der einen möglichst hohen Durchsatz erzielen soll, bringt... [/SIZE]

Es ist sicher sinnvoll Servern mit speziell angepassten Programmen unter die Arme zu greifen.Sowas wird immer gemacht wenn es sich rechnet.

Aber kein Anwender merkt ob Word 2006 und Doom 5 voll SMP oder auch SMT-optimiert sind um auf dem Home-PC vollends zu harmonieren.Da wird wie üblich die Grafikkarte zum Flaschenhals.

http://www.tecchannel.de/tecspecial2/artikel/04/15.html

reunion

2003-11-08, 14:56:18

Original geschrieben von Muh-sagt-die-Kuh
Die Strukturgröße hat relativ gesehen keine Auswirkungen, der Yield eines 50% größeren Kerns, egal in welchem Prozess, wird immer deutlich niedriger sein.

Stimmt, aber ein in 90nm Prozess gefertigter Opteron/A64 mit 1mb L2-Cache braucht eine DIE Fläche von 114 mm² + 50% währen 171 mm² also immernoch deutlich günstiger als die jetztigen in 130nm gefertigten Opterons bzw A64 und dabei theoretisch 100% schneller!

betasilie

2003-11-08, 16:00:36

Original geschrieben von Muh-sagt-die-Kuh
Die Strukturgröße hat relativ gesehen keine Auswirkungen, der Yield eines 50% größeren Kerns, egal in welchem Prozess, wird immer deutlich niedriger sein.
Die Anzahl der Transitoren wächst sowieso immer weiter. Deiner Logik nach dürfte der Yield in den letzten Jahren immer weiter zurückgegangen sein bzw. dürften wir heute garkeine CPUs mehr herstellen können. Natürlich kannst Du mit einer kleineren Strukturgröße höher Takten und mehr Transistoren auf´s Silizium bringen bei gleichem Yield. Es ist auch keine Frage, dass der Yield sinken würde bei 50% mehr Transistoren imm gleichem Herstellungsprozess. Die Frage ist nun aber, wann so eine Dualcore-CPU für den Desktopmarkt machbar wäre, also wann xxx Transistoren einen ausreichend hohen Yield bringen.

Mal ganz nebenbei ist es doch Wurst, ob AMD jetzt einfach nen größeren Cache einbaut, die Architektur aufbläßt oder einfach nen zweiten Die draufmacht. Das kommt von der Transistorenzahl sowieso aufs gleiche raus.

Außerdem werden imo solche Dualcore-CPUs sowieso erstmal für den Servermarkt produziert und da wäre ein nicht so toller Yield wirtschaftlich tragbar.

Gast

2003-11-08, 16:33:14

[QUOTE]Original geschrieben von Muh-sagt-die-Kuh

Der Routing- / Layout-Software ist es reichlich egal, ob sie einen SMT oder nicht-SMT Kern vor sich hat. ;)QUOTE]

das einfachste beispiel is wohl der platz, den die HT einheit (die sowieso nicht ganz zusammenhängt) am DIE einnimmt

ohne HT hätte man den platz anders nutzen können, und sei es um den DIE kleiner zu machen

ich kenn mich nicht gut genug mit der p4 architektur aus um genaue beispiele zu geben sie anders machen hätten können aber du kannst gift drauf nehmen das intel HT miteingeplant hat und nicht zuerst den p4 entworfen hat und dann HT "drum herum" gebaut hat

[QUOTE]Original geschrieben von Muh-sagt-die-Kuh
Das weiss ich...ich will einfach nur, dass du diese Behauptung, von der du wohl ziemlich überzeugt bist, fundiert begründest.[QUOTE]

ich hab echt keinen schimmer was du jetzt genau von mir hören willst :D

ich versuche es mal:
HT ist eine optimierung der vorhandenen (schalt)logik
und da unterschiedliche logiken allgemein nicht gleich stark optimiert werden können (allein deswegen nicht weil sie meist schon unterschiedlich stark optimiert sind) muss das auch für HT nicht zutreffen - kann aber im einzelfall durchaus so sein

Tesseract

2003-11-08, 16:35:41

ups, das kommt davon wenn man überstürzt von einem anderen pc postet

sry =)

Muh-sagt-die-Kuh

2003-11-08, 16:43:05

Original geschrieben von Ganon
Also auf dem Mac bringt es ungefähr 60% mehr Leistung. Quelle?

Muh-sagt-die-Kuh

2003-11-08, 16:50:22

Original geschrieben von Tesseract
ich kenn mich nicht gut genug mit der p4 architektur aus um genaue beispiele zu geben sie anders machen hätten können aber du kannst gift drauf nehmen das intel HT miteingeplant hat und nicht zuerst den p4 entworfen hat und dann HT "drum herum" gebaut hatSicherlich haben sie das...und was hat das jetzt mit "Kompromissen" zu tun.ich hab echt keinen schimmer was du jetzt genau von mir hören willst :D

ich versuche es mal:
HT ist eine optimierung der vorhandenen (schalt)logik
und da unterschiedliche logiken allgemein nicht gleich stark optimiert werden können (allein deswegen nicht weil sie meist schon unterschiedlich stark optimiert sind) muss das auch für HT nicht zutreffen - kann aber im einzelfall durchaus so sein Schön und gut....wie wärs, wenn du mal den P4 und K7/8 Core nimmst und auf technischer Ebene begründest, wieso der K7/8 Core (den du wohl implizit meinst) von SMT nicht so gut profitiert wie der P4.

Ganon

2003-11-08, 16:57:17

Original geschrieben von Muh-sagt-die-Kuh
Quelle?

Ich!

Guck mal in meine Sig! Außerdem stand das auch mal in einer c´t. Dort ging es um MacOS X Spiele.

GRiNSER

2003-11-08, 18:57:29

HT ist nicht vorrangig für die Beschleunigung von Programmen sondern für bessere Pseudoparallelität von mehreren Prozessen gemacht worden [bzw. zur besseren Auslastung der Ausführungseinheiten]...

Soll heißen, dass man entweder für ein Programm mehrere Prozesse macht die dann schneller ausgeführt werden als ein einziger Prozess [durch bessere Verteilung von Speicherzugriffen etc.] oder dass man mehrere Programme gleichzeitig mit weniger Performanceverlust verwenden kann...

Die Implementierung von HT beim P4 ist nicht so aufwändig wie vllt manche meinen -> guckt euch doch den link an: implementing hyper-threading (http://www.arstechnica.com/paedia/h/hyperthreading/hyperthreading-4.html)

HOT

2003-11-08, 19:02:06

Original geschrieben von Tesseract
sry, aber die 20% sind mir beim encoden relativ egal verglichen mit dem vorteil, den eine bessere threadaufteilung bringt - wenn man also parallel dazu weiterarbeiten will am pc

man nehme ein anderes os und dieses problem ist gelöst :P
das is ja nur windows was dahingehend so grottenschlecht ist.

Tesseract

2003-11-08, 19:19:33

Original geschrieben von Muh-sagt-die-Kuh
Sicherlich haben sie das...und was hat das jetzt mit "Kompromissen" zu tun

durch die HT anbindung gibt es sicher einige abschnitte innerhalb der CPU die komplexer ausgeführt sein müssen (da zB schaltungen vorhanden sind, die es ohne HT nicht braucht)
eine höhere komplexität (mehr leitungen/transistoren und dementsprechend mehr latenzen/verlustleistung etc.) bei selben ergebnis (also bei nichtnutzen von HT) sehe ich persönlich als kompromiss an weil es eine bessere lösung gäbe
ein theoretischer willamette ganz ohne HT (nicht nur deaktiviert sondern einfach nicht berücksichtigt) wär definitiv effektiver als einer mit deaktiviertem HT
(der willy mit deaktiviertem HT war aber in dem fall trotzdem die bessere lösung weil ein einheitliches design die nachteile bei weitem überwiegt)

Original geschrieben von Muh-sagt-die-Kuh
wie wärs, wenn du mal den P4 und K7/8 Core nimmst und auf technischer Ebene begründest, wieso der K7/8 Core (den du wohl implizit meinst) von SMT nicht so gut profitiert wie der P4.

dann hast du mich scheinbar falsch verstanden
ich vermute das der k7/k8 nicht so leicht auf einen SMT ansatz wie HT umgebaut werden kann oder es einfach nicht so viel bringt weil AMD niemand verbietet an einer derartigen lösung zu arbeiten, die es aber totzdem nicht tun - nicht jetzt und scheinbar nicht beim k9

einer der gründe könnte sein das die nicht verwendeten resourcen des k7/k8 relativ ungeeignet dafür sind zeitgleich an einem zweiten task zu arbeiten
vermutlich müsste AMD den kern zwar nicht grundlegend, aber an vielen stellen verändern weil SMT beim ur-athlon einfach kein thema war

das der p4 wie geschaffen für HT ist sieht man daran, das HT bei optimaler nutzung einiges mehr rausholen kann als er es ohne HT zu leisten im stande wäre, es lassen sich also relativ viele einheiten recyceln verglichen mit der singelthreading variante

kann natürlich sein das sich der k8 da ähnlich verhält, dann verstehe ich aber die entscheidung von AMD nicht

Tesseract

2003-11-08, 19:25:12

Original geschrieben von HOT
man nehme ein anderes os und dieses problem ist gelöst :P
das is ja nur windows was dahingehend so grottenschlecht ist.

du bist dazu eingeladen mir (bzw. der firma) sämtliche programme aus deiner tasche nachzukaufen bzw. zu portieren - alles legal versteht sich ;)

GRiNSER

2003-11-08, 19:36:03

Original geschrieben von Tesseract
durch die HT anbindung gibt es sicher einige abschnitte innerhalb der CPU die komplexer ausgeführt sein müssen (da zB schaltungen vorhanden sind, die es ohne HT nicht braucht)
eine höhere komplexität (mehr leitungen/transistoren und dementsprechend mehr latenzen/verlustleistung etc.) bei selben ergebnis (also bei nichtnutzen von HT) sehe ich persönlich als kompromiss an weil es eine bessere lösung gäbe
ein theoretischer willamette ganz ohne HT (nicht nur deaktiviert sondern einfach nicht berücksichtigt) wär definitiv effektiver als einer mit deaktiviertem HT
(der willy mit deaktiviertem HT war aber in dem fall trotzdem die bessere lösung weil ein einheitliches design die nachteile bei weitem überwiegt)...

wenn du den link von mir angucken würdest, den ich oben geschrieben habe, dann würdest du nicht sowas schreiben - denn: beim P4 sind nur diese einheiten doppelt ausgeführt [kleiner teil vom die]:

-> Register renaming logic
-> Instruction Pointer
-> ITLB
-> Return stack predictor
-> Various other architectural registers

das wird partitioniert genutzt [kleiner teil vom die]:

-> Re-order buffers (ROBs)
-> Load/Store buffers
-> Various queues, like the scheduling queues, uop queue, etc.

miteinander verwendet werden folgende einheiten [größter teil vom die]:

-> Caches: trace cache, L1, L2, L3
-> Microarchitectural registers
-> Execution Units

bei deaktivietem HT bleiben nur die doppelt ausgeführten einheiten ungenützt - der rest wird ganz normal verwendet -> nur halt ohne mehrauslastung...

Muh-sagt-die-Kuh

2003-11-08, 20:02:52

Original geschrieben von Tesseract
durch die HT anbindung gibt es sicher einige abschnitte innerhalb der CPU die komplexer ausgeführt sein müssen (da zB schaltungen vorhanden sind, die es ohne HT nicht braucht)Kannst du vielleicht ein einzige Mal konkret werden? Grinser hat schon geschrieben, was Sache ist...eine höhere komplexität (mehr leitungen/transistoren und dementsprechend mehr latenzen/verlustleistung etc.) bei selben ergebnis (also bei nichtnutzen von HT) sehe ich persönlich als kompromiss an weil es eine bessere lösung gäbe
ein theoretischer willamette ganz ohne HT (nicht nur deaktiviert sondern einfach nicht berücksichtigt) wär definitiv effektiver als einer mit deaktiviertem HT
(der willy mit deaktiviertem HT war aber in dem fall trotzdem die bessere lösung weil ein einheitliches design die nachteile bei weitem überwiegt)Das sollte (fast) keinen Unterschied machen, da die doppelt ausgeführten Einheiten einfach wegfallen und der zusätzliche Verwaltungsaufwand in der Execution Pipeline verschwindend gering ist (im Prinzip nicht mehr als ein Statusbit zu welchem Thread der Befehl gehört)dann hast du mich scheinbar falsch verstanden
ich vermute das der k7/k8 nicht so leicht auf einen SMT ansatz wie HT umgebaut werden kann oder es einfach nicht so viel bringt weil AMD niemand verbietet an einer derartigen lösung zu arbeiten, die es aber totzdem nicht tun - nicht jetzt und scheinbar nicht beim k9Was die Schwere eine SMT Implementation angeht gibt es zwischen P4 und K7/8 keine grundlegenden Unterschiede.einer der gründe könnte sein das die nicht verwendeten resourcen des k7/k8 relativ ungeeignet dafür sind zeitgleich an einem zweiten task zu arbeiten
vermutlich müsste AMD den kern zwar nicht grundlegend, aber an vielen stellen verändern weil SMT beim ur-athlon einfach kein thema warBeim K9 bekommen sie diese Chance...und so groß sind die Veränderungen auch nicht, siehe Grinsers Post.das der p4 wie geschaffen für HT ist sieht man daran, das HT bei optimaler nutzung einiges mehr rausholen kann als er es ohne HT zu leisten im stande wäre, es lassen sich also relativ viele einheiten recyceln verglichen mit der singelthreading varianteNein, das zeigt nur, dass SMT eine sinnvolle Technik ist.kann natürlich sein das sich der k8 da ähnlich verhält, dann verstehe ich aber die entscheidung von AMD nicht Tja, genau die verstehe ich nämlich auch nicht. ;)

Tesseract

2003-11-09, 16:14:07

Original geschrieben von Muh-sagt-die-Kuh
Kannst du vielleicht ein einzige Mal konkret werden?

ich muss nicht konkret werden
es ist eine tatsache das sich zusätzliche schaltungen in der CPU negativ auf die effektivität auswirken, auch wenn sie nichtmal mit den anderen in verbindung stehen, sondern nur platz wegnehmen - das und nichts anderes wollte ich sagen

wie groß dieser unterschied ist, ist natürlich situationsabhängig und in dem fall sicher zu vernachlässigen, aber dennoch vorhanden

Original geschrieben von Muh-sagt-die-Kuh

Das sollte (fast) keinen Unterschied machen, da die doppelt ausgeführten Einheiten einfach wegfallen und...

und genau dieses "fast" ist der springende punkt

Original geschrieben von Muh-sagt-die-Kuh

Was die Schwere eine SMT Implementation angeht gibt es zwischen P4 und K7/8 keine grundlegenden Unterschiede

grund? beleg?

Original geschrieben von Muh-sagt-die-Kuh
Beim K9 bekommen sie diese Chance...und so groß sind die Veränderungen auch nicht, siehe Grinsers Post

laut grinsers post sind die "veränderungen" am p4 nicht besonders groß
über den k7/k8/k9 sagt das zunächst mal garnichts aus

kennst du die architektur des p4 gut genug um beurteilen zu können welche architektonischen gesichtspunkte des gesammten designs auch ohne SMT so am besten gewesen wären?
und kennst du den athlon gut genug um sagen zu können das sich jede geundlegende funktionsweise von SMT leicht auf diese architektur übertragen lässt?

Original geschrieben von Muh-sagt-die-Kuh
Nein, das zeigt nur, dass SMT eine sinnvolle Technik ist.

genau das habe ich geschrieben, nur mit anderen worten (bzw. etwas spezieller, nämlich nur auf den p4 bezogen) ;)

Muh-sagt-die-Kuh

2003-11-09, 16:43:12

Original geschrieben von Tesseract
grund? beleg?

laut grinsers post sind die "veränderungen" am p4 nicht besonders groß
über den k7/k8/k9 sagt das zunächst mal garnichts ausDoch...Dinge wie Pipelinelänge oder Anzahl der Execution Units sind für SMT vollkommen irrelevant.

Beim K7/8 muss man exakt die gleichen Einheiten duplizieren bzw partitionieren wie beim P4.kennst du die architektur des p4 gut genug um beurteilen zu können welche architektonischen gesichtspunkte des gesammten designs auch ohne SMT so am besten gewesen wären?
und kennst du den athlon gut genug um sagen zu können das sich jede geundlegende funktionsweise von SMT leicht auf diese architektur übertragen lässt?Ja.

BlackBirdSR

2003-11-09, 19:57:38

Man schaue sich den IBM Power5 an. IBM hat sich hier den Power4 Kern vorgenommen und SMT hinzugefügt.

Dabei spricht man von ca 24% mehr Chipfläche.
Nun ist der Power4 aber ein Monster von einer CPU. FMAC Einheiten, 9 Stages zum Decoden von Befehlen etc.

Also kaum etwas, das ich mit dem P4 vergleichen würde. Trotzdem schreibt IBM dass momentan im Allg. nur ca 25% der Ausführungseinheiten ausgelastet sind.

Und nun soll der K7/8, der quasi als kleiner Bruder der Alphas gehandelt wird, nicht für SMT geeignet sein?

Um dem zu spotten, hat SUN SMT Chip die nur der InOrder Execution mächtig sind.
Machen die das zum Spass? oder ist SMT ein Feature dass nunmal einem der großen Probleme unserer Zeit auf die Pelle rückt?

LOCHFRASS

2003-11-09, 21:57:28

Original geschrieben von Tigerchen

Warum nur ist die SMP-Version von Quake 3 so langsam....

Quelle? Ich hab da eher 25-50% Leistungssteigerung im Kopf.

€dit: http://www.digit-life.com/articles/i815epacorp6a815epd/

Windi

2003-11-09, 23:05:05

Ich kanns irgendwie gar nicht glauben, das man das einfach 1 zu 1 übernehmen kann.
Wenn das wirklich möglich ist, heist es dann das man nur die Einheiten vergrößern/verdoppeln muss, die die Rechnungen verwalten und sonst nichts?
An den Recheneinheiten müsste nichts geändert werden?

GRiNSER

2003-11-09, 23:07:13

Original geschrieben von Windi
Ich kanns irgendwie gar nicht glauben, das man das einfach 1 zu 1 übernehmen kann.
Wenn das wirklich möglich ist, heist es dann das man nur die Einheiten vergrößern/verdoppeln muss, die die Rechnungen verwalten und sonst nichts?
An den Recheneinheiten müsste nichts geändert werden?
lies dir diesen artikel: implementing hyper-threading (http://www.arstechnica.com/paedia/h/hyperthreading/hyperthreading-4.html) durch und du wirst wissen wie es funkt...

Mehrpack

2003-11-10, 00:47:37

hi,
Intel und AMD haben doch ein Patentaustausch abkommen, nachdem sie 1 1/2 Jahre nachdem eine Technologie vom anderen in dem Markt gekommen ist, sie diese Technik nutzen dürfen.
Diese 1 1/2 Jahre wären doch bald um, oder??

Mehrpack

zeckensack

2003-11-10, 01:00:34

Original geschrieben von Mehrpack
hi,
Intel und AMD haben doch ein Patentaustausch abkommen, nachdem sie 1 1/2 Jahre nachdem eine Technologie vom anderen in dem Markt gekommen ist, sie diese Technik nutzen dürfen.
Diese 1 1/2 Jahre wären doch bald um, oder??

Mehrpack AMD braucht keine Intel-Patente, um SMT zu implementieren. Hyperthreading ist nur ein Marketinggewäsch-Name für eine längst bekannte und gut dokumentierte Idee.

GloomY

2003-11-10, 01:53:18

Eins vorweg: Die Länge einer Pipeline hat nichts mit der Auslastung und damit nichts mit der Eignung für SMT zu tun. Hierbei geht es einzig um Signallaufzeiten und um die Performanceeinbrüche bei falscher Programm-Verzweigung (Pipeline Löschen).

( :bäh: Ich saß hier sicher 5 Minuten, um zu überlegen, wie man "Branch Miss Penalty" übersetzt... :| )
Original geschrieben von Tesseract
sry, aber die 20% sind mir beim encoden relativ egal verglichen mit dem vorteil, den eine bessere threadaufteilung bringt - wenn man also parallel dazu weiterarbeiten will am pc Jedes Multitasking Betriebssystem (alles älter als DOS, also Win 3.1 oder sogar noch früher) schafft es quasie parallele Ausführung von Prozessen, indem man die Ausführung der Threads serialisiert. Dazu braucht man keine CPU, die wirklich parallel arbeitet.
Original geschrieben von BlackBirdSR
Und nun soll der K7/8, der quasi als kleiner Bruder der Alphas gehandelt wird, nicht für SMT geeignet sein?

Um dem zu spotten, hat SUN SMT Chip die nur der InOrder Execution mächtig sind.
Machen die das zum Spass? oder ist SMT ein Feature dass nunmal einem der großen Probleme unserer Zeit auf die Pelle rückt? Jep. Was Sun angeht, kommt es sogar noch krasser: In diesem Interview (http://www.aceshardware.com/read.jsp?id=55000247) wird sogar angedeutet, dass die 4-fach SMT Cores des Niagara Prozessors vielleicht sogar nicht mal superscalar sind. D.h. selbst ein Prozessor, der nur eine Pipeline besitzt (und damit keinerlei Probleme mit Befehlsparallelisierung besitzt), hat teilweise schon so eine schlechte Effizienz, dass sich hier 4-fach SMT lohnt. Sicherlich geht's hier um Serverapplikationen mit starken Mutithreading und Branch intensivem Code usw., aber es zeigt doch klar, wie schlecht es um die interne Auslastung der CPUs steht.

Das dort genannte Beispiel spricht ebenfalls für sich: Wenn man 100 Instructions betrachtet, wovon jede in einem Takt ausgeführt werden könnte und 99 davon auch in je einem Takt ausgeführt werden, aber eine davon Dank eines Cache Misses 300 Takte braucht, dann dauert es trotzdem insgesamt ~400 Takte. Die IPC Rate liegt dann wie man sich ausrechnen kann bei lächerlichen 25%.

Moderne Prozessoren sind sehr oft am warten, allein schon wegen des langsamen DRAMs.

Eine andere Überlegung meinersteits warum AMD kein SMT im K8 verwendet hat: Sie hatten einfach nicht die nötigen Kapazitäten (sprich: Entwickler, sowohl Hard- als auch Software) für eine gleichzeitige Implementation von x86-64 und SMT.

Tesseract

2003-11-10, 09:14:14

Original geschrieben von GloomY

Jedes Multitasking Betriebssystem (alles älter als DOS, also Win 3.1 oder sogar noch früher) schafft es quasie parallele Ausführung von Prozessen, indem man die Ausführung der Threads serialisiert. Dazu braucht man keine CPU, die wirklich parallel arbeitet.

sag das mal M$ :|

BlackBirdSR

2003-11-10, 11:13:12

Original geschrieben von GloomY

Jep. Was Sun angeht, kommt es sogar noch krasser:

Eine andere Überlegung meinersteits warum AMD kein SMT im K8 verwendet hat: Sie hatten einfach nicht die nötigen Kapazitäten (sprich: Entwickler, sowohl Hard- als auch Software) für eine gleichzeitige Implementation von x86-64 und SMT.

SUN hat sowieso nen Schlag :D

Ansonsten stimme ich dir zu, AMD hatte wohl einfach nicht die Kapazitäten um noch schnell eine SMT Implementation für den K7/8 zu entwickeln.
Die Prinzipien sind zwar gleich, aber natürlich muss man für jede Architektur anders an die Sache rangehen.

BlackBirdSR

2003-11-10, 11:17:59

Original geschrieben von Tesseract
sag das mal M$ :|

warum? klappt doch prima?

Oder hast du nicht eben gerade Winamp neben deinem Browsr laufen?
Time Sliced Multithreading z.B.
Jeder Thread erhält eine bestimmte Zeit die es in der Ausführung verbringen darf. Dann muss es dem nächsten Thread Platz machen.
So wird ständig zwischen Threads gewechselt. Für den User nicht ersichtlich, entsteht so eine Multitasking Umgebung.

SMT geht nun einen Schritt weiter, und lässt Befehle von 2 oder 4 Threads gleichzeitig in die Pipeline. Hier kann man von Parallelität sprechen.

Und wenn man das mal differenziert betrachtet: Vom technischen Standpunkt, ist SMT wohl eines der besten Features um die Auslastung der CPUs zu erhöhen.

Tesseract

2003-11-10, 12:24:16

Original geschrieben von BlackBirdSR
warum? klappt doch prima?

naja

es gibt genug fälle von shuttering, prioritätsungleichgewicht etc. (wenn zB eine applikation der anderen resourcen wegnimmt) und damit verbundenes stocken oder gar nichtmehr reagieren des ganzen systems für kurze zeit
besonders betroffen sind games, numbercruncher (zB RC5) hardwarenahe diagnoseprogramme(zB MBM), druck, scann, virenscanner etc.

in den meisten fällen funzt es prima (zB winamp+browser) aber es gibt auch beispiele wo es nicht ganz so rund läuft wie man es gerne hätte
HT kann in dem fall sehrwohl etwas bringen, nicht weil es in der theorie der bessere multitasker ist sondern es einfach "schlechte programme etwas ausgleicht"

Tigerchen

2003-11-10, 15:59:19

Original geschrieben von LOCHFRASS
Quelle? Ich hab da eher 25-50% Leistungssteigerung im Kopf.

€dit: http://www.digit-life.com/articles/i815epacorp6a815epd/

http://www.tecchannel.de/tecspecial2/artikel/04/15.html

Daher halte ich SMP für Gamer für eine Sache die relativ uninteressant ist.Und solange die großen Companys ihre CPU's nicht in Massen als Dual-Core für alle ausliefern wird sich daran auch nichts ändern.Vorher wird da nämlich kein Spieleentwickler was für SMP optimieren.

LOCHFRASS

2003-11-10, 16:10:49

Original geschrieben von Tigerchen
http://www.tecchannel.de/tecspecial2/artikel/04/15.html

Daher halte ich SMP für Gamer für eine Sache die relativ uninteressant ist.Und solange die großen Companys ihre CPU's nicht in Massen als Dual-Core für alle ausliefern wird sich daran auch nichts ändern.Vorher wird da nämlich kein Spieleentwickler was für SMP optimieren.

Recht seltsame Ergebnisse, anscheinend harmonieren Dual-P4 Systeme nicht so recht mit der Q3 Engine, das müsste ich mal auf meinem Dual AMD testen...

Mehrpack

2003-11-10, 17:01:42

nevermind

Muh-sagt-die-Kuh

2003-11-10, 17:45:30

Original geschrieben von GloomY
Eine andere Überlegung meinersteits warum AMD kein SMT im K8 verwendet hat: Sie hatten einfach nicht die nötigen Kapazitäten (sprich: Entwickler, sowohl Hard- als auch Software) für eine gleichzeitige Implementation von x86-64 und SMT. Dem würde ich zustimmen.

GRiNSER

2003-11-10, 18:11:53

Original geschrieben von GloomY
( :bäh: Ich saß hier sicher 5 Minuten, um zu überlegen, wie man "Branch Miss Penalty" übersetzt... :| )

Branch Miss Penalty ... Verzögerung durch falscher Sprungvorhersage?

Programme laufen pseudoparallel auf einem Multitasking Sys mit einem Prozessor ab...

Das manche Programme nicht gut im Hintergrund laufen wollen, liegt oft am schlecht programmierten Programm selber und nicht an windows...

mrdigital

2003-11-10, 18:48:22

Original geschrieben von Tesseract
naja

es gibt genug fälle von shuttering, prioritätsungleichgewicht etc. (wenn zB eine applikation der anderen resourcen wegnimmt) und damit verbundenes stocken oder gar nichtmehr reagieren des ganzen systems für kurze zeit
besonders betroffen sind games, numbercruncher (zB RC5) hardwarenahe diagnoseprogramme(zB MBM), druck, scann, virenscanner etc.

in den meisten fällen funzt es prima (zB winamp+browser) aber es gibt auch beispiele wo es nicht ganz so rund läuft wie man es gerne hätte
HT kann in dem fall sehrwohl etwas bringen, nicht weil es in der theorie der bessere multitasker ist sondern es einfach "schlechte programme etwas ausgleicht"

Hier wirfst du aber allerhand in einen Topf....
das es beim Starten von MBM hängt, liegt an MBM bzw daran, dass MBM das Board abfragt, was halt ein Moment braucht (muss eben erst mal den SM Bus initailisieren), Drucken ist auch nicht gut als Bsp, denn hier müssen Daten Timigkritisch (beim Parport) übertragen werden, und da der Parport meist nur lausig (nicht Busmasterfähig) an den Rest des System angehängt ist, wundert es nicht, das ein 3GHz Rechner "ruckelt". Wenn es bei nem USB Drucker auch "ruckelt" dann haste einen miesen Druckertreiber oder einen Schlechten USB Treiber / Controller. Eine Applikation unter W2K oder XP sollt ner Anderen keine Resourcen mehr wegnehmen können, ausser du selbst setzt die Prio dieser Task hoch, aber dann kann auch ein Notepad dein Rechner lahm machen, wenn Du die Prio auf Realtime setzt, gerade beim Numbercrunchen kannste die Prio auf Low setzten, dann juckt das keine andere App nebenher und deine Rechenzeit wird nicht wesentlich länger. Das es bei deinem Virenscanner langsamer wird, leuchtet auch ein, denn dein System hat halt nur eine HDD und wenn zwei Apps auf die HDD wollen, dann muss halt serialisiert werden, was halt ne Verzögerung bedeutet.
Also die Beispiele die du hier gebracht hast, sind eben gerade nur mäßig geeignet um die Vorteile von HT zu demonstrieren, da die Verzögerungen durch den Rest der Hardware entsehen und das auch HT nicht wett macht. Das es mit HT besser gehen sollte ist auch klar, aber es sind eben andere Fälle in denen HT seine Stärke ausspielen kann...

GRiNSER

2003-11-10, 19:17:16

gut ausgeführt, mrdigital - hatte selber keine lust zu :bäh:

Tesseract

2003-11-10, 21:17:39

das mit MBM mag stimmen
beim druck meine ich aber nicht aus M$ word eine seite text ausdrucken sondern wenn man vor einem postscriptdruck hunderte MB umrechnen lässt was sogar auf schnellen systemen ein paar sekunden dauern kann
das kann das system ziemlich in die knie zwingen - mit par/USB hat das zunächst nichts zu tun weil das ganze passiert, bevor der drucker angesprochen wird - es geht hier rein ums umrechnen
RC5 hat bei mir übrigenz trotz niedrigster priorität shuttering und allgemein "unruhigeren" lauf (weniger konstante FPS) von games verursacht
beim virenscanner hängt es davon ab was er gerade zutun hat ob die platte schuld ist oder nicht
ich hab bei meinem vater bemerkt das norton system works (inkl. antivirus) das system ziemlich bremsen kann obwohl keine plattenzugriffe stattgefunden haben - wenn jemand eine gute erklärung dafür hat bitte melden, aber da keine plattenzugriffe stattfinden nehmen ich mal an die priorität ist schuld

CrazyIvan

2003-11-10, 21:18:47

@ Mrdigital

Wo wir grad beim Thema sind:
Kannst Du mir vielleicht sagen, weshalb Opera bei mir des öfteren mal ein paar Sekunden lang das ganze System lahmlegt. Ich meine, soooo viel Auslastung kann das ja selbst bei meinem Athlon 900 nicht verursachen.

BTW
Hab Win2K und pfusche nicht an den Prios rum - zumindest nich bei Opera ;D

mrdigital

2003-11-11, 10:27:59

Original geschrieben von CrazyIvan
@ Mrdigital

Wo wir grad beim Thema sind:
Kannst Du mir vielleicht sagen, weshalb Opera bei mir des öfteren mal ein paar Sekunden lang das ganze System lahmlegt. Ich meine, soooo viel Auslastung kann das ja selbst bei meinem Athlon 900 nicht verursachen.

BTW
Hab Win2K und pfusche nicht an den Prios rum - zumindest nich bei Opera ;D

Nein kann ich dir nicht sagen, aber der freundliche Opera Support bestimmt ;D
Nein mal im Ernst, ein Windowssystem ist mit all seinen Komponenten ziemlich komlex (OS Version, ServicePack version, evtl. Hotfixes, dann 100000 Verschiedene Treiber, die sich teilweise auch gegenseitig stöhren können etc. pp, mal ganz von den Unzulänglichkeiten der Hardware abgesehen). In dieser Komplexität kann man eben ein "ruckeln" des System eben nicht sofort an einer Bestimmten Ursache oder Komponente festmachen. In meinem Betrag ging es auch nicht darum zu behaupten, dass es KEIN ruckeln gibt sondern das die genannten Beispiele eben keine Anwendungsfälle sind, in denen HT seine Stärke ausspielen kann.

Edit:Rechtschreibung

mrdigital

2003-11-11, 10:42:05

Original geschrieben von Tesseract
das mit MBM mag stimmen
beim druck meine ich aber nicht aus M$ word eine seite text ausdrucken sondern wenn man vor einem postscriptdruck hunderte MB umrechnen lässt was sogar auf schnellen systemen ein paar sekunden dauern kann
das kann das system ziemlich in die knie zwingen - mit par/USB hat das zunächst nichts zu tun weil das ganze passiert, bevor der drucker angesprochen wird - es geht hier rein ums umrechnen
RC5 hat bei mir übrigenz trotz niedrigster priorität shuttering und allgemein "unruhigeren" lauf (weniger konstante FPS) von games verursacht
beim virenscanner hängt es davon ab was er gerade zutun hat ob die platte schuld ist oder nicht
ich hab bei meinem vater bemerkt das norton system works (inkl. antivirus) das system ziemlich bremsen kann obwohl keine plattenzugriffe stattgefunden haben - wenn jemand eine gute erklärung dafür hat bitte melden, aber da keine plattenzugriffe stattfinden nehmen ich mal an die priorität ist schuld
Wie schon im meinem vorigen Post, Windows ist recht komlex ;). Gerade was das Drucken angeht, gibt es jede Menge Optionen die einen erheblichen Einfluss auf die System / Druckgeschwindigkeit haben. Manch ein Druckertreiber beginnt mit der Ausgabe der Daten zum Drucker, während er noch weitere Seiten aufbereitet. Wenn du Dokumente mit mehr als 100 Seiten umfang Druckst, dann kommt dein System auch an eine Arbeitsspeichergrenze (reche mal aus wie viel Speicher eine Seite A4 in 600dpi verbrät, das ist nicht wenig ;)). Wenn dein Rechner nun zu swappen anfängt, ruckelts halt....Wenn du zockst und nebenher RC5 am laufen hast, dann würd ich mich auch nicht wundern, dass es langsamer wird, HT hin HT her, wenn du eine Applikation am laufen hast, die 100% Systemlast erzeugt, dann bleibt halt nix für die anderen Übrig, nur ist es halt so das ein Word auch mit wenig Rechenleistung klarkommt (ich weiss nicht sicher ob du weisst, wie das Mutlitasking von Windows realisiert wird), und deshalb ein Numbercruncher im Background laufen kann mit niedriger Prio (aber auch ein LowPrio Task will mal Rechenzeit haben und wenn es die halt nicht mehr gibt, dann müssen halt die anderen Apps was von ihrer Zeit abgeben). Wenn deine Games was von ihrer Rechenzeit abgeben müssen ruckelts halt. Aber es wär mir neu, das man auf nem HT System problemlos zocken kann und nebenher mal noch ein paar Videos encodet und noch nen Webserver betreibt und das alles ohne ruckeln ;)

GloomY

2003-11-11, 11:12:55

Original geschrieben von Tesseract
naja

es gibt genug fälle von shuttering, prioritätsungleichgewicht etc. (wenn zB eine applikation der anderen resourcen wegnimmt) und damit verbundenes stocken oder gar nichtmehr reagieren des ganzen systems für kurze zeit
besonders betroffen sind games, numbercruncher (zB RC5) hardwarenahe diagnoseprogramme(zB MBM), druck, scann, virenscanner etc.Kein Problem, das Phänomen mit RC5 kann ich erklären (Klick (http://www.forum-3dcenter.net/vbulletin/showthread.php?s=&postid=1075789#post1075789)).

Das hat damit zu tun, dass beim P4 der Scheduler im Prozessor die Instruktionen der beiden Threads gleich behandelt, unabhänig von den Prioritäten der einzelnen Threads. Denn der Prozessor-Scheduler weiss bei HTT nichts von den Prioritäten, so wie es der Betriebssystem-Scheduler weiss. Hier kann man im allgemeinen Fall bei einem n-Thread SMT Prozessor sagen, dass wenn es n Threads gibt, die alle sehr viel Rechenzeit haben wollen, ein Thread maximal 1/n der maximalen Rechenleistung bekommen kann. Bei Intel ist n=2, also kann ein Thread maximal die Hälfte der CPU Zeit bekommen. Wenn er "alleine" ist (also es keine weiteren Threads gibt, die den Prozessor benötigen), dann kann dieser Thread natürlich die volle Rechenpower der kompletten CPU bekommen.

Andere SMT Implementationen (wie beim Power5 Prozessor) können prozessorseitig die Ausführung eines Threads graduell bevorzugen (also z.B. 70%/30%), wonach dieser Effekt natürlich vermieden werden kann. Intels HTT kann das nicht.
Original geschrieben von GRiNSER
Branch Miss Penalty ... Verzögerung durch falscher Sprungvorhersage?Ich hab's ja selbst nach einiger Zeit hinbekommen ("Performanceeinbrüche bei falscher Programm-Verzweigung"), aber manchmal ist man einfach so blockiert, dass gar nichts mehr geht ;)

Tesseract

2003-11-11, 11:40:11

Original geschrieben von GloomY
Andere SMT Implementationen (wie beim Power5 Prozessor) können prozessorseitig die Ausführung eines Threads graduell bevorzugen (also z.B. 70%/30%), wonach dieser Effekt natürlich vermieden werden kann. Intels HTT kann das nicht.

kann es sein das darin der vorteil vom überarbeiteten HT des prescott steckt? (falls es wirklich unterschiede gibt)

GloomY

2003-11-11, 12:12:16

Original geschrieben von Tesseract
kann es sein das darin der vorteil vom überarbeiteten HT des rescott steckt? (falls es wirklich unterschiede gibt) Nein. Die HTT-Verbesserungen des Prescott sind dessen PNI (Prescott New Instructions) und ein paar weitere Verbesserungen am Core (die aber eigentlich nichts mit SMT direkt zu tun haben und auch bei nicht SMT-Betrieb wirken). Und bei den PNI ist die prioritätsgesteuerte Ausführung von Threads definitiv nicht dabei.

Der Rest der "HTT-Verbesserungen" ausser den PNIs wirken ja auch bei nicht SMT Betrieb (größerer Trace- und L1 D-Cache, größerer Register File, mehr Load/Store Buffer usw.)