AMD mit Anti-Hyper-Threading?

[Gast]

Von Planet3DNow:

Bereits im April gab es Gerüchte über dem möglichen Einsatz einer Anti-Hyper-Threading genannten Technik bei AMD. Eine russische Seite will nun erfahren haben, dass Anti-Hyper-Threading kommt und zwar kurz vor dem offiziellen Start des Conroe.

Die Technik wird als Anti-Hyper-Threading bezeichnet, da sie sich praktisch gegenteilig zu Intels Hyper-Threading-Technologie verhält.

Als Hyper-Threading Technologie (HTT) bezeichnet Intel seine Implementierung von Simultaneous Multithreading (SMT) in den Prozessoren Pentium 4 und Xeon. Wie bei SMT werden mittels Duplizierung und Aufteilung bestimmter Ressourcen virtuelle CPUs (Siblings) generiert, die mehrere (Teil-)Programme (Threads) weitgehend parallel ausführen können.

Statt einer parallelen Ausführung soll Anti-Hyper-Threading bewirken, dass sich eine CPU mit mehreren Kernen gegenüber der Anwendungssoftware als eine CPU darstellt und die Recheneinheiten beider Kerne genutzt werden können. Dies soll dem Umstand Rechnung tragen, dass die Entwicklung von Software für den Endanwender, die auf Multithreading optimiert wurde, noch nicht weit vorangeschritten ist.

Laut diesem Bericht (englische Übersetzung) soll Anti-Hyper-Threading in den AM2-Prozessoren durch einen neuen Prozessortreiber und einen Microsoft-Patch freischaltbar sein und am Tag vor dem offiziellen Conroe-Launch vorgestellt werden.

Ist das vielleicht der Conroe Killer Effekt? Das wird auf alle Fälle ein heißer Sommer ;)

[Gast]

So ein Quatsch, typisch AMD...

[Gast]

Wieso Quatsch?

Wenn es gut funktionieren sollte dann gibt es bestimmt einen guten performance Schub...

[Fatality]

ne, wäre vermutlich äusserst ineffizient.

[BK-Morpheus]

[QUOTE='Fatality']Quelle?[QUOTE]
guck auf die ersten Buchstaben des ersten Postings:
PLANET 3D NOW ist die Quelle.

Die News sind schon älter und mich würde auch mal interessieren, was draus geworden ist.

[TheCounter]

http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1150705513
http://www.overclockers.ru/hardnews/22558.shtml
http://www.investorshub.com/boards/read_msg.asp?message_id=11637290

Na da bin ich mal gespannt obs denn was bringt wenn es wahr ist. Dann würd ich noch warten bevor ich mir nen X2 hol.

[Gast]

Fatality[/POST]']Quelle?
Steht doch im ersten Post als Überschrift!

Von Planet3DNow:

[Rente]

AFAIK haben sich die CPU-Gurus hier im Forum so geäußert, als das es totaler Blödsinn ist.

[dildo4u]

Von mir aus können sie so viele unsinnige Gerüchte streuen wie sie wollen AMD hat gezeigt das sie es nicht mher direkt mit Intel aufnehmen wollen im Desktop Segment deshalb werden auch alle X2 mit 2MB Cache eingestellt.Es wird kein Wunder treiber geben der plötzlich alle AMDs schneller macht.Wenn es den denn wirklich geben sollte würde man ihn schon jetzt bringen um schon mal im Vorfeld des Conroe Launches Werbung für den AM2 zu machen.
Außerdem woher soll der Treiber bei jeder Anwendung erkennen ob ein Programm vom DC profitiert oder nicht bei Quake 4 z.B würde es dann wesentlich langsammer laufen und die Optemierung im Grafikarten Treiber wär auch fürn Arsch.

[TheCounter]

dildo4u[/POST]']Wenn es den denn wirklich geben sollte würde man ihn schon jetzt bringen um schon mal im Vorfeld des Conroe Launches Werbung für den AM2 zu machen.

Das wäre aber Marketingtechnisch dann doch nicht so klug imo. Ist doch klasse wenn man einen Tag vor dem Release des Konkurrenzprodukts (oder am selben Tag) etwas released das die eigenen Produkte wieder nach vorne katapultiert ;)

Wird aber eh nicht passieren.

[rpm8200]

Vielleicht geht das eben nicht so schnell und es wird noch Zeit benötigt. Irgendwie finde ich die Meldung zwar auch seltsam, allein schon wegen der Namensgebung "AntiHyperThreading". Aber mal sehen. Wie immer würde ich sagen, dass es _viel_ zu früh ist sowas

a) als totalen Quatsch
b) als die reine Wahrheit hinzustellen

Und Graustufen dazwischen gibts eigentlich doch nicht wirklich (entweder is was dran oder nicht). Also mal abwarten.

[Monger]

Hmm... also dass die CPU selbstständig erkennen soll was in einen eigenen Thread gepackt werden kann und was nicht, halte ich für wenig wahrscheinlich. Aber ich lasse mich gerne vom Gegenteil überzeugen...

[rpm8200]

dildo4u[/POST]']... woher soll der Treiber bei jeder Anwendung erkennen ob ein Programm vom DC profitiert oder nicht ...Also wie eben gepostet bin ich auch eher skeptisch, ob diese Meldung stimmt/ ob da was dran ist. Allerdings die von Dir geschilderte Problematik ist nicht vorhanden. Der User könnte das entscheiden und "einfach" einen Schalter umlegen zwischen z.B. "emulation single" und "Dual". Es soll ja auch nur den zweiten Kern besser ausnutzen in nicht multithreaded-optimierten Anwendungen.

Wie gesagt, ich bin selbst skeptisch. Aber unlösbare Probleme gibt es da (glaube ich) nicht...

Auf der anderen Seite sehe ich keinen Grund, warum Intel das nicht ähnlich lösen könnte.

[Super Grobi]

Schade,
nur für AM2. Hätte das gerne auch für meine CPU. Ob die Sache auch Hardware abhäniig ist, oder marketingtechnisch softwareseitig nur für AM2 aktiviert wird? Aber erstmal müssen wir wohl abwarten, ob das so stimmt. WENN das stimmt, hat Intel wieder ein neues Prob.

SG

[Gast]

Zuerst sollen wir uns alle DC CPU´s kaufen und jetzt kommen die mit sowas, ich lach mich schlapp, verarsche pur...

[smoe82]

Die könnten ja auch mal auf die Idee kommen, 2 CPUs virtuell als 4 darzustellen, aber einen Thread - wenn er "alleine" ist - dann doch über beide CPUs (virtuell alle vier) zu verteilen.

Bei einer CPU isses ja mit HT ähnlich: Wenn nur ein Thread vorhanden ist, wird die gesamte CPU benutzt.


Nach "meiner Idee", könnte ein Thread auf beiden CPUs werkeln. Kommt da einer dazu, dann kriegt jeder Thread seine eigene CPU. Und bei drei Threads müssen sich 2 eine CPU teilen. Es wäre sogar denkbar, daß 2 Threads so aufgeteilt werden, daß einer eine ganze CPU bekommt und sogar mittels "AntiHT" einen Teil der zweiten CPU (als virtuelle HT-CPU).

[pippo]

Ich denke einen Treiber zu entwickeln, der erkennt ob eine Anwendung Single- oder MultiCore entwickelt ist, sollte doch das geringste Problem sein. Auch die ganzen Änderungen am Design des F-Steppings sind doch bisher nicht wirklich geklärt, bzw. lassen sich nicht ausschließlich auf die Virtualisierung zurückführen.

"Anti-Hyperthreading" ist, wie es viele wohl noch nicht gemerkt haben, kein offizieller Name von AMD. Im Übrigen würde eine solche Technologie auch ein 4x4 System ganz anders dastehen lassen und eine offizielle Ankündigung am Tag vorm Launch des Conroe macht durchaus Sinn.

Fazit: Technologisch durchaus möglich und würde auch erklären, warum AMD vorm Conroe nicht in die Hosen macht ;) Im übrigen gabs auch mal ne Meldung von SUN, die mit dem gleichen Prinzip die Performance bis zu 50% steigern konnten, wenn ich mich recht entsinne

[tombman]

Also falls das wirklich funktionieren sollte hat Intel ein großes Problem ;)

[Gast]

Toll, die Leute mit So. 939 stehen wieder im Regen :(

[Foxbat]

also Hyper-Threading ist sicher ein von Intel geschützter Name :biggrin:

[AnarchX]

Ich bezweifele, dass dies mit der aktuellen Architektur möglich ist.

[dargo]

Gast[/POST]']Bereits im April gab es Gerüchte über dem möglichen Einsatz einer Anti-Hyper-Threading genannten Technik bei AMD.
Das war nicht zufällig der 1 April? X-D

[Foxbat]

weiß vllt jemand wo der Thread zu finden ist in welchem erklärt wurde warum das nicht funzt? ich kanns grad einfach net finden. Bitte

mfg

[Gast]

dargo[/POST]']Das war nicht zufällig der 1 April? X-D

Da würde ich auch besser nochmal nachsehen :D

[rpm8200]

pippo[/POST]']"Anti-Hyperthreading" ist, wie es viele wohl noch nicht gemerkt haben, kein offizieller Name von AMD.Falls Du auf mich anspielst: Ich meinte mit meinem Post eher, dass ich es nicht für übermäßig glaubhaft halte, da diese Namensgebung sich arg nach Fan anhört (nicht nach einer offiziellen oder auch nur halb-offiziellen/ inoffiziellen Ankündigung/ Nachrichten/ internen Nachricht von AMD, die irgendwie geleaked ist). Insofern liegen wir nicht weit auseinander, ich habe mich nur nicht präzise ausgedrückt.

[Super Grobi]

Gast[/POST]']Toll, die Leute mit So. 939 stehen wieder im Regen :(

Deshalb wäre es ja gut zu wissen, ob ein DC AMD ausreicht, oder auf der CPU (AM2) irgentwie was hardwaretechnisch etwas da sein muss. Wenn nicht, wird es bestimmt Treiberhacks geben.

SG

[BK-Morpheus]

Ich glaube nen Aprilscherz war das nicht:

http://www.chip.de/news/c1_news_19500884.html

[dargo]

BK-Morpheus[/POST]']Ich glaube nen Aprilscherz war das nicht:

http://www.chip.de/news/c1_news_19500884.html
Also, wenn das wirklich stimmen sollte dann lache ich mich über das Gehype vom Conroe kaputt. :lol:
Auf der anderen Seite würde die enorme Preissenkung (auch) von den DC CPUs keinen Sinn machen. :uponder:

[Android]

Ob-1[/POST]']AFAIK haben sich die CPU-Gurus hier im Forum so geäußert, als das es totaler Blödsinn ist.

Naja, du solltest den Begriff "Guru" vielleicht ein wenig lockerer sehen.
Im Vergleich zu AMD und Intel Ingenieuren sind wir alle ein feuchter Pups. :D
Ansonsten wären unsere "Gurus" sehr reich und nicht hier. ;)

Tipp: Warten wir es ab und lassen wir uns überraschen. :ucoffee:

[Foxbat]

kann bitte jemand nochmal erklären warum das in der Form wie die meisten glauben nicht funktionieren kann? bitte

[saddevil]

hmm nachteilig glaube ich nicht
denn dann wäre es eine CPU mit doppekter anzahl an decodern und ausführungseinheiten ..
das keine scalierung von 100% drin ist sollte klar sein
die pro MHz leistung steigt recht heftig an ...
und wenn es nur 50-60% sind


die 4x4 ist das ein großes übel ..
denn das wäre eine extreme rechenleistung für einen einzigen thread

und 2threads wäre es immernoch übel da hier die kerne als eine 2 virtuelle arbeiten ....

[dargo]

saddevil[/POST]']und wenn es nur 50-60% sind
Das wäre ein schöner Traum. Ich stelle mir gerade einen X2 3800+ (~150-160€) @2x 2,5-2,7Ghz vor. :naughty:
Das wäre ein Venice @3,75-4,32Ghz. :eek:

[saddevil]

dargo[/POST]']Das wäre ein schöner Traum. Ich stelle mir gerade einen X2 3800+ (~150-160€) @2x 2,5-2,7Ghz vor. :naughty:
Das wäre ein Venice @3,75-4,32Ghz. :eek:


jetzt stelle man sich das mit 2x K8L quadcore vor auf nem dualboard

und 2 threads .. je thread eine quadcore CPU die als eine virtuelle läuft

:|

und wenn ein programm multithreaded .. dann eben 8 cores ...
wenn der treiber mit dem scheduler zusammenarbeitet .. kann da einiges bei rauskommen
wenn das wirklich kommt .. ist da ordentlich was zu holen

es wirkt anfänglich wie ein rückschritt
aber in wirklichkeit ist es eigentlich eine sehr universelle möglichkeit
die vorhandene rechenleistung effektiv umzusetzen

die angegebene leistung pro WATT steigt dadurch auch sehr drastisch
ein kern der nix zu tun hat idled nicht rum sondern tut sich mit einer anderen zusammen um die selbe arbeit zu machen


mein kommentar dazu : wenns klappt .... GEIL

[Gast]

tombman[/POST]']Also falls das wirklich funktionieren sollte hat Intel ein großes Problem ;)
Tut es nicht.

[Gast]

Android[/POST]']Naja, du solltest den Begriff "Guru" vielleicht ein wenig lockerer sehen.
Im Vergleich zu AMD und Intel Ingenieuren sind wir alle ein feuchter Pups. :D
Ansonsten wären unsere "Gurus" sehr reich und nicht hier. ;)
Immer das alte dumme Geschwätz. Um etwas zu beurteilen muss man es nicht unbedingt konstruieren können.

Es gibt nichtmal Compiler die das machen können und die haben deutlich mehr Zeit übrig und mehr Überblick als ein Prozessor der mit viel Glück ein Instruction-Window von 100 hat und das ganze Just-In-Time machen soll. Ganz abgesehen davon dass man derzeit nichtmal die normale Ausführungseinheiten auslasten kann.

Wenn du automatische Parallelisierung hinbekommst dann bekommst du den extra dafür eingeführten Nobelpreis für Informatik verliehen.

[Android]

Immer das alte dumme Geschwätz. Um etwas zu beurteilen muss man es nicht unbedingt konstruieren können.


Nöö, muss man auch nicht. Aber: Hast du alle Infos ? Nein ? Dann halt die Beine still. Denn dann kannst du es auch nicht beurteilen. Oder hast du ne Glaskugel, die mit dir spricht ?

[pippo]

Gast[/POST]']Immer das alte dumme Geschwätz. Um etwas zu beurteilen muss man es nicht unbedingt konstruieren können.

Es gibt nichtmal Compiler die das machen können und die haben deutlich mehr Zeit übrig und mehr Überblick als ein Prozessor der mit viel Glück ein Instruction-Window von 100 hat und das ganze Just-In-Time machen soll. Ganz abgesehen davon dass man derzeit nichtmal die normale Ausführungseinheiten auslasten kann.

Wenn du automatische Parallelisierung hinbekommst dann bekommst du den extra dafür eingeführten Nobelpreis für Informatik verliehen.
Ich glaub du hast das Prinzip nicht ganz verstanden. Es ist ja nicht so, dass 1 Thread in mehrere aufgeteilt/gesplittet wird, sondern z.B. 2 CPUs erscheinen als 1. Somit wäre es möglich, dass Core 0 von Core 1 Recheneinheiten benutzt.
Das hier ist bis jetzt das einzige Forum was ich gesehen hab, in dem immer wieder behauptet wird, dass es nicht funktionieren kann. Überall anders waren die Leute bisher anderer Meinung

[AnarchX]

Die Methode würde nur funktionieren, wenn man parallelisierbaren Code vor sich hat.
a+b=c
c+d=e

no go... ;)

Theoretisch müsste ja der zu verarbeitende Code noch analysiert werden, wie weit man ihn paralliesieren kann.
Dürfte das nicht ein riesiger Aufwand sein?

Das hier ist bis jetzt das einzige Forum was ich gesehen hab, in dem immer wieder behauptet wird, dass es nicht funktionieren kann. Überall anders waren die Leute bisher anderer Meinung

Vielleicht weil hier bestimmte Leute(Gurus) Ahnung haben... ;)

[Gast]

pippo[/POST]']Ich glaub du hast das Prinzip nicht ganz verstanden.
Oh doch, ich habe es eben verstanden. Und ich glaube du hast mir nicht zugehört: Ich habe erklärt das es bis heute keinen Compiler gibt der das zur Kompilierzeit schafft, wie willst du das zur Runtime machen?

Es ist ganz einfach Blödsinn bzw. von AMD willkommene Propaganda.

[Gast]

Android[/POST]']Nöö, muss man auch nicht. Aber: Hast du alle Infos ? Nein ? Dann halt die Beine still. Denn dann kannst du es auch nicht beurteilen. Oder hast du ne Glaskugel, die mit dir spricht ?
Nein ich weiß dass es unglaublich schwierig ist die Recheneinheiten die man mit einem Core hat überhaupt schon auszulasten, weil OOO-Execution und Superskalarität eben ihre Grenzen haben. Man kann noch Tricks anwenden wie Load/Store-Forwarding wie es Conroe macht aber der hat auch nur 4 Ports. Wenn man die Leistung so steigern könnte hätten CPUs schon längst 20 Execution-Units. Tun sie aber nicht. Der Pentium hatte 2 alles bis Conroe hatte 3.

Entsprechende Programme die die maschinenspezifischen Register auslesen zeigen dass bei einem P4 etwas eine Auslastung von maximal 50% in nicht-synthetischen Anwendungen entsteht. Was willst du da mit Recheneinheiten aus einem zweiten Core?

Und falls das alles nicht Quatsch genug wäre wie willst du denn die Ergebnisse quer über zwei Dies in einem Takt zurückschreiben? (Alles andere wäre eh wieder lahmer).

[tokugawa]

Android[/POST]']Naja, du solltest den Begriff "Guru" vielleicht ein wenig lockerer sehen.
Im Vergleich zu AMD und Intel Ingenieuren sind wir alle ein feuchter Pups. :D
Ansonsten wären unsere "Gurus" sehr reich und nicht hier. ;)


Das ist illusorisch. Selbst wenn man sich super auskennt und als Ingenieur eine Bereicherung für AMD/Intel/ATI/NVIDIA/weißderkuckuck wäre, heißt das nicht dass man steinreich werden würde und/oder bei denen arbeiten würde.

Oder dass man das überhaupt wollte. Manche Leute ziehen es z.B. auch eher vor in die universitäre Forschung zu gehen statt in die Wirtschaft, weil es ihnen nicht nur um's Geld geht. Sind diese Leute weniger qualifiziert als etwa ein NVIDIA-Ingenieur? Mitnichten! (Beweis ist ja die Autorentruppe etwa von GPU Gems 2, da reihen sich akademische Forscher neben Spieleentwickler neben NVIDIA-Thinktanks)

Das sehe ich sowohl für Software als auch für Hardware.

[pippo]

@ Gast
Ich versteh nicht ganz was du meinst. Zum einen muss das ganze ja in der Hardware auch dementsprechend umgesetzt sein. Da läufst du mit deinem Compiler gegen eine Wand.

Dass es funktioniert steht ja für mich ausser Frage. Ich finde zwar diese verd... News nicht mehr, aber es gab auf alle Fälle mal ne Meldung, dass man damit schon nicht zu verachtende Vorteile erzielt hat. Meiner Meinung gings damals um SUN, die, wenn ich recht überlege, doch einen Thread analysiert haben und dann nach Möglichkeit aufgesplittet

[AnarchX]

Auf Software-Ebene wird es noch lange nicht zu lösen sein.
Aber vielleicht könnte ein dafür spezialisierter CO-Prozessor für den HTX-Slot eingesetzt werden, was aber für den normalen Kunden dann nicht relevant wäre.

[Gast]

AnarchX[/POST]']Auf Software-Ebene wird es noch lange nicht zu lösen sein.
Wenn es da nicht zu lösen ist ist es in Hardware erst recht nicht zu lösen.

Ich habe schonmal gesagt dass die gemeinsame Nutzung von Execution-Resources nicht praktikabel ist weil die Laufzeit viel zu groß wäre zwischen den Dies. (Der P4 hat schon Drive-Stages um auf einem Die Daten zu verschieben). Außerdem müsste man soviel Logik zwischen den Frontends sharen dass das ganze am Ende wieder ganz normales SMT wäre.

Und Aufteilung in Threads ist in Echtzeit erst recht nicht automatisch möglich - das ist es nicht mal offline.

[anddill]

Hmm, eine normale CPU ist ja auch schon mit mehreren Ausführungseinheiten bestückt. Aber schon das zu syncronisieren macht eine Menge Aufwand nötig. Wie das über zwei Kerne mal so quer rüber gehen soll ist mir da auch ein Rätsel. Das einzige was evtl. gehen würde, wäre das man einfach schon mal mit dem zweiten Kern vorgreift und spekulativ ein Stück weiter hinten ins Programm greift. Passen die Enden dann zusammen, kann man es einfach anhängen und hat den Abschnitt sozusagen fertig, bevor er begonnen wurde. Passt es nicht, dann muß es halt verworfen werden.
Damit wäre ein Leistungsgewinn zwischen -10 bis 99% möglich, je nach Code.
Wobei die Sache gerade bei Spielen gut klappen könnte. Der Gameloop besteht ja immer aus den selben Grundbestandteilen, da könnte man mit spekulativer Ausführung sicher was gewinnen.

Aber zumindes ein Name für die Sache ist mir eingefallen: Kernfusion :D

[Demirug]

Um auf mehren Cores einen „Thread“ auszuführen kann man zum Beispiel TLS (Thread Level speculation) nutzen. Ich will jetzt nicht sagen das AMD das implementiert hat aber die Technik als solches funktioniert und ist eine Erweiterung der bekannte Branch Predication. Die Einheit die dabei bisher nur nach Sprüngen gesucht hat versucht nun auch Schleifen zu erkennen. Gelingt dies verteilt sie die Durchläufe auf die vorhandenen Cores. Da das Ergebnis aber dem Ergebnis der sequentiellen Abarbeitung entsprechen musst führen die Cores dabei eine gemeinsame IO Liste. Kommt es zu Kollisionen wird ein Roolback durchgeführt und die Ausführung dieser Schleife mit nur einem Core erneut am letzten Safepoint gestartet. Zusätzlich kann sich der Chip noch merken welche Schleifen nicht aufgeteilt werden. Theoretisch kann diese Lösung linear mit der Anzahl der Cores skalieren. Allerdings besteht ein Programm ja nicht nur aus Kollisionsfreien inneren Schleifen.

[Android]

tokugawa[/POST]']Das ist illusorisch. Selbst wenn man sich super auskennt und als Ingenieur eine Bereicherung für AMD/Intel/ATI/NVIDIA/weißderkuckuck wäre, heißt das nicht dass man steinreich werden würde und/oder bei denen arbeiten würde.

Oder dass man das überhaupt wollte. Manche Leute ziehen es z.B. auch eher vor in die universitäre Forschung zu gehen statt in die Wirtschaft, weil es ihnen nicht nur um's Geld geht. Sind diese Leute weniger qualifiziert als etwa ein NVIDIA-Ingenieur? Mitnichten! (Beweis ist ja die Autorentruppe etwa von GPU Gems 2, da reihen sich akademische Forscher neben Spieleentwickler neben NVIDIA-Thinktanks)

Das sehe ich sowohl für Software als auch für Hardware.

Ich glaube du hast den Begriff "Guru" nicht verstanden. Wikipedia: "Im weiteren Sinne kann ein Guru einfach ein Fachmann mit überdurchschnittlichem Wissen und langer Erfahrung sein." Umgangssprachlich kann man sogar noch einen Schritt weitergehen. Denn hier sagt man meistens zu jemandem "Guru" (ausserhalb der Religion versteht sich), wenn er ein absolutes Ass auf seinem Gebiet ist und nur wenige ihm das Wasser reichen können. Wenn diese Punkte zutreffen, dann sollte man wirklich keine Probleme mehr haben einen Job in der Industrie zu bekommen.

Und jetzt mal unabhängig von der Industrie: Welcher Uni-Mitarbeiter traut sich hier das von sich zu behaupten ?
Autodidakten mit einem grossen Talent sind wirklich gut. Aber Akademiker mit einem ebensogrossen Talent und einem autodidaktischem Beginn sind weitaus besser. Wer das bezweifelt ist ein Träumer.

Back to topic.

[anddill]

Demirug[/POST]']Um auf mehren Cores einen „Thread“ auszuführen kann man zum Beispiel TLS (Thread Level speculation) nutzen. Ich will jetzt nicht sagen das AMD das implementiert hat aber die Technik als solches funktioniert und ist eine Erweiterung der bekannte Branch Predication. Die Einheit die dabei bisher nur nach Sprüngen gesucht hat versucht nun auch Schleifen zu erkennen. Gelingt dies verteilt sie die Durchläufe auf die vorhandenen Cores. Da das Ergebnis aber dem Ergebnis der sequentiellen Abarbeitung entsprechen musst führen die Cores dabei eine gemeinsame IO Liste. Kommt es zu Kollisionen wird ein Roolback durchgeführt und die Ausführung dieser Schleife mit nur einem Core erneut am letzten Safepoint gestartet. Zusätzlich kann sich der Chip noch merken welche Schleifen nicht aufgeteilt werden. Theoretisch kann diese Lösung linear mit der Anzahl der Cores skalieren. Allerdings besteht ein Programm ja nicht nur aus Kollisionsfreien inneren Schleifen.

Wenn ich das jetzt richtig verstanden hab, hast Du gerade das gleiche geschrieben wie ich, oder? ;)

[Demirug]

anddill[/POST]']Wenn ich das jetzt richtig verstanden hab, hast Du gerade das gleiche geschrieben wie ich, oder? ;)

Mehr oder weniger. Dein Post war noch nicht da als ich angefangen habe zu tippen.

[tokugawa]

Android[/POST]']Ich glaube du hast den Begriff "Guru" nicht verstanden. Wikipedia: "Im weiteren Sinne kann ein Guru einfach ein Fachmann mit überdurchschnittlichem Wissen und langer Erfahrung sein." Umgangssprachlich kann man sogar noch einen Schritt weitergehen. Denn hier sagt man meistens zu jemandem "Guru" (ausserhalb der Religion versteht sich), wenn er ein absolutes Ass auf seinem Gebiet ist und nur wenige ihm das Wasser reichen können. Wenn diese Punkte zutreffen, dann sollte man wirklich keine Probleme mehr haben einen Job in der Industrie zu bekommen.


Ich glaube du hast nicht verstanden worauf ich hinaus wollte.

Der Inhalt meines Postings lautete: Selbst als Guru muß man nicht unbedingt einen Job in der Industrie wollen, selbst wenn man könnte ("keine Probleme hätte einen Job in der Industrie zu bekommen").

Es wird einem immer unterstellt, man sei kein echter Guru, weil wäre man einer, würde man in der Industrie einen Job haben und steinreich sein. Aber vielleicht wollen das einige Gurus überhaupt nicht?

Es gibt aber Gurus die Spaß an der Sache haben, und dies z.B. rein akademisch betreiben. Oder gar in der Uni-Forschung tätig sind. Und hier dann eben sehr viel weniger Geld scheffeln.

Also Fazit: nur weil man ein Guru ist, muß man nicht gleich in der Industrie sein Geld scheffeln. Manche interessiert ja auch die Sache an sich, und nicht der Profit.

Android[/POST]']
Und jetzt mal unabhängig von der Industrie: Welcher Uni-Mitarbeiter traut sich hier das von sich zu behaupten ?


Was zu behaupten? Dass er Uni-Mitarbeiter ist? Darf ich aufzeigen?

Android[/POST]']
Autodidakten mit einem grossen Talent sind wirklich gut. Aber Akademiker mit einem ebensogrossen Talent und einem autodidaktischem Beginn sind weitaus besser. Wer das bezweifelt ist ein Träumer.


Da hast du recht. Aber was hat das mit dem was ich geschrieben habe, zu tun?

[tombman]

HMm, und selbst wenn es funktioniert; wer sollte Intel davon abhalten ebenso einen "Treiber" rauszubringen, der genau das selbe macht?

[Demirug]

tombman[/POST]']HMm, und selbst wenn es funktioniert; wer sollte Intel davon abhalten ebenso einen "Treiber" rauszubringen, der genau das selbe macht?

Das geht nicht nur mit einem Treiber. Der Treiber kann maximal im Chip bereits vorhandene Funktionen freischalten.

[Android]

tokugawa[/POST]']Ich glaube du hast nicht verstanden worauf ich hinaus wollte.

Der Inhalt meines Postings lautete: Selbst als Guru muß man nicht unbedingt einen Job in der Industrie wollen, selbst wenn man könnte ("keine Probleme hätte einen Job in der Industrie zu bekommen").

Es wird einem immer unterstellt, man sei kein echter Guru, weil wäre man einer, würde man in der Industrie einen Job haben und steinreich sein. Aber vielleicht wollen das einige Gurus überhaupt nicht?

Es gibt aber Gurus die Spaß an der Sache haben, und dies z.B. rein akademisch betreiben. Oder gar in der Uni-Forschung tätig sind. Und hier dann eben sehr viel weniger Geld scheffeln.

Also Fazit: nur weil man ein Guru ist, muß man nicht gleich in der Industrie sein Geld scheffeln. Manche interessiert ja auch die Sache an sich, und nicht der Profit.



Was zu behaupten? Dass er Uni-Mitarbeiter ist? Darf ich aufzeigen?



Da hast du recht. Aber was hat das mit dem was ich geschrieben habe, zu tun?

1. Nein man muss nicht in der Industrie arbeiten um ein Guru zu sein.
2. Uni-Mitarbeiter, der von sich behauptet ein Guru zu sein und hier im Forum verkehrt.
3. Hat rein gar nichts mit dem zu tun was du gesagt hast.
4. Back to topic. PLZ !!

[tombman]

Demirug[/POST]']Das geht nicht nur mit einem Treiber. Der Treiber kann maximal im Chip bereits vorhandene Funktionen freischalten.
Hmm, du meinst AM2 hat ein böses Geheimnis, das bisher keiner kannte? :eek:

[Foxbat]

Demirug[/POST]']Das geht nicht nur mit einem Treiber. Der Treiber kann maximal im Chip bereits vorhandene Funktionen freischalten.


Also würds prinzipiell doch gehen? oder wie soll man das alles verstehen?

mfg

[AnarchX]

tombman[/POST]']Hmm, du meinst AM2 hat ein böses Geheimnis, das bisher keiner kannte? :eek:

Dazu passt aber nicht so ganz, dass man den Transistorcount obwohl DDR2-Controller noch reduziert hat.
Ergo müssten die benötigten Schaltkreise in den K8-DCs von Anfang an vorhanden sein.

Ich halt es ehrlich gesagt nur für ein Gerücht, das wohl sich als falsch herausstellt.

[Demirug]

tombman[/POST]']Hmm, du meinst AM2 hat ein böses Geheimnis, das bisher keiner kannte? :eek:

Ich schrieb doch extra das ich nicht weiß ob AMD eine solche Technik bereits implementiert hat. Ich kann lediglich sagen das es prinzipiell auf Multicore CPUs machbar ist. Es soll aber nicht unerwähnt bleiben das es nur bei den Cores innerhalb einer CPU funktioniert. Also einfach mal 4 QuadCore CPUs zusammenschalten ist nicht drin.

[anddill]

Demirug[/POST]']Ich schrieb doch extra das ich nicht weiß ob AMD eine solche Technik bereits implementiert hat. Ich kann lediglich sagen das es prinzipiell auf Multicore CPUs machbar ist. Es soll aber nicht unerwähnt bleiben das es nur bei den Cores innerhalb einer CPU funktioniert. Also einfach mal 4 QuadCore CPUs zusammenschalten ist nicht drin.

Kommt drauf an, wieviel davon Hardware ist und wieviel Software. Allerdings kommt man mit genug Software dann irgendwann auf dem Niveau von Transmetas Codemorphing oder einer VM an.

[Demirug]

anddill[/POST]']Kommt drauf an, wieviel davon Hardware ist und wieviel Software. Allerdings kommt man mit genug Software dann irgendwann auf dem Niveau von Transmetas Codemorphing oder einer VM an.

Das Problem warum es Cores und keine getrennten CPUs sein müssen ist die Latenz auf den Buffer der für das IO Tracking benutzt wird. Also selbst wenn man es mit Software lössen könnte (was bei x86 Code recht aussichtloss ist) dieses Problem bekommt man nicht weg.

[anddill]

Demirug[/POST]']Das Problem warum es Cores und keine getrennten CPUs sein müssen ist die Latenz auf den Buffer der für das IO Tracking benutzt wird. Also selbst wenn man es mit Software lössen könnte (was bei x86 Code recht aussichtloss ist) dieses Problem bekommt man nicht weg.
IO Tracking? Was meinst Du genau damit?
Ansonsten kann ich Dir anscheinend folgen: Wenn man entscheiden muß, ob der spekulativ ausgeführte Code nun verwendet werden darf oder nicht, kann man nicht erst kreuz und quer im ganzen PC nach den Schnipseln suchen. :confused:

[Demirug]

anddill[/POST]']IO Tracking? Was meinst Du genau damit?
Ansonsten kann ich Dir anscheinend folgen: Wenn man entscheiden muß, ob der spekulativ ausgeführte Code nun verwendet werden darf oder nicht, kann man nicht erst kreuz und quer im ganzen PC nach den Schnipseln suchen. :confused:

Beim IO Tracking protookuliert jeder Core auf welche Speicherstellen lesend oder schreiben zugegriffen wurde. Kommt es dabei zu Überschneidungen haben wir unter Umständen eine Abbruch Bedingung.

Also sobald ein Core schreibt darf der andere Core die Zelle nicht mehr anfassen. Umgekehrt gilt aber auch das eine Zelle die vom anderen Core bereits gelesen wurde nicht mehr beschrieben werden darf. Beide Cores lesend geht dagegen ohne Probleme. Man kann das mit entsprechendem Aufwand auch noch feiner machen.

Sobald beide Cores sich wieder synchronisieren wird das Protokoll gelöscht und von vorne angefangen.

[Henroldus]

ich halte die Idee für gar nicht so dumm.
bevor sämtliche Software umgeschrieben und in einzelne Threads aufgeteilt werden muss, verteilt einfach der CPU Treiber von dem hier die Rede ist die Aufgaben/Threads auf die Kerne.
dies kann nach verschiedenen Methoden funktionieren ala ATI Crossfire.
Endlich wäre ein DC System merklich schneller auch bei nichtoptimierten Anwendungen.

[Gast]

Gast[/POST]']Von Planet3DNow:

Bereits im April gab es Gerüchte über dem möglichen Einsatz einer Anti-Hyper-Threading genannten Technik bei AMD. Eine russische Seite will nun erfahren haben, dass Anti-Hyper-Threading kommt und zwar kurz vor dem offiziellen Start des Conroe.

Die Technik wird als Anti-Hyper-Threading bezeichnet, da sie sich praktisch gegenteilig zu Intels Hyper-Threading-Technologie verhält.

Als Hyper-Threading Technologie (HTT) bezeichnet Intel seine Implementierung von Simultaneous Multithreading (SMT) in den Prozessoren Pentium 4 und Xeon. Wie bei SMT werden mittels Duplizierung und Aufteilung bestimmter Ressourcen virtuelle CPUs (Siblings) generiert, die mehrere (Teil-)Programme (Threads) weitgehend parallel ausführen können.

Statt einer parallelen Ausführung soll Anti-Hyper-Threading bewirken, dass sich eine CPU mit mehreren Kernen gegenüber der Anwendungssoftware als eine CPU darstellt und die Recheneinheiten beider Kerne genutzt werden können. Dies soll dem Umstand Rechnung tragen, dass die Entwicklung von Software für den Endanwender, die auf Multithreading optimiert wurde, noch nicht weit vorangeschritten ist.

Laut diesem Bericht (englische Übersetzung) soll Anti-Hyper-Threading in den AM2-Prozessoren durch einen neuen Prozessortreiber und einen Microsoft-Patch freischaltbar sein und am Tag vor dem offiziellen Conroe-Launch vorgestellt werden.

Ist das vielleicht der Conroe Killer Effekt? Das wird auf alle Fälle ein heißer Sommer ;)

[dildo4u]

rpm8200[/POST]'] Allerdings die von Dir geschilderte Problematik ist nicht vorhanden. Der User könnte das entscheiden und "einfach" einen Schalter umlegen zwischen z.B. "emulation single" und "Dual". Es soll ja auch nur den zweiten Kern besser ausnutzen in nicht multithreaded-optimierten Anwendungen.
Als wenn jeder 08/15 Dau bei Tausenden von verschiedenen Anwendungen weiß obs schon Dual Core Optemiert ist oder nicht.

[saddevil]

bleibt dennoch abzuwarten was da jetzt an wahrheiten dran ist

[crusader4]

Falls es noch von Interesse ist: Hier nochmal die alte Diskussion um dieses Feature.

4207498

Edit: Die Diskussion geht über mehrere Seiten.

[Seraf]

Das hört sich sowas von Banane an. Wie soll man ein Programm das "sequenziell" abläuft "während der Laufzeit" auf zwei Cores aufsplitten?! :hammer:

[pippo]

Wäre es denn nicht möglich, aus 2 Cores eine 6-fach skalare CPU zu "simulieren" ?

[BlackBirdSR]

pippo[/POST]']Wäre es denn nicht möglich, aus 2 Cores eine 6-fach skalare CPU zu "simulieren" ?

nicht ohne eine Menge Wartzeiten. Und die versauen dir deine Leistung.

Wichtig ist es, das Problem zu verstehen. Es geht nicht so sehr darum wie man die beiden Cores verschaltet.
Vielmehr muss man irgendwoher den Code zur Ausführung herbekommen.

Es ist prinzipiell unmöglich A+C in einem zu berechnen, während C=A+B im anderen Core läuft.
Diese Abhängigkeiten sind mit die größten Probleme die es gibt.
Und der erste Schritt muss der sein, aus dem Code Stellen zu extrahieren, der sicher ausgeführt werden kann.
Bzw zusätzlich sichere Threads auszuführen.

TLS ist zwar nett, das letzte Dokument dazu, das ich gelesen habe sprach aber von ca 7% mehr Performance im Schnitt.

[HellHorse]

Gast[/POST]']
Wenn du automatische Parallelisierung hinbekommst dann bekommst du den extra dafür eingeführten Nobelpreis für Informatik verliehen.
Das ist einfach für single assignment, reps. pur funktionale Sprachen. Ja, sogar ich würde das hinkriegen.
Gast[/POST]']Oh doch, ich habe es eben verstanden. Und ich glaube du hast mir nicht zugehört: Ich habe erklärt das es bis heute keinen Compiler gibt der das zur Kompilierzeit schafft, wie willst du das zur Runtime machen?
Wie schon gesagt, keine Nebeneffekte und das ist einfach:
http://sisal.sourceforge.net/

[TheGoD]

BlackBirdSR[/POST]']
TLS ist zwar nett, das letzte Dokument dazu, das ich gelesen habe sprach aber von ca 7% mehr Performance im Schnitt.

Die bereits für AMDs Marketingabteilung ausreichen würden.

[Hakim]

Solange nix offiz. von AMD kommt ist es für mich eindeutig ein Gerücht was so gut wie 0 glaubwürdigkeit hat. Die antwort auf dem Conroe seitens AMD werden 4+4 und der starke Preisfall am Tag nach dem Conroe launch sein (später K8L). Warum sollte AMD die preise senken wenn sie nachträglich Anti-Hyper-Threading aktivieren können? Und alleine der name schon.....naja lasse mich eines besseren belehren, aber eher glaube ich an Nessi als an einen Aktivierbaren Anti-Hyper-Threading.

[Gast]

Noch mehr Ausführungseinheiten in einem Kern zu vereinen wie gegenwärtig beim K8 oder Conroe realisiert, ist einfach nicht sinnvoll. Ähnlich wie bei Hyperthreading kann vor allen Dingen zu Anfang der Schuß mächtig nach hinten los gehen. Mancher Code wird dann auf einem Kern schneller laufen als auf den kombinierten 6 Ausführungseinheiten der zweier Kerne, schlicht weil er hochgradig ungeeignet ist. Ganz zu schweigen davon, daß dir dein zweiter Kern und dess größer werdende Vorteile abhanden kommen werden. Schon das erste Spiel, daß hochgrading den zweiten Kern nutzt, schickt die Technik in Rente. Ohne heftigen Support durch die Software geht also auch hier nix!!!

[Gast]

anddill[/POST]']Aber zumindes ein Name für die Sache ist mir eingefallen: Kernfusion :D

hey cool endlich mal eine erklärung die auch ich verstehe, ich weiß ich endlich aus welchen blickwinkel ich das thema betrachten soll lol lol lol
:)

[Sephiroth]

Gast[/POST]']...
Es gibt nichtmal Compiler die das machen können und die haben deutlich mehr Zeit übrig und mehr Überblick als ein Prozessor der mit viel Glück ein Instruction-Window von 100 hat und das ganze Just-In-Time machen soll. Ganz abgesehen davon dass man derzeit nichtmal die normale Ausführungseinheiten auslasten kann.

Wenn du automatische Parallelisierung hinbekommst dann bekommst du den extra dafür eingeführten Nobelpreis für Informatik verliehen.
Was genau kann kein Compiler der Welt?
Was machen dann VLIW-Compiler? Die optimieren und analysieren den Code auch soweit es möglich ist auf parallelausführbare Instruktionen. Freilich geht es nicht zu 100% aber mehr als "gar nicht". ;)

AnarchX[/POST]']Die Methode würde nur funktionieren, wenn man parallelisierbaren Code vor sich hat.
na das sowieso

Und eben hier versteh ich euch grad nicht so ganz. Ihr kommt immer mit dem totschlag Argument "nicht parallelisierbarer Code". Klar das es damit nicht geht!
Reden wir aber mal von parallelisierbaren Programmcode, aber die Anwendung (eigentlich der Programmierer ;)) nutzt SMT nicht explizit aus (z.b. eine klassische single threaded application).
Der Code wird, wenn möglich, auf dem einen Core durch mehrere Ausführungseinheiten parallel ausgeführt. Spinnen wir das mal soweit, daß dies auch Core-übergreifend geschehen kann. Möglich?
Vielleicht ist ja genau das eigentlich gemeint!

[Gast]

mir fällt da ein:
angenommen diese meldung stimmt und amd wird wirklich so einen treiber rausbringen und amd plant das schön länger, dann könnte das doch der grund sein warum man die produktion von x2 cpu's mit 1mb cache einstellt

amd kann so viel geld sparen(enorme platz ersparnis auf dem wafer) und durch diesen treiber wird man trozdem wieder mit intel mithalten können

wie gesagt, wenn an der meldung etwas dran ist

[rpm8200]

dildo4u[/POST]']Als wenn jeder 08/15 Dau bei Tausenden von verschiedenen Anwendungen weiß obs schon Dual Core Optemiert ist oder nicht.Ach komm. Mumpitz. Nicht mal Du benutzt 1000 verschiedene Programme. Ich denk mal, die meisten User haben 10 Standardanwendungen die immer wieder mal laufen (und die wahrscheinlich auch auf nem PIII-500 gut und schnell genug gehen). Nen halbwegs organisierter Zocker wird wohl wissen, dass das feature bei diesem oder jenem Prog besser aus ist. Nebenbei denk ich, dass es manchmal auch egal ist (wenn es denn funktioniert), ob man 20% Mehrleistung aus nem Dualcore Betrieb zieht oder 15% aus nem simulierten Singlecore. Zumindest ginge davon die Welt nicht unter.

Wenn es funzt (ich weiss es ja nicht!), dann wird es wohl bedeuten, dass man nen Dualcore im Schnitt auch mit "normalen" Anwendungen besser ausnutzen kann. Einfach mal noch n bisschen abwarten...

<edit>als Faustregel wird man sich wohl merken können, dass die meisten Progs nicht DC optimiert sind</edit>

[Wishnu]

Gast[/POST]']

amd kann so viel geld sparen(enorme platz ersparnis auf dem wafer) und durch diesen treiber wird man trozdem wieder mit intel mithalten können


Hm, was findet sich derzeit eigentlich an pubklikumswirksamen Benchmarks, welche noch nicht multithreaded sind, bzw. davon profitieren würden?

[AnarchX]

Wishnu[/POST]']Hm, was findet sich derzeit eigentlich an pubklikumswirksamen Benchmarks, welche noch nicht multithreaded sind, bzw. davon profitieren würden?

3DMark01Se... ;)

[BlackBirdSR]

Sephiroth[/POST]']Was genau kann kein Compiler der Welt?
Was machen dann VLIW-Compiler? Die optimieren und analysieren den Code auch soweit es möglich ist auf parallelausführbare Instruktionen. Freilich geht es nicht zu 100% aber mehr als "gar nicht". ;)


Wobei man an den Transmetas sieht, wie schwer das ist.
Wenn die Sache einen neuen Compiler benötigt, hat AMD damit schon verloren.
Braucht es eine eigene VLIW Logik, dann verliert man viel Performance.


Der Code wird, wenn möglich, auf dem einen Core durch mehrere Ausführungseinheiten parallel ausgeführt. Spinnen wir das mal soweit, daß dies auch Core-übergreifend geschehen kann. Möglich?
Vielleicht ist ja genau das eigentlich gemeint!

Nehmen wir die Spec-Suite
Ein K8 hat im Schnitt eine IPC von 0.8
Selten erreicht man in normalen Programme eine IPC von 1.7.

Der K8 hat mehr als genug Ausführungseinheiten. Der Clou ist, die mit genug Arbeit zu versorgen. Da fehlt es dem K8.
Von daher würde ich keinen Sinn darin sehen, die Ausführungseinheiten des 2. Cores zu nutzen.
Vielleicht bei extremen SIMD Anwendungen. Aber das macht sich für 90% der Nutzer nicht bemerkbar.
[/quote]

[Gast]

NEC hat(te) dies bereits in Entwicklung.

http://www.computerbase.de/news/hardware/prozessoren/2005/dezember/nec_multi-core-technik/

[FlashBFE]

Ich bin bei dem Thema auch sehr skeptisch. Wenn tatsächlich AMD es schaffen würde, in der Laufzeit aus einer Singethreaded Anwendung mehr Parallelität herauszuholen, dann würde das ja im Umkehrschluss bedeuten, dass die großen Compilerbauer Intel und Microsoft jahrelang was falsch gemacht haben.

[Demirug]

FlashBFE[/POST]']Ich bin bei dem Thema auch sehr skeptisch. Wenn tatsächlich AMD es schaffen würde, in der Laufzeit aus einer Singethreaded Anwendung mehr Parallelität herauszuholen, dann würde das ja im Umkehrschluss bedeuten, dass die großen Compilerbauer Intel und Microsoft jahrelang was falsch gemacht haben.

Nicht zwingend. Es gibt Dinge die man erst zur Laufzeit erkennen kann und die daher aktive Hardwareunterstüzung brauchen.

[DauerGast]

Demirug[/POST]']Nicht zwingend. Es gibt Dinge die man erst zur Laufzeit erkennen kann und die daher aktive Hardwareunterstüzung brauchen.
Ja, und genau diese Logik zusätzlich zur (ver-)spekulierten Ausführung auf dem zweiten Kern würde das Verhältnis Instruktionen/Watt deutlich verschlechtern. Und dass, obwohl AMD Conroe's 'memory disambiguation" für zur 'teuer' in Bezug auf Leistungsaufnahme beschreibt und im K8L nicht realisieren will? Nee, die Meldung ist eine Ente!

[SKYNET]

Demirug[/POST]']Ich schrieb doch extra das ich nicht weiß ob AMD eine solche Technik bereits implementiert hat. Ich kann lediglich sagen das es prinzipiell auf Multicore CPUs machbar ist. Es soll aber nicht unerwähnt bleiben das es nur bei den Cores innerhalb einer CPU funktioniert. Also einfach mal 4 QuadCore CPUs zusammenschalten ist nicht drin.

naja, wäre dennoch extrem, evtl. war ja AMDs 2x X2 der start dafür, so das man praktisch 2x "2" fette "singel"-cores hat!? *mhh*

[#44]

BlackBirdSR[/POST]']Aber das macht sich für 90% der Nutzer nicht bemerkbar.

DAS hat noch keinen HW-Hersteller abgehalten, solange man damit werben kann und besser (natürlich ausgesuchte) Benches bei rauskommen...

[Gast]

Eine CPU soll plötzlich besser parallelisieren können, als ein Compiler? Kaum vorstellbar. Da haben sich schon andere die Zähne dran ausgebissen.

Es gibt klassische Befehle, die sich durchaus hervorragend parallelisieren lassen. Hier mal zwei aus der C-Bibliothek.

"memmove" und "memcpy".

Kein Problem bei Speicheroperationen. Aber was ist mit Algorithmen in Spielen? Da ist viel Mathematik enthalten, deren Ergebnisse erst nacheinander zustande kommen. Da ist nichts mit Parallelität. Kaum vorstellbar, wie hier ein Performanceschub herauskommen soll.

Und zum NEC Artikel. Da steht Zitat: "Die Aufteilung läuft komplett spekulativ ab". Naja ... Und welche Trefferrate soll dabei herauskommen?

Ich tippe mal auf einen Performancegewinn vom maximal 10%, wenn überhaupt.

[Blutmaul]

Gast[/POST]']Eine CPU soll plötzlich besser parallelisieren können, als ein Compiler? Kaum vorstellbar. Da haben sich schon andere die Zähne dran ausgebissen.

Es gibt klassische Befehle, die sich durchaus hervorragend parallelisieren lassen. Hier mal zwei aus der C-Bibliothek.

"memmove" und "memcpy".

Kein Problem bei Speicheroperationen. Aber was ist mit Algorithmen in Spielen? Da ist viel Mathematik enthalten, deren Ergebnisse erst nacheinander zustande kommen. Da ist nichts mit Parallelität. Kaum vorstellbar, wie hier ein Performanceschub herauskommen soll.

Und zum NEC Artikel. Da steht Zitat: "Die Aufteilung läuft komplett spekulativ ab". Naja ... Und welche Trefferrate soll dabei herauskommen?

Ich tippe mal auf einen Performancegewinn vom maximal 10%, wenn überhaupt.

Und würden nicht die Allermeisten ihre Seele für diese 10% herschenken ?

[Gast]

Blutmaul[/POST]']Und würden nicht die Allermeisten ihre Seele für diese 10% herschenken ?

Ja schon, aber die Leistung, die dabei verbraten wird. OMG!

Ich kann mich noch an den Hype, um den IA-64 erinnern. Es war zwar keine DC CPU, aber sie soll ja so super, hyper-spekulativ, Befehle ausführen können. Allerdings nur, wenn der Compiler da mitspielt. Wie steht es denn um die CPU heute?

[Blutmaul]

Gast[/POST]']Ja schon, aber die Leistung, die dabei verbraten wird. OMG!

Ich kann mich noch an den Hype, um den IA-64 erinnern. Es war zwar keine DC CPU, aber sie soll ja so super, hyper-spekulativ, Befehle ausführen können. Allerdings nur, wenn der Compiler da mitspielt. Wie steht es denn um die CPU heute?

Die verbratene Leistung ist in manchen Fällen doch unwichtig.
Sonst dürfte es gar kein OCen geben und die Rechner liefen noch mit 50 Mhz.
Ich denke, ganz abgesehn davon, ob dieses Anti-HT nun tatsächlich existiert, das allein ein paar zusätzliche Prozente Leistungsgewinn genug locken, um es wünschenswert zu machen.
Den Rest hängt auch vom intelligenten Management ab.

Wo soll dieses Anti-HT eigentlich Vorteile haben?
Viele "ernsthafte" Anwendungen sind doch längst für Multicore optimiert?

[Gast]

Blutmaul[/POST]']Wo soll dieses Anti-HT eigentlich Vorteile haben?
Viele "ernsthafte" Anwendungen sind doch längst für Multicore optimiert?

Gute Fragen, die ich auch gerne beantwortet sähe . Bei Spielen sehe ich es so, dass eine optimale Performance, nur bei echter Parallelisierung heruaskommen wird. Viele der verwendeten Algorithmen sind parallelisierbar, aber keinesfalls durch durch eine "Anti-HT"-Technolgie.

[rpm8200]

Kein Mensch redet von optimaler Performance. Es ist doch allein vom Konzept her klar, dass dies nur ein Trick ist um die Performance etwas anzuheben, damit der zweite Core nicht direkt vor sich hin idelt (_wenn_ es denn überhaupt mehr ist als ein Gerücht). Wenn dabei 10-20% rum kommen würden, dann wäre das schon ne tolle Sache.

Um DC optimal zu nutzen braucht es eben auch multithreaded Anwendungen. Dass man das machen kann, das steht ausser Zweifel. Nur mit ein paar Zeilen Code ändern ist es nicht getan.

Hier wird ständig von irgendwelchen Rechenoperationen gefaselt, die in Abhängigkeit voneinander laufen -> klar dass da mit multithreaded nicht viel drin ist. Aber es spricht z.B. nichts dagegen beispielsweise die KI von dem einen Team auf dem einen Core zu rechnen und die KI eines anderen Teams auf dem anderen. Innerhalb eines Games sollte es tatsächlich mehrere größere Objekte geben, die sich auf mehreren Kernen -unabhängig voneinander- verteilt rechnen lassen.

Ist erst einmal wirklich der Schritt in die DualCoreProgrammierwelt vollzogen, dann ist es nur noch ein (verhältnismäßig) kleiner Schritt um auf 4,8,16 ... ... Kernen zu rechnen. Nur jetzt gerade tut es eben weh, weil man gewohnt ist sequentiell zu denken (ist ja auch die Natur des Menschen) und dieses Denken muss erst mal verschwinden...

... und da kommt der Bogen wieder zurück: Wenn es also AMD gelingen sollte, in der Übergangszeit wirklich den zweiten Core für Anwendungen zu nutzen, die nicht explizit Multicore-optimiert sind (ich würde sagen, das sind nach wie vor die meisten), dann ist das ganz sicher ein Schritt nach vorn (für den User).

[Blutmaul]

Ich hab irgendwo ein Diagramm gesehn, das sich auf das Thema bezieht und folgendes Patent zu Grunde legt:

United States Patent 6,574,725
Kranich , et al. June 3, 2003

Aber jetzt komm ich nicht mehr dahin, vielleicht will sich ein anderer das mal ansehn, der auch das Fachwissen hat?

[Ionstorm]

Welcher Prozessortreiber ist denn aktuell? hab mal vor nem Monat rum nen 1.3.1.0 installiert den ich aber nicht direkt von der AMD Seite habe, dort ist er auch nicht zu finden, da ich nur einen single core opteron besitze kann ich nicht nachvollziehen ob es Verbesserungen im Dualcore-Bereich gibt. Auf meinem Turion64-Notebook gibts auf jeden Fall keine längeren Akku-Laufzeiten...leider :wink:

Der Treiber ist auf den 28.04.2006 Datiert, weiß irgendjemand genaueres darüber?

MfG Ionstorm

Edit: bei Athlon™ 64/FX gibts ihn, unter Turion64 nicht...aber ohne genauere Angabe

[pippo]

AMD wird diesen Treiber sicherlich nicht jetzt schon auf der Homepage haben und ein Patch von Microsoft soll ja auch noch nötig sein

[Gast]

Ich weiß ja nicht warum ihr hier so auf AMD herumreitet. Intel arbeitet doch an der selben Technik. Bei denen heißt das ganze "Speculative Threading"; wie ich übrigens schon in 2 Threads gepostet habe:

Link: http://www.intel.com/technology/magazine/research/speculative-threading-1205.htm


The results obtained by the Mitosis compiler/architecture for this subset of the Olden benchmarks are very encouraging, outperforming single-threaded execution by 2.2x. When compared with a big out-of-order core, the speed increase is close to 2x. One can also see that the benefits of Mitosis do not come only from reducing memory latency—using Mitosis enables the system to outperform an ideal system with perfect memory by about 60 percent. Overall, this work demonstrates that significant amounts of thread-level parallelism can be exploited in irregular codes, with a rather low overhead in terms of extra (wasted) activity.



Das System arbeitet allerdings nicht nur auf der Hardware-Seite sondern benötigt für ein optimales Arbeiten auch neue Compiler.

[Seraf]

Gast[/POST]']Ich weiß ja nicht warum ihr hier so auf AMD herumreitet. Intel arbeitet doch an der selben Technik. Bei denen heißt das ganze "Speculative Threading"; wie ich übrigens schon in 2 Threads gepostet habe:

Link: http://www.intel.com/technology/magazine/research/speculative-threading-1205.htm




Das System arbeitet allerdings nicht nur auf der Hardware-Seite sondern benötigt für ein optimales Arbeiten auch neue Compiler.


Wenn ich das richtig gelesen habe braucht man einen Compiler und Bibliotheken mit denen man "Speculative Threads" erstellen kann.
Ein normaler Compiler schließt für einen Thread während des compilierens Speicherbereiche aus auf die der Thread nicht zugreifen darf. Diese sind manchmal aber garnicht belegt. Der Compiler geht ziemlich konservativ vor. Ein Speculativer Thread macht einen Test erst wenn er gestartet wird (und falls der Bereich belegt ist beendet er sich). Wenn er Glück hat ist der Speicherbereich frei und kann verwendet werden...


Speculative threads enable the compiler to try numerous types of unsafe, aggressive, optimistic optimizations when generating the precomputation slice. In the end, you'll end up with highly optimized code that can precompute these values very quickly and still be correct most of the time. This is illustrated in Figure 2.


Das bedeutet also nicht das Speculative Threads automatisch erstellt werden. Sie ersetzen höchstens normale Threads. :rolleyes:

...ohne Gewähr...

[Henroldus]

neues futter dazu beim Inquirer:

http://www.theinquirer.net/?article=32589

[Bauer]

den Artikel hab ich auch gerade gelesen, finde aber er klingt sehr stark nach Null Fachwissen und ist wohl einfach aus anderen Artikeln zusammengereimt.
Hauptsache Sensation und ein paar clicks...

[Gast]

Bauer[/POST]']den Artikel hab ich auch gerade gelesen, finde aber er klingt sehr stark nach Null Fachwissen und ist wohl einfach aus anderen Artikeln zusammengereimt.
Hauptsache Sensation und ein paar clicks...

Das war beim Inquierer bis jetzt immer so.
Vorstellbar wäre es, aber 2 Cores sind dafür zu wenig.
Ich schätze erst mit Vista bzw. mit dem K8L wird es wirklich möglich sein.

[Gast]

Gast[/POST]']Das war beim Inquierer bis jetzt immer so.
Vorstellbar wäre es, aber 2 Cores sind dafür zu wenig.
Ich schätze erst mit Vista bzw. mit dem K8L wird es wirklich möglich sein.

was ist eigentlich der K8L??
les ich hier immer wieder ohne wirklich zu wissen was das ist

[SavageX]

Woher stammt eigentlich die Ansicht, dass erst Vista die Multicores richtig nutzen wird? Das erscheint mir doch so ohne weiteres doch an den Haaren herbeigezogen (Multiprocessing ist ein alter Hut, wird von NT seit jeher unterstützt... und von allem, was sich ein *nix nennt).

[îÇë-çøøL]

Viele Pressemeldungen von MS.

Paul

[Monger]

SavageX[/POST]']Woher stammt eigentlich die Ansicht, dass erst Vista die Multicores richtig nutzen wird? Das erscheint mir doch so ohne weiteres doch an den Haaren herbeigezogen (Multiprocessing ist ein alter Hut, wird von NT seit jeher unterstützt... und von allem, was sich ein *nix nennt).

:|
Das habe ich so auch noch nie wahrgenommen. Im Consumer-Markt haben wir erst halt seit ein paar Monaten Multi-Cores.

[Botcruscher]

Monger[/POST]']:|
Das habe ich so auch noch nie wahrgenommen. Im Consumer-Markt haben wir erst halt seit ein paar Monaten Multi-Cores.

Eigentlich seit Abit BP6 und 500 Celli.

[StefanV]

Monger[/POST]']:|
Das habe ich so auch noch nie wahrgenommen. Im Consumer-Markt haben wir erst halt seit ein paar Monaten Multi-Cores.
Nein, im 'Consumermarkt' hatten wir zu P2/P3 Zeiten durchaus einige brauchbare Optionen für SMP Rechner, da hat sicher der eine oder andere sich so ein Teil hingestellt, sogar der Celeron war zuerst MP Fähig!!

Leider hat man diese 'Consumertauglichen Produkte' entsorgt, mit dem P4 und auch K7 (letzterer war aber teilweise MP tauglich) so dass es momentan nur sau teure Server Hardware gibt, mit 2 Sockeln...

AMD versucht wieder 2 Sockel in den Consumerbereich zu pushen, was aber eigentlich ein alter Hut ist, gruß ans P2B-D...

[SuperHoschi]

Hinweis zu Mongers Post:

Das habe ich so auch noch nie wahrgenommen. Im Consumer-Markt haben wir erst halt seit ein paar Monaten Multi-Cores.

Er hat nicht von CPUs gesprochen, sondern von Cores.

lg
SuperHoschi

[Neomi]

SuperHoschi[/POST]']Er hat nicht von CPUs gesprochen, sondern von Cores.

Ja und? Multi-CPU ist Multi-Core, nur eben auf mehrere Dies verteilt.

[KraetziChriZ]

SavageX[/POST]']Woher stammt eigentlich die Ansicht, dass erst Vista die Multicores richtig nutzen wird? Das erscheint mir doch so ohne weiteres doch an den Haaren herbeigezogen (Multiprocessing ist ein alter Hut, wird von NT seit jeher unterstützt... und von allem, was sich ein *nix nennt).

Nur weil das Betriebsystem 2 Cores unterstüzt, heist das noch lange nicht, das es auch davon profitiert ;)

gruß
chris

[SavageX]

KraetziChriZ[/POST]']Nur weil das Betriebsystem 2 Cores unterstüzt, heist das noch lange nicht, das es auch davon profitiert ;)


Nun, mir wäre es am liebsten, wenn *Anwendungen* profitieren ;)

[KraetziChriZ]

SavageX[/POST]']Nun, mir wäre es am liebsten, wenn *Anwendungen* profitieren ;)

Das wäre natürlich optimal, doch es wäre ja schon Klasse, wenn das Betriebsystem mitsamt Oberfläche bzw. dem ganzen Desktop Environment auf Dual Core / SMP optimiert wäre, und der Kernel die Aufgaben ordentlich auf 2 CPUs verteilen würde...

gruß
chris

[SavageX]

KraetziChriZ[/POST]']Das wäre natürlich optimal, doch es wäre ja schon Klasse, wenn das Betriebsystem mitsamt Oberfläche bzw. dem ganzen Desktop Environment auf Dual Core / SMP optimiert wäre, und der Kernel die Aufgaben ordentlich auf 2 CPUs verteilen würde...


Nun, zumindest das Verteilen von Threads auf die einzelnen Kerne sollte von Windows NT/XP schon ziemlich gut gemacht werden. Ich bin nun wirklich kein Fan von Windows, muss diesem System aber zubilligen, sowas grundlegendes ordentlich zu unterstützen.

Die einzelnen Systemdienste sind ja verschiedene Prozesse, die vom Scheduler bereits hübsch verteilt werden (müssten).

Die Bedienoberfläche von XP mag nicht vernünftig in Threads unterteilt sein - keine Ahnung. Nach heutigen Massstäben bindet sie aber sowieso eher wenig CPU-Zeit. Hier könnte Vista vermutlich tatsächlich den Hebel ansätzen und die anfällige Last vernünftig verteilen. Allerdings dürfte Vista insgesamt deutlich mehr CPU-Zeit verbraten, so dass unter dem Strich für wirkliche Nutzanwendungen aus meiner Sicht nicht wirklich mehr herauskommen kann.

Abwarten, Tee trinken. Vista kommt noch diese Dekade.

[KraetziChriZ]

SavageX[/POST]']Nun, zumindest das Verteilen von Threads auf die einzelnen Kerne sollte von Windows NT/XP schon ziemlich gut gemacht werden. Ich bin nun wirklich kein Fan von Windows, muss diesem System aber zubilligen, sowas grundlegendes ordentlich zu unterstützen.

Klar ist es möglich, manuell etwas auf die CPUs zu verteilen, aber per default wird da in der Regel nicht viel getan, ausser diese 2 häckchen im Taskmanager, was mit bei fehlendem Support der Anwendung für 2 CPUs 0 bringt...

SavageX[/POST]']Die einzelnen Systemdienste sind ja verschiedene Prozesse, die vom Scheduler bereits hübsch verteilt werden (müssten).

Da wird nix verteilt, die laufen alle auf beiden CPUs. (bei mir mit HT)

SavageX[/POST]']Die Bedienoberfläche von XP mag nicht vernünftig in Threads unterteilt sein - keine Ahnung. Nach heutigen Massstäben bindet sie aber sowieso eher wenig CPU-Zeit. Hier könnte Vista vermutlich tatsächlich den Hebel ansätzen und die anfällige Last vernünftig verteilen. Allerdings dürfte Vista insgesamt deutlich mehr CPU-Zeit verbraten, so dass unter dem Strich für wirkliche Nutzanwendungen aus meiner Sicht nicht wirklich mehr herauskommen kann.

http://www.planet-smilies.de/ugly/ulgy_22.gif

gruß
chris

[Neomi]

KraetziChriZ[/POST]']Da wird nix verteilt, die laufen alle auf beiden CPUs. (bei mir mit HT)

Was erwartest du denn vom OS? Soll es etwa die Affinity Mask selbst setzen? Bloß nicht, das ist nur ein Werkzeug für den User bzw. für Anwendungen, um Prozesse bzw. Threads auf bestimmte CPUs zu beschränken. Wenn irgendwas prinzipiell auf beiden CPUs laufen darf (per gesetzter Affinity Mask), dann heißt das nur, daß das OS bestimmen darf, auf welcher CPU es denn nun tatsächlich läuft. Das einzige, was die Maske über die Verteilung aussagt, ist daß ein Programm unter keinen Umständen auf den CPUs laufen kann, die nicht angehakt sind.

[Neomi]

SavageX[/POST]']Die Bedienoberfläche von XP mag nicht vernünftig in Threads unterteilt sein - keine Ahnung. Nach heutigen Massstäben bindet sie aber sowieso eher wenig CPU-Zeit. Hier könnte Vista vermutlich tatsächlich den Hebel ansätzen und die anfällige Last vernünftig verteilen. Allerdings dürfte Vista insgesamt deutlich mehr CPU-Zeit verbraten, so dass unter dem Strich für wirkliche Nutzanwendungen aus meiner Sicht nicht wirklich mehr herauskommen kann.

Warum sollte Vista mehr CPU-Zeit verbraten? Und welcher Teil von Vista? Falls du die Benutzeroberfläche meinst: Aero läßt die GPU arbeiten, die für solche Dinge geradezu prädestiniert ist, die CPU wird dadurch entlastet.

[SavageX]

KraetziChriZ[/POST]']Klar ist es möglich, manuell etwas auf die CPUs zu verteilen, aber per default wird da in der Regel nicht viel getan, ausser diese 2 häckchen im Taskmanager, was mit bei fehlendem Support der Anwendung für 2 CPUs 0 bringt...


Err.. warum sollte ich etwas *manuell* an die CPUs verteilen wollen? Für sowas ist der Scheduler zuständig.

KraetziChriZ[/POST]']
Da wird nix verteilt, die laufen alle auf beiden CPUs. (bei mir mit HT)


Wenn eine Ansammlung von Prozessen auf beiden CPUs läuft so werden doch offensichtlich die Prozesse ordentlich verteilt. Insofern scheint mir, dass wir aneinander vorbei reden.

KraetziChriZ[/POST]']
http://www.planet-smilies.de/ugly/ulgy_22.gif


:confused:

[SavageX]

Neomi[/POST]']Warum sollte Vista mehr CPU-Zeit verbraten? Und welcher Teil von Vista? Falls du die Benutzeroberfläche meinst: Aero läßt die GPU arbeiten, die für solche Dinge geradezu prädestiniert ist, die CPU wird dadurch entlastet.

Vista erfordert mindestens eine CPU der Grössenordnung um 800 MHz. XP fordert entschieden weniger. Ergo wird irgendwo CPU-Zeit konsumiert. Ob nun die Systemdienste (da werden wohl so einige Features dazukommen), der Kernel (sollte eigentlich nicht wirklich fetter geworden sein), die Oberfläche (möglich) oder WasAuchImmer diese Zeit verbraten...

Die Nutzung der GPU entlastet die CPU insofern, als dass man in Software viel langsamer wäre, wenn man die gleichen Effekte berechnen würde. Gegenüber XP bei jeweils Standardeinstellungen erwarte ich keine Entlastung (der 2D Kram, den XP nutzt, wird ja schliesslich auch in Hardware von der GPU beschleunigt).

[haifisch1896]

Neomi[/POST]']Warum sollte Vista mehr CPU-Zeit verbraten? Und welcher Teil von Vista? Falls du die Benutzeroberfläche meinst: Aero läßt die GPU arbeiten, die für solche Dinge geradezu prädestiniert ist, die CPU wird dadurch entlastet.

Genug zu tun haben müsste die CPU aber auch. Ich denke, die CPU-Last von Vista wird sich auf dem Level von Win XP einpendeln.

[StefanV]

SavageX[/POST]']Vista erfordert mindestens eine CPU der Grössenordnung um 800 MHz. XP fordert entschieden weniger. Ergo wird irgendwo CPU-Zeit konsumiert. Ob nun die Systemdienste (da werden wohl so einige Features dazukommen), der Kernel (sollte eigentlich nicht wirklich fetter geworden sein), die Oberfläche (möglich) oder WasAuchImmer diese Zeit verbraten...

Die Nutzung der GPU entlastet die CPU insofern, als dass man in Software viel langsamer wäre, wenn man die gleichen Effekte berechnen würde. Gegenüber XP bei jeweils Standardeinstellungen erwarte ich keine Entlastung (der 2D Kram, den XP nutzt, wird ja schliesslich auch in Hardware von der GPU beschleunigt).
Die 'Mindestanforderungen' kannst eh in die Tonne kloppen, die sind meist (viel) zu niedrig angegeben!

Gerade beim Speicher wird gern mal 'gemogelt'.

Schonmal Windows 95 mit 8MB RAM betrieben?
_DAS_ schockt, ehrlich :ugly:
Gleiches ist bei Windows 2k/XP mit 128MB RAM, auch nicht wirklich schön.

DIe CPU Leistung ist durchaus wichtig, aber nicht so wichtig, wie man meinen würde...

Man kann mit Office und Co durchaus noch recht gut mit 'nem 250MHz Prozessor arbeiten, wirklich machen tuts aber kaum einer, vorallendingen utner aktuellen Betriebssystemen...

[Monger]

Neomi[/POST]']Ja und? Multi-CPU ist Multi-Core, nur eben auf mehrere Dies verteilt.
Nö, das ist nicht egal.
Wir hatten es doch vorhin davon: Dieses Anti-Hyper-Threading wäre auf einem Multiprozessor gar nicht machbar, weil man zumindest einen Speicher braucht, auf den sich beide schnell synchronisieren können.

Multi-CPU Lösungen gibt es natürlich schon lange, aber die haben sich im Consumermarkt (zu Recht) nie wirklich durchgesetzt. Das sieht jetzt mit Multi-Core ganz anders aus.

[TheGoD]

AFAIK wird unter Vista auch der Grafiktreiber immer auf dem zweiten Kern ausgelagert.

[Neomi]

Monger[/POST]']Nö, das ist nicht egal.
Wir hatten es doch vorhin davon: Dieses Anti-Hyper-Threading wäre auf einem Multiprozessor gar nicht machbar, weil man zumindest einen Speicher braucht, auf den sich beide schnell synchronisieren können.

Klar ist das egal, denn es ging dort nicht um das ominöse "Anti-Hyper-Threading", sondern um die angebliche "richtige" Nutzung von MultiCore-CPUs erst ab Vista. Und letzteres ist eben Kappes. Daß Multi-CPU-Systeme anders zu verwalten sind, ist klar, allerdings dank mehrerer NUMA-Nodes nur schwieriger als MultiCore in einer CPU. Ein OS, das mit mehreren CPUs umgehen kann, kann grundsätzlich auch mit mehreren Cores in einer CPU umgehen.

Und jetzt nochmal zum "Anti-Hyper-Threading": der Begriff alleine ist schonmal falsch, da man mehrere Cores nicht wie einen einzelnen arbeiten lassen kann, der Ansatz ist ein völlig anderer (falls daran gearbeitet wird). Und zwar wird nichts zusammengefaßt, sondern Software parallelisiert. Da, wo es auf Programmierebene wegen des viel zu großen Synchronisationsoverheads nicht lohnt, kann es unter Umständen auf Hardwareebene noch hinhauen, da der Overhead viel kleiner ausfallen kann. Mehrere Cores in einer CPU könnten sich über interne Wege sehr effektiv synchronisieren, theoretisch können sie sogar Registerinhalte ohne Umweg über den Speicher direkt austauschen. Mit einer virtuellen Verschmelzung von zwei Kernen hat das aber nicht wirklich was zu tun, es wäre nur eine Art Mikro-Parallelisierung.

[Haarmann]

http://www.scs.ch/~frey/booster.html

War vor ewigen Jahren in aller Munde. Bei den heutigen Fortschritten müsste sowas durchaus möglich sein. Unterm Strich ist das bei DC auf einem Die keiner riesige Hexerei mehr.
Aber da war doch letztens mal ein Bild irgendwo zu sehen von einem neuen AMD Die, wo der Experte meinte, dass die Decoder verdoppelt seien oder nicht?

http://www.theinquirer.net/?article=32424

Das meinte ich

[BAGZZlash]

Hmm, jetzt steht's auf der 3DCenter-Startseite: "Reserve HyperThreading" soll das Ding heißen, und alle vier Male ist's falsch geschrieben. Mein lieber Aths, richtig lesen, gerade beim Inquirer:


...nicht einmal die genannten Namen "Reserve HyperThreading" ...


Nee, genannt ist ja auch der Name "Reverse HyperThreading", AMD hat da keine Reserven mehr und auch nix, um Intel in die Reserve zu treiben... :rolleyes:

[Seraf]

BAGZZlash[/POST]']Hmm, jetzt steht's auf der 3DCenter-Startseite: "Reserve HyperThreading" soll das Ding heißen, und alle vier Male ist's falsch geschrieben. Mein lieber Aths, richtig lesen, gerade beim Inquirer:



Nee, genannt ist ja auch der Name "Reverse HyperThreading", AMD hat da keine Reserven mehr und auch nix, um Intel in die Reserve zu treiben... :rolleyes:

Was hat aths mit den News zu tun? Die macht Leo.

[BAGZZlash]

Echt? Sorry, Aths (war eh nicht als Angriff gedacht).

[Denniss]

Richtig schreiben kann's der INQ auch nicht, Hyper-Threading und nicht HyperThreading. Mit dem großen T gibt es in der Schreibweise HyperTransport aber nicht HTT.

[Tigerchen]

SavageX[/POST]']Nun, zumindest das Verteilen von Threads auf die einzelnen Kerne sollte von Windows NT/XP schon ziemlich gut gemacht werden. Ich bin nun wirklich kein Fan von Windows, muss diesem System aber zubilligen, sowas grundlegendes ordentlich zu unterstützen.

Die einzelnen Systemdienste sind ja verschiedene Prozesse, die vom Scheduler bereits hübsch verteilt werden (müssten).

Die Bedienoberfläche von XP mag nicht vernünftig in Threads unterteilt sein - keine Ahnung. Nach heutigen Massstäben bindet sie aber sowieso eher wenig CPU-Zeit. Hier könnte Vista vermutlich tatsächlich den Hebel ansätzen und die anfällige Last vernünftig verteilen. Allerdings dürfte Vista insgesamt deutlich mehr CPU-Zeit verbraten, so dass unter dem Strich für wirkliche Nutzanwendungen aus meiner Sicht nicht wirklich mehr herauskommen kann.

Abwarten, Tee trinken. Vista kommt noch diese Dekade.

Nein. Wir hatten wir auch schon mal einen Thread der bewies daß der Windows XP Scheduler in dieser Hinsicht nix taugt.

[SavageX]

Tigerchen[/POST]']
Nein. Wir hatten wir auch schon mal einen Thread der bewies daß der Windows XP Scheduler in dieser Hinsicht nix taugt.


In mehr als Einzelfällen?

Den perfekten Scheduler gibt es nicht, aber dass Windows XP Prozesse bzw. deren Threads konsequent an den bereits schwitzenden Kern bindet ("nix taugt") würde mich etwas wundern und wäre ein gewisses Armutszeugnis für die Herren aus Redmond.

[dildo4u]

Nur mal so zur Info die Funktion ist natürlich auch im Conroe vorhanden.

[Coda]

dildo4u[/POST]']Nur mal so zur Info die Funktion ist natürlich auch im Conroe vorhanden.
Woher kommt jetzt der Blödsinn schon wieder?

[Seraf]

SavageX[/POST]']In mehr als Einzelfällen?

Den perfekten Scheduler gibt es nicht, aber dass Windows XP Prozesse bzw. deren Threads konsequent an den bereits schwitzenden Kern bindet ("nix taugt") würde mich etwas wundern und wäre ein gewisses Armutszeugnis für die Herren aus Redmond.

Bei einer Hyperthreading CPU macht Windows das nicht. Warum sollte es dann bei einem echten Mehrprozessorsystem sowas machen?

[dildo4u]

Coda[/POST]']Woher kommt jetzt der Blödsinn schon wieder?

http://www.xtremesystems.org/forums/attachment.php?attachmentid=48597&stc=1&d=1151158718

http://techreport.com/etc/2006q2/cmt.png

http://techreport.com/onearticle.x/10247


"Spannend ist in diesem Zusammenhang auch die Aussicht, dass sich derartige Funktion sowohl bei AMD als auch bei Intel durch ein schlichtes BIOS-Update der entsprechenden Motherboards aktivieren lassen könnte. Tech-Report verweist hier auf einen Screenshot von einem Intel-BIOS mit einer Option zum Aktivieren der Core Multiplexing Technology, die im Kern dem Reverse-HyperThreading entsprechen soll. Die Kernfrage, ob eine derartige Technologie von Intel oder AMD tatsächlich den Markt erreichen wird, vermag zu aktueller Stunde wohl niemand zu beantworten. Hier bleibt wohl vorerst keine andere Wahl, als die Füße still zu halten und den Juli abzuwarten, wenn Intel und AMD ihre neuen Prozessoren einführen,"

http://www.hardtecs4u.com/?id=1151362057,57256,ht4u.php

[Coda]

Ja is gut, erstmal abwarten was sich damit auf sich hat. Wird mal wieder viel heißer gekocht als gegessen. Mit "Conroe hat das" schreist du mal wieder deutlich zu früh mit irgendwas rum.

Das ganze sieht für mich eher danach aus als will man Hotspots auf einem Core verhindern.

Da spinnen sich manche schon aus "Ist das die Antwort auf AMDs geheime Waffe" WTF? Manche Leute müssen schon gute Drogen haben.

[Neomi]

Coda[/POST]']Das ganze sieht für mich eher danach aus als will man Hotspots auf einem Core verhindern.

Das denke ich auch. Wahrscheinlich wird einfach nur ständig zwischen beiden Cores hin- und hergeschoben, um eine einseitig hohe Temperatur zu verhindern.

[chrisihamm]

Hi,


dem kann ich nur beipflichten,diese Zeichnungen im Thread vorher zu Intels MultiPlexingTechnology sind vo einem User im Xtremsystems Forum mit einem Zeichenprogramm erstellt worden. ;D


mfg

[dildo4u]

Coda[/POST]']Ja is gut, erstmal abwarten was sich damit auf sich hat. Wird mal wieder viel heißer gekocht als gegessen. Mit
Ich bin deiner Meinung die Funktion ist wohl ähnlich überflüssig und bringt whol ähnlich wenig wie HT in die andere "Richtung" egal obs von AMD oder Intel kommt.Es braucht keine Antwort auf gar nix es gibt zur Zeit nichtmal Hinweise in irgendeinem AM2 Bios ob es bei AMD überhaupt so eine Funktion gibt/ geben wird.

[StefanV]

Ach, Hardtecs4U ist (leider) etwas arg Intel orientiert :|
Wenn Intel da irgendwas macht, wird auf dieser Seite viel zu viel Tamtam gemacht...

Und auch hier hat sich Rico ein wenig arg weit ausm Fenster gelehnt, hätt ihn nicht jemand gehalten, wär er rausgeflogen...

Vorallendingen kann mit diesem Dingsda so ziemlich alles gemeint sein :|

[Mave@Work]

chrisihamm[/POST]']Hi,


dem kann ich nur beipflichten,diese Zeichnungen im Thread vorher zu Intels MultiPlexingTechnology sind vo einem User im Xtremsystems Forum mit einem Zeichenprogramm erstellt worden. ;D


mfg

Die Zeichnungen ja siehe hier:

Posting #2 (http://www.xtremesystems.org/forums/showthread.php?t=104178) und hier:

Posting #80 (http://www.xtremesystems.org/forums/showthread.php?t=104178&page=4)

Das hat derjenige wohl zur erläuterung gemacht, was er meint.

aber die biosoptionen aus Dildo4u's Post sind hier im orginal:
Posting #59 (http://www.xtremesystems.org/forums/showthread.php?t=104178&page=3) scheinen wohl echt zu sein

[pippo]

Mal ein anderer Ansatz: Wieviel würde es denn bringen, wenn man nicht den kompletten 2. Core, sondern nur dessen Cache benutzt. Quasi DualChannel und somit theoretisch die doppelte Bandbreite erhält? Bisher war doch z.B. die Bandbreite des L2-Cache eines K8 immer ein Kritikpunkt

[Hakkerstiwwel]

pippo[/POST]']Mal ein anderer Ansatz: Wieviel würde es denn bringen, wenn man nicht den kompletten 2. Core, sondern nur dessen Cache benutzt. Quasi DualChannel und somit theoretisch die doppelte Bandbreite erhält? Bisher war doch z.B. die Bandbreite des L2-Cache eines K8 immer ein Kritikpunkt
In dem Fall muesste AMD die komplette Cache Logik ueberarbeiten http://www.xbitlabs.com/articles/cpu/display/dualcore-dtr-analysis_4.html .
edit: vielleicht ist das Ganze ja mal nicht so schwierig, da anscheinend eine Crossbar im X2 integriert ist, aber komischerweise nicht genutzt wird.

[pippo]

Wenn man den DIE-Shot vom F-Stepping ansieht, wurde da doch eh ziemlich viel getan. Drum bin ich ja auch erst auf die Idee gekommen

[anddill]

pippo[/POST]']Mal ein anderer Ansatz: Wieviel würde es denn bringen, wenn man nicht den kompletten 2. Core, sondern nur dessen Cache benutzt. Quasi DualChannel und somit theoretisch die doppelte Bandbreite erhält? Bisher war doch z.B. die Bandbreite des L2-Cache eines K8 immer ein Kritikpunkt

Dann wärs ein Conroe, der kann das nämlich.
Leider wird diese Technik wieder zum Hemmschuh, wenn man wirklich beide Cores auslastet, dann schmeißen sich die Threads gegenseitig aus dem Cache. Deshalb ist das auch die Archillesferse des Conroe, und deshalb will AMD das nicht so bauen.

[pippo]

Was du meinst ist ein shared L2-Cache. Ich mein was ganz anderes, wie du auch siehst wenn du meinen Post liest ;)

Im übrigen wird der K8 auch über shared Cache verfügen

[anddill]

pippo[/POST]']Was du meinst ist ein shared L2-Cache. Ich mein was ganz anderes, wie du auch siehst wenn du meinen Post liest ;)
Na was gibt es denn da noch für Möglichkeiten, den Cache zu teilen?
pippo[/POST]']
Im übrigen wird der K8 auch über shared Cache verfügen
Hä? Der K8 hat separate Caches für jeden Core.

[pippo]

Sorry, da hab ich das "L" vergessen, also meinte ich den K8L.

Es gibt 2 Arten, auf den Cache des anderen Core zu nutzen:
1. ich verdopple die Größe, indem ich die Caches in "Reihe" schalte
2. ich verdopple die Bandbreite, indem ich die Caches "parallel" schalte

Letzteres wär für mich mal interessant zu wissen, was das bringen würde

[Coda]

Da der Cache shared ist wäre "Dual Channel" nix anderes als eine Verdopplung der Anbindungsbreite. Und das kostet eben wohl unverhältnismäßig viele Transistoren.

[pippo]

Mir gehts ja nicht darum, dass man extra nochmal den Cache verdoppelt umd diesen Effekt zu erhalten, sondern was es als bringen würde, wenn der 2. Core abgeschaltet ist, diesen Cache einfach so zu nutzen

[Bokill]

pippo[/POST]'] ... Im übrigen wird der K8 auch über shared Cache verfügen Es werden bei AMD Vorbereitungen getroffen, dass irgendwann L3 Cache integriert wird.

Wann shared L3 Cache, wieviel und womit (Stichwort Z-RAM) ist eher aus einer Glaskugel zu entnehmen, als offiziellen Pressemeldungen.

Bis zum K8L (also alle K8 Modelle vorher) haben definitiv keinen shared Cache.

MFG Bobo(2006)

[anddill]

pippo[/POST]']Mir gehts ja nicht darum, dass man extra nochmal den Cache verdoppelt umd diesen Effekt zu erhalten, sondern was es als bringen würde, wenn der 2. Core abgeschaltet ist, diesen Cache einfach so zu nutzen
Dazu mußt Du halt beide Cores an den Cache-Bus beider Caches anklemmen. Dadurch bekommst Du einen gemeinsamen Bus für beide Cores und einen Unified Cache und kommst wieder beim Conroe-Design an.
Und wie der K8L aufgebaut sein wird, ist noch nicht bekannt.

[pippo]

@ Bokill
Ich hatte meinen Rechtschreibfehler korrigiert ;)

@ anddill
Ich wage zu bezweifeln, dass Conroe seinen Cache auch parallel schalten kann. Das wäre bei der Einführung von Woodcrest sicherlich bekannt geworden.

Ausserdem wurde immer noch nicht meine simple Frage beantwortet: Was könnte das ungefähr bringen?

[TheGoD]

Bei Conroe können beide Cores auf den gleichen Cache zugreifen.

[pippo]

Ich gebs auf, ich frag in nem anderen Forum ;)

[Coda]

Nein du verstehst es nicht. Der Cache hängt an einem Interface. Nicht an zweien. Was willst du da parallel schalten?

[dildo4u]

Coda[/POST]']Nein du verstehst es nicht. Der Cache hängt an einem Interface. Jup siehe hier.


http://www.hkepc.com/hwdb/x6800vsfx62/asc.jpg

[pippo]

Ich versteh nicht was du meinst. Dass die 2 Cores über 1 Interface an der Crossbar hängen ist mir schon klar, aber darüber wird der Cache ja nur "gefüttert". Es sollte ja kein Problem darstellen, auf beiden Cores die gleichen Daten abzulegen.
Über die Inter-Core communication könnte dann doch Core 0 auf den Cache von Core 1 zugreifen, theoretisch gesehen.

[HOT]

Bokill[/POST]']Es werden bei AMD Vorbereitungen getroffen, dass irgendwann L3 Cache integriert wird.

Wann shared L3 Cache, wieviel und womit (Stichwort Z-RAM) ist eher aus einer Glaskugel zu entnehmen, als offiziellen Pressemeldungen.

Bis zum K8L (also alle K8 Modelle vorher) haben definitiv keinen shared Cache.

MFG Bobo(2006)

Laut den K8L Infos hat der K8L einen shared L3 (für je 2 Cores) und der besteht definitiv nicht aus ZRAM.
Das ist aber auch das Einzige, was am K8L geteilt wird. L2 bleibt Core exklusiv, wenn er auch kleiner gehalten wird.Ich vermute aber, dass AMD beim L2 die Latenzen so niedrig wie möglich halten will.
Der K8L stellt von den Caches her so ziemlich das Gegenteil zu dem dar, was Intel mit seinem shared L2 betreibt.

[HOT]

pippo[/POST]']Ich versteh nicht was du meinst. Dass die 2 Cores über 1 Interface an der Crossbar hängen ist mir schon klar, aber darüber wird der Cache ja nur "gefüttert". Es sollte ja kein Problem darstellen, auf beiden Cores die gleichen Daten abzulegen.
Über die Inter-Core communication könnte dann doch Core 0 auf den Cache von Core 1 zugreifen, theoretisch gesehen.

Die L2 hängen beim K8 doch an den Cores selber, nur die Synchronisation läuft über den Crossbar.

[HOT]

dildo4u[/POST]']Jup siehe hier.


http://www.hkepc.com/hwdb/x6800vsfx62/asc.jpg

Tolles Marketingbildchen, verdeutlicht aber mehr die Vorteile, die durch den Wegfall der Cache Synchronisation über den FSB entstehen als die Vorteile eines unified Caches.

[pippo]

HOT[/POST]']Die L2 hängen beim K8 doch an den Cores selber, nur die Synchronisation läuft über den Crossbar.
Was meinst du damit? Über die Crossbar werden doch die Daten aus dem Arbeitsspeicher nachgeladen, oder nicht?

[Coda]

Das Interface zum L1 ist eben nur n-bits breit. Das müsste man ja auch verdoppeln.

Überhaupt halte ich es sehr viel sinnvoller 4MB Cache zu haben als 2MB der doppelten Durchsatz hat (Latenz ist beim Cache eh unglaublich viel wichtiger).

[pippo]

Ich hab mich ja nicht nur auf den L2-Cache bezogen.

Im übrigen wird doch in jedem Artikel über den K8 die Bandbreite des L2-Cache bemängelt. 10Gb/s aus theoretischen 32Gb/s beim FX62 ist schon arg schwach, meiner Meinung. Ich weiß jetzt zwar nicht mehr auswendig, wieviel ein 3,2Ghz P4 aus seinen theoretischen 100Gb/s rausholt, aber es war doch deutlich mehr. Und, dass der Speicher nun seit DDR2 mit der gestiegenen Bandbreite nicht mehr so gut skaliert, ist doch schließlich auch auf den geringen Durchsatz des L2-Cache zurückzuführen

[Bokill]

pippo[/POST]'] ... Und, dass der Speicher nun seit DDR2 mit der gestiegenen Bandbreite nicht mehr so gut skaliert, ist doch schließlich auch auf den geringen Durchsatz des L2-Cache zurückzuführen Schon mal daran gedacht, dass die Kern-Taktfrequenzen des K8 derzeit so gering sein könnten, dass erst bei höherem Takt auch die Speicher-Bandbreite steigt?

Genau das tut der K8 im Sockel AM2. Es sieht so aus, dass der grosse L1 Cache so manches abfedert.

MFG Bobo(2006)

[pippo]

Weil irgendwo ein Flaschenhals da ist, ja. Mit steigendem Takt wird dieser natürlich kleiner und der Speicher kann besser skalieren. Es ist aber sicherlich nicht der Weisheit letzter Schluss, die Taktrate hoch zu treiben um dieses Problem zu beseitigen

[Bokill]

pippo[/POST]']Weil irgendwo ein Flaschenhals da ist, ja. ... Nein. Du verstehst mich offensichtlich nicht.

Ein Flaschenhals bleibt ein Flaschenhals, wenn trotz erhöhter erforderlicher Rechenleistung eben nichts mehr geht.

Der Witz ist, dass bei höherer Taktrate der K8 im Sockel AM2 dort eben nicht "dichtmacht" sondern schlicht weiter skaliert. Gäbe es einen Flaschenhals, dann könnte eben auch nichts weiter skalieren, so einfách ist das.

MFG Bobo(2006)

[pippo]

Ich verstehs nicht, nein. Egal wo der Flaschenhals ist, nichts im Prozessor hat ja einen festen Takt (bis auf HT). Somit steigt mit höherem Takt auch die Bandbreite des Flaschenhalses mit an, was auch den Speicher weiter skalieren lässt.

Wie erklärst du dir denn, dass erst mit einem hohen Prozessortakt das Verhältnis von realer zu theoretischer Bandbreite in eine Region kommt, die man von DDR1 kannte? Die reale Bandbreite ist derzeit doch noch weit von der theoretischen entfernt und ich glaube nicht, dass das an einem schlechten Memorycontroller liegt.

Ich behaupte, für DDR1-400 war der Flaschenhals noch groß genug, sodass der Speicher wunderbar skalieren konnte. Nun mit DDR2-800 haben wir die doppelte Bandbreite, die der Athlon64 aber erst mit einem hohen Takt nutzen kann.

[HOT]

pippo[/POST]']Was meinst du damit? Über die Crossbar werden doch die Daten aus dem Arbeitsspeicher nachgeladen, oder nicht?

Die normale SMP Cache Synchronisation läuft beim K8 nicht über den RAM sondern nur über den Crossbar. Deshalb sind die AMDs sogar in Videoschnitt und anderen Strteaminganwendungen den P-Ds so überlegen. Beim Conroe wurde dieses Manko auch behoben, hoffentlich auch beim Kentsfield, wir werden es sehen.

[OBrian]

@Bokill & pippo: Ich glaube, Ihr redet aneinander vorbei, meint aber dasselbe: Die CPU an sich ist der Flaschenhals und kann soviel Bandbreite gar nicht ausnutzen. Die Frage ist nur, fordern die Recheneinheiten nicht mehr an, oder kann die Kette aus Memorycontroller und Cache nicht mehr durchleiten?

Beides wird natürlich mit mehr CPU-Takt besser, aber in ersterem Falle könnte man mehr oder schnellere Recheneinheiten einbauen, im zweiten Falle das Speichersubsystem aufbohren, um bei gleichem Takt mehr Leistung zu erhalten.

Interessanterweise tut AMD beim K8L aber beides, also scheint es beides gleichermaßen notwendig bzw. im Umkehrschluß bisher ausgewogen gewesen zu sein.

[HOT]

pippo[/POST]']Ich verstehs nicht, nein. Egal wo der Flaschenhals ist, nichts im Prozessor hat ja einen festen Takt (bis auf HT). Somit steigt mit höherem Takt auch die Bandbreite des Flaschenhalses mit an, was auch den Speicher weiter skalieren lässt.

Wie erklärst du dir denn, dass erst mit einem hohen Prozessortakt das Verhältnis von realer zu theoretischer Bandbreite in eine Region kommt, die man von DDR1 kannte? Die reale Bandbreite ist derzeit doch noch weit von der theoretischen entfernt und ich glaube nicht, dass das an einem schlechten Memorycontroller liegt.

Ich behaupte, für DDR1-400 war der Flaschenhals noch groß genug, sodass der Speicher wunderbar skalieren konnte. Nun mit DDR2-800 haben wir die doppelte Bandbreite, die der Athlon64 aber erst mit einem hohen Takt nutzen kann.

In vielen Fällen reichen sogar 3,2GB/Sec aus, wie man gut an den Sockel754 Athlons sehen kann. Der Punkt ist aber der, dass der Prozessor in den seltensten Fällen soviele Daten benötigt, als über DDR2-800 geliefert werden können. Steigert man jetzt aber den Takt des Athlons, steigt auch der potenzielle Bedarf an Bandbreite.
Der Flaschenhals liegt beim K8 wie auch schon beim K7 in der Auslastung der Recheneinheiten. Das klappt beim Conroe etwas besser, deshalb ist er auch schneller. Mit der Cache Bandbreite muss das nicht zusammenhängen, hier spielt sicherlich die Latenz eine grössere Rolle. Wie gross diese Rolle ist, kann man am Dothan ganz gut sehen.
Der Bandbreitenbedarf an den Cache steigt ja auch nicht weiter beim K8, der Cache wird doch mit dem CPU Takt weiter beschleunigt.

[pippo]

@ OBrain
Beim K8L wurde doch auch nur die Bandbreite zwischen L1 und L2 auf 256bit erhöht, oder? Ich hab mich schon damals gefragt, ob das reicht.
Bisher dachte ich eigentlich immer, dass man die Bandbreite des Cache und des Speichers unabhängig von den Ausführungseinheiten messen kann. Ist dem also nicht so und alle in Benchmark ermittelten Werte sind nur so gering, weil die Ausführungseinheiten nicht mehr angefordert haben?

[Gast]

HOT[/POST]']Die normale SMP Cache Synchronisation läuft beim K8 nicht über den RAM sondern nur über den Crossbar. Deshalb sind die AMDs sogar in Videoschnitt und anderen Strteaminganwendungen den P-Ds so überlegen. Beim Conroe wurde dieses Manko auch behoben, hoffentlich auch beim Kentsfield, wir werden es sehen.
Schoen waer's

So, I have to state that I can’t find any indication of direct data transfers from one execution core to another in the Athlon 64 X2 processor. According to my tests, the most recent copy of data is always read from system RAM. This must be a limitation of the MOESI protocol implementation. The following seems to happen when data are accessed: on receiving a read request probe read that the second core puts on the system bus, the first core performs a write-back of the modified cache line into memory. After this write or at the same time with it, the requested line is transferred to the second core. If the data in the first core’s cache haven’t been modified, they are read from system RAM. Why is there no direct transfer between the cores via the crossbar switch? Ask AMD’s engineers about that! :) .
quelle
http://www.xbitlabs.com/articles/cpu/display/dualcore-dtr-analysis_4.html

[BlackBirdSR]

Gast[/POST]']Schoen waer's

quelle
http://www.xbitlabs.com/articles/cpu/display/dualcore-dtr-analysis_4.html

Es gab eine Diskussion darüber, dass die verwendeten Algorithmen das nicht zeigen könnten.


by abinstein on Jun 01, 2006 - 03:37 AM
(User information | Send a message)
According to my tests, the most recent copy of data is always read from system RAM. This must be a limitation of the MOESI protocol implementation. ... Why is there no direct transfer between the cores via the crossbar switch? Ask AMD’s engineers about that!


Unfortunately xbit is wrong here.

If we look at AMD's MOESI protocol (Ch.7 of Programmer's Manual Vol.2), there is NO read probing in the invalid state. In fact, there is NO ANY probing when a cache line is invalid. (How could it, anyway, since the cache line isn't mapped to any physical address yet!)

So yes, with his toy app xbit won't observe inter-core communication on Athlon64 X2, because core#1 doesn't (and shouldn't) care about what data core#0 is reading if core#1 wasn't previously working on the data. This is also true with Pentium-D. On the other hand, Prescott and Yonah/Conroe manifest their inter-core communications with this toy app just fine simply because in their cases core#1's cache line is loaded (shared) with core#0's.

A more realistic test program should measure the sequence of {core#0.read, core#0.write, core#1.read, core#1.write} m times on the same address, divide the number of cycles by m, then measure the sequence on the next address, and so on. Such a producer-consumer scenario at least better reflects the behaviors of real multi-threaded applications.

What xbit just proved in the article is really the following: simple artifical benchmark results are sometimes misleading and could lead to completely wrong conclusions (in this case to the conclusion that there is no inter-core communications in Athlon64 X2).

[anddill]

Ich glaube, ich versteh so ganz langsam, was pippo meint:
Er will über die Crossbar mit Core0 auch auf den L2 von Core1 zugreifen, wenn Core1 gerade nichts zu tun hat. Dabei würde sich dann seiner Meinung nach die Bandbreite zwischen Core0 und dem L2 verdoppeln. Was er dabei nicht bedenkt, ist daß
1. Jedes Bit erst mal in den L2 reinmuß, das muß der Speichercontroller erst mal bringen
2. Je nach Zufriffsweg haben die L2-Zugriffe unterschiedliche Latenzen. Viel Spaß beim syncronisieren. Der Verlust dadurch dürfte den Performancegewinn um das mehrfache übertreffen.

[Bokill]

pippo[/POST]'] ... Somit steigt mit höherem Takt auch die Bandbreite des Flaschenhalses mit an, Nein. Flaschenhals bedeutet, dass da nich mehr bei rumkommt, egal wie hoch der Takt weitergetrieben wird.
was auch den Speicher weiter skalieren lässt. Eben das lässt den Speicher nicht mehr skalieren.

Wie erklärst du dir denn, dass erst mit einem hohen Prozessortakt das Verhältnis von realer zu theoretischer Bandbreite in eine Region kommt, die man von DDR1 kannte? Die reale Bandbreite ist derzeit doch noch weit von der theoretischen entfernt und ich glaube nicht, dass das an einem schlechten Memorycontroller liegt. Nun der K8 ist ausgelegt auf kurze Latenzen des Speichers, bzw. erst der integrierte Speicherkontroller holt dadurch Mehrleistung raus.

Bei DDR2 haben wir zwar formal höhere Bandbreiten (bezogen auf den Speicherzellentakt), da doppelt so viele Speicherzellen parallel angesprochen werden. Nützt aber gar nichts, wenn Latenzen eine Rolle spielen.

Ich behaupte, für DDR1-400 war der Flaschenhals noch groß genug, sodass der Speicher wunderbar skalieren konnte. Nun mit DDR2-800 haben wir die doppelte Bandbreite, die der Athlon64 aber erst mit einem hohen Takt nutzen kann. Nichts anderes (als im dick markierten Satz) habe ich doch vorher auch gesagt ;)

MFG Bobo(2006)

[OBrian]

Bokill[/POST]']Nein. Flaschenhals bedeutet, dass da nich mehr bei rumkommt, egal wie hoch der Takt weitergetrieben wird.Wenn man eine Flasche in der Größe gleichmäßig skaliert, ändert sich ja auch der Durchmesser des Halses, trotzdem bleibt das der Flaschenhals ;)

@ OBrain
Beim K8L wurde doch auch nur die Bandbreite zwischen L1 und L2 auf 256bit erhöht, oder? Ich hab mich schon damals gefragt, ob das reicht.Der K8L soll doch erst noch kommen, da muß man nicht unbedingt in der Vergangenheitsform reden, das hört sich ja an, als ginge es um den K6 ;)

Außerdem weiß wohl keiner ganz genau, was alles geändert wird. Die bisherigen "Infos" sind doch nur hingeworfene Brocken von AMD und Spekulationen von mehr oder weniger fachkundigen Leuten aus diversen Internetforen. Wenn er tatsächlich da ist und man spezielle Benchmarks damit fahren kann, kann man damit evtl. einige Vermutungen verifizieren. Aber vorher wär ich ziemlich vorsichtig im Umgang mit diesem "Tatsachen"...

[pippo]

@ anddill
Genau das meinte ich ;) Da im 2. Cache ja die gleichen Daten liegen, hat der Speichercontroller auch nicht mehr arbeit.
zu 1) Das Interface müsste halt überarbeitet werden, damit es die Daten spiegeln kann
zu 2) und genau das war meine Frage. Ob sich der Aufwand/Nutzen lohnt, wenn das ganze synchronisiert werden muss. Ich hab nie was anderes geschrieben :)

@ Bokill
Ist das deine eigene Definition von Flaschenhals? Ich denke du stimmst mir zu, dass beim MP-Systemen Intels Flaschenhals der FSB ist, oder? Wenn dieser jetzt nun mit 1Ghz takten würde, ist es sicherlich keiner mehr. 32Gb/s schafft ja nichtmal HT.
Den Satz, den du Dick markiert hast, meinte ich so, dass erst bei einem hohen Takt der Flaschenhals verschwindet und so die Bandbreite voll ausgenutzt werden kann

@ OBrain
Die Vergangenheitsform hat sich im Eifer des Gefechts eingeschlichen ;)
Da der K8L in 1 Jahr kommt, sollte das Design ja schon zu 99% stehen. Von dem her sollten also die Angaben von AMD doch stimmen

[Bokill]

pippo[/POST]']
@ Bokill
Ist das deine eigene Definition von Flaschenhals? Ich denke du stimmst mir zu, dass beim MP-Systemen Intels Flaschenhals der FSB ist, oder? Wenn dieser jetzt nun mit 1Ghz takten würde, ist es sicherlich keiner mehr. 32Gb/s schafft ja nichtmal HT.
Den Satz, den du Dick markiert hast, meinte ich so, dass erst bei einem hohen Takt der Flaschenhals verschwindet und so die Bandbreite voll ausgenutzt werden kann Ja das mit dem klassischen Bus bei Intelsystemen ist ein gutes Beispiel.

Solange der Bus bei seiner Bandbreite bleibt, solange ist das ein Flaschenhals, da nutzt ein höherer Speichertakt und ein höherer CPU Takt immer weniger. Irgendwann macht das System als ganzes "dicht".

Genau dieses "dichtmachen" sieht man bei dem K8 aber nicht mit DDR2. Bei gesteigerten CPU Takt skaliert der Speicherbus tapfer weiter. Deswegen sehe ich keinen Flaschenhals.

Was ich da sehe bei DDR2 ist die Konkurrenz von hoher Bandbreite mit schlechteren Latenzen. Bei DDR1 haben wir kurze Latenzen mit vergleichsweise gut genutzter Speicherbandbreite. Der Nachteil bei DDR1 ist, dass irgendwann (bei hohen CPU Takt), dann der Speicherbus nicht mehr hinterher kommt ("dichtmachen").

Wo (bei welchen CPU Takt) die Sättigungsgrenze vom DDR1 Speicherbus ist bei dem K8 kann ich aber nicht sagen, das überlasse ich gerne den OC-Freaks.

MFG Bobo(2006)

[saddevil]

Bokill[/POST]']
Wo (bei welchen CPU Takt) die Sättigungsgrenze vom DDR1 Speicherbus ist bei dem K8 kann ich aber nicht sagen, das überlasse ich gerne den OC-Freaks.
MFG Bobo(2006)

300MHZ 3-4-4-10
war langsamer als
250MHz 2-2-2-5
beim test von DDR1 aufm K8

aber dennoch stieg die performance immernoch an mit jedem MHz

[Hakkerstiwwel]

Wo Rauch ist auch Feuer:
http://www.dailytech.com/article.aspx?newsid=3152
Vielleicht nicht ganz das was von vielen erwartet wurde, aber immerhin etwas

[BlackBirdSR]

Hakkerstiwwel[/POST]']Wo Rauch ist auch Feuer:
http://www.dailytech.com/article.aspx?newsid=3152
Vielleicht nicht ganz das was von vielen erwartet wurde, aber immerhin etwas

Also das war es sicher nicht.
Das ist einfach ein Fix für Probleme in Windows ;)

[Kolos]

http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1152536765

[Blutmaul]

Ok, steht schon über meinem Posting...

[Coda]

Leider ist die Quelle Inquirer. Mir wäre ein offizielles Dementi lieber...

[BlackBirdSR]

Coda[/POST]']Leider ist die Quelle Inquirer. Mir wäre ein offizielles Dementi lieber...

Einer der vielen Momente, wo eine Quellenangabe bei INQ mal nützlich wäre ;)
Aber ich denke dazu werden wir gar nichts mehr erfahren.
Wenn INQ mal etwas vorhersagt, dann aber wieder zurückrudern muss, gibts in der Regel keine weiteren Infos dazu. Siehe den angeblichen AMD-ATi Deal.

[AnarchX]

Was aber dann die Core Multiplexing Technology, welche man auf einem BIOS-Screen des Bad-AXE sehe konnte... :|

edit:
http://techreport.com/etc/2006q2/cmt.pnghttp://www.xtremesystems.org/forums/attachment.php?attachmentid=48597&stc=1&d=1151158718


Vielleicht hat AMD das Gerücht ihrer es Anti-HTs in die Welt gesetzt um Intel zuvorzukommen, von welchen sie wussten, dass diese soetwas schon in der Planung haben...

[S940]

Coda[/POST]']Leider ist die Quelle Inquirer. Mir wäre ein offizielles Dementi lieber...

;D Naja, da der Inquirer sonst immer solche Gerüchte in die Welt setzt, und nie was dementiert, denke ich, dass in dem Fall die Aussage 100% stimmt.
Von AMD wirst Du nie was bekommen, die freuen sich doch eher über das Gerücht, selbst wenn es nicht zutrifft .. ;-)

ciao

Alex

[Avalox]

Andreas Stiller hat Margaret Lewis, AMD Director of Commercial ISV Marketing danach gefragt. Sie hat wohl gelächelt und gesagt "AMD forsche an zahlreichen Techniken zur Performance-Verbesserung".

http://www.heise.de/ct/06/15/026/

[Neomi]

AnarchX[/POST]']Was aber dann die Core Multiplexing Technology, welche man auf einem BIOS-Screen des Bad-AXE sehe konnte... :|

Das ist mit sehr hoher Wahrscheinlichkeit einfach nur eine Option zur gleichmäßigeren Wärmeverteilung, indem die Cores immer wieder die Aufgaben untereinander wechseln. Da ist nichts magisches dran.

AnarchX[/POST]']Vielleicht hat AMD das Gerücht ihrer es Anti-HTs in die Welt gesetzt um Intel zuvorzukommen, von welchen sie wussten, dass diese soetwas schon in der Planung haben...

AMD weiß ganz genau, daß auch Intel keinen seriellen Code parallelisieren kann.

[Gast]

Neomi[/POST]']AMD weiß ganz genau, daß auch Intel keinen seriellen Code parallelisieren kann.In heutzutage typischem seriellen Code steckt aber eine Menge Parallelisierbares, und Compiler müssen recht konservativ bei der Parallelisierung vorgehen, da längst nicht alle Unabhängigkeiten sicher vorhergesagt werden können. Intels Mitosis arbeitet doch an dem gleichen Problem wie AMDs Anti-Hyper-Threading, und das hat mehr mit Programmiererfaulheit (oder vielmehr mit jahrzehntealten Gewohnheiten) als mit technischen bzw. logischen Problemen zu tun.

[Coda]

Gast[/POST]']In heutzutage typischem seriellen Code steckt aber eine Menge Parallelisierbares
Das nützen die CPUs sowieso schon aus. Auf Threadebene kannst du das vergessen zur Runtime.

[Gast]

Coda[/POST]']Das nützen die CPUs sowieso schon aus. Auf Threadebene kannst du das vergessen zur Runtime.Bei Intel sind die Arbeiten an Mitosis aber nicht nur ein Gerücht, sondern sie informieren höchstselbst die Welt darüber. Intel hat zwar eine Menge Moneten auf der hohen Kante, die sind dort aber nicht gelandet, weil Intel andauernd Geld für Spinnereien ohne Nutzen herauswirft. Wenn auch AMD an ähnlichem arbeitet kanns so spinnert nicht sein.

[BlackBirdSR]

Gast[/POST]']Bei Intel sind die Arbeiten an Mitosis aber nicht nur ein Gerücht, sondern sie informieren höchstselbst die Welt darüber. Intel hat zwar eine Menge Moneten auf der hohen Kante, die sind dort aber nicht gelandet, weil Intel andauernd Geld für Spinnereien ohne Nutzen herauswirft. Wenn auch AMD an ähnlichem arbeitet kanns so spinnert nicht sein.

Wobei Mitosis nichts mit dem zu tun hat, was als angeblich "Anti-Hyperthreading" darstellen sollte.
Mitosis erzeugt spekulative Threads die in zusammenarbeit mit dem Compiler! und der Hardware einen Performanceschub bringen können.

[Bokill]

Gast[/POST]']Bei Intel sind die Arbeiten an Mitosis aber nicht nur ein Gerücht, sondern sie informieren höchstselbst die Welt darüber. ... Dass sie "Informieren" hat was mit PR zu tun ... ;)

Jede CPU Schmiede macht sich über Parallelisierung Gedanken ... und das schon seit Jahrzehnten. Das ist ein uraltes IT-Problem.

MFG Bobo(2006)