Anti Hyper Threading -- AMD auf Irrwegen?

So schelcht finde ich die Idee gar nicht. Anwendungen, die auf Multi-Core bzw. Thread ausgelegt sind, können ja beide Kerne nutzen. Anwendungen, die nur einen Core bzw. Thread nutzen, kann aber mit diesem "Anti-Hyper Threading" Performancevorteile verschaffen. Sonst würde sich ja der 2. Core langweilen.
 
"Man ist sich bei AMD darüber im Klaren, dass die aktuelle K8-Architektur nicht mit den neuen Technologien aus dem Hause Intel mithalten kann."

Soso, wer hat das denn behauptet? Wird WF zum neuen THG?
Bisher ist es doch eher PaperLaunch gegen jetzige Produkte....
 
Ich weiß irgendwie noch nicht, was ich davon halten soll. Klingt zwar auf dem Papier wie die optimale Lösung (da ein großer Teil der Software nicht auf absehbare Zeit, vielleicht nie vernünftig auf mehrere Kerne verteilbar ist).
Aber es ist nicht gesagt, wie das funktionieren soll, oder wie lange und intensiv AMD daran schon arbeitet. Falls es überhaupt stimmt und nicht nur ein wildes Gerücht ist, was irgendein betrunkengemachter AMD-Mitarbeiter spaßeshalber lanciert hat.
 
Man ist sich bei AMD darüber im Klaren, dass die aktuelle K8-Architektur nicht mit den neuen Technologien aus dem Hause Intel mithalten kann.
Und bei Intel ist man sich sicher darüber im Klaren, dass ein 486er nicht mit einem K6 mithalten kann.
Vergleichen die wieder mal Apfelsaft mit Pflaumenmus oder so?:]
 
Denselben Effekt könnte man sicher auch erreichen, wenn der Prozessortreiber intelligneter gestaltet werden würde und im Bedarfsfall einen der beiden Kerne abschaltet und dafür die Taktrate des verbleibenden Kerns steigert. Das wäre sicher ohne größere Änderungen am Prozessordesign möglich und würde ebenfalls die Nachteile eines multicore Prozessordesigns auszugleichen helfen.
 
Zuletzt bearbeitet:
Interessant ist es durchaus wenn man es technisch realisieren kann.

Naja, da kann man leider wieder nur sagen, abwarten und nicht vorher die Glaskugel befragen! ;)
 
Je mehr ich darüber nachdenke, desto logischer wird das ganze. Theoretisch könnte es ja wie ein Raid-Stripeset funktionieren, indem die Teile des Threads aufgeteilt, abgearbeitet und dann wieder zusammen geführt werden. Sicher würde dabei Rechenleistung verloren gehen, aber selbst wenn nur 50% übrig bleiben würden, dann würde sich ein X2 mit 2x2Ghz theoretisch wie ein 3GHz Single Core A64 verhalten.
 
Dieses wird aber mit Sicherheit auch Nachteile haben, gegenüber einem System was die einzelnen Cores beläßt. Wie auch Raid-o bzw. HyperThreading in bestimmten Fällen zum Nachteil werden kann.

Für Games, die nicht DC optimiert sind, könnte es noch mehr FPS geben. Da wo eine echte limitiert. Aber was ist mit Programmen, die DC nutzen bzw. man die Prozesse auf unterschiedlichen Cores verteilen will.

Wie soll dies dann noch funktionieren ? - bzw. entweder nutzt man das System als DC oder schnelles Single-System, beides zugleich dürfte nicht möglich sein.
 
Und schon bald wird alles nur noch über virtuelle CPUs berechnet - was und wieviel dahinter wirklich ist weiss dann nichtmal mehr Windows. Genauso war es früher mit den Grafik APIs unter Windoof. Dann kam endlich DirectX und konnte die GraKa direct ansprechen... das kommt dann auch für die CPUs und wir sind wieder da wo wir heute sind... Aber bis dahin sind wir sicher bei 6GHz statt 3.

Ich liebe diese Idee. Ich kann doch heute schon komplette Computer emulieren - warum nicht eine 5GHz CPU emulieren und ihre Berechnungen von zwei kleineren ausführen lassen? Sollte alles mit dem CPU Treiber möglich sein - wie oben schon einer geschrieben hat.
 
Der einzige Ansatz, der für mich Sinn macht sieht folgendermaßen aus: Nehmen wir an wir haben eine Dual-Core CPU mit je 3 ALU und 2 FPU Pipes. Doch anstatt dass diese Recheneinheiten den beiden Kernen fest zugeordnet sind, kann sich Kern A auch mal die Recheneinheiten von Kern B ausleihen. Somit könnten die Recheneinheiten beider Kerne besser ausgelastet werden.

Ein viel weiter gedachter Ansatz ist der, dass die CPU selber einen Thread in mehrere Unterthreads zerteilt und diese auf die verschiedenen Kerne verteilt. Das erfordert jedoch gegenüber heutigen Decodern deutlich intelligentere Versionen.
 
Wenn AMD wirklich soetwas auf den Markt bringen will, sollte es bald geschehen... Aber einen besseren Namen als "Anti-Hyper-Threading" wird es schon brauchen *lol*
 
... soo ähm... ich weiche mal etwas vom PC ab.... also: Der Cell Prozessor hat doch auch eine multiprozessor architektur mit Einem hauptcore und vielen kleinen untercores. müsste das bei dem nich schon so funktionieren wie mtb][sledgehammer gesagt hat, dass der Prozessor automatisch mehrere Unterthreads erstellt, oder wird das vom Programmierer erledigt? das stelle ich mir allerdings ziehmlich umständlich vor!
Und wenn ich jetzt davon ausgehe, dass das ganze mal so beim PC funktioniert wäre es dann nicht am inteligentesten die vielen kleinen untercores auf bestimmte Aufgaben zu spezialisieren... einen für integer einen für fließkomma (halt die sachen, die auf jeden fall benötigt werden), der hauptcore würde also nur noch dafür sorgen, dass komplexe befehlssätze unterstützt werden und diese in einfachere befehle für die untercores aufteielen?!
Und wenn man wollte kann man dann die einelnen cores auch seperat ansprechen um das letzte bisschen leistung herauszubekommen.

(oh gott, ein Glück dass wir im thread Spekulationen sind) :]
 
Zuletzt bearbeitet:
Wenn AMD wirklich soetwas auf den Markt bringen will, sollte es bald geschehen... Aber einen besseren Namen als "Anti-Hyper-Threading" wird es schon brauchen *lol*
Solche Techniken werden langfristig entwickelt und dürften im Basis-Design schon viele Jahre alt sein. Nachdem bei Hyper-Threading oft Performance-Verluste auftreten und AMD ja schon seit Ewigkeiten weis, daß Dual-Core nicht für alle Applikationen Vorteile bringt lag solch eine Entwicklung nahe.

Ob Intel sie im Conroe bereits hat muss man sehen. Es erscheint aber lt. einigen ersten Benchmarks möglich. Allerdings enthält der (erste) Conroe lt. Intel nur die elementartsten Umsetzungen für dessen integrierte Hardware. Wirklich interessant wird es erst wenn die zeite Conroe-Generation (45nm ?) auf die erste neue (und ausgefeilte) von AMD trifft.
 
Im Cell muss der Programmierer AFAIK selbst dafür sorgen, dass er die ganzen CPU Kerne mit Arbeit versorgt.
 
War es nicht Sun, die bereits vor einigen Monaten preisgegeben haben, dass sie an einer solchen Technik arbeiten? Damals hieß es doch, dass die Decoder so intelligent sein sollen, dass diese selbstständig einen Thread in mehrere "Unterthreads" zerlegen können
 
Wenn der Kram rauskommt ist eh schon das meiste DC optimiert...
Das bezeifle ich beinah. Wünschenswert wäre es zwar, aber bei vielen Programmen lohnt sich der Aufwand den Code für multicore oder multiprocessor System zu optimieren gar nicht. Manchmal bläht man den Code dadurch auch nur unnötig auf, dass das Programm auf Singelcore Systemen langsamer wird und auf DualCore Systemen wegen der fehlenden Ausprägung der Parallelisierbarkeit nicht wesentlich schneller wird. Außerdem werden oftmals auch noch ältere Programme eingesetzt. Gerade bei Firmen. Dort soll es durchaus noch System gegen, die als Betriebssystem auf Windows 98 oder NT 4.0 setzen.
 
Also ich finde es gut. Eine gute Funktion mehr.
Ich werde mir dann keinen 939 sondern einen AM2 holen.
 
mtb][sledgehammer;2690856 schrieb:
Im Cell muss der Programmierer AFAIK selbst dafür sorgen, dass er die ganzen CPU Kerne mit Arbeit versorgt.

Ah danke... hm darum dauern Spieleportierungen wohl auch so lang...... aber das ist ein anderes Thema.

Wnn kommt der (völlig) neue AMD Kern gleich nochmal, 2008?!
 
War es nicht Sun, die bereits vor einigen Monaten preisgegeben haben, dass sie an einer solchen Technik arbeiten? Damals hieß es doch, dass die Decoder so intelligent sein sollen, dass diese selbstständig einen Thread in mehrere "Unterthreads" zerlegen können


hast du dazu nen Link? (bzgl. dem SUN Gerücht)

Hier mal was ich bei Intel fand ...
http://www.intel.com/technology/magazine/research/speculative-threading-1205.htm

CB
.
.
Edit:
Und bei Intel ist man sich sicher darüber im Klaren, dass ein 486er nicht mit einem K6 mithalten kann.
Vergleichen die wieder mal Apfelsaft mit Pflaumenmus oder so?:]

es ist echt lästig, wenn man über Technologien spuekuliert,
und sich FanBoy geflame untermischt ...

Denselben Effekt könnte man sicher auch erreichen, wenn der Prozessortreiber intelligneter gestaltet werden würde und im Bedarfsfall einen der beiden Kerne abschaltet und dafür die Taktrate des verbleibenden Kerns steigert. Das wäre sicher ohne größere Änderungen am Prozessordesign möglich und würde ebenfalls die Nachteile eines multicore Prozessordesigns auszugleichen helfen.

also auf Softwareebene kann ich mir die Lösung garnicht vorstellen,

hardwareseitig könnte das vllt so aussehen,
dass ein Core vor dem Betriebssystem versteckt bleibt,
und dieser dann bei parallelisierbarem Code Routinen vom Hauptcore zur Abarbeitung bekommt.
Da wird dann auch kein Scheduler Einfluss drauf haben.

CB
 
Zuletzt bearbeitet:
Zurück
Oben Unten