News Microsoft veröffentlicht nochmals AMD-FX Scheduler-Patch für Windows 7

[Opteron]

<div class="newsfloatleft"><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1326327456"><img src="http://www.planet3dnow.de/photoplog/images/54308/1_UnlockedFXProcessorLogo.png" border="0" alt="P3D-Downloads-Logo"></a></div>
Gestern Abend gegen Mitternacht stellte Microsoft erneut Hotfixe für AMDs FX-Prozessor online. Im Gegensatz zur Erstveröffentlichung(siehe <a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1323989517">News-Meldung vom 15.12.2011</a>) bei der der zweite Hotfix fehlte, weswegen der erste Patch plötzlich ebenfalls wieder verschwand, gibt es jetzt beide Patches. Wunder wird man trotzdem kaum erwarten können, laut <a href="http://blogs.amd.com/play/2012/01/11/early-results-achieved-with-amd-fx-processor-using-windows%C2%AE-7-scheduler-update/" target="b">AMDs Blogeintrag</a> wird quasi nur ein Intel-ähnlicher SMT-Modus aktiviert, der im Teillastbereich Threads zuerst auf die einzelnen Module verteilt, anstatt ein einziges Modul mit 2 Threads zu belasten. Selbiges steigert seit Windows 7 auch schon bei Intel die Leistung im Teillastbereich und aktiviertem Hyper-Threading. Zusätzlich zum Dezember-Update gibt es jetzt auch noch einen Hotfix, der sich dem Core-Parking annimmt. Bisher wird davon laut AMD zu oft gebraucht gemacht. Wird der Prozessor geparkt, d.h. abgeschaltet, werden die L1- und L2-Cache-Inhalte in den L3 oder ins RAM ausgelagert. Man kann sich deshalb leicht vorstellen, dass einige Zeit verstreicht, bis so ein "geparkter" Kern wieder betriebsbereit ist und ein Verhindern des zu häufigen Parkens etwas Leistung bringt. Beide Hotfixes für Windows 7 bzw. Windows Server 2008 können bei Microsoft heruntergeladen werden, Links siehe unter "Quellen".

Danke an deadohiosky fürs Posten der Nachricht im Forum.

<b>Quellen:</b><ul><li><a href="http://blogs.amd.com/play/2012/01/11/early-results-achieved-with-amd-fx-processor-using-windows%C2%AE-7-scheduler-update/" target="b">AMD Blog</a></li><li><a href="http://support.microsoft.com/kb/2645594" target="b">Microsoft Hotfix für den Scheduler</a></li><li><a href="http://support.microsoft.com/kb/2646060" target="b">Microsoft Hotfix für das Core Parking</a></li></ul><b>Download:</b><ul><li><a href="http://www.planet3dnow.de/cgi-bin/file/get.cgi?20120329141126">Bulldozer Scheduler-Patch KB2645594 [Windows 7 x86]</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/file/get.cgi?20120329141127">Bulldozer Scheduler-Patch KB2645594 [Windows 7 x64]</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/file/get.cgi?20120329141128">Bulldozer Coreparking-Patch KB2646060-v3 [Windows 7 x86]</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/file/get.cgi?20120329141129">Bulldozer Coreparking-Patch KB2646060-v3 [Windows 7 x64]</a></li></ul><b>Links zum Thema:</b><ul><li><a href="http://www.planet3dnow.de/vbulletin/showthread.php?t=399188&page=25">Diskussion im Forum</a></li><li><a href="http://www.planet3dnow.de/cgi-bin/newspub/viewnews.cgi?id=1323989517">Bulldozer-Patch für Windows 7 nicht der Weisheit letzter Schluss (Update)</a></li></ul>

 

[C4rp3di3m]

Hat dieser Patch auch eine positive Wirkung auf andere mehr Kern AMD CPU´s? Wird damit das von Kern zu Kern springen unterbunden? Oder ist dieser Patch wirklich nur FX only und hat negative Auswirkungen auf x4 oder x6 CPU´s?Danke für die Info.

mfg

 

[Opteron]

Ne, davon steht leider nirgends was. SMT-Mode+Coreparking/C6, das wars.

 

[kalkzone]

"The best possible cases for improvement are applications that use ½ cores in your AMD FX processor."


What the fuck is a "half core" ?

Ist das eine Hälfte von der Hälfte eines Bulldozermodules ?

Oder hat ein Bulldozer-Modul doch nur EINEN Core ?

ist also ei 8150 nunmehr doch NUR ein 4 Core ?
.
EDIT :
.
Zitat:

In fact, heavily threaded apps (those designed to use all 8 cores), get little or no uplift from this hotfix –
---------------------

they are already maxing out the processor. In other cases, the uplift averages out to a 1-2 percent uplift.
------- ---------------

 

[Redphil]

Schon jemand erste Erfahrungen gesammelt? Mir fehlt atm leider die Muße zum selber-testen, aber ein Geschwindigkeitsschub für den FX-4100 wäre natürlich nice.

 

[Stechpalme]

@kalkzone
Ein FX hat 4 Module mit je zwei Kernen. Nur das die zwei Kerne in einem Modul sich die FPU teilen müssen. Entweder kann ein Kern die volle Anbindung von 256bit zur FPU nutzen oder eben jeder Kern eines Moduls 128bit.
Bei FPU Lasigen Anwendungen die eben nicht volle 8 Kerne nutzen, wäre es eben positiv wenn der Sheduler dem Programm das z.B. nur 4 Kerne nutzt, jeweils ein Kern pro Modul zuweisen kann damit der Kern eben die volle FPU Leistung nutzen kann. Derzeit ist es leider so, dass Windows die Programme durch alle Kerne springen lässt und damit auch Programme die nur wenige Kerne efektiv nutzen, nie die volle FPU Leistung bekommen können.
Die neuen Sheduler sollen eben dis erkennen und dem Programm immer ein Kern pro Modul zuweisen. Ein Programm das eben 4 Kerne nutzt, soll dann eben auf alle 4 Module verteilt werden wo jeweils dann nur ein Kern verwendet wird.

Allerdings sollte man sich davon auch nicht zu viel erhoffen, denn nicht alles braucht eine hohe FPU Leistung. Und bei genutzen 8 Kernen kann dies auch nichts bringen, da ja alle Kerne verwendet werden müssen.

 

[Redphil]

Schon jemand erste Erfahrungen gesammelt? Mir fehlt atm leider die Muße zum selber-testen, aber ein Geschwindigkeitsschub für den FX-4100 wäre natürlich nice.

Ah, in der Quelle steht es ja konkreter:

Our testing shows that not every application realizes a performance boost. In fact, heavily threaded apps (those designed to use all 8 cores), get little or no uplift from this hotfix – they are already maxing out the processor. In other cases, the uplift averages out to a 1-2 percent uplift.

Mhm, das ist jetzt nicht gerade vielversprechend.

 

[Fuddelbaerentatze]

Mal ne Frage: Laufen ältere Betriebssysteme wie XP/Server 2003 überhaupt noch auf Bulldozer? Bei den Chipsets hat sich doch kaum was getan seit der 700er Reihe, von der Seite her dürfte es doch keine Probleme geben für NT 5.x. Wie sieht es auf der CPU Seite aus? Bin gerade nicht auf der Höhe der Zeit was MS angeht Lese hier aber immer nur von Scheduler Patches für Windows 7 und mich beschleicht die Befürchtung das XP/2003 keine Scheduler Optimierungen bekommt. Weiß jemand was genaues?

 

[Onkel_Dithmeyer]

Windows XP ist der Mainstream-Support bereits ausgelaufen. Der Extendet-Support läuft noch bis 2014, enthält aber ohne Zusatzvertrag keine nicht-sicherheitsrelevanten Updates mehr. Für den Normalkunden bedeutet das, dass es kein Scheduler-Patch mehr für XP geben wird. Wie hoch das Interesse Microsofts ist für die "alten" Windows-Versionen ein entsprechendes Update zu bringen, sei einmal dahingestellt.

 

[Stechpalme]

Man sollte auch bedenken das Windows XP mittlerweile über 10 Jahre alt ist (es kam 2001 raus). In der Computerwelt damit schon mehr als Steinzeitlich. Da kann man nicht erwarten das die Hersteller nch weitere 10 Jahre einen Support bieten.

 

[genervt]

Lasst doch mal XP in Friede ruhen

 

[Fuddelbaerentatze]

Lasst doch mal XP in Friede ruhen

Man sollte auch bedenken das Windows XP mittlerweile über 10 Jahre alt ist (es kam 2001 raus). In der Computerwelt damit schon mehr als Steinzeitlich. Da kann man nicht erwarten das die Hersteller nch weitere 10 Jahre einen Support bieten.

"Da draußen" dürften schon noch so manche XP 64bit Workstations und Server 2003 sein deren Betreiber lieber die Hardware upgraden würden als die Betriebssysteme.

Wie auch immer, wenn überhaupt noch mal ein Windows auf einen meinen Rechner kommt, dann sicher kein Vista/7/8 ...

 

[hoschi_tux]

Heißt das auch, dass der Turbo Modus endlich mal so funktioniert, wie er angedacht ist?

 

[Byce]

Ich entsinne mich noch dunkel, dass AMD ebenso meinte, dass es eine Leistungssteigerung gibt, wenn zwei von einander abhängige Threads im selben Modul berechnet würden, da dann ja der Umweg über den L3 wegfällt. Dieses "Feature" wird ja durch den Hotfix dann so gut wie nie auftreten - sehe ich das richtig? Ist in die Richtung eventuell etwas geplant?

Grüße, Byce

 

[bbott]

"Da draußen" dürften schon noch so manche XP 64bit Workstations und Server 2003 sein deren Betreiber lieber die Hardware upgraden würden als die Betriebssysteme.

Wie auch immer, wenn überhaupt noch mal ein Windows auf einen meinen Rechner kommt, dann sicher kein Vista/7/8 ...

Das ist die falsche Einstellung! Die HW ist so teuer das sich der BS Preis kaum noch bemerkbar macht und auch bei den BS hat sich eine Menge getan. Alleine aus Sicherheitssicht lohnt sich ein Upgrade des BS.

Habe vor kurzem jemanden kennen gelernt, der auf XP statt Win7 setzt wegen des RAM Verbrauches! Und das bei <30€ für 8GB?! Die Windows 7 Lizenz bekommt er übrigens im MSDN-AA umsonst. Zusätzlich schaltet der das Menü auf Win2000 oder 98 um, damit er schneller Arbeiten kann. Für mich klingt das einfach nach einem Gewohnheitstier. Diese Einstellung ist in der IT meiner Meinung nach nicht tragfähig, erst recht nicht in so jungen alter wie er. Klar muss man nicht jedem Hype hinterher springen, aber an der alten grauen Win98 GUI festzuhalten

 

[LoRDxRaVeN]

@kalkzone
Ein FX hat 4 Module mit je zwei Kernen. Nur das die zwei Kerne in einem Modul sich die FPU teilen müssen. Entweder kann ein Kern die volle Anbindung von 256bit zur FPU nutzen oder eben jeder Kern eines Moduls 128bit.

Irgendwie durchblicke ich dies noch nicht. Immer wieder kommen Argumentationen, dass bsplw. ein Thuban vor einem Quadmodul-Zambezi liegt (in bestimmten Fällen), da Zambezi nur 4 FPUs hat und Thuban eben deren 6. Aber Thubans FPU ist doch nur 128bit und da kann ja Zambezi seine FPU "teilen" und somit auf sozusagen (im Intel SMT Chargon - Opteron hat diese Art der Teilung als SMT beschrieben) 8 "virtuelle" (128bit) FPUs (bzw. 4 reale FPUs + 4 virtuelle FPUs) zurückgreifen.

Für mein Verständnis passt das nicht zusammen! Könnte man stattdessen vll. sagen, dass es nicht an den FPU-Ausführungseinheiten selbst liegt, sondern z.B. am FP-Scheduler, der ja geshared wird? Oder ist es an einer anderen Stelle zu knapp (Flaschenhals), sodass die zwei 128bit FPUs (FPU-Threads?!) eines Moduls nicht die Leistung erreichen wie zwei (vollwertige) Thuban FPUs?
Oder wäre die Vorstellung richtiger, dass man es ähnlich wie bei Intels HTT sieht, dass der zweite Thread nur ein "Lückenfüller" ist und somit im Maximum nur 20-30% Mehrleistung durch den zweiten Thread ("virtuellen Kern") realistisch sind und eben nicht 100% + (fast) 100%?!

Ich würde mich freuen, wenn mir das jemand erklären könnte, weshalb 4*2 FPUs = 8 von Zambezi weniger sind, also die 6*1 FPUs = 6 von Thuban

LG

 

[Stechpalme]

@Fuddelbaerentatze
Selbst schuld wenn man auf ein OS setzt das veraltet ist und mit aktuellen BS nicht mithalten kann, weder bei der SIcherheit noch sonst irgendwas. Aber dazu hat ja bbott schon alles gesagt.

@LoRDxRaVeN
Der X6 hat für jeden Kern seine eigene FPU

 

[Onkel_Dithmeyer]

@Stechpalme

Das ist korrekt, allerdings kann die BD-FPU 1x256bit- oder 2x128bit-Befehle ausführen. Bei Thuban kann jede FPU nur 1x128bit-Befehl bearbeiten. Ich galube das wolle der Lord uns sagen


edit:
wenn ich mir die geplanten änderungen bei Piledriver angucke, wurde die FPU-load-Queue von 40 auf 44 erhöht. Vielleicht lag da der Flaschenhals.

 

[Stechpalme]

Ich bin grad nicht ganz auf dem Laufenden, aber war die FPU des Thuban nicht trotzdem schneller als wenn beim BD ein Kern (nicht Modul) nur auf die 128 bit greifen kann? Gleicher Takt mal vorrausgesetzt.

 

[Fuddelbaerentatze]

Das ist die falsche Einstellung! Die HW ist so teuer das sich der BS Preis kaum noch bemerkbar macht und auch bei den BS hat sich eine Menge getan. Alleine aus Sicherheitssicht lohnt sich ein Upgrade des BS.

Habe vor kurzem jemanden kennen gelernt, der auf XP statt Win7 setzt wegen des RAM Verbrauches! Und das bei <30€ für 8GB?!

REG ECC unterliegt etwas anderen Preiskategorien ... und dir ist sicherlich klar das es G34 nicht erst seit Bulldozer gibt ...

Und wenn du anführst das BS Kosten zu vernachlässigen sind im Vergleich zur HW, dann denke auch mal darüber nach das da auch Zertifizierungskosten noch dran hängen könnten die für XP schon erbracht sind. Somit müßte nur noch die neue Hardware zertifiziert werden für ein upgrade. Wenn du aber BS und HW tauschst in solchen Systemen dann mußt du beides neu zertifizieren mit entsprechenden Kosten ... und Zertifizierungskosten sprengen den Rahmen von Hardware Upgrades oder Softwarelizenzen gerne mal um ein größeres Vielfaches ...

Die Windows 7 Lizenz bekommt er übrigens im MSDN-AA umsonst. Zusätzlich schaltet der das Menü auf Win2000 oder 98 um, damit er schneller Arbeiten kann. Für mich klingt das einfach nach einem Gewohnheitstier. Diese Einstellung ist in der IT meiner Meinung nach nicht tragfähig, erst recht nicht in so jungen alter wie er. Klar muss man nicht jedem Hype hinterher springen, aber an der alten grauen Win98 GUI festzuhalten

Also ich bin fast 40 und XP läuft bei mir auch im Windows 2000 "Look". Gar nichtmal wegen der gewohnheit sondern weil ich Luna nicht abkann genausowenig wie Aero. Und was die Bedienung angeht, bei Vista/7 fehlt einfach eine frei konfigurierbare Favorietenleiste. Die Sprunglisten und was man da im Kontextmenü der neuen Taskbar anpinnen kann sind da kein adequater Ersatz. Und das bißchen was die einem an Platz für Favoriten/Eigene Orte im Explorer zugestehen in der neuen UI ist einfach ein Witz, zumal man ja auch noch ausschließlich auf Verknüpfungen in den Verzeichnisbaum festgelegt ist (unter XP kann man dort auch jederzeit Verknüpfugnen auf Programme samt Parameter und WSH / Batch Aufrufe ablegen) und das alles obendrein noch in einer flachen Liste, ohne eine eigene Baumstruktur wie sie unter XP problemlos möglich ist. Und so weiter und so fort, es gibt da so manchen Rückschritt in der UI seit Vista/7 und ich könnte noch einiges hier aufzählen, aber ich lasse es denn schließlich sind wir schon reichlich OT.

Wie auch immer, bleibt die Hoffnung das einer der Großkunden von MS mit dem Schuh auf den Tisch klopft ...

 

[bbott]

@Stechpalme

Das ist korrekt, allerdings kann die BD-FPU 1x256bit- oder 2x128bit-Befehle ausführen. Bei Thuban kann jede FPU nur 1x128bit-Befehl bearbeiten. Ich galube das wolle der Lord uns sagen

Das aufteilen ging glaube ich aber unter bestimmten Unständen nicht bzw. bei bestimmten Befehlen, sodass es eben keine vollen FPUs alà 2x128bit sind. Auch können keine zwei Threads je 128bit nutzen sondern nur einer 2x128bit.

Das ist das was mir im Gedächtnis hängen geblieben ist. Ich glaube auch mit Piledriver sollen auch einige Beschränkungen aufgehoben werden.

 

[Opteron]

Heißt das auch, dass der Turbo Modus endlich mal so funktioniert, wie er angedacht ist?

Wohl eher weniger, denn für den Turbo-Mode braucht man 4 Threads auf 2 Module und 2 geparkte Module. Letztere ziehen keinen Strom, weshalb man die ersten beiden höher Takten kann, da mehr TDP Spielraum ist.
Die allermeiste Software läuft aber eh besser, wenn jeder Thread ein volles Modul bekommt. Das ist bekannt, seit es die ersten 4C/4M Tests beim BD Start gab.

Große Preisfrage ist jetzt Software, deren Threads sich Daten teilen, die würden wohl dann vom großen und gemeinsamen L2 profitieren, aber bisher schauts da eher mau aus, sprich ich kenn im Moment keine.

Ich entsinne mich noch dunkel, dass AMD ebenso meinte, dass es eine Leistungssteigerung gibt, wenn zwei von einander abhängige Threads im selben Modul berechnet würden, da dann ja der Umweg über den L3 wegfällt. Dieses "Feature" wird ja durch den Hotfix dann so gut wie nie auftreten - sehe ich das richtig? Ist in die Richtung eventuell etwas geplant?

Siehe Preisfrage oben. Das ist offen und in den Patch-Beschreibungen steht nix davon. Man kann hoffen, dass der Core-Parking Patch was dreht, müßte man halt testen.

Ich bin grad nicht ganz auf dem Laufenden, aber war die FPU des Thuban nicht trotzdem schneller als wenn beim BD ein Kern (nicht Modul) nur auf die 128 bit greifen kann? Gleicher Takt mal vorrausgesetzt.

Jo, denn Thuban hat ne volle FPU mit 3 Pipes (1xMulti, 1xADD und einmal Rest), BD hat zwar 2 FMACs, aber bei 2 Threads kann jeder Thread nur 1xAdd oder 1xMul abschicken. Oder, wenn mans mit nem X6 vergleicht: je 6 ADD und Mul Pipes (also insgesamt 12) stehen 8 FMACs gegenüber. Alles in Allem geht das aber schon relativ gut, so lahm sind die FMACs nicht, meistens reichts doch für nen Gleichstand. Das ist für 8 < 12 gar nicht so schlecht, und mit FMA Code gehts sowieso ab.

 

[TiKu]

Mal ne Frage: Laufen ältere Betriebssysteme wie XP/Server 2003 überhaupt noch auf Bulldozer? Bei den Chipsets hat sich doch kaum was getan seit der 700er Reihe, von der Seite her dürfte es doch keine Probleme geben für NT 5.x. Wie sieht es auf der CPU Seite aus? Bin gerade nicht auf der Höhe der Zeit was MS angeht Lese hier aber immer nur von Scheduler Patches für Windows 7 und mich beschleicht die Befürchtung das XP/2003 keine Scheduler Optimierungen bekommt. Weiß jemand was genaues?

Laufen dürften die Systeme schon noch, aber sie können die Möglichkeiten der Hardware nicht ausnutzen. Der Scheduler von Windows XP skaliert bpsw. ziemlich schlecht (der von Windows 2000 vermutlich noch schlechter). D. h. dass er mit zunehmender Anzahl von CPU-Kernen es immer weniger schafft, die Arbeit optimal auf die Kerne zu verteilen - selbst wenn es genug Arbeit gäbe, alle Kerne auszulasten. Windows Vista und 7 sind da schon deutlich besser.
Beim RAM sieht es nicht anders aus. Windows 2000 und XP verfolgen noch den Ansatz, immer möglichst viel RAM freizuhalten und lagern deshalb vorschnell auf die Festplatte aus. Heutige Rechner haben nicht selten 8 GB RAM oder mehr. Beim normalen Arbeiten wird diese Speichermenge höchst selten mal benötigt. Windows Vista und 7 machen das einzig richtige (das was die meisten anderen Systeme schon seit Ewigkeiten machen): Sie verwenden den RAM intensiv als Dateicache, sodass Zugriffe auf häufiger benötigte Dateien möglichst nicht bis auf die schneckenlangsame Festplatte gehen, sondern nur bis auf den RAM.
Man könnte noch einige weitere solche Dinge anführen. Windows XP ist sicher kein schlechtes System, aber für heutige Rechner einfach ungeeignet.

 

[Stechpalme]

@Opteron
Danke für die Erklärung

 

[Opteron]

Das aufteilen ging glaube ich aber unter bestimmten Unständen nicht bzw. bei bestimmten Befehlen, sodass es eben keine vollen FPUs alà 2x128bit sind. Auch können keine zwei Threads je 128bit nutzen sondern nur einer 2x128bit.

Vom Front-End können pro Takt nur 2 Instruktionen eines Threads angeliefert werden. Die kommen dann aber gleich in die Warteplätzen der FMACs. Da greift dann die OoO Ausführung, d.h. das Ganze wird bunt durchmischt, so wies halt optimal ist. Nachdem AMD die Warteplatzanzahl deutlich vergrößert hat, gibts da jetzt viel mehr Flexibilität und Möglichkeiten. Es können also durchaus 2x128b Instruktionen von 2 Threads parallel berechnet werden.