Archiv verlassen und diese Seite im Standarddesign anzeigen : Diskussion zu: AMD Bulldozer: Rechenkerne in Modul-Bauweise
Leonidas
2010-08-25, 08:57:58
Link zum Artikel:
http://www.3dcenter.org/artikel/amd-bulldozer-rechenkerne-modul-bauweise
Update 10:00
Absatz und Bild zur Anzahl der INT-Einheiten hinzugefügt
Update 09:00 am 26.8.
Nachtrag zur Performance von Bulldozer bzw. zur Nichtbeurteilbarkeit von dieser hinzugefügt
Update 14:00 am 29.8.
Nachtrag mit Specs-Tabelle
MadManniMan
2010-08-25, 11:18:47
Letztlich wird's dann also am Marketing hängen bzw. auch an der Community, wie die Neudefinition der "Kerne" dann aufgenommen wird.
In der allgemeinen Wahrnehmung ist HT eher ein Rattenschwanz eines echten Kernes - was wird das dann erst beim Bulldozer werden?
Ich vermute mal, dass AMD bewusst nur 2 Int-Einheiten pro Kern spendiert, da mehr (unter Praxisbedingungen) mit geteilten Fetch/Dedoce/Scheduler/FB-Einheiten einfach nicht ausgelastet werden können - und eben dies der Grund ist, weshalb "nur" 80% der Performance eines vollwertigen Cores erreicht werden.
Mir scheint AMD baut da mit dem Bulldozer ein möglichst DIE-Größen/energieeffizientes Design zusammen ?
Unter dem Gesichtspunkt ist die Aussage, dass ein (16Kern bzw ) 8 Modul Bulldozer System 50% mehr Leistung als ein 12 Kern Istanbul erreichen soll, doch garnichtmal so schlecht.
Ähm, die letzte Info ist Quatsch. BD läuft sehr wohl auf anderen Mobos. Andernfalls hätte ich gerne einen Beleg für die letzte Behauptung. Das wurde von AMD seit Einführung des AM2 nie so gehandhabt, warum sollte man jetzt damit anfangen? Sofern ein BIOS mit aktuellen AGESA vorhanden ist läuft jede CPU auf jedem Mobo (TDP-Einschränkungen nicht beachtet). Da hätte man BD gleich nen eigenen Sockel verpassen können - sry aber diese Aussage so völlig unhinterfragt in einem Artikel so zu behaupten ist total daneben. Wäre er elektrisch nicht mit AM3 kompatibel, hätte er eine anderes Sockellayout.
Überhaupt ist ein Nehalem nicht 25% schneller als ein K10, sondern das trifft nur punktuell zu. Nur bei Intel-Optimierter Software kann es mehr werden - von durchschnittlich kann man da also wohl kaum sprechen. Hinzu kommt, dass die hier getroffene Performanceeinschätzung völlig anders ist als bei anderen Artikeln, wie z.B. bei ht4u (http://ht4u.net/reviews/2010/amd_bulldozer_preview/).
Der Artikel ist ... fragwürdig, sry.
Der Vergleich mit HT passt eigentlich sehr gut, im Prinzip ist es "nur" eine Erweiterung, bei der auch Teile der Recheneinheiten mehrfach ausgelegt sind. 2 "Kerne" können auf jeden Fall auch wie ein einzelner Kern arbeiten. Damit sollte eine ordentliche Single-Threaded-Leistung pro MHz eigentlich drinnen sein, Multithreaded hat man eh keine Probleme. Ein "8-Kerner" von AMD wird dann wohl gegen einen 6-Kerner von Intel antreten, da dürfte es wohl auch vom Transistorcount keine wirklichen Nachteile geben. Die Idee von AMD ist denke ich gut, mich wundert ehrlich gesagt, dass noch kein Prozessorhersteller etwas derartiges gemacht hat.
Vor allem mit immer mehr Kernen und Software die nicht hinterherkommt diese auch auszunützen ist das Konzept ideal, man hat swohl wenige starke als auch viele schwächere Kerne in einem Design.
Iceman346
2010-08-25, 13:18:31
Das Bulldozer nicht auf bereits erhältlichen Boards läuft melden auch andere Seiten, gestern geisterten Folien durchs Netz, wo AMD davon sprach, dass für volle Performance bei Bulldozer ein AM3+ Board nötig ist. Ganz klar scheint das nicht zu sein, nur sicher ist wohl, dass man auf Leistung verzichten muss falls es überhaupt funktioniert.
Was die Rohleistung angeht liegen die aktuellen Intelprozessoren taktbereinigt eigentlich durchweg 20-30% vor den AMD Prozessoren, die Angabe ist schon richtig so.
Amun-Re
2010-08-25, 13:26:14
@Hot
Vielleicht ist deine Wahrnehmung einfach nicht ganz objektiv.
Wie mein Vorredner schon sagte ist die Info bezüglich der Notwendigkeit eines neuen Boards für BD der Hot Chip Konferenz entnommen insofern wurden hier wohl keine Gerüchte gestreut (im Gegensatz zur vorherigen Annahme vieler AMD Anhänger das BD mit an Sicherheit grenzender Wahrscheinlichkeit abwärtskompatibel sei.) sondern die Info darf nun als von AMD abgesegnet betrachtet werden.
Das es möglicherweise inoffiziell dennoch möglich sein wird BD auf AM3 zu betreiben mag dabei auf einem anderen Blatt Papier stehen. Im übrigen hält auch ht4u sich weitestgehend zurück was Performanceprognosen anbelangt weil es dafür schlichtweg noch zu früh ist.
Nun da sich aber die Informationen zumindest etwas verdichten wird halt nur klar das auch BD in seiner Konzeption nicht frei von Kompromissen entwickelt worden ist.
Savay
2010-08-25, 13:33:02
hm mir scheint es als würde leo einen kleinen denkfehler begehen im bezug auf die kritik zur leistungsfähigkeit der bulldozer module da er die kerne des moduls komplett voneinander entkoppelt.
sie verhalten sich ggü. dem OS ja defakto wie EIN kern mit SMT da sie ja HINTER dem decoder liegen. bei einer dualcore CPU ist wird ja jeder core auch von einem eigenen decoder gefüttert.
AMD mag zwar die "subkerne" der module aus marketing gründen trennen...defakto kann man das aber (wenn ich jetzt keinen denkfehler begehe) eigentlich nicht!?
denn ob man jetzt in dem modul z.B. einen monolytischen kern mit 4 ALUs und 4 AGUs hat oder 2 "subkerne" mit 2 ALUs und AGUs ist letztlich egal wenn die decoder bzw die scheduler den workload dynamisch auf die vorhandenen rechenwerke verteilen können..
beispielsweise:
workload A) 2 threads -> der decoder & scheduler verteilt es "klassisch" wie in einem 2 kern system über beide "subkerne"
workload B) 1 "superskalarer thread" -> der decoder & scheduler verteilt die last auf beide cores als wäre es EIN monolytischer "4ALU+4AGU" kern ähnlich wie es bei einem traditionellen Kern aktueller bauweise geschehen würde.
der rest hängt dann im grunde an der leistungsfähigkeit der einzelnen Pipelines etc.
das ganze führt aber dazu das ein BD modul weder mit einem klassischen dualcore zu vergleichen ist...noch dazu das man einen "kern" eines BD moduls mit einem einzelnen kern einer "klassischen" CPU gleichsetzen kann...ein BD modul ist ein hybrid zwischen dualcore und SMT singlecore.
so wie ich es verstanden habe wirkt ein BD-Modul je nach workload nach aussen schlicht wie ein singlecore mit 2 threads ODER halt wie ein singlecore mit 1 thread aber doppelten ALUs und AGUs.
wie gut das funktioniert hängt dann aber letztlich ja wirklich noch am decoder und dem scheduler und letztlich bleiben auch noch genug fragezeichen.
wenn ich einen denkfehler begangen habe korrigiert mich bitte. :)
puntarenas
2010-08-25, 13:57:05
Ähm, die letzte Info ist Quatsch. BD läuft sehr wohl auf anderen Mobos. Andernfalls hätte ich gerne einen Beleg für die letzte Behauptung.
Just to clarify on that... on the socket question:
Bulldozer based products will not be drop in for AM3 - so it will require a different socket, we are calling AM3+ - our AM3+ - I am sorry AM3 CPUs - will be able to - will function in an AM3+ Bulldozer socket, so you can bring your previous CPUs into the AM3 infrastructure, but not the other way round.
Quelle: Audiomitschnitt (ab 23:00) (http://www.yousendit.com/transfer.php?action=batch_download&send_id=931186725&email=9920dd428d1b6716f0a5c2296845a836)
Savay
2010-08-25, 14:03:17
In der allgemeinen Wahrnehmung ist HT eher ein Rattenschwanz eines echten Kernes - was wird das dann erst beim Bulldozer werden?
IMO ist ein 8modul BD eine "8 Kern" CPU...technisch präziser in dem zusammenhang wäre wohl auch die zählweise nach frontend und decoder...
ergo ist nen "16 kern" BD ja eigentlich ein "8 CMT-Kern" CPU, da sich die CPU ja je nach workload mal wie eine 16kern CPU aber eben auch wie eine 8 kern CPU mit doppelter ALU/AGU zahl verhalten kann bzw könnte...
vorrausgesetzt die decoder und scheduler können das wirklich leisten. ;)
aber 8 kern CPU klingt natürlich nicht so toll wie 16 kern...zumal die aussage 8kern CPU mit 16threads ja auch falsch wäre da es je nach last ja deutlich darüber hinausgeht was SMT zu leisten vermag.
...vorallem verklicker mal den kunden das er eine 8kern CPU kauft die sich aber eben oft (aber nicht immer) wie eine 16 kern CPU verhält. da ist es wohl einfacher zu sagen man hätte es mit einer 16 kern CPU zu tun! ;)
Leonidas
2010-08-25, 14:29:22
wenn ich einen denkfehler begangen habe korrigiert mich bitte. :)
So weit ich das verstanden hab, ergibt ein Modul im Betriebssystem zwei Kerne und so werden die auch so vermarktet.
Ich hoffe ja diesbezüglich einen Denkfehler zu begehen, aber bisher sieht es nicht danach aus.
Und nochwas zu Zählweise: Ob AMD ein 2-Modul-Chip nun QuadCore oder DualCore nennt, ist eigentlich wurscht - wichtig ist, was im Desktop-Markt davon ankommt. Und da denke ich, werden wir maximal 3-Modul-Chip sehen, also wie bisher 6 Kerne. Im Serverbereich mag es AMD einfacher haben, auf mehr Kerne zu kommen und dort existiert auch der Bedarf und die Software dafür. Im Desktop-Bereich wird es aber nicht mehr Kerne geben - und dann haben wir das Problem, daß die Bulldozer-Kerne eben nicht so viel wert sind wie K10/Nehalem-Kerne. Wie gesagt hoffe ich, mich diesbezüglich zu täuschen, aber so sieht es derzeit aus.
AMD wird hoffentlich nicht mit voller Absicht eine CPU designen, deren letztendliche "Single-Thread-Leistung":upara: um einiges unter der des schon nicht gerade supertollen Vorgängers liegt.
So weit ich das verstanden hab, ergibt ein Modul im Betriebssystem zwei Kerne und so werden die auch so vermarktet.
Natürlich, anders hätte der ganze Spaß ja überhaupt keinen Sinn.
Eine HT-CPU meldet sich auch als 2-Kerner (pro physischem Kern)
Und nochwas zu Zählweise: Ob AMD ein 2-Modul-Chip nun QuadCore oder DualCore nennt, ist eigentlich wurscht - wichtig ist, was im Desktop-Markt davon ankommt. Und da denke ich, werden wir maximal 3-Modul-Chip sehen, also wie bisher 6 Kerne.
Das bezweifle ich, ich denke wir werden mindestens 4/8-Kerne im Desktop sehen, im Server-Markt eher mehr.
Aber auch so hätte das kaum Auswirkungen, im Desktopbereich gibt es kaum Software die so viele Kerne ausnützen kann, nachteilig wird das ganze nur bei Software die wirklich alle Kerne ausnützt. Da hätte Intel mit 6 starken gegenüber 6 schwachen Kernen natürlich Vorteile.
Ansonsten können aber auch jeweils 2 "Minikerne" wie ein großer arbeiten und damit die Single-Thread-Leistung erhöhen.
Das Konzept an sich klingt sehr gut, die Frage ist natürlich wie gut die Umsetzung ist und wie gut die Scheduler eines Moduls ihre einzelnen Kerne auslasten kann, wenn mal nicht mehrere Threads vorhanden sind.
Wie kommt ihr überhaupt darauf, dass die Singlethread-Leistung geringer als bei K10 wäre?
Wie kommt ihr überhaupt darauf, dass die Singlethread-Leistung geringer als bei K10 wäre?
Die Singelthreadleistung eines "Cores" sollte niedriger sein, da ganz einfach die Zahl der Recheneinheiten abgenommen hat. Allerdings sollte die Singelthreadleistung eines Moduls (bestehend aus 2 Cores) höher sein, wenn nicht hat AMD was verbockt und der Aufwand war umsonst.
Die Frage ist natürlich um wieviel, bekanntermaßen bringt bei CPUs das simple hinzufügen von weiteren Recheneinheiten eher wenig.
Leonidas
2010-08-25, 17:24:17
AMD sagt selber: Ein Kern eines Moduls hat 80% der Performance wie als wenn man dasselbe Design als regulären Prozessor ausgeführt hätte.
Ich finde den Artikel informativ aber es fehlen noch die internen Bandbreiten zu den Caches um die Leistungsfähigkeit von Bulldozer beurteilen zu können.
Zum Beispiel bringt Hyperthreading oft nicht so viel, weil ein Kern ohne und mit Hyperthreading die gleiche Bandbreite zum L2 hat.
Gibt es Informationen darüber mit welcher Bandbreite beim Bulldozer der L2 Cache an die Kerne und der L3 Cache an das Modul angebunden sind?
Insbesondere ist die L2 Bandbreite bei gleicher Frequenz eines Bulldozer Kerns gleich der eines K10 Kerns? Ist die L3 Bandbreite eines Bulldozer Moduls gleich der zweier K10 Kerne?
Gipsel
2010-08-25, 19:16:57
AMD sagt selber: Ein Kern eines Moduls hat 80% der Performance wie als wenn man dasselbe Design als regulären Prozessor ausgeführt hätte.
Nein, AMD sagt genau genommen, daß wenn man statt 4 Decodern und 64kB L1-I 2x4 Decoder sowie 2x64kB L1-I und auch statt 2x128Bit FMACs 2x2x128Bit FMACs verbauen würde, die Performance bei Multithread-Anwendungen durchschnittlich 25% höher wäre.
Wie es sich mit der singlethread-Leistung verhält, dazu wurde eigentlich noch nichts gesagt. Es ist durchaus möglich (d.h. sogar wahrscheinlich), daß im Schnitt ein Bulldozer-Kern (also die Hälfte eines Moduls) gleich oder auch etwas mehr IPC schafft als ein K10-Kern (ja, trotz reduzierter ALU-Anzahl). Glaubt man AMD, so wurde Bulldozer auch für recht hohe Taktraten ausgelegt, so daß wir evtl. zusammen mit der 32nm Fertigung locker (über?) 4GHz sehen werden, so daß auch die Single-Thread-Leistung eine ordentliche Steigerung erfährt. Zumal ja auch das Turbo-Feature aufgebohrt worden sein soll und einem einzelnem Thread im Modul dann auch die volle FPU und alle Decoder zur Verfügung stehen. Die single-Thread-FPU-Leistung z.B. dürfte recht ordentlich werden.
angenommen ich hab n bulldozer mit 2 modulen, weiss windows, dass 2 threads sinnvollerweise auf beide module und nicht auf eins aufgeteilt werden sollten?
das gleiche frage ich mich auch bei core i5 oder i7...
Gipsel
2010-08-25, 22:42:11
angenommen ich hab n bulldozer mit 2 modulen, weiss windows, dass 2 threads sinnvollerweise auf beide module und nicht auf eins aufgeteilt werden sollten?
das gleiche frage ich mich auch bei core i5 oder i7...
Im Prinzip schon (zumindest bei den neueren Windows-Versionen). Allerdings wundert es mich immer wieder, was Windows mit diesen Informationen anfängt (scheinbar nicht viel). Die Threads werden für meinen Geschmack viel zu sehr über alle Kerne verteilt und immer fröhlich von einem Kern zum nächsten durchgetauscht.
Leonidas
2010-08-26, 06:55:33
Nein, AMD sagt genau genommen, daß wenn man statt 4 Decodern und 64kB L1-I 2x4 Decoder sowie 2x64kB L1-I und auch statt 2x128Bit FMACs 2x2x128Bit FMACs verbauen würde, die Performance bei Multithread-Anwendungen durchschnittlich 25% höher wäre.
Wie es sich mit der singlethread-Leistung verhält, dazu wurde eigentlich noch nichts gesagt. Es ist durchaus möglich (d.h. sogar wahrscheinlich), daß im Schnitt ein Bulldozer-Kern (also die Hälfte eines Moduls) gleich oder auch etwas mehr IPC schafft als ein K10-Kern (ja, trotz reduzierter ALU-Anzahl). Glaubt man AMD, so wurde Bulldozer auch für recht hohe Taktraten ausgelegt, so daß wir evtl. zusammen mit der 32nm Fertigung locker (über?) 4GHz sehen werden, so daß auch die Single-Thread-Leistung eine ordentliche Steigerung erfährt. Zumal ja auch das Turbo-Feature aufgebohrt worden sein soll und einem einzelnem Thread im Modul dann auch die volle FPU und alle Decoder zur Verfügung stehen. Die single-Thread-FPU-Leistung z.B. dürfte recht ordentlich werden.
Danke für die Klarstellung, das hilft weiter.
pool1892
2010-08-26, 10:36:38
leonidas,
lässt du bei den performance-vorhersagen nicht gerade die vorhersage ein wenig hinten runterfallen? ich meine die gesammte predictionlogic, tlb, prefetch usw.
bekanntermaßen ist die gesteigerte pro-kern-leistung bei nehalem vor allem der neu gestalteten speicher- und statistikhierarchie zu verdanken - und amd spricht hier auch (im gegensatz zu den letzten designs) von stark überarbeiteten bzw. verbesserten mechanismen.
nur als beispiel, in einem nehalemkern ist die predictionlogik insgesamt größer als die eigentlichen ausführungseinheiten inkl. float:
http://images.anandtech.com/reviews/cpu/intel/nehalem/uarch/nehalemcore.jpg
Leonidas
2010-08-26, 19:19:37
Richtig, ich lass das herunterfallen - weil das nichts verifizierbares ist, hier existiert immer nur das Wort der Prozessorenentwickler. Ist nicht schön, das man das nicht besser betrachten kann, aber ich sehe hier keinen streng faktenbasierten Ansatz.
Leonidas
2010-08-27, 08:10:45
Läßt sich die nachfolgende Tabelle eventuell noch vervollständigen? Fehlend sind insbesondere Angaben zu den Cache-Wegen/Bandbreiten:
(alles pro Kern)
Reihenfolge:
1. K10
2. Bulldozer
3. Core 2
4. Nehalem
Pipeline
12 Stufen
?
14 Stufen
16 Stufen
Dekoder
bis zu 3 Ops
für zwei Kerne: bis zu 8 Ops
bis zu 5 Ops
bis zu 5 Ops
Integer
3x ALU, 3x L/S
2x ALU, 2x L/S
3x ALU, 2x L/S
3x ALU, 2x L/S
Fließkomma
3x FPU
für zwei Kerne: 2x FPU
2x FPU
2x FPU
FPU-Bandbreite
128 Bit
128 Bit
128 Bit
128 Bit
L1 Instr.-Cache
64 kB, 2fach assoziativ
für zwei Kerne: 64 kB
32 kB, 16fach assoziativ, 256 Bit Bandbreite
32 kB, 8fach assoziativ
L1 Daten-Cache
64 kB, 2fach assoziativ, 128 Bit Bandbreite
16 kB
32 kB
32 kB
L2-Cache
512 kB, 16fach assoziativ
für zwei Kerne: 2 MB, 16fach assoziativ
für zwei Kerne: 6 MB, 12fach assoziativ, 256 Bit Bandbreite
256 kB
L3-Cache
für vier Kerne: 6 MB, 48fach assoziativ
?
keiner
für vier Kerne: 8 MB
hm mir scheint es als würde leo einen kleinen denkfehler begehen im bezug auf die kritik zur leistungsfähigkeit der bulldozer module da er die kerne des moduls komplett voneinander entkoppelt.
sie verhalten sich ggü. dem OS ja defakto wie EIN kern mit SMT da sie ja HINTER dem decoder liegen. bei einer dualcore CPU ist wird ja jeder core auch von einem eigenen decoder gefüttert.
AMD mag zwar die "subkerne" der module aus marketing gründen trennen...defakto kann man das aber (wenn ich jetzt keinen denkfehler begehe) eigentlich nicht!?
denn ob man jetzt in dem modul z.B. einen monolytischen kern mit 4 ALUs und 4 AGUs hat oder 2 "subkerne" mit 2 ALUs und AGUs ist letztlich egal wenn die decoder bzw die scheduler den workload dynamisch auf die vorhandenen rechenwerke verteilen können..
Das wäre natürlich durchaus interessant und der Single-Thread-Performance zuträglich. Allerdings hat AMD in keinem Beispiel auf seinen Folien gezeigt, dass ein Thread auf beiden Integer-Kernen laufen kann. Stattdessen wurde auf jeder Folie, die es zu Threads gab, gesagt, dass die Threads getrennt entweder auf dem Kern 1 oder Kern 2 laufen, nur die FPU kann komplett von einem Thread übernommen werden. Du schlägst dagegen vor auch die Integerkerne von einem Thread benutzen zu lassen, genau das will AMD aber nicht. Intel nutzt mit SMT alle Rechenwerke für ein Thread oder Splitet diese auf zwei Threads, also dein "Vorschlag" ist dem Design von Intel mit SMT näher, als dem von AMD....
angenommen ich hab n bulldozer mit 2 modulen, weiss windows, dass 2 threads sinnvollerweise auf beide module und nicht auf eins aufgeteilt werden sollten?
das gleiche frage ich mich auch bei core i5 oder i7...
das war auch die erste frage, die mir beim lesen des nachtrags durch den kopf schoss.
Im Prinzip schon (zumindest bei den neueren Windows-Versionen). Allerdings wundert es mich immer wieder, was Windows mit diesen Informationen anfängt (scheinbar nicht viel). Die Threads werden für meinen Geschmack viel zu sehr über alle Kerne verteilt und immer fröhlich von einem Kern zum nächsten durchgetauscht.
kann jemand das genauer beschreiben, was windows (falls es unterschiede gibt: die verschiedenen versionen) über die cores des prozessors weiss und nach welchen kriterien anwendungen/threads darauf verteilt werden?
Die Threads werden für meinen Geschmack viel zu sehr über alle Kerne verteilt und immer fröhlich von einem Kern zum nächsten durchgetauscht.
Der Taskmanager zeigt den Durchschnitt jeder Sekunde an. Wenn deine CPU 3GHz hat sind dabei 3000000000 Takte vergangen. Die paar 100 Takte die durch das verteilen der Threads auf die einzelnen Kerne verloren gehen sind da völlig egal.
Du brauchst auch nicht denken, dass dadurch Sparfunktionen die einzelne Kerne abschalten bzw. die automatischen Übertaktungsfunktionen nicht funktionieren.
Wenn ein Thread zu 50% der Zeit auf Core0 und die anderen 50% auf Core1 läuft wird immer der Core auf dem der Thread gerade läuft übertaktet bzw. der andere Schlafen geschickt.
Windows arbeitet wie die meisten Desktop-Betriebssysteme preemtive, jeder Thread wird also auf jeden Fall nach einer bestimmten Zeitspanne angehalten und die CPU ihm entzogen. Auf welchem Core er dann weiter läuft ist im Prinzip völlig egal.
silent-efficiency
2010-08-29, 20:42:25
kann jemand das genauer beschreiben, was windows (falls es unterschiede gibt: die verschiedenen versionen) über die cores des prozessors weiss und nach welchen kriterien anwendungen/threads darauf verteilt werden?
Für SMT gibt es ab Windows 7 sogenanntes SMT-Core-Parking. Das heißt, die "Kerne" die durch SMT simuliert werden, sind erst "geparkt"=werden nicht genutzt. Erst wenn alle nicht geparkten echten Kerne eine Last haben, werden die virtuellen Kerne reaktiviert und mit Threads beladen. Dadurch ist ein Sechskerner von Intel, der ja bekanntlich dank SMT bis zu 12 Threads ausführen kann, unter Windows 7 schneller. (Je weniger Kerne die CPU hat, desto weniger gibt es einen Performancevorteil durch dieses Feature, weil die Software dann eben doch oft mehr als zwei logische CPUs mit Threads versorgen kann und dann SMT-Core-Parking eh nicht verwendet wird...)
Gipsel
2010-08-30, 10:13:51
Der Taskmanager zeigt den Durchschnitt jeder Sekunde an. Wenn deine CPU 3GHz hat sind dabei 3000000000 Takte vergangen. Die paar 100 Takte die durch das verteilen der Threads auf die einzelnen Kerne verloren gehen sind da völlig egal.
Du brauchst auch nicht denken, dass dadurch Sparfunktionen die einzelne Kerne abschalten bzw. die automatischen Übertaktungsfunktionen nicht funktionieren.
Wenn ein Thread zu 50% der Zeit auf Core0 und die anderen 50% auf Core1 läuft wird immer der Core auf dem der Thread gerade läuft übertaktet bzw. der andere Schlafen geschickt.
Windows arbeitet wie die meisten Desktop-Betriebssysteme preemtive, jeder Thread wird also auf jeden Fall nach einer bestimmten Zeitspanne angehalten und die CPU ihm entzogen. Auf welchem Core er dann weiter läuft ist im Prinzip völlig egal.
Da hast Du leider Unrecht.
Zum einen dauert ein Taskswitch effektiv länger als nur ein paar hundert Takte, auch da die ganzen benutzten Daten nach und nach wieder in die privaten Caches nachgeladen werden müssen (das ist bei AMD sowohl L1 und L2).
Außerdem lade ich dich herzlich ein, mal zu erklären, warum das Turbo-Feature der letzten X6 und X4 denn bei Single-Thread-Auslastung deutlich weniger bringt, als eigentlich zu erwarten wäre. Offensichtlich kommt die Geschwindigkeit der Taktanpassung dann doch nicht mit dem Switchen über alle Kerne hinweg mit. Das geschieht übrigens standardmäßig alle 10ms. Ein wenig Zeit benötigt die Taktanpassung nämlich auch, zum einen um überhaupt zu erkennen, welcher Kern gerade ausgelastet ist. Und die Taktanpassung geschieht auch nicht Nullzeit (Spannungen müssen geändert werden, abgewartet werden, bis sie sich stabilisiert haben, das gleiche nochmal mit den Frequenzen). Du stellst Dir das Prozedere offensichtlich etwas zu einfach vor.
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.