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

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*]

und mit nem x2 wäre meine GraKa nur bei ~40% Auslastung und mein BF3 würde ruckeln - hab ich durch, hatte vorher nen x2 240 @3500 - die Werte sind ohne Hintergrundtask "Bluray wandeln". ;)
 
Zuletzt bearbeitet:
@jackd7: Ein altbekanntes Phänome - Produkttreue. Das nutzen Unternehmen auch weidlich aus bzw. das ist auch gut so, denn Stammkundschaft ist in vielen Bereichen des täglichen Lebens und Wirtschaftens überlebenswichtig. Und wenn es sich letztlich nur auf Bequemlichkeit zurückführen läßt.

Früher gab es viele Krankheiten, Pest, Cholera, Blattern, Pocken ... heute ist es nur noch AIDS, in vielen Mutationsformen, aber immer die gleiche Seuche. Heutige Generationen können sich kaum noch etwas anderes und schlimmeres als AIDS vorstellen, Pocken und Pest sind seit Jahrzehnten so gut wie eingedämmt. Und so verlieren sich die Vergleichsmöglichkeiten.
Früher, da gab es 64Bit RISC Prozessoren auf gewaltigen Plattformen. Vor rund 20 Jahren gabs letztlich bereits all das, was wir heute runderneuert sehen, nur eben langsamer und stromfressender. Heute gibt es nur noch eine Seuche - und die heißt Intel-kompatibel. Es ist müßig sich mit Fußvolk und Pubertierenden über Vor- und Nachteile der verkorksten x86-Abkömmlinge auseinanderzusetzen und es wird immer schwieriger, weil immer weniger die älteren RISC Architekturen kennen.

Es ist heute einfach albern, sich als Fanboy zu outen. Der Intel x86-Müll ist genauso kompatibel wie der aus dem Hause AMD. Die monokulturelle "Standardsoftware" läuft auf beiden CPUs. Es ist egal, welcher Seuche man sich hingibt. Bei AMD war es zur Zeit des ersten Opteron noch möglich, ECC auch auf den Heimplattformen zum Einsatz zu bringen und das Angebot an guten servertauglichen Chipsätzen auf UP-Sockelsystemen, die auch als Workstation dienen konnten, war üppig. Da griff man dann gerne zu den HIV Typ IV Vieren, hatten die HIV Typ III Viren doch weniger zu bieten. Nun ja, der Vergleich mit der Seuche ist vielleicht ein bißchen zu scharf, aber er macht mir deutlich, daß es letztlich egal ist. AMD bietet mir auf lange Sicht nicht (mehr) die Hardware, die ich haben will! Beim Konkurrenten zahle ich ein bißchen mehr, erhalte aber solides Material - das stimmt zwar infolge einer Ermangelung eines ernsten Konkurrenten nicht mehr generell (siehe Intels kastrierten Chipsätze der X79-Generation), aber dennoch ist das Rundumzufriedenpaket bei Chipzilla leichter einzukaufen als bei AMD. AMD laboriert immer noch an einem vernünftigen Serverchipsatz, Leistungsaufnahme und Leistung der BD-Kern getriebenen Prozessoren haben alle Negativrekorde gebrochen, die es zu brechen gab. Eine Klasse für sich ...
 
@jackd7: Ein altbekanntes Phänome - Produkttreue. Das nutzen Unternehmen auch weidlich aus bzw. das ist auch gut so, denn Stammkundschaft ist in vielen Bereichen des täglichen Lebens und Wirtschaftens überlebenswichtig. Und wenn es sich letztlich nur auf Bequemlichkeit zurückführen läßt.

[...]

Es ist müßig sich mit Fußvolk und Pubertierenden über Vor- und Nachteile der verkorksten x86-Abkömmlinge auseinanderzusetzen und es wird immer schwieriger, weil immer weniger die älteren RISC Architekturen kennen.

Es ist heute einfach albern, sich als Fanboy zu outen.

[...]

AMD laboriert immer noch an einem vernünftigen Serverchipsatz, Leistungsaufnahme und Leistung der BD-Kern getriebenen Prozessoren haben alle Negativrekorde gebrochen, die es zu brechen gab. Eine Klasse für sich ...

oh ja, stimmt, durch meine extreme Produkttreue kehre ich nun nach 15 oder 20 Jahren zu AMD zurück und mutiere direkt zum AMD-MEGA-Fanboy weil ich einen Bulldozer habe und ihn nicht super schlecht finde ... ja, ne, is kla ;)

Da pubertierend auf mich nicht mehr zutreffen kann bin ich dann wohl Fußvolk für Dich, sei es drum, wenn es Dich fröhlich stimmt Menschen die potentiell anderer Meinung sind wie Du durch solche Äußerungen herabsetzen zu müssen spricht das ja unbedingt für Deine hohe Kompetenz 8)

Les Dich mal schlau was eine RISC-Architektur ist und wo die heute so verbaut sein könnte - du kannst auch heutige Maschinen an einer tollen CL laufen lassen, dann kannst Du auch nen DECnet simulieren und Dich wie früher fühlen - ist dann nur nicht so bunt ...

In dem Sinne,

der AMD-Mega-Fanboy der seit 15 oder 20 Jahren wieder seinen ersten AMD hat ;)

cheers,

jack
 
Zum Vergleich habe ich mein Testprogramm mal auf einem Intel i7-2600 (3.4GHz, Win7, 64-Bit) laufen lassen (natürlich ohne irgendeinen speziellen Patch):
4 Threads, auf Cores 0, 2, 4 und 6 festgenagelt: 3.250 Millionen Iterationen/s.
4 Threads, nichts festgenagelt: 3.250 Millionen Iterationen/s.
Beim Intel ist kein Unterschied festzustellen! Aber interessant beim nicht festnageln : Auch hier schlummern Cores 5 und 7, der Rest ackert.
Nebenbei: Auf 8 Threads verteilt sind (natürlich) für jeden Prozi die Ergebnisse gleich (festgenagelt oder nicht), aber:
FX-8120: 1980 Millionen Iterationen/s.
i7-2600: 5470 Millionen Iterationen/s.
OT: AVX 256-Bit ist eine Schwachstelle vom BD.
 
@Helle53
Hast du ein Link zu deinem Apfelmännchen Benchmark?
Was genau wolltest du mit dem Benchmark testen?
Wurde der Bench für den BD recompiliert, das ist nötig um AVX mit 256Bit zu nutzen. ;)
 
@WindHund:
Der AVX-Teil (256-Bit) des Test-Programmes ist von mir komplett in Assembler (FAsm) geschrieben. Für Bildschirm-Ausgabe usw. nutze ich hier PureBasic; könnte aber auch sonstwas sein. Getestet werden soll natürlich die Thread-Verteilung von Win7. Unter 'http://www.mdcc-fun.de/k.helbing/Bulldozer/Bulldozer.zip' habe ich eine ZIP-Datei abgelegt, die 6 Dateien enthält: 3x Exe; für 8 und 4 Cores nicht festgepinnt sowie 4 Cores festgepinnt (0,2,4,6). Weiterhin 3x der jeweilige Source-Code, der lässt sich z.B. auch mit Wordpad lesen.
Die Exe benötigt Win7 64-Bit mit SP1 (wegen der 256-Bit-AVX-Register).
Der maximale AVX-Durchsatz ergibt sich im schwarzen Bereich (hier wird max.iteriert). Also einfach den Mauszeiger in etwa auf Koordinaten 0,0 ziehen und linke Maustaste gedrückt halten.
Gruß
Helle
 
... Beim Intel ist kein Unterschied festzustellen! Aber interessant beim nicht festnageln : Auch hier schlummern Cores 5 und 7, der Rest ackert.
Nebenbei: Auf 8 Threads verteilt sind (natürlich) für jeden Prozi die Ergebnisse gleich (festgenagelt oder nicht), aber:
FX-8120: 1980 Millionen Iterationen/s.
i7-2600: 5470 Millionen Iterationen/s.
OT: AVX 256-Bit ist eine Schwachstelle vom BD.
Für die Leser hier im Forum:

AMDs Bulldozer hat lediglich nur eine AVX-Einheit, während SandyBridge schon zwei davon an Bord hat.

MFG Bobo(2012)
 
Für die Leser hier im Forum:

AMDs Bulldozer hat lediglich nur eine AVX-Einheit, während SandyBridge schon zwei davon an Bord hat.
Jein ... um Mißverständnisse vorzubeugen muss man da immer auch ins Detail gehen, v.a. da er ja selbst codet. Sandy hat

1x 256b ADD und
1x 256b MUL

BD hat
2x 128b FMAC Units.

Sandy kann pro FPU je einen MUL und ADD BeEfehle durchschleußen, egal ob 128 oder 256b.
BD kann pro Takt 2x 128b ADD oder 2x 128b MUL oder 2x 128b FMA, aber auch (mit 2-3% Verlust) 1x256b ADD/MUL/FMA. Verwendet man kein FMA, was offiziell bei AVX ja nicht dabei ist, kommt beim BD nur 50% theoretische Leistung raus. Mit FMA hätte man Gleichstand. Kommt halt dann konkret darauf an, ob man FMA in seinem Code brauchen kann oder nicht oder bzw. ob man sich überhaupt die Mühe machen will AMD-Instruktionen zu verwenden, die bei Intels nicht laufen.
 
... Sandy hat

1x 256b ADD und
1x 256b MUL

BD hat
2x 128b FMAC Units. ...
Soooo viele Worte - obgleich du selbst es schon auf den Punkt gebracht hast.

AMD hat die FPU aufgebohrt - das ist wahr - zu dumm nur, dass damit die 128 Bit breite Einheit (einstmals als SSE5 - wie du damals ja schon selbst geschrieben hattest) Grundlage dazu war.

AVX ist nativ auf bis zu 256 Bit breite Datenworte ausgelegt. Erschwerend kommt hinzu, dass Intel zuerst und vor allem in deutlich höherer Verbreitung mit Ihrer Auslegung von AVX am Markt war und ist.

MFG Bobo(2012)
 
AVX ist nativ auf bis zu 256 Bit breite Datenworte ausgelegt. Erschwerend kommt hinzu, dass Intel zuerst und vor allem in deutlich höherer Verbreitung mit Ihrer Auslegung von AVX am Markt war und ist.
Hehe, da muss ich jetzt nochmal Erbsenzählen :) Das "nativ" würde ich so nicht schreiben. Ne Implementierung kann "nativ" sein, aber ein Instruktions-Standard nicht ;-)

Wenn Du also magst, dann ist Sandys AVX Implementierung nativ, aber nicht AMDs ;-)

Wobei dann aber doch (schon wieder) die Frage aufkommt, was man damit eigentlich meint. Die CPUs beider Hersteller verstehen die AVX Befehle und können 256bit in einem Rutsch bearbeiten.
Im Endeffekt muss man dann da auch wieder konkret werden und sagen was Sache ist, da es ansonsten zu schwammig bleibt.

Hab gerade den Apfelmännchenalgo angeschaut, ist recht simpel und es gibt da ne Quadratfunktion (also Multiplikation), die bei komplexen Zahlen auch noch ne Addition / Substraktion beinhaltet, da könnte man also nen FMA Befehl nutzen. Ist aber nicht ganz optimal, da das - was addiert / substrahiert wird - selbst auch noch das Ergebnis einer Multiplikation ist, die kann man dann nicht einsparen, aber man sollte von ca. 50% auf vielleicht 75% theoretischer Intel-Leistung kommen.

Hauptalgo (Multiplikation komplx. Zahlen) ist:
z1 * z2 := (x1*x2 – y1*y2 l x1*y2 + x2*y1)

Also je 2x Multiplikation und dann daraus ne Addition. Das kann man auch mit 1x Mul und 1xFMA machen.
 
Das der BD für 256-Bit-AVX beide Cores eines Moduls benötigt hatte ich ja schon geschrieben. Da ist SB natürlich im Vorteil.
Ich habe in meinem Code mal
VMULPD ymm3,ymm3,ymm4 //AVX
VADDPD ymm3,ymm3,ymm3 //AVX
VADDPD ymm3,ymm3,ymm2 //AVX
duch
VADDPD ymm3,ymm3,ymm3 //AVX
VFMADDPD ymm3,ymm3,ymm4,ymm2 //FMA
ersetzt, aber der große Bringer ist es nicht (habe auf die Schnelle keine weitere sinnvolle Änderungs-Stelle gefunden). Das Problem ist nicht nur die halbe Anzahl 256-Bit-AVX-Einheiten (gegenüber SB), sondern auch die z.T. doppelten Ausführungszeiten (Latency) der 256-Bit-AVX-Instruktionen (geschuldet dem "Zusammenbacken" der Cores?). Für Addition und Subtraktion benötigt BD 6 Taktzyklen, SB nur 3; für simples Registerladen BD 2, SB nur 1. Bei der Multiplikation hält es sich in Grenzen: BD 6, SB 5.
Ich hoffe, das Ganze ist nicht zu Off Topic!
 
... Das Problem ist nicht nur die halbe Anzahl 256-Bit-AVX-Einheiten (gegenüber SB), sondern auch die z.T. doppelten Ausführungszeiten (Latency) der 256-Bit-AVX-Instruktionen (geschuldet dem "Zusammenbacken" der Cores?). Für Addition und Subtraktion benötigt BD 6 Taktzyklen, SB nur 3; für simples Registerladen BD 2, SB nur 1. Bei der Multiplikation hält es sich in Grenzen: BD 6, SB 5.
Ich hoffe, das Ganze ist nicht zu Off Topic!
Nö, nö - das passt schon.

Insbesondere bei den Latenzen erwarte ich eine Verbesserung beim Pillendreher-Kern ... so viel Erbsenzählerei und Spekulatius darf schon sein ;)

MFG Bobo(2012)
 
Und interessant ist es auch noch bei euch mitzulesen. ;D
 
Das der BD für 256-Bit-AVX beide Cores eines Moduls benötigt hatte ich ja schon geschrieben. Da ist SB natürlich im Vorteil.
Ich habe in meinem Code mal
VMULPD ymm3,ymm3,ymm4 //AVX
VADDPD ymm3,ymm3,ymm3 //AVX
VADDPD ymm3,ymm3,ymm2 //AVX
duch
VADDPD ymm3,ymm3,ymm3 //AVX
VFMADDPD ymm3,ymm3,ymm4,ymm2 //FMA
ersetzt, aber der große Bringer ist es nicht (habe auf die Schnelle keine weitere sinnvolle Änderungs-Stelle gefunden). Das Problem ist nicht nur die halbe Anzahl 256-Bit-AVX-Einheiten (gegenüber SB), sondern auch die z.T. doppelten Ausführungszeiten (Latency) der 256-Bit-AVX-Instruktionen (geschuldet dem "Zusammenbacken" der Cores?). Für Addition und Subtraktion benötigt BD 6 Taktzyklen, SB nur 3; für simples Registerladen BD 2, SB nur 1. Bei der Multiplikation hält es sich in Grenzen: BD 6, SB 5.
Ich hoffe, das Ganze ist nicht zu Off Topic!

Hab gerade etwas gesucht und im AMD Optimierungsguide gibts sogar ein Beispiellisting fürs Multiplizieren von complexen Zahlen mit Hilfe von AVX & FMA:

http://support.amd.com/us/Processor_TechDocs/47414_15h_sw_opt_guide.pdf

Seite 179/180. Schaus Dir mal an, ob Du da noch was verwenden kannst, z.B. das 32B Alignment oder den nontemporal store (MOVNTPS).

Was benützt Du fürs Registerladen, vmovaps? Das ist ab Piledriver umsonst (0 statt 2 Takte), eventuell ein wunder Punkt, den AMD schon mal abstellt :)
Aber ADDs dauern nachwievor 6 Takte, da tut sich nicht viel. Ist dann natürlich auch ein großer Unterschied, wenn Intel das in 3 kann.

ciao

Alex
 
Aus diesem AMD Software Optimization Guide stammen auch die Latency-Zeiten für den BD. Die für SB übrigens von 'http://www.agner.org/optimize/instruction_tables.pdf'; der Mann ist über jeden Zweifel erhaben.
Alignment 32 ist wunderschön, aber 1. kann mein "Wirtsprogramm" Purebasic das (noch) nicht (ich müsste dann eine reine Assembler-Variante schreiben), benachteiligt werden aber beide CPUs. 2. habe ich betr. Alignment schon diverse Tests durchgeführt mit durchwachsenden Ergebnissen. Für einen ganz zeitkritischen (extrem oft aufgerufenen) Befehl kann es durchaus Vorteile bringen, ansonsten je nach Umständen. Bitte nicht verwechseln mit Daten-Alignment; da ist dies extrem wichtig (je grösser die Datenbreite, desto wichtiger).
Die Non-Temporal Hint-Instuktionen (z.B. MOVNTPD/S) schreiben Daten nur in den Speicher, nicht in Register; ist somit hier nicht relevant.
Piledriver soll VMOVAPS in Null-Komma-Nichts ausführen? Da habe ich auf die Schnelle nichts bei Google gefunden. Über eine Quellenangabe wäre ich sehr dankbar. Da bin ich nämlich sehr kritisch, derartige Angaben sind (natürlich, sage ich mal) an bestimmte Voraussetzungen gebunden (schon in einem Cache o.ä.).
So, um jetzt wieder einen Bogen zum Topic zu bekommen, wollte ich eigentlich schon längst den Sinn des Tests mit dem "Apfelmännchen" erklären: 1. Macht dies mir Spaß. 2. Es ist ein Parade-Beispiel für die Möglichkeit der Parallelisierung. Was nützt mir eine CPU mit z.B. 8 Cores, wenn das ablaufende Programm die damit möglichen 8 (echt) gleichzeitig ablaufenden Threads nicht nutzen kann, weil ein Thread (z.B. eine Berechnung) von dem Ergebnis einer vorangegangenen Berechnung abhängig ist. Anders beim "Apfelmännchen": Jede (Bildschirm-) Zeile lässt sich völlig unabhängig von der Vorzeile berechnen. Also: Für z.B. 4 Threads wird die Bildschirm-Höhe in 4 gleiche Abschnitte aufgeteilt, jeder Abschnitt kann simultan (jeder 1 Thread) berechnet werden. Die 4 Threads schreiben ihre Ergebnisse in den Bildschirm-Speicher und siehe da, wir haben ein Gesamtbild, von dem 4 Teile (fast) gleichzeitig berechnet wurden.
Gruß
Helle
 
Die Info mit dem 0 Takten für VMOVAPS stammen ebenfalls aus dem SOG :)
Neueste Version von vor letzter Woche, Table 12 oder 13.
Hab was dazu in Arbeit, aber weiß nicht ob ich den noch bringen soll, irgendwie doch zuviel Spekulation.Einzeln steht dazu eigentlich schon alles in den letzten Postings des BDv2 Sammelthread:
http://www.planet3dnow.de/vbulletin/showthread.php?t=387886

Agner ist klar, den muss man kennen :)
 
In der V.3.06 des SOG stehen tatsächlich 0 Takte für div. Float-Moves ???. Sorry, halte ich für Unfug. In V.3.03 stehen noch 2 Takte (halte ich für glaubwürdiger). Zwischenversionen habe ich nicht gefunden. V.3.03 ist zwar vom April 2011 (also vor Verkaufs-Termin des BD); aber die Innovation von AMD hätte ich bestimmt mitbekommen!
Ist nicht bös gemeint!
Helle
 
In der V.3.06 des SOG stehen tatsächlich 0 Takte für div. Float-Moves ???. Sorry, halte ich für Unfug. In V.3.03 stehen noch 2 Takte (halte ich für glaubwürdiger). Zwischenversionen habe ich nicht gefunden. V.3.03 ist zwar vom April 2011 (also vor Verkaufs-Termin des BD); aber die Innovation von AMD hätte ich bestimmt mitbekommen!
Ist nicht bös gemeint!
Helle
Schau mal unter MOVAPS (oder MOVAPD, auf alle Fälle ohne V), dass sind die SSE-Äquivalente, die Instr. hat auch schon in der alten PDF-Version 0 Takte, d.h. der aktuelle BD macht den Befehl ebenfalls schon in 0 Takten. Halte ich jetzt nicht für Hexenwerk, wenn sie jetzt auch die AVX-Version aufs gleiche Niveau bringen, AVX war halt noch schnell an BD drangebastelt, weswegen es noch etwas im Gebälk knirschte.

Auch nicht bös gemeint (bei AMDs PDF muss man eh vorsichtig sein, das nimmt Dir keiner krumm, wenn Du da skeptisch bist ^^) :)

Edit:
Oder hast Du mit "diverse MOVs" auch das MOVAPS gemeint, und in der 3.03er steht das ebenfalls noch mit 2 Takten drin?
Edit2: Hab noch ne 3.03 Version bei mir auf Platte gefunden, und konnte es jetzt schnell selbst nachprüfen: Für die SSE-Varianten werden dort auch schon 0 Takte angegeben.
 
Ich nehme alles zurück :)! Vor Jahren babe ich mal ein 32-Bit-Programm zur Latenz- und Durchsatz-Messung geschrieben, dessen Ergebnisse immer sehr gut mit Hersteller- und anderen Test-Angaben übereinstimmten. Heute habe ich dieses Programm schnell auf 64-Bit umgeschrieben und auf einen FX-8120 losgelassen. Und siehe da, die SSE-MOV-Befehle (Register-Register) werden mit einer Latenz von 0.2 Takte ausgewiesen (eine gewisse Bandbreite ist natürlich vorhanden). Also tatsächlich (fast) Null. Könnte ich mir so erklären, dass die MAL-Pipe (des BD) richtig gut auf Register-Renaming getrimmt ist. Ein i7-920 (mein Büro-Zweitrechner) zeigt 0.91 Takte an, also fast 1. Meinen i7-2600 teste ich später zu Hause.
Gruß
Helle
 
Hat jemand mal das Kernel-Update auf nem K10 oder K8+ ausprobiert:

Davor
CPU 0,1,2,3...7 bei nem Dual-Quadcoresystem (2x 2382er Opterons)
nun
CPU 0 Node 0
CPU 1 Node 0
CPU 0 Node 1
CPU 1 Node 1
...



im Taskmanager uswusf.

wobei dies doch eigentlich total falsch ist
CPU 0 Node 1 gibts doch nur bei den 61xx und 62xx Opterons wo Node 1 das 2. DIE auf dem CPU Träger wäre *noahnung*

Wie unterteilt dies Microsoft nun bei nem Dual-Opteron 61xx System ?

CPU 0 Node 1 Die 1 ???

Da hamse bei Microsoft und/oder AMD mal wieder Bockmist gebaut.
Und rausreden, dass diese Update nur für AMD Family 15h gedacht sei kann man sich auch nur bis wieder ein Sicherheitsupdate für den Kernel (ntoskrnl.exe) kommt - danach hams auch alle, auch wenn es sich um ein Dual-Dualcoresystem oder was auch immer handelt..
 
Zuletzt bearbeitet:
Wenn ich mal raten müsste.....CPU = Kern, Node = Prozessor?
 
Naja

NodeID gibt das jeweilige DIE auf dem Prozessor (Opteron 61xx und 62xx) an, daher

CPU 0 = 1. Prozessor(sockel) mit Node 0 (1. DIE aufm Träger) und Node 1 (2. DIE aufm Träger).
CPU 1 = 2. Prozessor(sockel) uswusf.

noch etwas ausm SOG für AMD Family 15 Model 00h-2Fh

47414_15h_sw_opt_guid9trd6.png


und ausm BKDG
42301_rev_3.00-k15bkdwvx1d.png
 
Zuletzt bearbeitet:
@crashtest:
Öh ja klingt arg abstrus, da ist nun die Frage, wie das bei Intel und den SMT gelöst ist, irgendnen Sinn wirds (hoffentlich ^^) haben :)

@Sompe: Node auf Deutsch bedeutet "Rechenknoten". Da wird man aber nicht viel schlauer ^^
Bei AMD hießen früher die CPUs in den Mehrprozessor-Servern so. Dann mit den Mehrkernprozessoren, war Node = CPU Sockel, und seit Magny Cours bedeutet Node = Die. Ein Magny COurs 6000er Opterons hat also schon 2 Nodes. Hintergrund ist z.B. der Einsatz bei der NUMA Speicher-Adressierung.

Dass da jetzt ein Patch daran herumpfuscht ist schon etwas komisch, aber ich hoffe doch stark, dass sie das Teil auch auf Opterons getestet haben. Solange man kein NUMA einsetzt sollte es im Desktop egal sein.

@Helle53:
Optimal, wenn Dus selbst auch noch testen konntest ist es perfekt, Glückwunsch :)
 
Die Node Bezeichnung kenne ich noch vom alten AMD Power Monitor und wenn ich mich recht erinnere, dann bezog sie sich dort auf die CPU bzw. das einzelne Die und da einzelne Kerne in der Software auch gern als CPU bezeichnet werden vermute ich das Node nicht das Die auf einem Träger, sondern das Die im System bezeichnet.

Ich kann ja nachher mal mein altes Athlon MP System ausgraben und schauen was der Power Monitor dazu sagt.


Edit: ah Opteron weiss da schon mehr. :)
 
Zuletzt bearbeitet:
Ich habs bisher nur auf folgenden Systemtypen getestet und dieses "Chaos" gesehen:

Dual AMD Opteron 2218 System mit HyperDings 2008r2:
CPU 0 Node 0
CPU 1 Node 0
CPU 0 Node 1
CPU 1 Node 1
im Taskmanager bei den Zugehörigkeiten

Dual AMD Opteron 2382 System mit Server 2008r2:
CPU 0 Node 0
CPU 1 Node 0
CPU 0 Node 1
CPU 1 Node 1
CPU 0 Node 2
CPU 1 Node 2
CPU 0 Node 3
CPU 1 Node 3

Beim Kumpel mit seinem Dual Opteron 6176
CPU 0 Node 0
CPU 1 Node 0
..
CPU 0 Node 11
CPU 1 Node 11


Aber bei meinem AMD C-50 ist es weiterhin
CPU 0
CPU 1
für einen Dualcore ?
 
Zurück
Oben Unten