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

Hab den Link jetzt nicht, war aber bei einem P3D Now Test mit im Fazit.

Ich hatte von 2000 bis 2011 AMD PC´s, bin jetzt auf Intel umgestiegen und bin Froh drum. Wenn ich jetzt vergleiche wie ein Intel System läuft und wie ein AMD. Sag ich nur AMD ist Beta.

Tut mir leid is aber so.

Ich sage dir das Intel kein bisschen besser ist!

Hatten auch einen TBL-Bug,
8MB Bug (SSDs),
SATA III Bug
....
Intel ist mindestens genauso BETA ;)
 
Hatten auch einen TBL-Bug,
Jupp, aber es war 1. nicht der gleiche und 2. kostete das BugFix keine Leistung (SpeicherTransfer... )
Und? AMD hat nich mal SSDs, und andere SSD Hersteller hatten auch ihr Probleme.
Gabs nicht, du meinst wohl Sata II
Ich selber hab hier so ein Board, mit 4 Sata II und 4 (vollfunktionsfähigen) Sata III Ports, die ich auch nutze. Und nun?
 
Ich selber hab hier so ein Board, mit 4 Sata II und 4 (vollfunktionsfähigen) Sata III Ports, die ich auch nutze. Und nun?
bist Du ein auf nem Pulverfass sitzender Glückspilz *lol*

Aber wenns nur BOINC Rechner sind .. ok :)

Mal wieder was zum Thema, ht4u hat getestet, die konnten anscheinend den Patch einspielen:
http://ht4u.net/news/24987_neue_pat...dlich_beschleunigen_-_ergebnisse_sind_durchw/

"Schön" durchwachsen. Teilweise schneller, teilweise langsamer, wenn ich nen BD hätte, würde ich wohl darauf verzichten, die Threads im Zweifelsfall selbst verteilen / pinnen (gibt ja Tools) und fertig.
 
Bisschen zum "Ablollen", daß XP zur Sprache kam, aber niemand sich beschwert, daß es den Patch für Vista nicht gibt. Wo Vista doch die gleichen Vorzüge hat - mit welchen man hier XP schlecht machte - wie Win7. Oder soll es das auch für Vista geben? Mit dem nächsten SP? :D

Die Vorzüge des Schedulers von NT6.x 32bit vs. XPsp3 hat im Netz imho noch keiner mit Zahlen belegen können. Die des neuen TCP/IP-Stacks auch nicht. Und auch wenns bisschen OT ist, ich bin für derartige Links natürlich dankbar.

Zu dem Patch. Man sollte erstmal nicht aus den Augen verlieren, daß der von Ms geschrieben ist und das vorerst auch "nur" v1.0 wäre. Daher fände ich interessant, wenn die Redaktion auch die Ohren dafür offen hält, was die Kernelhacker bei Linux und *BSD dazu basteln. Da ist bestimmt auch noch einiges im Anflug.

Der Patch selbst ist bei Mediacontent (Packen, Coding, Spiele in bereits gestrigen Auflösungen usw.) natürlich enttäuschend. Durchwachsen wäre er, wenn es bei einem Teil wenige Prozent bringen würde und beim Rest KEINEN Minus.
Gut wäre es, wenn es 5% bis 10% bringen würde und beim Rest auch KEINEN Minus.

Ich hoffe AMD hat Ms bei der 1.0 dieses Patches (noch) nicht assistiert. Sonst geht es anscheinend nicht besser und die Geschichte bleibt ein Luftschloß.
 
Zuletzt bearbeitet:
Ich hoffe AMD hat Ms bei der 1.0 dieses Patches (noch) nicht assistiert. Sonst geht es anscheinend nicht besser und die Geschichte bleibt ein Luftschloß.

Nun ich denke schon, dass Amd MS beim Patch assistiert hat, sonst würde der Bulli doch in Windows 8 nicht so gut laufen oder? (Wobei gut laufen auch nur Relativ ist.)
 
Der Clou ist ja, dass man mit dem alten Scheduler kaum durchgehend gleiche Testergebnisse in den Szenarien erzielen kann, in denen der neue Patch hilft.

Wenn HT4U also folgendermaßen Dualcore oder Tripplecore Szenarien testet:

FIFA12
ohne Patch
Szene Y:...Test 1 100 fps, Test 2 110 fps, Test 3 90 fps
mit Patch
Szene Y:...Test 1 105 fps, Test 2 108 fps, Test 3 109 fps

So sah der Testvergleich nämlich auf meinem Bulldozer FX-6 aus. Vergleicht man nun die jeweils besten Werte miteinander, bekommt man 0 % Zuwachs. Leider tritt aber ein Fall von -10% bis -20 % Performance, ohne Patch sehr häufig auf. Insofern könnte man in dem Fall nicht von Nulleffekt sprechen.

Das sollte keine Unterstellung sein, nur ein Hinweis, wie man die Ergebnisse interpretieren kann und die Ergebnisse ausführlicher besprechen könnte. Ich habe da eine Woche dran getestet und HT4U hatte kaum Zeit. Vielleicht ist ihnen die Schwankungsbreite gar nicht so aufgefallen, oder FIFA12 ist ein Sonderfall, oder der Patch funktioniert tatsächlich nicht so gut wie das manuelle Festpinnen.

Zusätzlich muss dann obendrein noch ohne Turbo getestet werden. Denn mir ist aufgefallen, dass 1. der Turbo bis zu 4 % weniger Performance bringt als manuelles Übertakten. Ob dort der Scheduler spinnt, k:A. . Und der FX verbraucht ohne Turbo auch weitaus weniger Energie. Wenn also mit neuem Scheduler ein Test auf 4 Modulen und 4 Kernen läuft, kostet das etwa 10-15 % weniger Energie, als wenn 2 Module unter vollem Turbo werkeln. Insofern wäre auch das ein Vorteil. Manuelles Übertakten auf Turbotakt, spart mit dem Patch Energie und ist schneller. Und am Ende dann bitte noch mit Win8 Beta vergleichen. ;-)

Das gesamte Problem ist nicht mit 10 Benchmarks und einem Vergleich mit dem besten Fall ohne Patch abgehandelt. Das ist im Gegenteil, ein sehr weites Feld. Wie gesagt, keine Kritik, mir ist die Problematik nur erst nach langem Testen klar geworden.

Ergänzung:
Natürlich ist das Testen von Energieverbräuchen bei Spielen eh Quatsch. Messen kann man Unterschiede sowieso nur im CPU Limit. Wenn man also auf der CPU Mehrleistung erzielt (gleicher oder weniger Verbrauch), frisst die GPU gleich wieder mehr, weil sie mehr rendern kann. Geht man aus dem CPU Limit raus, spielt die Perfomance der CPU dann wieder keine Rolle, weil die GPU limitiert.
 
Zuletzt bearbeitet:
Div. getestet (Windows 7, 64-Bit, FX-8120) mit 256-Bit-AVX-Programm ("Apfelmännchen"). Dazu werden ja beide Cores eines Moduls gleichzeitig benötigt, so dass hier die richtige Thread-Zuweisung eine besonders große Rolle spielt.
Ergebnis für 4 Threads (werden im Programm erzeugt, Zahlen sind Millionen Iterationen; wichtig sind die Relationen; Mittelwerte mehrerer Durchläufe):
Threads fest zugewiesen (im Programm, Cores 0, 2, 4, 6):
Ohne Patch : 1.950
Mit Patch (KB2645594) : 1.950
Threads ohne Core-Zuweisung:
Ohne Patch : 1.460
Mit Patch (KB2645594) : 1.550
Reproduzierbar bei mit Patch und ohne feste Zuweisung: Cores 5 und 7 ruhen, aber alle anderen arbeiten. 1 und 3 sollten eigentlich auch ruhen. So bleibt es eben bei 1.550 und keine Chance, die 1.950 zu erreichen.
 
Div. getestet (Windows 7, 64-Bit, FX-8120) mit 256-Bit-AVX-Programm ("Apfelmännchen"). Dazu werden ja beide Cores eines Moduls gleichzeitig benötigt, so dass hier die richtige Thread-Zuweisung eine besonders große Rolle spielt.
Ergebnis für 4 Threads (werden im Programm erzeugt, Zahlen sind Millionen Iterationen; wichtig sind die Relationen; Mittelwerte mehrerer Durchläufe):
Threads fest zugewiesen (im Programm, Cores 0, 2, 4, 6):
Ohne Patch : 1.950
Mit Patch (KB2645594) : 1.950
Threads ohne Core-Zuweisung:
Ohne Patch : 1.460
Mit Patch (KB2645594) : 1.550
Reproduzierbar bei mit Patch und ohne feste Zuweisung: Cores 5 und 7 ruhen, aber alle anderen arbeiten. 1 und 3 sollten eigentlich auch ruhen. So bleibt es eben bei 1.550 und keine Chance, die 1.950 zu erreichen.
CoreParking abschalten, dann sollten die 1950 mit Patch erreichbar sein.
 
Jupp, aber es war 1. nicht der gleiche und 2. kostete das BugFix keine Leistung (SpeicherTransfer... )

Und? AMD hat nich mal SSDs, und andere SSD Hersteller hatten auch ihr Probleme.

Gabs nicht, du meinst wohl Sata II
Ich selber hab hier so ein Board, mit 4 Sata II und 4 (vollfunktionsfähigen) Sata III Ports, die ich auch nutze. Und nun?

1. Der TBL-Bug von AMD war nur für VM relevant, also im Desktop Bereich hätte man volle Performance nutze können. Auch wurde er nur einmal bei x huntert CPUs in freier Wildbahn entdeckt.
Der TBL-Bug von Intel war eigendlich schweigender, scheinbar aber besser Patchbar per BIOS Update.

2. deswegen auch weitere Beispiele... behoben ist der immer noch nicht endgültig, dass ist z.Z. zumindestens mein Kenntnisstand.

3. Wer mit 2 SATA aus kommt... eine HDD, eine SSD und dann? WO mit dem Optischen-Laufwerk oder einer zweiten HDD/SSD hin? Ich komme nicht damit aus und fast alle Bekannte von mir auch nicht.

Ich weiß, du gehörst zu den Leuten, bei denen Intel das darf und AMD nicht.

Das waren nur die letzten die mir eingefallen sind, es waren aber noch deutlich mehr Bugs in letzter Zeit als ich aufgezählt habe.

Achso bevor ich es vergesse, wie sieht es mit dem Thema Intel und Grafik aus? Ich persönlich nenne das Alpha.
 
1. Der TBL-Bug von AMD war nur für VM relevant, also im Desktop Bereich hätte man volle Performance nutze können. Auch wurde er nur einmal bei x huntert CPUs in freier Wildbahn entdeckt.
Der TBL-Bug von Intel war eigendlich schweigender, scheinbar aber besser Patchbar per BIOS Update.
Ich hatte ein AM2 Board mit zwangs-patch im Bios, da gabs nur die frickelmöglichkeit per Software unter Windes den Patch zu deaktivieren. Läßtig!
2. deswegen auch weitere Beispiele... behoben ist der immer noch nicht endgültig, dass ist z.Z. zumindestens mein Kenntnisstand.

3. Wer mit 2 SATA aus kommt... eine HDD, eine SSD und dann? WO mit dem Optischen-Laufwerk oder einer zweiten HDD/SSD hin? Ich komme nicht damit aus und fast alle Bekannte von mir auch nicht.
Deswegen hab ich mir ja auch ein Board mit 4 Sata 2 Ports besorgt, da ich nicht warten wollte 8)
Ich weiß, du gehörst zu den Leuten, bei denen Intel das darf und AMD nicht.
Nö, man muss nur Unterscheiden können, was akzeptabel ist, und was nicht.

Das waren nur die letzten die mir eingefallen sind, es waren aber noch deutlich mehr Bugs in letzter Zeit als ich aufgezählt habe.

Achso bevor ich es vergesse, wie sieht es mit dem Thema Intel und Grafik aus? Ich persönlich nenne das Alpha.
Ursprünglich ging es ja um CPUs, fällt dir da nix mehr ein?
 
bist Du ein auf nem Pulverfass sitzender Glückspilz *lol*

Aber wenns nur BOINC Rechner sind .. ok :)

Mal wieder was zum Thema, ht4u hat getestet, die konnten anscheinend den Patch einspielen:
http://ht4u.net/news/24987_neue_pat...dlich_beschleunigen_-_ergebnisse_sind_durchw/

"Schön" durchwachsen. Teilweise schneller, teilweise langsamer, wenn ich nen BD hätte, würde ich wohl darauf verzichten, die Threads im Zweifelsfall selbst verteilen / pinnen (gibt ja Tools) und fertig.
Hm warum haben die den V2 Patch genutzt ich hab folgende Datei bekommen via Email: Windows6.1-KB2646060-v3-x64

Jetzt noch warten bis der hotfix offiziell wird dann kann getestet werden.
Im Anhang mal AIDA64 AES Bench mit aktivem HPC, Turbo & C6

*lol*
 
Zuletzt bearbeitet:
@ windhund lad mal die beta
da is schon nen fx 6100 zum vergleich drin der kommt auf
CPU CPU Takt Motherboard Chipsatz Speicher CL-RCD-RP-RAS Note
6x FX-6100 3300 MHz Asus Sabertooth 990FX AMD990FX Dual DDR3-1866 9-9-9-24 CR1 356995
 
@sush
Danke, jetzt schaltet er auch nicht mehr auf die 4,2GHz hoch.
Es ist aber nicht viel mehr, klar wenn max. 4 Kerne genutzt werden. ;)
 
Zuletzt bearbeitet:
Ich hatte von 2000 bis 2011 AMD PC´s, bin jetzt auf Intel umgestiegen und bin Froh drum. Wenn ich jetzt vergleiche wie ein Intel System läuft und wie ein AMD. Sag ich nur AMD ist Beta.

Wir haben in unserem Unternehmen ein sehr heterogenes Rechnerumfeld. Die Erfahrungen haben gezeigt, dass man mit AMD und Intel Probleme haben kann. Das was man AMD eventuell anlasten kann ist die Schwäche bei der Zusammenarbeit mit ISVs. Wir hatten z.B. mit VMWare in Zusammenhang mit gewissen Client-Betriebssystemen und AMD Plattformen Probleme (Speicher). Die genaue Ursache konnte nie geklärt werden. Eventuell war auch nicht der Prozessor sondern der Mainboardchipsatz schuld (Nvidia).
 
Ich sag jetzt einfach mal es war der Chipsatz.
[rant]
Nividia hat soviel Bockmist mit ihren scheiß Chipsätzen getrieben, sodass ich froh bin nie wieder einen dieser Verunstaltungen in meinem System begrüßen zu müssen. Danke nochmal, dass du, Nvidia, aus dem Chipsatzmarkt herauskomplimentiert wurdest. Danke.[/rant]
 
Ich sag jetzt einfach mal es war der Chipsatz.
[rant]
Nividia hat soviel Bockmist mit ihren scheiß Chipsätzen getrieben, sodass ich froh bin nie wieder einen dieser Verunstaltungen in meinem System begrüßen zu müssen. Danke nochmal, dass du, Nvidia, aus dem Chipsatzmarkt herauskomplimentiert wurdest. Danke.[/rant]


Also ich hatte mit den Nvidia Chipsätzen nicht mehr Probleme als mit den Amd Chipsätzen.
Finde es schade dass Nvidia keine Chipsätze für Amd Systeme mehr entwickelt.
 
Leute der Winter war zwar noch nicht hier, aber haben wir denn schon das Sommerloch? Nvidia, XP, TBL-Bug, SATA... Pathologische Redezwänge?

Was ist jetzt mit Win8? Rennt da der Bulli besser als unter dem gepatchten Win7sp1? Und wenn ja, warum das denn? Und überhaupt, laut welchen Tests und wo sind die zu finden?

Den Pat mit der v3 und v4 irgendeines Patches check ich grad nicht. Was geht da ab? Oder war das ein Teil eines Chats der durch Datenbankbugs seinen Weg bis hierhin gefunden hat?

Bis dann mal.

p.s.:
Das von Helle53 gefällt mir. Da sieht man, daß der Patch noch nicht die nötigen Skills hat um erwähnenswert zu sein. Dafür aber einige real life Prozesse wie bei HT4U gezeigt noch tiefer ins Verderben zu reißen. Auch v2 also völliger Mumpitz. Nochmal an die Schreibtische, Ms/AMD. Diesmal richtig bitte.
 
Zuletzt bearbeitet:
Die neuen AMD Prozessoren teilen sich nicht nur eine FPU pro Modul, sie teilen sich auch einen ordentlichen Happen der dem Modul vorgeschalteten Arbitrationslogik (Prefetcher, Level 2 Cache, etc.). Würde genau diese mit 100%iger Effizienz arbeiten, müßten in nahezu allen Anwendungen, die lediglich SSE-Code ausführen (und damit 128bit und nicht 256bit wie bei AVX Erweiterungen), eine Leistungssteigerung in 100%ig skalierenden Anwendungen von 100% erfahren. Daß das nicht der Fall ist und bei akruellen Paradigmen nicht realisierbar ist, hat Amdahl bereits quantifiziert. AMD gab bereits im Vorfeld der Bulldozer-Einführung an, daß man ca. 20% unterhalb der Leistungssteigerung einer echten doppelten Kernausführung mit der Modulausführung zu liegen käme. Hier obsiegen wohl die Kosten der Produktion, also Die-Fläche und Entwicklungs-/Produktionsaufwand.

Die Leistungsgewinne durch den "Patch" sind an sich, was man bislang sehen konnte, doch recht manierlich, geben sie doch Durchschnitsswerte ab. Warum nicht unter UNIX oder Linux testen, dort sind diese Makulaturen der Scheduler wesentlich schneller gelöst und vor allem auch noch nachvollziehbar offen im Quelltext vorhanden. Auch dort, also konkret unter Linux oder BSD UNIX, sind die Leistungssteigerungen vergleichbar mit den Windoof Patches. Wenn in einigen Extremanwendungen bis zu 15% herausgeschlagen werden können, reflektiert das einen guten Schnitt - meiner Meinung. Denn nicht alle Code Abschnitte sind parallelisierbar, so daß wir wiederum Amdahl bemühen müssen/müßten, um es zu verstehen.

Ich werde zunehmend an das Kasperletheater von der "Speicherverdoppelung" durch Software erinnert. Was sich bei diesen "Optimierungsorgien" letztlich klar herauskristallisiert ist, daß die BD-Architektur nicht das ist, was sie eigentlich versprach. Im Vergleich zur Konkurrenz bewahrheitet sich dieses Faktum leider wieder in für AMD eher leicht katastrophalen Form. Aber peinlich wird es, wenn man die Methusalem K10.5-Architekturen der Phenom-II Generation in die Vergleiche mit hinzuzieht, die mit 6 Kernen operieren.
Da AMD den eher für Juristen und Wirtschaftler winkeladvokatischen PR-Gag "Modul" und "Kern" zu verwässern sucht und sich Fanboys jetzt aussuchen dürfen, ob sie einen 4-Kern Konkurrenten gegen einen 4-Modul Konkurrenten antreten lassen, je nach gusto, gibt es den noch ehrlicheren Vergleich über Preis und Leistung. Was bietet AMD, was der Konkurrent, wie sieht auf diesem Level der Verbrauch und die Effektivleistung aus bei genau definierten Testmethoden. Bislang hat mich AMD in keinem Punkt überzeugen können und all die wahnwitzigen Optimierungsunterfangen haben mitlerweile einen beschämend-belustigenden Charakter. Wiederbelebungsversuche eines Mythos ...
 
Also - ich als AMD Starter (486 DX4/100), dann Intel Nutzer bis zum c2q 9550 habe nun einen Bulldozer 8120. Normale Büroarbeit, hin und wieder mal nen Film umrechnen und Battlefield 3 sind meine Anwendungsbereiche. Die Leistung des Bulldozers, mit oder ohne Patch, empfinde ich als mehr als ausreichend. Alle meine Kerne laufen auf 4050 MHz, kein Turbomodus, kein c1, c6 oder c&q.
Ich hatte vor dem Patch einen kompletten AIDA64 Benchmark laufen lassen und jetzt gerade, nach dem Patch noch einen:
VOR NACH
Speicher lesen: 15386 15075 MB/s

Speicher schreiben: 10559 10795 MB/s

Speicher kopieren: 18807 19038 MB/s

Speicherverzögerung: 46,3ns 46,5ns

CPU Queen: 34542 34650

CPU Photoworxx: 56682 55495

CPU ZLib 294,2 294,2 MB/s

CPU AES 409242 396778

CPU Hash 4114 4119 MB/s

CPU VP8 2961 2832

FPU Julia 13120 13305

FPU Mandel 6710 6703

FPU SinJulia 2806 2835

Ich sehe im Patch keine gewaltigen Abweichungen - aber für Systeme wie meins ist der Patch ja wohl auch nicht so gut geeignet. Wie auch immer, der Bulldozer ist eine schnelle CPU und ich halte das "Modul-System" für durchaus innovativ. AMD war schon immer der Underdog und sie haben bestimmt auch ihre Fehler gemacht, was aber nichts daran ändert, ich kann mit dem Bulldozer super zocken, meine 6970er Graka is immer auf 100% und der Bulldozer zwischen 40 und 60%.
Mit dem Bulldozer kann ich nebenher ne Bluray in ein MKV umwandeln und noch immer zocken - was will ich mehr? Also mir reicht er und beim Zocken gucke ich nicht auf den Stromverbrauch meiner Büchse ... ;)

cheers,

jack

Edit:

CineBench 11.5 64bit
Vorher: 6.6
Nachher: 6.07

WinRAR 4.01 64bit
Vorher: ~4000 KB/s
Nachher: ~3800 KB/s
 
Zuletzt bearbeitet:
Mit dem Bulldozer kann ich nebenher ne Bluray in ein MKV umwandeln und noch immer zocken - was will ich mehr?
Das liegt nicht am Bully sondern am Multitasking Betriebssystem ;) Man muss nur die Prioritäten richtig setzen, dann geht das auch mit einem X2 [nur das das Umwandeln dann ewig dauert *buck*]
 
Zurück
Oben Unten