Bulldozer auf Weltreise (BD rollt an Part II)

Status
Für weitere Antworten geschlossen.
Hallo zusammen,

wenn dem so ist könnte man das aber, wenn die Bios der Systemboards es zulassen, doch auch mal gegentesten und CMT abzuschalten. dann sollte sich das Bild doch auch wieder bessern können oder?

lg
 
... die FX4110 Benches @ 4,2 ghz zeigten doch wie gut BD ist.

3DMark Vantage
FX4xxx @ 4,2 17858
Phenom II X4 @ 3,8 14433

Cinebench R11.5 OpenGL Test
FX4xxx @ 4,2 ghz 56,21 fps
Phenom II X4 @ 3,6 ghz 46,56 fps

Tests mit gleicher mhz Anzahl lassen sich ja nicht machen da der Phenom nicht so hoch geht. jedenfalls sieht das doch gut aus.

der FX4xxx ist Dem X4 Deutlich überlegen. und ist noch lange nicht an seinem takt Maximum. Jetzt kommt es nur noch auf den Verbrauch an der zz noch unbekannt ist.
Schon mal daran gedacht, dass der Bulldozer auch auf gleichen Takt heruntergedreht werden kann? ;)

Nur so kann wahrhaftig auch über architektonische Vorteile gesprochen werden. Unzweifelfhaft kristallisiert sich ja heraus, dass der Bulldozer nativ auf hohen Takt ausgelegt ist.

Und leider muss man abwarten wie gut und vor allem wie schnell Microsoft und Linux einen Patch nachschieben, damit das offensichtliche Sheduler-Problem behoben wird. Wenn nicht, kommt mir der Bulldozer wie ein besoffener Weberknecht vor, der immer wieder selbst über die eigenen Beine stolpert - das kanns ja nicht sein!

MFG Bobo(2011)
 
Hat Opteron nicht die Tage ein Paper verlinkt in dem stand dass die Latenzen bei Speicherzugriffen zumindest bei "streaming writes" deutlich länger sein können als bei K10?
Und wo als Hinweis stand dass das erst mit Piledriver behoben wird?

Nebenbei, hat eigentlich mal irgendwer gecheckt ob die diversen API-Erweiterungen bei BD überhaupt genutzt werden in den Einschlägigen Benches?
Wenn da nämlich dusslich abgefragt wird so alla
if (Vendor == intel) {
SSE4-Pfad
} else {
x86/max. SSE2-Pfad
}

Dann liegt unter Umständen einiges des Potenzial brach das BD hätte. Und wofür auch Transistoren geopfert wurden.
Die cache-Werte sehen nach wie vor nicht gut aus.
Und wenn pseudo-Optimierungen angewendet werden, so alla "AMD-Architektur, also 64Kb-Häppchen laden weil die in den L1 passen" - dann haben wir bei BD gleich nochmal den Salat.
Irgendwie ironie, dass nach all den Schelten die Intel gekriegt hat wegen fehlernder Optimierungen für AMD-Architekturen etc. Ausgerechnet jetzt AMD eine Architektur bringt für die manche Intel-Optimierung besser passen dürfte als die für den eigenen Vorgänger *noahnung*

Vielleicht sollte man sich da mal einige Fragen stellen.
Dass die X4er schneller sind als x8er ist nicht uninteressant... allerdings haben die ja auch mehr "Luft" für den Turbo, weil weniger Kerne mitsaufen.
Nebenbei hat das alles wenig mit Trinity zu tun, weil Piledriver mal völlig von der Leistung abgesehen, durchaus weitere Stromsparfeatures beherbergen könnte. Ebenso dürfte der Turbo dort ausgereifter sein als bei Llano und Trinity wird nativ nur 2 Module "mitschleppen" müssen, und keine 4.
Da dürfte Taktratenseitig einiges drin sein, ebenso was den Stromverbrauch betrifft. Und der 32nm-Prozess sollte ja auch eher besser werden als schlechter...
Immer wieder erstaunlich wie schnell doch pauschalisiert und mit der großen Keule draufgehauen wird ohne differenziert und analytisch zu betrachten woran es hapert... Oo
Und nur weil einer nicht das hält was er versprochen hat, ist gleich die ganze Familie verdammt... sicherlich...
Willkommen im Mittelalter... -.-
.
EDIT :
.

Schon mal daran gedacht, dass der Bulldozer auch auf gleichen Takt heruntergedreht werden kann? ;)

Nur so kann wahrhaftig auch über architektonische Vorteile gesprochen werden. Unzweifelfhaft kristallisiert sich ja heraus, dass der Bulldozer nativ auf hohen Takt ausgelegt ist.

Und leider muss man abwarten wie gut und vor allem wie schnell Microsoft und Linux einen Patch nachschieben, damit das offensichtliche Sheduler-Problem behoben wird. Wenn nicht, kommt mir der Bulldozer wie ein besoffener Weberknecht vor, der immer wieder selbst über die eigenen Beine stolpert - das kanns ja nicht sein!

MFG Bobo(2011)
Es kann auch ein Vorteil einer Architektur sein, bei höherem Takt, dennoch weniger Strom zu verbrauchen, was sich dann nicht in besserer IPC, aber dennoch besseren IPW niederschlagen kann *noahnung*
Also ist nicht der Takt entscheidend, sondern die Watt die konsumiert werden.
 
Hat Opteron nicht die Tage ein Paper verlinkt in dem stand dass die Latenzen bei Speicherzugriffen zumindest bei "streaming writes" deutlich länger sein können als bei K10?
Und wo als Hinweis stand dass das erst mit Piledriver behoben wird?
Jo, war in #518, weils so schön war, nochmal:
The following performance caveats apply when using streaming stores on AMD Family 15h cores.
• When writing out a single stream of data sequentially, performance of AMD Family 15h
processors is comparable to previous generations of AMD processors.

• When writing out two streams of data, AMD Family 15h version 1 processors can be up to three
times slower than previous-generation AMD processors. AMD Family 15h version 2 processor
performance is approximately 1.5 times slower than previous AMD processors.

• When writing out four non-temporal streams, AMD Family 15h version 1 can be up to three
times slower than previous AMD processors. AMD Family 15h version 2 processor performance
is comparable to previous AMD processors.

• Using non-temporal stores but not writing out an entire cacheline may cause performance to be up
to six times slower than previous AMD processors.
For more information on write-combining, see Appendix A, “Implementation of Write-Combining.
Nebenbei, hat eigentlich mal irgendwer gecheckt ob die diversen API-Erweiterungen bei BD überhaupt genutzt werden in den Einschlägigen Benches?
Wenn da nämlich dusslich abgefragt wird so alla
if (Vendor == intel) {
SSE4-Pfad
} else {
x86/max. SSE2-Pfad
}
Andere Frage, benützt Cinebench SSE41/42?

Die cache-Werte sehen nach wie vor nicht gut aus.
Naja, von nem WriteThrough Cache kann man nur L2 Write Werte erwarten. Solange die nicht höher ausfallen .. ok.

Und wenn pseudo-Optimierungen angewendet werden, so alla "AMD-Architektur, also 64Kb-Häppchen laden weil die in den L1 passen" - dann haben wir bei BD gleich nochmal den Salat.
Jo, wobei Intelcode optimal laufen sollte, in deren Optimierungsbüchern steht drin, dass man wg. SMT auf 16kB L1D optimieren soll.
Blöd nur, wenn BD bei Cinebench nun trotzdem den AMD Pfad bekommt. Eventuell ist das der Grund, weshalb Cinebench 10 besser läuft, da gabs noch keinen AMD Pfad ;-)

Irgendwie ironie, dass nach all den Schelten die Intel gekriegt hat wegen fehlernder Optimierungen für AMD-Architekturen etc. Ausgerechnet jetzt AMD eine Architektur bringt für die manche Intel-Optimierung besser passen dürfte als die für den eigenen Vorgänger *noahnung*
Lol, genau ;-)


Oo
Und nur weil einer nicht das hält was er versprochen hat, ist gleich die ganze Familie verdammt... sicherlich...
Willkommen im Mittelalter... -.-
Ja sehe ich auch so. Wobei jetzt schon wieder das gerede wg. letzter Piledriverfolie anfängt, die +10% x86 Leistung verspricht. +10% ist auf dem aktuellen Niveau immer noch langsamer als ein K10 :(

Edit:
Nochmal zum Performanceloch:
While the L1D is mostly included in the L2, there are some situations where lines can reside in the L1D without being present in the L2. As a result, the L1D may need to be snooped when another core misses in the L3 cache. This is extremely undesirable, since there will be substantial snoop traffic in a Bulldozer system which will cost both power and performance if the L1D caches must always be snooped by remote cache misses. In Nehalem, the L3 cache is inclusive precisely to eliminate this sort of snoop traffic. It stands to reason that Bulldozer was designed to eliminate snoop traffic to the L1D caches and instead have the L2 cache for each module handle all the coherency snoops for that module. Unfortunately, AMD was unwilling to disclose the precise nature of their coherency protocol at Hot Chips, so we will have to wait to find out more details.
http://www.realworldtech.com/page.cfm?ArticleID=RWT082610181333&p=9
Eventuell hat AMD da nichts enthüllt, da es nichts zu enthüllen gab, und das Snooping echt so besch...eiden ist.
 
Zuletzt bearbeitet:
Immer wieder erstaunlich wie schnell doch pauschalisiert und mit der großen Keule draufgehauen wird ohne differenziert und analytisch zu betrachten woran es hapert... Oo
Und nur weil einer nicht das hält was er versprochen hat, ist gleich die ganze Familie verdammt... sicherlich...
Willkommen im Mittelalter... -.-

Ich denke um das alles differenzert und analytisch zu betrachten sollten wir wirklich noch die Woche abwarten, bis wir alle Informationen haben, die das erst ermöglichen.
Zu diesem Zeitpunkt sieht man nur, dass AMD eine CPU auf den Markt bringen wird, die gigantisch viele Transistoren hat und im Vergleich dazu eine sehr schlechte Leistung. Schlechter sogar als der Vorgänger aus den eigenen Reihen (von ganz wenigen Ausnahmen abgesehen).
Das kann und das wird nicht das sein was AMD sich vorgestellt hat.
Das eventuell ein neues BIOS, eine neue Revision oder eben BD2 da ganz anders aussehen können, davon sollte man fast ausgehen, denn AMD hätte schon längst die Reissleine gezogen, wenn dass die maximal mögliche Leistung des Designs wäre.
 
Also Maxon (Cinebench) schmust natürlich mit Intel im Himmelsbett und nutzt auch den Intel C++ Compiler...

http://software.intel.com/en-us/blo...our-compilers-libraries-and-cluster-toolkits/


Tilo Kühn at Maxon Computer said, “We’ve been enthusiastically using the new version of Intel® C++ Compiler Professional Edition that includes support for Intel® Advanced Vector Extensions (Intel AVX.) Being able to performance tune our software well in advance of processor availability gives us a major development head start to ensure that our Cinebench product will be ready when the first Intel AVX-enabled processor is delivered.”

Aber ob das irgendwelche Flags zum Nachteil von AMD gesetzt werden, wage ich zu bezweifeln (außer den ICC-Flags natürlich... es stellt sich die Frage welche Version benutzt wird, ICC 12 dürfte ja AMD Prozessoren deutlich auf die Sprünge helfen)
.
EDIT :
.

An alle Freunde der verbrennungsmotorbetriebenen Baumaschinen:

Charlies Artikel zur Hot Chips 23 und Bulldozer



http://semiaccurate.com/2011/10/10/exclusive-a-look-at-the-bulldozer-architecture/
.
EDIT :
.

Erste Erkenntnis:


Bulldozer is one of those industry legends, an architecture that has grown far beyond anything the silicon could ever be.

*buck*


*lol*
 
Es brauchen ja auch keine Flags gesetzt zu werden.

Die aktuelle Version des Cinebench wird den BD noch nicht kennnen und erkennt deshalb einfach nur: Oh kein Intel, sondern AMD Prozessor, also nimm den Pfad für AMD.

Im aktuellen Cinebench ist BD auf jeden Fall benachteiligt da nur maximal SSE2 Optimierungen angewendet werden können.
 
Es brauchen ja auch keine Flags gesetzt zu werden.

Die aktuelle Version des Cinebench wird den BD noch nicht kennnen und erkennt deshalb einfach nur: Oh kein Intel, sondern AMD Prozessor, also nimm den Pfad für AMD.

Im aktuellen Cinebench ist BD auf jeden Fall benachteiligt da nur maximal SSE2 Optimierungen angewendet werden können.

Benachteiligt im Vergleich zu Intel ganz sicher, aber nicht im Vergleich zum X6 z.B.

Mich persönlich regt ja am meisten das Abschneiden im Vergleich zum X6 oder X4 auf.
Für mich als X4-Besitzer bedeutet das noch mindestens bis zum Q3 2012 auf BD2 warten oder doch zu Intel zu wechseln. Sehr ärgerlich.
 
BD1 hat keinen Wirklichen Fehler. Und wenn es ein paar Sachen gibt die evtl Optimierbar sind, Führen sie Garantiert nicht zu 50% weniger Verbrauch.



http://www.chip.de/ii/1/1/6/4/9/3/9/0/fusion.desk-31b6e1b992893773.jpg

wie du siehst wird Trinity die Halbe anzahl an BD Cores haben. daher also die Hälfte an Verbrauch.

Im Gegensatz zum BD hat der Trinity aber auch eine halbwegs potente GPU die zusätzlich Strom zieht und eine andere Plattform auf die er aufbaut.

aber die gleiche zahl cores wie llano. also sind die bd cores gegenüber k10 wahre stromsparwunder, oder nicht?
Die gleiche Anzahl an Marketing Kernen, ja aber letztenendes ist es nur noch ein aufgemotzter Dualcore, wenn man sich auf alle Teile des Prozessors bezieht.
Realistisch betrachtet dürfte aber eine Effizienzsteigerung gegenüber den K10 Kernen des Llano kein wirkliches Problem sein....zumindest bei den Desktop Modellen.

Trinity wird nur interessant wenn die CPU Cores 25% schneller als Llano werden.
Und der Nachfolger des SB wenn die GPU um 50-100% schneller wird und das gleiche kann wie die der Konkurrenz?
 
Ja, etwa so lustig wie 'ne Darmspiegelung. :] Na ja, Niveau darf man halt von Intel Trollen nicht erwarten. Lustig ist was anderes. Das ist noch einfallsloser als die ganzen "Hitler ..." Videos.


Muss mal den Punkt von FredD aufreifen, die Write-Werte vom L1 und L2 sind doch beschissen, oder? Und 5,2ns Latenz sind praktisch doppelt so viel wie beim Ph II. Einzig die Read-Werte sind gut.
Yep, der L1 Read Wert passt. L2 passt mMn auch. Man darf diesen nicht mit Intel vergleichen. Intel hat extrem kleine (1/8 von Orochi) und schnelle L2 Caches. Was die Latenz betrifft, da habe ich keine Vergleichswerte. Sie sollte höher sein, aber nicht doppelt so hoch. Es sind 15 Zyklen beim K10 vs 18-20 Zyklen bei Bulldozer. L1 Write und Copy sind mMn totaler Müll. Die sollten mindestens die Hälfte des Read Wertes erreichen. Mittlerweile muss man eigentlich von einem Bug im Design ausgehen. Was für mich nicht sonderlich überraschend wäre, da AMD meines Wissens hier zum ersten auf einen inklusiven Cache setzt. Es wäre jedenfalls ungewöhnlich, wenn ein BIOS oder AIDA Update jetzt noch etwas daran ändern würde.


wie du siehst wird Trinity die Halbe anzahl an BD Cores haben. daher also die Hälfte an Verbrauch.
Emmerdeur meinte etwas anderes, Trinity im Vergleich zu Llano. Und die haben gleich viele "Kerne". IIRC war die Aussage von AMD, dass man die Performance von Llano mit halbierter Leistungsaufnahme liefern kann. Hört sich zwar verwegen an. Da man das aber nicht näher spezifiziert hat, lässt das Spielraum für Spekulationen. CPU Performance? GPU Performance? Kombinierte Performance? Letztendlich bringt Trinity eine Reihe von Veränderungen mit, die im Gesamtpaket schon einiges an Effizienz ausmachen können. 16h (?) vs 12h Kerne, VLIW4 vs VLIW5, reiferes Fusion Design, reiferer Fertigungsprozess, etc. Vielleicht gibt's auch Sachen, die noch gar nicht bekannt sind. Wie die ULK Geschichte beim RevE 6-Kerner, die auch recht überraschend kam.


die info habe ich letzte woche iergentwo im luxx gelesen.

hab sie mal für euch raus gesucht.

CB shows 4.22GHz FX4170 faster than 4.22GHz

http://www.xtremesystems.org/forums...-info-fans-!&p=4967046&viewfull=1#post4967046
Das sind mMn nichts weiter als Messschwankungen, die von System zu System auftreten können. Solange du keinen FX8 Wert auf dem selben System zum Gegenvergleichen hast, ist das doch ein recht dünner Strohhalm. Die 3DMark Vantage und Cinebench OpenGL Werte sind auf die GPU zurückzuführen. Wie schon gesagt wurde, die schlechten Cache Werte sind jedenfalls auch beim FX4 zu beobachten. Das deutet auf ein grundsätzliches Problem im Design hin.
 
Ich hab mal einen Vergleich für euch angefertigt:
Die beiden rechten Screens kommen von hier, der linke von mir.
compareaida3k0x.png


Vorsicht!
Unterschiedlicher RAM und Takt!
 
Kann sich noch einer an den Linux Patch für den gemeinsamen L1I erinnern?
http://www.planet3dnow.de/vbulletin/showthread.php?p=4487776#post4487776

Jetzt schreibt einer, dass es eher 10-20% Einfluß sind, nicht nur ~3%:

Actually, we already have such an issue known for Bulldozer, and NO bench-marked system has the patch installed!

The shared L1 cache is causing cross invalidations across threads so that the prefetch data is incorrect in too many cases and data must be fetched again. The fix is a "simple" memory alignment and (possible)tagging system in the kernel of Windows/Linux.

I reviewed the code for the Linux patch and was astonished by just how little I know of the Linux kernel... lol! In any event, it could easily cost 10% in terms of single threaded performance, possibly more than double that in multi-threaded loads on the same module due to the increased contention and randomness of accesses.

Not sure if ordained reviewers have been given access to the MS patch, but I'd imagine (and hope) so! Last I saw, the Linux kernel patch was still being worked on by AMD (publicly) and Linus was showing some distaste for the method used to address the issue. One comment questioned the performance cost but had received no replies... but you don't go re-working kernel memory mapping for anything less than 5-10%... just not worth it!
http://www.xtremesystems.org/forums...nally-tested&p=4969164&viewfull=1#post4969164

Würde ich jetzt einen BD haben, würde ich meinen Linux Codehacker Freund anrufen und mal nachfragen, ob er schnell den Patch bei nem gentoo etc. einbauen kann und dann ein paar Boinc Programme drauf loslassen ;)
Oder gleich bei AMD in München anrufen ;)
 
Zuletzt bearbeitet:
@Onkel_Dithmeyer:

ja, ist ein recht schlechter Wert, aber das Board hat auch Onboard-Grafik und CL9 RAM.
 
Zuletzt bearbeitet:
Moin erstmal, hier darf und kann man wenigstens noch weiter diskutieren ;)

Kann sich noch einer an den Linux Patch für den gemeinsamen L1I erinnern?

Jetzt schreibt einer, dass es eher 10-20% Einfluß sind, nicht nur ~3%:

Würde ich jetzt einen BD haben, würde ich meinen Linux Codehacker Freund anrufen und mal nachfragen, ob er schnell den Patch bei nem gentoo etc. einbauen kann und dann ein paar Boinc Programme drauf loslassen ;)
Oder gleich bei AMD in München anrufen ;)

Es kommt bei den Performance-Einbußen natürlich stark darauf an, wie relevant der gemeinsam genutzte Cache für die Architektur ist. Für BD ist der gemeinsame L1I ja geradezu grundlegend.

Das könnte erklären, wieso er eben auch bei multithread nicht so glänzen kann wie erhofft.

Mannoman..

wieso ist i denn bei Aida sooo viel besser?

Andere Cache-Architektur (inklusiv, kostet nutzbare Kapazität, bringt aber mehr Durchsatz, weil die Caches nicht aufeinander abgestimmt werden müssen)
 
Zuletzt bearbeitet:
Das gilt für L1 und L2 Cache und konnte gerade bei alter Hardware, bei der man beides im BIOS abschalten konnte, sehr gut demonstriert werden. Beim Abschalten des L2 war der Performanceeinbruch sehr deutlich, beim Abschalten des L1 geradezu katastrophal.

Lang ists her.... :)
 
Also die konspirativen Kräfte arbeiten weiter, vor zwei Tagen wurde auf anandtech diese Aussage von einem "one post wonder" getätigt:

http://forums.anandtech.com/showpost.php?p=32385421&postcount=226

I'm not sure if borked is the right word but it definitely has a performance issue. An AMD engineer I spoke with said it has already been fixed and in the working Trinity APU engineering samples. It just wasn't corrected in time for the Zambezi launch, however it may follow shortly with the next production run when higher clock speed models are released. Bulldozer enhanced core I've seen it referred to as, will offer a few more tweaks before they move on to Piledriver.

Diese Aussage deckt sich ja mit einer, die hier vor einiger Zeit getätigt wurde... aber ich frage mich in wieweit diese Verbesserungen mit neuem stepping, die bis jetzt kolportierten krassen Performanceeinbrüche gegenüber Phenom II beseitigen könnte.

Hinweis:

Bitte gegebenenfalls und je nach gusto "wenn und aber", "jedoch", "unter Umständen" "laut meiner Mutter" einfügen.
 
Da bleibt die Frage, wer soll jetzt noch Bulldozer kaufen? Vor Monaten wurde schon begonnen, Trinity zu bewerben und noch vor dem Launch von BD wurde der Nachfolger angekündigt, mit dem dann "alles besser wird".

Falls davon überhaupt noch viele produziert werden...
 
evtl. hängt die schlechtere Performance vom PhenomII in AIDA auch vom Unganged-Modus ab, vs. Ganged-Modus.

in Sisoftware Sandra jedenfalls bekommt man auch im Unganged-Modus höhere Werte raus.
 
I'm not sure if borked is the right word but it definitely has a performance issue. An AMD engineer I spoke with said it has already been fixed and in the working Trinity APU engineering samples. It just wasn't corrected in time for the Zambezi launch, however it may follow shortly with the next production run when higher clock speed models are released. Bulldozer enhanced core I've seen it referred to as, will offer a few more tweaks before they move on to Piledriver.

Da stellt sich jetzt die Frage, ob es ein C0-Stepping geben wird, das nicht Piledriver heisst sondern "nur" ein gefixter Bulldozer ist.
Ist dann Piledriver D0 oder wird da gleich neu mit dem zählen begonnen?

Ich könnte mir auch vorstellen, dass Trinity z.B. eine deutlich höhere IPC haben wird aus dem Grund heraus, weil Trinity die ganzen Multi-Socket-Snoop-Mechanismen nicht benötigt.
Man hat ja auch gesehen, dass ein Deneb gegenüber einem Shanghai nicht sooo sehr abfällt. Bei Trinity könnten hier "TDP-Reserven" frei werden, die in mehr Takt umgemünzt werden können.

Last not Least:
Im ISSCC-Vortrag hieß es ja auch, dass man Teile des Chips mittels Bibliotheken generieren musste. Hier wird man von Stepping zu Stepping mehr Teile handverdrahten können. Im Endeffekt wird man mit weniger Transistoren die selben Berechnungen tätigen können und dabei kürzere Signallaufzeiten erreichen.
Ich gehe mal davon aus, dass BDver1 noch in zu vielen Bereichen syntetisiert (aus Bibliotheken heraus) entstanden ist. Jetzt,wo die Kuh vom Eis (die Bugs sind ausgemerzt) kann man sich darum kümmern Teile des Transistorbudgets wieder ein zusparen. Dadurch wird man nicht direkt Die-Fläche einsparen,da diese Einsparungen über den gesamten Core hinweg verteilt sind,man wird aber gewisse Hotspots wieder entlasten können und an manchen Stellen die Signallaufzeiten wieder verkleinern können. Vllt. gelingt es ja auch diesen freigewordenen Platz durch ein größeres OoO-Fenster wieder sinnvoll zu nutzen.
 
Ups, das sieht ja gar nicht gut aus.

Bin zwar nicht so fit wie manche hier in Sachen CPU-Designs bzw. Technik, aber die Benches von Donanim Haber lassen schlimmes vermuten. Aber in einerlei Hinsicht hinkt dieser Vergleich: Beide CPUs wurden mit derselben Speicherkonfiguration getestet: DDR3-1866 CL 8. SB unterstützt nativ jedoch nur 1333er meines Wissens. Dennoch dürfte es das ganze auch nicht mehr wirklich rausreissen.

Wie kann man diesen vermuteten Prefetcher-Fehler im Cache sehen. Habe da keine Ahnung: Ist das in etwa mit dem TLB-Bug des Ph1 9x00 zu vergleichen? Wenn es so wäre, würde das doch bedeuten, daß die Architektur an und für sich noch ein enormes Potential hat, welches derzeit nur noch nicht abgerufen wird, oder? Ich selbst habe nen Kumpel, wo noch ein X4 9600BE verbaut ist. Dank des Deaktivieren des TLB-Fixes läuft diese CPU auch heute noch einigermaßen schnell und bis dato absolut fehlerfrei - danke an dieser Stelle an P3D und MusicIsMyLife für die Anleitung dazu :).

Aber wenn es denn beim BD so wäre, dann würde das ja quasi bedeuten, daß man eine fehlerbehaftete CPU launcht. MMn wäre sowas schon eine Riesensauerei. Nun gut, ich warte jetzt erstmal auch den Launch in zwei Tagen und entscheide dann, ob ich mein Sys komplett wechseln werde, oder mein bewährtes AM2+-Board via einem X6 in die Verlängerung schicken werde :).
 
Aber wenn es denn beim BD so wäre, dann würde das ja quasi bedeuten, daß man eine fehlerbehaftete CPU launcht. MMn wäre sowas schon eine Riesensauerei.
Meines Wissens nach gibt es keine fehlerfreie CPU.
Haben alle ihre Makken. Lustig wird es nur, wenn man noch nicht mal ein Errata Sheet vom Hersteller bekommt. Hat uns mal um Wochen im Projekt zurückgeworfen.
 
Zuletzt bearbeitet:
Werde mir den FX-8150 kaufen wenn er verfügbar ist, allein aus dem Grund der neugier wie sich die Performance in laufe der Zeit vielleicht noch ändert mit Bios Updates oder neuen Software Versionen.
Habe auch schon an ein kleines User review gedacht, mit enthalten wäre auch ein Test zwischen AM3 und AM3+ Board. Wenn ich mit dem weniger FPS in Spielen habe als mit meinem PII 945, dann wird er halt so gut es geht untervolted und muss dann zur strafe die nächsten Jahre für P3D in Boinc Punkte holen :D
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben Unten