AMD - AMDs Bulldozer - neue CPU-Architektur für Q2 2011 [Archiv] - Seite 25

Archiv verlassen und diese Seite im Standarddesign anzeigen : AMD - AMDs Bulldozer - neue CPU-Architektur für Q2 2011

Seiten : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 [25]

HOT

2011-10-11, 13:41:11

Quark. Wenn Windoof es für BD total ungünstig die Threads verteilt, wird das auch nur für BD dann schneller, wenn man das ändert.

S940

2011-10-11, 13:45:09

Wegen unter +10%? ...
Dann darfst Du z.B. den 2700K oder sonstige leichte CPU Upgrades auch nicht mehr testen, die paar Mhz mehr Takt liefern auch nicht mehr %te ab.

DavChrFen

2011-10-11, 13:51:30

Kann man da nicht einfach ein total veraltetes Betreibssystem nehmen und dort z.B. Linpack benchen? Wenn man dann die gleiche .exe nimmt und auf einem neuen Betriebssystem testet, und man eine Verschlechterung der Leistung hat, dann sollte man doch einschätzen können, ob es so einen Wunderpatch übehaupt geben kann, oder?

Fabian_HT4U

2011-10-11, 14:04:18

Quark. Wenn Windoof es für BD total ungünstig die Threads verteilt, wird das auch nur für BD dann schneller, wenn man das ändert.
Ob nun der Scheduler von Windows 7 oder der von Windows 8 oder der von XP oder Linux, kein Scheduler ist perfekt. Es gibt stets Kompromisse und weil etwas mit einem Programm gut funktioniert heißt es nicht, dass es mit einem anderen gut gehen muss.

Mal ein Beispiel, um die Komplexität zu verdeutlichen.
Nehmen wir an, wir haben einen Thread A und B, diese sind eng miteinander verknüpft und teilen sich Daten. Also würde man sagen man steckt sie in das gleiche Modul, da gemeinsamer L2-Cache. Nun gibts dann vielleicht das L1-ICache-Problem. Trennt man die Threads auf unterschiedliche Module gibts dann wieder mehr Datenverkehr zwischen den Caches, was auch nicht optimal ist. Weiterhin sind dann mind. zwei Module aktiv, was den Turbo beeinträchtigt, also ist Variante 1, dass beide Threads im gleichen Modul laufen doch die bessere Wahl. Was aber wenn beide nun starken Gebrauch von AVX-Befehlen mit 256 bit Operanden machen? Wäre dann möglicherweise eine Aufteilung auf zwei Module doch wieder besser, da dann die FPUs besser genutzt werden können?

Man sieht, dass es nicht so ganz trivial ist. Und nur weil man den Scheduler vermeintlich verbessert, muss das nicht für alles gut sein.

grüße
Fabian

V2.0

2011-10-11, 14:11:01

naja, wenn sich denn alle an den +10%-patch festklammern...
was mit sicherheit nur in einem fall so sein wird. sonst 3-5% vielleicht.

mit pech, werden die intel-cpus dann auch noch schneller....lol
weil ja auch der scheduler in w8 verändert wurde.
+10% für amd, +15% für intel. (sicher nicht, aber...)

mfg

Zumindest bei den Intel-CPUs mit SMT würde ich es nicht ausschließen wollen, dass die auch messbar zulegen.

S940

2011-10-11, 14:13:09

Alles halb so schlimm mit dem Patch, nach ner gewissen Zeit löst sich das anscheinend von selbst:

Yes, my numbers are accurate... except they only apply for about 20% of the time... or less... the problem apparently irons itself out under sustained load, which is not what I was anticipating when I did my simulations ( yes, simulations - based of scant data, but still... I'm a dork ).

It was something I had entirely dismissed as being likely due to the nature of the patch - changing the memory mapping, going-semi static (security risk) and much more was being done in the patch as I saw it. Not sure what the final patch looks like, just found out about all this parroting of my post (google it - it's freaking CRAZY!) on other forums and came back here to do damage control...
http://www.xtremesystems.org/forums/showthread.php?275786-AMD-FX-8150-Bulldozer-finally-tested&p=4969954&viewfull=1#post4969954
Frage ist, ob das schon für nen kurzen Cinebenchlauf gilt, oder nicht ^^

HOT

2011-10-11, 14:13:51

Ob nun der Scheduler von Windows 7 oder der von Windows 8 oder der von XP oder Linux, kein Scheduler ist perfekt. Es gibt stets Kompromisse und weil etwas mit einem Programm gut funktioniert heißt es nicht, dass es mit einem anderen gut gehen muss.

Mal ein Beispiel, um die Komplexität zu verdeutlichen.
Nehmen wir an, wir haben einen Thread A und B, diese sind eng miteinander verknüpft und teilen sich Daten. Also würde man sagen man steckt sie in das gleiche Modul, da gemeinsamer L2-Cache. Nun gibts dann vielleicht das L1-ICache-Problem. Trennt man die Threads auf unterschiedliche Module gibts dann wieder mehr Datenverkehr zwischen den Caches, was auch nicht optimal ist. Weiterhin sind dann mind. zwei Module aktiv, was den Turbo beeinträchtigt, also ist Variante 1, dass beide Threads im gleichen Modul laufen doch die bessere Wahl. Was aber wenn beide nun starken Gebrauch von AVX-Befehlen mit 256 bit Operanden machen? Wäre dann möglicherweise eine Aufteilung auf zwei Module doch wieder besser, da dann die FPUs besser genutzt werden können?

Man sieht, dass es nicht so ganz trivial ist. Und nur weil man den Scheduler vermeintlich verbessert, muss das nicht für alles gut sein.

grüße
Fabian

Hm, soviele CPU-Architekturen gibts doch garnicht auf dem x86-Markt. Wieso gibts keine Scheduler-Profile, die dann optimiert arbeiten? Dann könnte man das einfach upgraden, wenn eine neue Architektur erscheint und fertig. Irgendwie macht dieser Monsterkompromiss doch garkeinen Sinn oder?

S940

2011-10-11, 14:19:14

Fabian_HT4U

2011-10-11, 14:21:13

Hm, soviele CPU-Architekturen gibts doch garnicht auf dem x86-Markt. Wieso gibts keine Scheduler-Profile, die dann optimiert arbeiten? Dann könnte man das einfach upgraden, wenn eine neue Architektur erscheint und fertig. Irgendwie macht dieser Monsterkompromiss doch garkeinen Sinn oder?
Das Problem sind nicht nur die Architekturen, sondern eben auch die unterschiedlichen Programme. Nur weil etwas mit Programm A gut funktioniert, muss es nicht mit Programm B auch gut gehen. Aus diesem Grund, pinnen manche Programmierer Threads explizit an bestimmte Kerne (natürlich architekturabhängig). Doch ist das natürlich auch nur eine kurze Sichtweise, denn wer weiß schon was morgen kommt.

Um das mal ganz deutlich zu machen. Viele regen sich darüber auf, dass z.B im Cinebench im 1-Thread-Bench ständig der Kern gewechselt wird und damit der Turbo nicht ausgenutzt wird. Pinnt doch mal den Thread an einen Kern. Ich hab das beim Nehalem gemacht, bei Lynnfield und bei Sandy Bridge und in keinem der Fälle ging der Score nach oben.

Was ich damit sagen will, wir sehen aktuell das Problem und vielleicht eine Lösung, diese kann aber mit anderen Dingen kollidieren und stellt daher auf einmal keine Lösung dar. Und am Ende ist der Status Quo vielleicht doch gar nicht so schlecht...

grüße
Fabian

S940

2011-10-11, 14:29:34

Ich hab das beim Nehalem gemacht, bei Lynnfield und bei Sandy Bridge und in keinem der Fälle ging der Score nach oben.
Hmm wieso mit keinem Phenom2? Naja, probiers mal mit Eurem BD mit/ohne Turbo (ich hoffe Ihr habt einen bekommen). Entweder passiert was, oder es passiert nix, in jedem Fall ist die Chose dann gegessen ;-)

Fabian_HT4U

2011-10-11, 14:36:49

Hmm wieso mit keinem Phenom2? Naja, probiers mal mit Eurem BD mit/ohne Turbo (ich hoffe Ihr habt einen bekommen). Entweder passiert was, oder es passiert nix, in jedem Fall ist die Chose dann gegessen ;-)
Der Phenom II hat einen anderen Turbo (3 Kerne dürfen Volllast haben), daher sieht man da mit Cinebench kaum Effekte, selbst wenn der Thread springt. Hier bräuchte man Tools die keine festgepinnten Threads haben, max. 3 Threads haben und stets die CPU so auslasten, dass der Turbo zugeschalten wird. Daher habe ich den Phenom II hier mal außen vor gelassen (Bei Lynnfield/SB gibts ja nen extra 1-Thread-Turbo, und den sieht man eben häufig nicht, die Auslese-Tools zeigen nur schwankende Taktwerte an, bei festgepinntem Thread aber stets den max. Turbo-Takt). Warum AMD sowas net hat, frage ich mich übrigens - denn das bringt in der Windows-Welt imho immer noch ne ganze Menge...

Zum Rest. Kommt Zeit kommt Rat würde ich sagen :wink:

grüße
Fabian

foenfrisur

2011-10-11, 14:41:46

x-dragon

2011-10-11, 14:46:12

Bisher laufen die da auch noch unter unbekannt :)
http://geizhals.at/deutschland/?cat=cpuamdam3&xf=1133_unbekannt#xf_top

S940

2011-10-11, 14:50:31

Bisher laufen die da auch noch unter unbekannt :)
http://geizhals.at/deutschland/?cat=cpuamdam3&xf=1133_unbekannt#xf_top
Naja, 2x halt, unbekannt und AM3+. Ich mach mal ne "Fehlermeldung", dann sollte das in ein paar Stunden gefixt sein ;-)

Ronny145

2011-10-11, 15:00:09

ERSTE listungen bei geizhals

FX-8150 (http://geizhals.at/deutschland/689396)
FX-8120 (http://geizhals.at/deutschland/689394)
FX-6100 (http://geizhals.at/deutschland/689390)
FX-4100 (http://geizhals.at/deutschland/689366)

mfg

Der FX-4100 ist deutlich zu teuer, aber ist sicher normal bei ersten Listungen. Einen deutlich schnelleren X4 965 gibt es ab 100€ (http://geizhals.at/deutschland/476201). Mehr als 60-70€ dürfte der gar nicht kosten.

S940

2011-10-11, 15:02:48

Der FX-4100 ist deutlich zu teuer, aber ist sicher normal bei ersten Listungen. Einen deutlich schnelleren X4 965 gibt es ab 100€ (http://geizhals.at/deutschland/476201). Mehr als 60-70€ dürfte der gar nicht kosten.
Naja, Frühbucheraufschlag... er wird auf das gleiche Niveau absinken, so minus 10-20 Euro sind sicherlich noch drin. Aber dann bleibt halt immer noch der Leistungsunterschied. Naja, wie schon besagt, mein Upgradepfad ist dann trotzdem eher 960T -> BDv2 (in der Hoffnung, dass Rev.C und OS Feintuning was bringt ^^).

Reneeeeeee

2011-10-11, 15:23:50

Ja, eigentlich wollte ich mir ein Bulldozer-System holen. Doch jetzt warte ich auf die zweite Generation. :D

Genau den gleichen Gedankengang hatte ich auch gerade :D

Thunder99

2011-10-11, 16:49:59

Naja, Frühbucheraufschlag... er wird auf das gleiche Niveau absinken, so minus 10-20 Euro sind sicherlich noch drin. Aber dann bleibt halt immer noch der Leistungsunterschied. Naja, wie schon besagt, mein Upgradepfad ist dann trotzdem eher 960T -> BDv2 (in der Hoffnung, dass Rev.C und OS Feintuning was bringt ^^).
Wird bei mir wahrscheinlich ebenso sein.

Anscheinend braucht AMD immer ne Rev. C bis alles so laufen soll wie es geplant war (siehe Ph1 zu Ph2) :rolleyes:

davidzo

2011-10-11, 17:08:07

intel auch: http://vr-zone.com/articles/sandy-bridge-e-should-hit-c2-stepping-after-launch/13677.html

Nur Intel hat durch den Prozessvorsprung mal eben auch locker für ne Rev.C oder sogar D (SB) Zeit.
Bei AMD ist man da einfach zu optimistisch, alles eher mit heißer Nadel zusammengestrickt...
Dass man seit Jahren hinten liegt und nun wirklich gerade kein Geld für neue Ingenieure hat verbessert die Situation nicht gerade.

Botcruscher

2011-10-11, 19:35:35

Intel hat aber die Zeit und was dann im Handel ankommt hat wenigstens Qualität. BD in dem Zustand in den Handel zu bringen ist einfach nur ein Scheitern. Um die Qualität hat man schon lange gewusst. Da hätte man auch einen X6@32nm bringen können. Mich da mit TLB-Bug die Zweite selbst zu zitieren ist da schon unnötig. Was da wirklich kaputt ist wird sich ja zeigen. Wenn AMD es für nötig hält das zu kommunizieren...

boxleitnerb

2011-10-11, 19:48:06

Naja bei Intel läuft dieses Jahr so einiges schief, und das nicht nur bei CPUs. Qualität würde ich da nicht pauschal zu sagen.

Exxtreme

2011-10-11, 20:02:44

Hmmm, Patches vom Patchday sind da. Nichts was auf ein Update für AMD-CPUs hindeutet.

dildo4u

2011-10-11, 20:10:45

Natürlich nicht man sollte nicht jeden Mist aus den Foren glauben.

deekey777

2011-10-11, 20:17:23

Hmmm, Patches vom Patchday sind da. Nichts was auf ein Update für AMD-CPUs hindeutet.
So einen Patch (wenn es so einen gibt) gibt es nicht über Windows-Update, oder?

w0mbat

2011-10-11, 20:31:23

doch, er ist da!!! krass, KB198276830 bringt knappe 20% mehr an performance. OMG!

Knuddelbearli

2011-10-11, 20:32:43

da mach ich mir nichttmal die mühe nachzuschauen ^^

Coda

2011-10-11, 20:34:32

So einen Patch (wenn es so einen gibt) gibt es nicht über Windows-Update, oder?
Service-Pack weil der Kernel modifiziert werden muss.

Thunder99

2011-10-11, 20:35:22

doch, er ist da!!! krass, KB198276830 bringt knappe 20% mehr an performance. OMG!
Sicher? (http://search.microsoft.com/results.aspx?form=MSHOME&mkt=en-us&setlang=en-us&q=KB198276830)

Coda

2011-10-11, 20:39:42

:facepalm:

anddill

2011-10-11, 20:52:04

Wenn sowas kommt, dann bestimmt ähnlich dem CPU-Treiber für XP oder dem Dualcore-Optimizer direkt als "Treiber" von AMD.

Exxtreme

2011-10-11, 21:15:35

So einen Patch (wenn es so einen gibt) gibt es nicht über Windows-Update, oder?
Sowas könnte als ein sog. Hotfix kommen. Den muss man aber von MS separat herunterladen.

foenfrisur

2011-10-11, 21:23:09

deekey777

2011-10-11, 21:26:25

Service-Pack weil der Kernel modifiziert werden muss.
Sowas könnte als ein sog. Hotfix kommen. Den muss man aber von MS separat herunterladen.
Eben. Die Hotfixes, die später mit dem SP 1 für Win7 ausgeliefert wurden, gab's nur per Email.

mapel110

2011-10-11, 21:29:50

Warum soll das gut aussehen?! Für mich sieht das richtig übel aus. In Spielen wird das ein richtiger Fail. Selbst wenn da noch irgendwo 10% hergezaubert werden.

Coda

2011-10-11, 21:34:41

Wenn sowas kommt, dann bestimmt ähnlich dem CPU-Treiber für XP oder dem Dualcore-Optimizer direkt als "Treiber" von AMD.
Nein, das muss tief in das OS vergraben werden, da hilft kein Treiber.

Es hat soweit ich das bisher mitbekommen habe übrigens auch nichts mit dem Scheduler zu tun. Es sieht eher nach der Code-Alignment-Geschichte aus, die auch schon frühere GCC-Patches angezeigt haben:

This patch provides performance tuning for the "Bulldozer" CPU. With its
shared instruction cache there is a chance of generating an excessive
number of cache cross-invalidates when running specific workloads on the
cores of a compute module.

This excessive amount of cross-invalidations can be observed if cache
lines backed by shared physical memory alias in bits [14:12] of their
virtual addresses, as those bits are used for the index generation.

This patch addresses the issue by zeroing out the slice [14:12] of
the file mapping's virtual address at generation time, thus forcing
those bits the same for all mappings of a single shared library across
processes and, in doing so, avoids instruction cache aliases.

Ronny145

2011-10-11, 21:39:02

hier sieht der fx ganz gut aus, aber nicht überragend

http://www.xtremesystems.org/forums/showthread.php?275859-AMD-FX-Benchmarks

Inwiefern ganz gut? Ich kann bislang nur den Durchsatz in Packerbenchmarks als Stärke ausmachen. Die anderen Werte wären ja wunderbar wenn Bulldozer nur 200 mm² groß wäre mit Verbrauch zwischen i5-i7. Bulldozer mit seinen 8 Integer Kernen und Gesamt 315 mm² die size ist 85% größer als SBs CPU part. Was das eigentlich bedeuten müsste, kann sich jeder ausdenken. Ich finde die alte Architektur effizienter. Was wohl mit einem Thuban in 32nm drin wäre? Nur das fehlende AVX+AES wäre störend...

Thunderhit

2011-10-11, 21:39:03

Warum soll das gut aussehen?! Für mich sieht das richtig übel aus. In Spielen wird das ein richtiger Fail. Selbst wenn da noch irgendwo 10% hergezaubert werden.

Kommt auf die Spiele an. Bulli arbeitet doch am besten, wenn alle Cores richtig ausgenutzt werden, was man bei Blender und TechARP deutlich sehen kann. Singlethreaded ist er langsamer, aber reine Singlethreadanwendungen sind doch immer seltener, zumindest bei Spielen.

MR2

2011-10-11, 21:40:39

Na so schlecht sieht das nun wirklich nicht aus, besser als 1100T.
Interessant wäre was ein FX8150P OC nun genau bedeudet.

LovesuckZ

2011-10-11, 21:41:47

Kommt auf die Spiele an. Bulli arbeitet doch am besten, wenn alle Cores richtig ausgenutzt werden, was man bei Blender und TechARP deutlich sehen kann. Singlethreaded ist er langsamer, aber reine Singlethreadanwendungen sind doch immer seltener, zumindest bei Spielen.

Im Vergleich zu SB und Deneb ist alles bis 4, gegen X6 alles bis 6 Threads "Single-Threaded".

mironicus

2011-10-11, 21:43:09

Gut sind eigentlich nur die x264-Werte. Und da soll ja sogar noch Spielraum nach oben sein... (Code-Optimierung für Bulldozer XOP etc.)

Hugo78

2011-10-11, 21:44:40

Wenn es sich morgen wirklich alles so bestätigt wird, was bisher zusehen ist, ist mein Fazit simple.

Hin und wieder trifft "Nomen est Omen" den Punkt.
Die Einen hoften hier auf etwas das "alles platt macht", dass aber wäre dann aber eher ein "Steamroller".
Ein Bulldozer dagegen ist eine spezialisierte Maschine um viel Zeug gleichzeitig weg zuräumen, kein Porsche Cayenne mit Räumschild...

mironicus

2011-10-11, 21:47:41

Kommen die Test wohl wieder so um 6:00 oder schon ab 00:00?

Exxtreme

2011-10-11, 21:54:18

Es hat soweit ich das bisher mitbekommen habe übrigens auch nichts mit dem Scheduler zu tun. Es sieht eher nach der Code-Alignment-Geschichte aus, die auch schon frühere GCC-Patches angezeigt haben:

Wieviel würde das etwa bringen wenn man das Code-Alignment fixt?

Coda

2011-10-11, 21:57:28

Das sind wohl die besprochenen 10% in manchen Fällen.

(del676)

2011-10-11, 22:16:45

Kommen die Test wohl wieder so um 6:00 oder schon ab 00:00?

Hoechstwahrscheinlich 5:01.
Siehe HWLUXX, dort ist der Test schon verlinkt mit genauem Zeitstempel.

http://www.hardwareluxx.de/index.php/artikel/hardware/prozessoren.html

(del676)

2011-10-11, 22:18:19

Warum soll das gut aussehen?! Für mich sieht das richtig übel aus. In Spielen wird das ein richtiger Fail. Selbst wenn da noch irgendwo 10% hergezaubert werden.

Ja, der letzte Bench aus dem XS Forum vertreibt die letzten Hoffnungen auf einen guten Spieleprozessor. Wenn ein i5-2500k ganze 44% schneller ist als der FX-8150 (in 1920x1200!), dann sehe ich da nicht mehr viel Licht.
Aber gottseidank gibts fuer Prozessoren noch viele andere Anwendungsfaelle. ;)

Monkey

2011-10-11, 22:28:39

Mich würd vor allem die Performance unter Photoshop interessieren. Da waren die AMD ja irgendwie nie wirklich Raketen...

Wobei, is eh nur aus interesse, weil ich jetzt wegen der verschieberei nach knapp 10 Jahren wieder nen Intel habe.

Savay

2011-10-12, 00:08:48

die performance beim RAW processing von ACR (LR oder PS ist mir da egal) fände ich wesentlich interessanter...vorallem batch umwandlung. so ne serie mit 400 bilder zu exportieren dauert ja selbst auf nem X6 seine weile...und der ist da kaum (aka garnicht) langsamer als ein 2500k/2600k.

bei den normalen photoshop funktionen sind die unterschiede eh nicht wirklich praxisrelevant...
99% der filter sind aus "gutem grund" ja nichtmal multithreaded...das optimieren lohnt bei einem USM usw. scheinbar nicht
einfach weil es im workflow oftmals kaum eine rolle spielt ob sie in 0,025 oder 0,035s über ein bild laufen. der anspruchvollste der standard filter ist ja auch der entrauschungsfilter....und das ist der einzige der auf mehr als 1 kern läuft :ugly:
insofern finde ich den üblichen retouch artists benchmark zwar informativ aber im grunde ziemlich banane...in der praxis limitiert ja meistens eher der anwender und nicht das system.

wer permanent komplexe scripts über seine bilder laufen lässt hat dann mit nem AMD natürlich pech und für den ist es noch am ehesten interessant...stitching von panoramen, hdr-script usw. (mache ich persönlich aber eh lieber mit anderen programmen)
aber für den reicht auch ein hochtaktender i3...der wird in solchen szenarien wohl kaum langsamer sein als ein gleichwertiger i7/i5...eben weil es lächerlicherweise nur auf einen kern rennt...da wäre ein solches gewaltiges optimierungspotenzial vorhanden das es gradezu ärgerlich ist wie wenig sich adobe darum kümmert. vorallem da grade bei panoramen man schnell ein 80MPix bild vor der nase hat...

GloomY

2011-10-12, 00:15:17

Nein, das muss tief in das OS vergraben werden, da hilft kein Treiber.

Es hat soweit ich das bisher mitbekommen habe übrigens auch nichts mit dem Scheduler zu tun. Es sieht eher nach der Code-Alignment-Geschichte aus, die auch schon frühere GCC-Patches angezeigt haben:
Nein, das hat nichts mit Alignment zu tun. Es geht um Aliasing im Intructions-Cache und die Art und Weise wie Bulldozer in Hardware dieses Aliasing verhindert (indem er nämlich - genau wie K7, K8 und K10 - beim Holen einer neuen Cacheline möglicherweise andere Cachelines verdrängt, wenn diese virtuelle Aliase der gerade neu geholen Cacheline sein könnten.) Dieser HW-Mechanismus ist notwendig für Caches, die virtuell indiziert werden und deren Way-Größe größer ist als die Seitengröße (Bei allen Intel-CPUs sowie K6 und Lano nicht der Fall/notwendig).

(Man muss sich insbesondere klar werden, dass in einem virtuell indiziertem Cache, der es zulässt, dass virtuelle Aliases vorhanden sind, es mehrere Cachelines geben kann, die die gleichen Daten enthalten, weil die zugehörigen virtuellen Addressen auf die gleiche physikalische Addresse abgebildet wird.)

Bulldozer hat - genau wie K7, K8 und K10 - einen 64 kiB großen Instruktionscache mit 64 Byte Cachelines und zweifacher Assoziativität. Er ist virtuell indiziert und physikalisch getaggt. Er ist somit anfällig für virtuelle Aliases.

Mit dieser Konfiguration gibt es für jede Cacheline acht mögliche virtuelle Aliase - also bis zu 7 weitere, die potentiell im Cache sein könnten. Diese insgesamt acht Cacheline-Addressen sind genau solche, die alle 2^3 = 8 möglichen Kombinationen in Addressbits 14 bis 12 enthalten (Addressbits 14 bis 5 werden zur Auswahl des Cache-Satzes mit Hilfe der virtuellen Addresse verwendet und Bits 11 bis 0 sind gleich den physikalischen Bits, da diese sich bei der Übersetzung virtuell->physikalisch nicht ändern).

Wenn K7, K8, K10 oder Bulldozer eine neue Cache-Line in den Cache holen, prüfen diese für die gegebene virtuelle Addresse alle sieben weiteren Cachesätze nach möglichen virtuellen Aliases und schmeißt diese gegebenenfalls aus dem Cache (invalidieren). Dadurch stellt man sicher, dass sich zu keinem Zeitpunkt zwei Cachelines im Cache befinden, die jeweils ein virtuelles Alias der anderen sind.

Bei Bulldozer gibt es aber nur ein Front-End pro Modul, also eins pro zwei CPUs und somit auch nur einen Instruktion-Cache für zwei CPUs. Der Mechanismus, der virtuelle Aliases im Instuction-Cache verhindert, kann aber nun bei "ungünstiger" Platzierung von gemeinsam genutztem Code (Libraries) dazu führen, dass das Holen einer Cacheline für CPU0 eine andere Cacheline invalidiert - nämlich dann, wenn beide echte virtuelle Aliase voneinander sind.

Das ist z.B. der Fall, wenn eine Library gemeinsam genutzt wird, in Addressraum0 an Addresse x und in Addressraum1 an Addresse y beginnt und diese Addressen sich in Addressbits 14 bis 12 unterscheiden. Wenn dann beide Prozesse auf CPU0 und 1 eines Moduls gleichzeitig ausgeführt werden, kann sich jede (physikalische) Cacheline immer nur entweder für CPU0 oder CPU1 - aber nie gleichzeitig - im Cache befinden.
("Für" heißt in diesem Fall, dass pro (physikalischer) Cacheline entweder jene für die virtuelle Addresse in Addressraum0 oder Addressraum1 befindet - diese befinden sich ja an (möglicherweise vollkommen) unterschiedlichen virtuellen Addressen in den beiden Addressräumen).

Ein Cache-Miss von Z.B. CPU0 (und fetchen der entsprechenden Cacheline) führt dann dazu, dass die (gleiche physikalische) Cacheline für CPU1 aus dem Cache fliegt. Der Cache hat beim Zugriff bei CPU0 nicht getroffen, weil sich die virtuelle Addresse für CPU0 und 1 für diese physikalische Addresse unterscheiden. Daher macht man diese genau gleich, indem man die virtuellen (Start-)Addressen für shared Libraries in Bits 14 bis 12 vereinheitlicht (auf Null setzt) und diese damit ins gleiche Cache-Set zwingt.

Das hat zwei positive Auswirkungen auf die Performance:

- gemeinsam genutzte Libraries sind nun nur einmal im Cache (ähnlich wie ein physikalisch indizierter Cache), auch wenn beide Prozessoren im Modul darauf zugreifen. Dadurch erhöht sich die praktische Cache-Kapazität.

- Neue Cacheline-fetches auf Addressen der gemeinsam genutzten Library schmeißen nicht die gleichen Cachelines des anderen Prozessors raus, wenn diese sie schon einmal in den Cache geholt hat.

Sir Integral Wingate Hellsing

2011-10-12, 00:19:50

Gloomy is back :wave:

Passend zum Launch :D

MadManniMan

2011-10-12, 00:22:20

Gloomy is back :wave:

Passend zum Launch :D

Woah :eek:

Ich reib' mir gerade echt die Augen =)

S940

2011-10-12, 00:25:07

Es hat soweit ich das bisher mitbekommen habe übrigens auch nichts mit dem Scheduler zu tunJa das sind 2 Paar Stiefel, nicht mitbekommen?

Außerdem gabs mittlerweile ne Quelle, die sagt, dass sich das Problem "mit der Zeit" selbst lösen solle:

http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8978197#post8978197

Keine Ahnung obs stimmt, kann sich GloomY ja mal angucken, er scheint Ahnung zu haben ;-) An dieser Stelle Danke für die Erklärung.

ciao

Alex

S940

2011-10-12, 00:41:26

hier sieht der fx ganz gut aus, aber nicht überragend

http://www.xtremesystems.org/forums/showthread.php?275859-AMD-FX-Benchmarks

mfg

edit:

das macht mich neugierig:
Frankly speaking, it's performance is not that impressive (especially in terms of single-threaded environment).
...But I have an 'exclusive' justification regarding its single-core (= thread-wise) performance. I'm sure that no other HW site/lab has been dealing with it.

Coming soon!

Bilder sind down, Sicherheitskopie:
http://www.abload.de/thumb/eef9a3dc-bbf9-45ea-bcd2uxj.jpg (http://www.abload.de/image.php?img=eef9a3dc-bbf9-45ea-bcd2uxj.jpg) http://www.abload.de/thumb/ea108883-363f-488f-b58buu3.jpg (http://www.abload.de/image.php?img=ea108883-363f-488f-b58buu3.jpg) http://www.abload.de/thumb/c43a366a-7ef9-4daf-bc35u6m.jpg (http://www.abload.de/image.php?img=c43a366a-7ef9-4daf-bc35u6m.jpg) http://www.abload.de/thumb/42d24b80-2547-42b5-a026u3m.jpg (http://www.abload.de/image.php?img=42d24b80-2547-42b5-a026u3m.jpg) http://www.abload.de/thumb/be9b424b-3683-455a-afbkuwv.jpg (http://www.abload.de/image.php?img=be9b424b-3683-455a-afbkuwv.jpg) http://www.abload.de/thumb/63178eff-b48e-4b3b-83chuqk.jpg (http://www.abload.de/image.php?img=63178eff-b48e-4b3b-83chuqk.jpg) http://www.abload.de/thumb/46291638-672d-4779-afbrui2.jpg (http://www.abload.de/image.php?img=46291638-672d-4779-afbrui2.jpg) http://www.abload.de/thumb/f0de0a67-bcdd-40de-a063uro.jpg (http://www.abload.de/image.php?img=f0de0a67-bcdd-40de-a063uro.jpg) http://www.abload.de/thumb/8dbd68f3-f4b0-4658-83e0uvi.jpg (http://www.abload.de/image.php?img=8dbd68f3-f4b0-4658-83e0uvi.jpg) http://www.abload.de/thumb/7fcb25e5-8546-4d34-b2cmu5s.jpg (http://www.abload.de/image.php?img=7fcb25e5-8546-4d34-b2cmu5s.jpg)

Chrisch

2011-10-12, 00:50:22

Denke der Server ist nen bissel überlastet, bei mir funzen die zumindest alle im XS :)

Sir Integral Wingate Hellsing

2011-10-12, 00:50:34

Bei mir geht die Seite noch... inkl. Pics...

EDIT: http://www.computerbase.de/news/2011-10/interlagos-und-kepler-fuer-den-titan/

Der Jaguar wird zum Titan: Das Oak Ridge National Laboratory (ORNL) des amerikanischen Energieministeriums hat den Supercomputer-Pionier Cray mit der Aufrüstung seines Jaguar XT5 genannten Supercomputers beauftragt, der auf Opteron-Prozessoren von AMD basiert und eine Spitzenleistung von 2,3 Petaflops erreicht.

Innerhalb des nächsten Jahres wird der Supercomputer von einem XT5- zu einem XK6-System hoch gerüstet. Der dann Titan genannte Supercomputer soll, abhängig von der gewählten Konfiguration, eine Spitzenleistung zwischen 10 und 20 Petaflops erreichen. Doch nicht nur die Prozessoren werden ausgetauscht. Zusätzlich erhält das System mehr Speicher, das leistungsfähigere „Gemini“-Netzwerk zum Datenaustausch zwischen den Nodes und GPUs für eine hohe Leistung bei hoch parallelen Berechnungen.

In einer ersten Phase werden dieses Jahr die 6-Kern-Prozessoren gegen AMDs brandneue Opteron-Prozessoren mit 16 Kernen („Interlagos“) ausgetauscht. Pro Node wird statt zwei nur noch ein Prozessor verbaut, die Zahl der Kerne pro Node steigt damit aber dennoch um ein Drittel und erreicht eine Gesamtzahl von 299.008. Damit einher geht auch ein Wechsel der Boards. Durch die Verringerung der Prozessoren pro Node soll die Integration der Tesla-GPUs von Nvidia erleichtert werden. Gleichzeitig werden der Speicher des Systems auf 600 Terabyte erhöht und die ersten 1.000 GPUs der Tesla-20-Serie („Fermi“) implementiert. Dadurch soll den Anwendern die Möglichkeit gegeben werden, ihre Software auf die zusätzliche Nutzung der GPUs hin zu optimieren.

Diese werden in der Mehrzahl im Laufe der zweiten Jahreshälfte 2012 integriert werden. Dann soll das System um 7.000 bis 18.000 GPUs von Nvidias nächster Hardware-Generation „Kepler“ erweitert werden, die den Nutzern ab Anfang 2013 die neue Spitzenleistung von 10 bis 20 Petaflops bereitstellen sollen.

Superheld

2011-10-12, 01:17:41

Interessant wäre was ein FX8150P OC nun genau bedeudet.

schätz der hat 4.5GHz ca, kann man bei Crysis:Warhead bissel rauslesen wenn man mit der Phenom II Taktfrequenz vergleicht.

GloomY

2011-10-12, 02:24:05

Gloomy is back :wave:

Passend zum Launch :D:wave: Ich war eigentlich nur mal wieder da, weil ich ein neues System brauche. :D Ansonsten bleibt auf Grund von Berufstätigkeit nur eingeschränkt Zeit für Anderes.

Außerdem gabs mittlerweile ne Quelle, die sagt, dass sich das Problem "mit der Zeit" selbst lösen solle:

http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8978197#post8978197

Keine Ahnung obs stimmt, kann sich GloomY ja mal anguckenDas ist alles ziemlich wage. Man weiß nicht, was looncraz genau getestet hat. Original hat er gesagt:[...] the problem apparently irons itself out under sustained load [...]

Insgesamt glaube ich ihm aber eher weniger.
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.Nein. Multi-threaded ist nicht das Problem sondern Multi-Prozess mit shared Library ausgeführt auf dem gleichen Modul. Bei Multithreading ist die Library im gleichen Addressraum, wird also auch an die gleiche virtuelle Addresse gemappt. :) Nur wenn die Library in zwei verschiedenen Addressräumen an unterschiedliche virtuelle Addressen gemappt wird, gibt es im L1-I Cache Performance-Probleme.

edit:
Der AMD-Typ, der den Linux Kernel-Patch eingereicht hat, spricht (http://article.gmane.org/gmane.linux.kernel/1172226) von
Up to 3% for a CPU-intensive style benchmark, and it can vary highly in a microbenchmark depending on workload and compiler.

S940

2011-10-12, 02:39:07

Ok Danke, hört sich dann eher "merkwürdig" an.

Ansonsten @topic:
Hier hat wieder mal jemand Fotos des WaKü Setups gepostet:
http://www.xtremesystems.org/forums/showthread.php?265710-AMD-Zambezi-news-info-fans-!&p=4970571&viewfull=1#post4970571

Wenn das wirklich bei nem FX dabei wäre, wärs wirklich ein gutes Angebot, denke ich - trotz aller Haken und Ösen ^^

GloomY

2011-10-12, 02:39:57

Nachtrag: Andere CPU-Mikroarchitekturen haben ähnliche "Probleme" mit virtuellen Aliases bei shared mappings für mehrere Addressräume. Linux hat sogar ein Define (SHMLBA), das jeder CPU-Portierung setzen kann/muss, das den Abstand und das Alignment von Shared memory mappings im Addressraum bestimmt. (siehe: Kernel documentation (http://www.mjmwired.net/kernel/Documentation/cachetlb.txt#229)).

Wobei es dabei nicht nur um Performance geht sondern in erster Line um Korrektheit! D.h. ohne diese Einstellungen liefern die Caches unter Umständen veraltete Daten zurück, weil sie virtuelle Aliase beinhalten. Bulldozer garantiert die Korrektheit in HW, in ungünstigen Fällen aber zu Lasten der Performance.

S940

2011-10-12, 03:20:24

edit:
Der AMD-Typ, der den Linux Kernel-Patch eingereicht hat, spricht (http://article.gmane.org/gmane.linux.kernel/1172226) von
Jo deswegen hab ich den Typen in XS auch gefragt, da er plötzlich von 10% sprach. Naja alles in allem eher zweifelhaft.
Wobei es dabei nicht nur um Performance geht sondern in erster Line um Korrektheit! D.h. ohne diese Einstellungen liefern die Caches unter Umständen veraltete Daten zurück, weil sie virtuelle Aliase beinhalten. Bulldozer garantiert die Korrektheit in HW, in ungünstigen Fällen aber zu Lasten der Performance.Wenn ich mich recht erinnere, dann schrieb ein AMDler im Linux Thread auch, dass BDv2 das Problem eh behebt. Kann aber auch woanders gewesen sein, weiß jetzt nicht mehr genau.

Ansonsten, ein UK Shop ist vorgeprescht und hat die volle AMD FX Special Seite online:

http://www.aria.co.uk/AMDFX

Leider aber immernoch keine Info zur WaKü. Gibt zwar schwarze und weiße Kartons, aber das ist wohl eher 8core und der (teildefekte) Rest. Black Editon steht auch überall drauf. Dachte zuerst, dass AMD vielleicht die Bedeutung auf WaKü geändert hätte - aber ne, wohl eher nicht.

Naja egal in ein paar Minuten wissen wir mehr.

Ich verzieh mich aber jetzt ins Bett.

An die noch Wachen: Gute Nacht.

An die Frühaufsteher: Guten Morgen und viel Spass beim Lesen.

Alex

merfu

2011-10-12, 04:28:57

Es ist jetzt 4:30 und noch nix neues. Ich dreh gleich durch... :freak:

Moin an die Leidensgenossen. :wave2:

Edit: http://ht4u.net/news/24453_erste_haendlerlistungen_zu_amds_bulldozer-prozessoren_scheinen_einen_baldigen_start_zu_bestaet/

USS-VOYAGER

2011-10-12, 04:33:47

Hier ist ein Test.
http://translate.google.de/translate?hl=de&sl=cs&u=http://pctuning.tyden.cz/hardware/procesory-pameti/22227-amd-bulldozer-procesory-fx-8150-a-8120-v-testu-1-2&ei=ePeUTpGVBs-Sswbxmq3lBQ&sa=X&oi=translate&ct=result&resnum=10&ved=0CH0Q7gEwCQ&prev=/search%3Fq%3Damd%2Bfx%26hl%3Dde%26sa%3DX%26biw%3D1024%26bih%3D617%26tbs%3Dqdr:h% 26prmd%3Dimvnsu

merfu

2011-10-12, 04:43:50

Im Mittel kann er sich mit dem X6 messen, bei Multi-Thread 20% schneller und in games wird er meist vom X6 geschlagen.

Sehr durchwachsen. Die Stromverbrauchswerte sehen ganz gut aus und OC um 33% ist auch nicht schlecht.

mFg

USS-VOYAGER

2011-10-12, 06:04:36

Es geht los.

http://www.hardwareluxx.de/index.php/artikel/hardware/prozessoren/20127-bulldozer-amd-fx-8150.html

http://www.pcgameshardware.de/aid,848744/Test-Bulldozer-FX-8150-Gelungenes-Comeback-fuer-AMD/CPU/Test/

http://www.computerbase.de/artikel/prozessoren/2011/test-amd-bulldozer/

merfu

2011-10-12, 06:33:46

Bulldozer Review Thread
http://www.forum-3dcenter.org/vbulletin/showthread.php?p=8979336&posted=1#post8979336