hm was heißt da unbezahlt,also ein kommender 12 kerner wird bestimmt nicht so viel kosten wie ein aktueller 16 kerner,das glaube ich nicht,wobei teuer als aktuell dann schon.Ich darf schon mal ordentlich Geld zusammen sparen,denn wenn es teuer wird,dann wird das wirklich hart werden.
Special Ryzen 9 9950X3D2 Dual Edition im Test: Die schnellste Desktop-CPU, die es jemals gegeben hat
- Ersteller PCGH_Dave
- Erstellt am
Schak28
Software-Overclocker(in)
Naja wäre auch super dreist wieder nen großen Aufschlag zu verlangen für eine CPU die 1 1/2 Jahre alt ist.
Man hat die leicht verbesserte Version des 9800X3D für 40-50€ mehr gebracht.
Man hat beim 9950X3D2 einfach den Doppelten Preis eines 9850X3D genommen.
Der Preis wird sich nicht lange halten.
Ists legitim ? Ja find ich schon.
Den selbst der 9850X3D ist zu teuer … theoretisch.
Aber schon ein besserer Preis als der 9800x3D hatte.
Zuletzt bearbeitet:
Eine "CPU-Krise" fehlt tatsächlich noch. Ansonsten: Wenns Leben davon abhängt, warum nicht reinballern? Der Rest kann chillen. Oder wird bei "unbezahlbarer" Hardware erleben, wie sich der Markt für immer verändern wird.
Bislang bleibt selbst dieses Teil hier fünf Fußball-WMs später noch billiger als der olle Athlon FX. Überhaupt: Wo ist hier diese historische Inflationsrate, die Hersteller-Influencer auf YT mit der groben Kelle verrechnen, um Anschaffungs-Preissteigerungen als "unumgänglich" zu framen?
(Vorsicht: Anschaffungspreise ungleich Kosten. Gelle, liebe Autoliebhaber.
)
Zuletzt bearbeitet:
Thoriig
Komplett-PC-Aufrüster(in)
Hoffen wir einfach mal. Wenn man sich anschaut das moderne x86 multicore cpus sogar in tomahawks und patriots verbaut sind, von denen gerade eine menge verwendet wurden, dann fragt man sich natürlich, welche Produktionskapazitäten dafür verwendet werden sollen.Nun, gegen das alles spricht der Release von 9850X3D - leicht verbesserte Version für den selben Preis wie der Vorgänger.
AMD will hier einfach viel zu viel Geld. Niemand sagt, die CPU soll billiger werden als der Vorgänger.
Der Preis wird schon sinken.
Im Gegensatz zu früheren HEDT oder aktuellen EPYC & Threadripper bietet das Ding ja nix wirklich Besonderes (nur in ganz wenigen Szenarien sieht man einen Vorteil, der Rest ist nur messbar, wenn überhaupt).
Prozessoren für 1000€ und mehr haben sich immer schon verkauft, ich erinnere mich noch an die Preise von dem, was auf X99 so released wurdeDa gab es aber nen ordentlichen Sprung zwischen den Modellen.
Tesla kauft große Produktionsmengen von Samsungs Ram Modulen, will von Intel A18 Fertigungskapazitäten für CPUs.
Die Hochtechnologie findet überall Einzug und der Bedarf steigt deutlich schneller als die Fertigungskapazitäten das abdecken können. Alles zusätzlich zum Infrastruktur-Ausbau und der Knappheit an zentralen Ressourcen (was auch selbstverschuldet ist).
Ich bezweifle, dass die alten Zeiten so schnell zurück kommen, schon gar nicht bei dem ganzen emotionalen Reaktivismus. Hoffen können wir dennoch, dass China ruhe bewahrt und passiv zuschaut.
MechUnit
Software-Overclocker(in)
@Thoriig hat es dir genauer erklärt. Aber du willst es nicht einsehen oder das letzte Wort haben... keine Ahnung.
Wie gesagt: AMD verlangt nicht einfach aus Spaß den Preis für die CPU - ist so.
Und nochmal: nach momentaner Inflation, Wirtschaftslage und mit der IPC ist der Preis für die CPU gerechtfertigt. Ist auch so, fertig.
TE
TE
Ich habe mich entschieden, den Meinungskasten in diesem Test zu entfernen. Der Grund ist einfach: Die aktuelle Diskussion im Internet trifft mich persönlich mehr, als ich erwartet hätte. Vieles davon basiert auf Missverständnissen und Annahmen, die meiner Arbeit und der der Redaktion nicht gerecht werden. Was mich dabei besonders trifft, ist, wie schnell Einschätzungen von außen als gegeben angenommen werden, ohne dass zuvor der direkte Austausch gesucht wird. Ich bin hier im Forum sehr aktiv, beantworte Nachrichten, erkläre unsere Testmethoden und versuche, so transparent wie möglich zu sein. Gerade deshalb hätte ich mir gewünscht, dass man zuerst das Gespräch sucht, bevor sich ein bestimmtes Bild festsetzt.
Der Test des 9950X3D2 war mir persönlich wichtig. Ich habe mich wirklich auf diesen Launch gefreut, weil es etwas Besonderes ist. Solche CPU bleiben schließlich über Jahre spannend (man denke nur an den Ryzen 7 5800X3D). Umso frustrierender ist es, dass sich jetzt vieles nur noch um die Sampling-Situation dreht. Zumal das eine Entscheidung ist, die nicht bei uns liegt. Nach sieben Jahren im Amt sollte man meinen, man steckt so etwas einfach weg. Aber diesmal merke ich, dass es etwas mit mir macht. Wenn man viel Zeit, Energie und Herzblut in so einen Test steckt und dann sieht, wie darüber gesprochen wird, hinterlässt das Spuren.
Ja, ich wäre auch frustriert gewesen, wenn wir kein Sample bekommen hätten. Aber mich hätte mein Ehrgeiz dann eher dazu angetrieben, mir auf anderem Weg ein Sample zu organisieren und einen noch größeren Test umzusetzen. In der nächsten Zeit werdet ihr weniger von mir lesen, denn meine Zeit und Energie werde ich vorerst in andere Projekte investieren. Ich komme wieder, sobald ich für mich den richtigen Fokus gefunden habe.
Der Test des 9950X3D2 war mir persönlich wichtig. Ich habe mich wirklich auf diesen Launch gefreut, weil es etwas Besonderes ist. Solche CPU bleiben schließlich über Jahre spannend (man denke nur an den Ryzen 7 5800X3D). Umso frustrierender ist es, dass sich jetzt vieles nur noch um die Sampling-Situation dreht. Zumal das eine Entscheidung ist, die nicht bei uns liegt. Nach sieben Jahren im Amt sollte man meinen, man steckt so etwas einfach weg. Aber diesmal merke ich, dass es etwas mit mir macht. Wenn man viel Zeit, Energie und Herzblut in so einen Test steckt und dann sieht, wie darüber gesprochen wird, hinterlässt das Spuren.
Ja, ich wäre auch frustriert gewesen, wenn wir kein Sample bekommen hätten. Aber mich hätte mein Ehrgeiz dann eher dazu angetrieben, mir auf anderem Weg ein Sample zu organisieren und einen noch größeren Test umzusetzen. In der nächsten Zeit werdet ihr weniger von mir lesen, denn meine Zeit und Energie werde ich vorerst in andere Projekte investieren. Ich komme wieder, sobald ich für mich den richtigen Fokus gefunden habe.
@PCGH_Dave
Lass dir nicht die Laune vermiesen, ist es nicht wert . Das ist Internetkindergarten wie man es kennt. Ich wundere mich zwar sehr oft welch hohen Stellenwert materielle Güter bei Menschen einnehmen können ( deshalb dachte ich zuerst du verarscht AMD durch die Blume mit deinem Kommentar im Sinne aller Redaktionen was ich cool gefunden hätte ) aber man (ich) muss akzeptieren, dass nicht alle Menschen gleich sind . Damit hat sich das für mich auch erledigt (bzw. hat mich dein Kommentar überhaupt nicht weiter beschäftigt) und ich werde weiterhin gerne deine Artikel lesen wie auch zuvor.
Lass dir nicht die Laune vermiesen, ist es nicht wert . Das ist Internetkindergarten wie man es kennt. Ich wundere mich zwar sehr oft welch hohen Stellenwert materielle Güter bei Menschen einnehmen können ( deshalb dachte ich zuerst du verarscht AMD durch die Blume mit deinem Kommentar im Sinne aller Redaktionen was ich cool gefunden hätte ) aber man (ich) muss akzeptieren, dass nicht alle Menschen gleich sind . Damit hat sich das für mich auch erledigt (bzw. hat mich dein Kommentar überhaupt nicht weiter beschäftigt) und ich werde weiterhin gerne deine Artikel lesen wie auch zuvor.
KevinSimulinski
Komplett-PC-Aufrüster(in)
Nach Lesen der gedruckten Ausgabe eine Anmerkung zum Statement "...den AMD driver weglassen...", an dem ich so meine Zweifel habe, weil ich mich frage, warum immer von "Inter-CCD Latenz" geredet wird.
Nach meiner Recherche gibt es zwischen den L3-Caches der beiden CCDs keine direkte Verbindung, ein L3 nimmt die "victims" der L2 der Cores seines CCD auf, eine CCD-IOD-CCD L3-Übertragung finde ich in keiner Folie.
D.h. der L3 wird nur befüllt wird, wenn Speicherinhalte des vollen L2 eines Cores durch neue ersetzt werden. Und neu in den L2 eines Cores kommen Speicherinhalte nur, indem der Core diese per Instruktion einliest. Einen "Hintenrum-Mechanismus", bei dem sich die L3 der beiden CCDs selbst synchronisieren würden, habe ich in keiner Folie gefunden.
Sehe ich mir dann die zweifarbige Tabelle mit den "Inter-CCD" Latenzen an, bei denen von 70-80 Nanosekunden "zwischen beiden CCDs" die Rede ist, sehe ich Werte, die auch vom RAM-Lesen stammen könnten, da sie DDR5-6000 CL30 inkl. IOD-Latenz unterbieten.
Der nicht nur von euch verwendete MicroBenchX referiert bzgl. Core-Core-Latency auf den CoherencyLatency, der einfach zwei Threads per Affinitymask auf jeweils verschiedene Cores zwingt, die dann einen Speicherbereich entweder "Interlocked", also exklusiv beschrieben (CMPXCHG8B lässt grüßen
) oder nur lesend beharken. Einen direkten Zusammenhang zu explizitem L3 Lesen/Schreiben finde ich nicht, das passt auch zu meinem Finding, dass der L3 ein Victim-Overflow der Core-L2's ist und nichts anderes.
Übrigens muss beim Interlocked-Schreiben über beide CCDs das jeweils andere CCD über die Sperre informiert und dort die L1/L2/L3 Caches invalidiert werden (Cache-Ping-Pong, Thrashing), ich nehme an, das erhöht die Latenz ggü. dem reinen RAM-Zugriff (DDR-6000 mit CL30 etwa 10 ns) ebenso wie die Latenzen zwischen RAM, IOD und CCDs.
Lt. Cohen/Subramony hat der 32 MB L3-Cache eine Zugriffszeit von 8 Prozessor-Cycles, bei 5 GHz wären das 1,6 Nanosekunden, das ist viel kürzer als die MicroBenchX Same-CCD Messung von 22 ns
D.hl MicroBenchX Same-CCD misst ebenfalls nicht die L3-Cache-Latenz, sondern das Exclusiv-Schreiben und dessen Auswirkungen ausserhalb des CCD (evtl. verhindert das IOD den Parallelzugriff durch PCIe/DMA auf die exklusiv beschriebenen Speicherstellen?)
Aus den genannten Punkten geht für mich hervor, dass es keine "Inter-CCD-Latenzen" gibt, vielmehr alles mit konkurrierenden RAM-Zugriffen erklärt werden muss und schliesse daraus:
Wär doch wirklich interessant, wie sich Games ohne den AMD-Treiber verhalten?!?
Nach meiner Recherche gibt es zwischen den L3-Caches der beiden CCDs keine direkte Verbindung, ein L3 nimmt die "victims" der L2 der Cores seines CCD auf, eine CCD-IOD-CCD L3-Übertragung finde ich in keiner Folie.
D.h. der L3 wird nur befüllt wird, wenn Speicherinhalte des vollen L2 eines Cores durch neue ersetzt werden. Und neu in den L2 eines Cores kommen Speicherinhalte nur, indem der Core diese per Instruktion einliest. Einen "Hintenrum-Mechanismus", bei dem sich die L3 der beiden CCDs selbst synchronisieren würden, habe ich in keiner Folie gefunden.
Sehe ich mir dann die zweifarbige Tabelle mit den "Inter-CCD" Latenzen an, bei denen von 70-80 Nanosekunden "zwischen beiden CCDs" die Rede ist, sehe ich Werte, die auch vom RAM-Lesen stammen könnten, da sie DDR5-6000 CL30 inkl. IOD-Latenz unterbieten.
Der nicht nur von euch verwendete MicroBenchX referiert bzgl. Core-Core-Latency auf den CoherencyLatency, der einfach zwei Threads per Affinitymask auf jeweils verschiedene Cores zwingt, die dann einen Speicherbereich entweder "Interlocked", also exklusiv beschrieben (CMPXCHG8B lässt grüßen
) oder nur lesend beharken. Einen direkten Zusammenhang zu explizitem L3 Lesen/Schreiben finde ich nicht, das passt auch zu meinem Finding, dass der L3 ein Victim-Overflow der Core-L2's ist und nichts anderes.Übrigens muss beim Interlocked-Schreiben über beide CCDs das jeweils andere CCD über die Sperre informiert und dort die L1/L2/L3 Caches invalidiert werden (Cache-Ping-Pong, Thrashing), ich nehme an, das erhöht die Latenz ggü. dem reinen RAM-Zugriff (DDR-6000 mit CL30 etwa 10 ns) ebenso wie die Latenzen zwischen RAM, IOD und CCDs.
Lt. Cohen/Subramony hat der 32 MB L3-Cache eine Zugriffszeit von 8 Prozessor-Cycles, bei 5 GHz wären das 1,6 Nanosekunden, das ist viel kürzer als die MicroBenchX Same-CCD Messung von 22 ns
D.hl MicroBenchX Same-CCD misst ebenfalls nicht die L3-Cache-Latenz, sondern das Exclusiv-Schreiben und dessen Auswirkungen ausserhalb des CCD (evtl. verhindert das IOD den Parallelzugriff durch PCIe/DMA auf die exklusiv beschriebenen Speicherstellen?)
Aus den genannten Punkten geht für mich hervor, dass es keine "Inter-CCD-Latenzen" gibt, vielmehr alles mit konkurrierenden RAM-Zugriffen erklärt werden muss und schliesse daraus:
- Workloads, deren Threads vorwiegend thread-lokale Daten beharken, profitieren von 2 x 96 MB L3
- Workloads, deren maximal 16 Threads vom Treiber auf ein CCD gezwungen werden, profitieren ebenfalls
- Workloads, die einen Großteil thread-übergreifende Daten bearbeiten und die nicht auf demselben CCD laufen, profitieren nicht.
Aber grau ist alle Theorie und grün eure Tests, die also nicht nur dir persönlich wichtig sind
Wär doch wirklich interessant, wie sich Games ohne den AMD-Treiber verhalten?!?
Darkearth27
BIOS-Overclocker(in)
Von einem Kern in CCD 1 der Zugriff auf einen Kern in CCD2 braucht wird die Latenz deswegen höher, weil beide DIEs über den FCLK verbunden sind.
Das steht so auch in seinem Artikel online. Der Cache wird dabei gar nicht genutzt in dem Test (Micro-Bench) soweit ich das richtig verstanden habe.
www.pcgameshardware.de
Das steht so auch in seinem Artikel online. Der Cache wird dabei gar nicht genutzt in dem Test (Micro-Bench) soweit ich das richtig verstanden habe.
Ryzen 9 9950X3D2: 8 vs. 16 Kerne - welche ist die richtige Wahl?
Ryzen 7 9850X3D gegen den König Ryzen 9 9950X3D2: Spieler müssen unbedingt auf eine Sache achten! PCGH macht den Vergleich.
KevinSimulinski
Komplett-PC-Aufrüster(in)
Warum glaubst du, dass ein Kern auf einen anderen Kern zugreifen kann?
Ein Core bzw. Thread kann einem anderen Thread nur per Interrupt oder APIC signalisieren, dass er etwas braucht.
Ein Kern greift auch nicht auf den L3 des anderen CCD zu, das ist nirgends so dokumentiert.
Ein Kern kann nicht mal explizit den L3 auslesen, das passiert unter der Haube.
Das Ammenmärchen, dass hier von L3 des CCD1 zu L3 des CCD2 übertragen wird, findet sich in keiner Folie, die AMD bereitstellt.
Zu den Werten des MicroBenchX:
Latenz eigener L3 : 20 ns
Latenz "von anderem L3" : 80 ns
Da lese ich doch schneller von meinem RAM, da kommen die Daten nach etwa 10 ns an.
Und was ist mit den L3-Zugriffszeiten im selben CCD im einstelligen Nanosekunden-Bereich?
Woher kommen die 20/80 ns Werte des MicroBenchX ?
Und sieh mal in den "Cache-to-Cache"-Teil
des MicroBenchX rein, ich zitiere:Und der genannte CoherencyLatency beschreibt den Speicher mit der Funktion _InterlockedCompareExchange64, dahinter steckt ein "gesperrter Speicherzugriff" LOCK CMPXCHG8B, der alles andere macht, als den L3 des anderen CCD zu lesen. Im Gegenteil, der sperrt die Caches und zwar CCD-übergreifend!
Mein Fazit: der MicroBenchX bringt zwar eine schöne Tabelle, nur die Werte haben nicht viel mit L3-Zugriffen zu tun.
Sorry, wenn ich eure heile Doppel-3D-Cache Welt kaputtmache, beweist mir das Gegenteil
(Gelobt sei mein 7800X3D
, da muss ich mir solche Gedanken eigentlich gar nicht machen).
blautemple
Kokü-Junkie (m/w)
Wie kommst du auf den Fantasiewert? Den kannst du mal ganz locker verzehnfachen.
Darkearth27
BIOS-Overclocker(in)
Hä? @kevin keiner redet auch nur im Ansatz über den Cache, außer dir. Lies doch Mal den Text, den Dave dazu geschrieben hat.
KevinSimulinski
Komplett-PC-Aufrüster(in)
Kann man überall nachlesen, z.B. bei Corsair:
CL: CAS Latency. The number of cycles it takes between the processor asking for data from the memory and returning it.
Und bei MEMCLK=3000 MHz -> 0,333 ns wären CL30 = 30 x 0,333 ns = 10 ns für das Auslesen im RAM.
Die Latency beschreibt das Öffnen einer 1K Page, wenn die offen ist, geht's flotter, weil bereits alles eingelesen ist.
Kommt noch die Ausgabe der Adresse durch den Prozessor und die Rückgabe der Daten dazu, das führt m.E. aber auch nicht zu Gesamt-Zugriffszeiten über
Wenn jeder RAM-Zugriff 100 ns brauchen würde, hätten wir bei DDR5 mit 32 Bit:
4 Bytes/100ns = 40 Bytes/µs = 40.000 Bytes/ms = 40.000.000 Bytes/s = 40 MB/s
Fakt sind aber Raten von 60-80 GB/s und die bekomme ich nicht hin, wenn jeder RAM-Zugriff 100 ns dauern würde.
Zumindest behauptet auch Lexar:
A DDR5-6000 kit with CL30 has a true latency of 10 nanoseconds. A DDR5-7200 kit with CL40 has a true latency of 11.1 nanoseconds.
Und die 20 ns bzw. 80 ns in der MicroBenchX Tabelle haben sicher nix mit L3 Cache zu tun. Da finde ich Werte im einstelligen Nanosekunden-Bereich, s. Link auf Cohen/Subramony oder bei Chips&Cheese:.
From L3, a single core can achieve 32 bytes per cycle with only reads or only writes, or 64 bytes per cycle with an even mix of both.
Nicht nur bei PCGH (hier und hier) taucht die per MicroBenchX erzeugte Tabelle auf,
die geistert durch das Web, ohne dass sich jemand die Mühe macht, zu analysieren,
was das Teil konkret misst.
Und mir geht es nur um die Aussage im Heft, dass man den 9950X3D2 auch ohne AMD Treiber, der das Core Parking macht, also die Games auf ein CCD begrenzt, fahren könne. Die zweifel ich an.
Aber das wäre auch ein nettes Test-Thema für das nächste Heft
Darkearth27
BIOS-Overclocker(in)
Ja aber er misst ja gar nicht die L3 Latenzen, sondern die Latenzen, die ein Kern braucht um mit dem anderen zu interagieren.. verstehst du nun warum deine Aussagen so seltsam sind?
Ein Kern braucht, durch die (langsame) Verbindung mit dem FCLK, im selben CCD 20ns während ein Kern im 2. CCD eben 80ns braucht (über die selbe langsame Verbindung des FCLK).
Da ist nirgends die Rede von den L3 Cache Latenzen.
Außerdem wird die Latenz durch den langsamen FCLK immer höher sein, wenn Zugriffe erfolgen, als intern ein Befehl abgearbeitet werden kann / theoretisch könnte. (Stau auf der Datenautobahn).
Ein Kern braucht, durch die (langsame) Verbindung mit dem FCLK, im selben CCD 20ns während ein Kern im 2. CCD eben 80ns braucht (über die selbe langsame Verbindung des FCLK).
Da ist nirgends die Rede von den L3 Cache Latenzen.
Außerdem wird die Latenz durch den langsamen FCLK immer höher sein, wenn Zugriffe erfolgen, als intern ein Befehl abgearbeitet werden kann / theoretisch könnte. (Stau auf der Datenautobahn).
Zuletzt bearbeitet:
Cleriker
PCGH-Community-Veteran(in)
Finde ich ganz ehrlich richtung schade. Lass diese Idioten doch reden. Von denen ist keiner mit Leidenschaft dabei.
Ich weiß natürlich nicht was du so an post bekommen hast, aber mir schien es im Forum darum ruhig geworden zu sein.
blautemple
Kokü-Junkie (m/w)
Nein, das ist die Latenz die vergeht bevor der Arbeitsspeicher die nächste Aktion durchführen kann. Das ist nicht die Latenz zwischen CPU und Ram.
KevinSimulinski
Komplett-PC-Aufrüster(in)
Korrekt, aber wieviel kommt dann noch durch Adresse senden und Daten empfangen via Core + IOD dazu?
Kann mir nicht vorstellen, dass da permanent 80 ns zusammenkommen, sonst würde die Übertragungsleistung von 80 GB/s schwer zustande kommen.
Nach meinem Dafürhalten sind es die Latenzen, mit denen die Kerne mit dem RAM agieren.
Ich finde nirgends einen Hinweis, dass Kerne miteinander agieren können, von Interrupts abgesehen.
Jedenfalls können die Kerne nicht gegenseitig in ihre Caches schreiben.
Und der L3 kann nicht explizit durch Instruktionen beschrieben werden, da geht der Overflow vom L2 rein.
Zumindest finde ich nirgends eine andere Darstellung.
Der Punkt ist auch nicht die CMPXCHG Instruktion, sondern dass sie für die atomare Ausführung mit dem LOCK PREFIX versehen wird und dazu finde ich:
In a multiprocessor environment, the LOCK# signal ensures that the processor has exclusive use of any shared memory while the signal is asserted.
Und lt. Intel manual "8.1.4 Effects of a LOCK operation on Internal Processor Caches":
Instead, it will modify the memory location internally and allow it’s cache coherency mechanism to ensure that the operation is carried out atomically. This operation is called “cache locking.” The cache coherency mechanism automatically prevents two or more processors that have cached the same area of memory from simultaneously modifying data in that area.
Dieses Cache-Sperren geht, wenn das zweite CCD diesen RAM-Bereich gar nicht im Cache hat, recht flott, dauert, wie du auch sagst, über IOD mit FCLK gegen das andere CCD aber länger.
Nur findet nach meiner Ansicht eben kein "Datenaustausch" zwischen den CCDs statt, sondern einfach ein Cache-Locking, das gemessen wird.
Mein eigentliches Problem war aber die Aussage im Absatz "Die Sache mit dem Chipsatz-Treiber":
Es geht hier nur um die Tatsache, dass das zweite CCD geparkt wird. Ein 9950X3D2 kann sich somit beim Gaming nicht anders verhalten als ein 9950X3D. Deshalb spricht AMD auch von der durchschnittlich gleichen Gaming-Performance. Man könnte auch sagen: Pfeifen Sie auf den Chipsatztreiber beim Einsatz des 9950X3D2. Es spielt keine Rolle, auf welchem CCD die Last liegt.
Da sehe ich einen Widerspruch, weil das Parken des zweiten CCDs doch grad bei Games die Performance ggü. ungeparkt erhöht. Oder lese ich das falsch? Grad für Games wurde doch das Parken des Chipsatztreibers eingeführt.
Und Windows - abgesehen von Server Editionen - kennt nativ keine CCDs, da würden die Threads doch zufallsmäßig auf die CCDs verteilt.
Ich selbst kann das nicht beurteilen oder messen, da mein Prozi nur ein CCD hat.
Kann mir daher auch wurscht sein, aber interessant wäre das Verhalten bei Games ohne das CCD-Parking trotzdem.
blautemple
Kokü-Junkie (m/w)
Wie gut dass Latenz und Bandbreite nicht zusammenhängen.
KevinSimulinski
Komplett-PC-Aufrüster(in)
Die große Latenz tritt nur beim Adressieren einer Page (1K) auf, wenn die Page erstmal geöffnet ist, können die Daten darin wesentlich schneller ausgelesen und per Burst transferiert werden, die Übertragung von Daten insgesamt ist quasi ein Mix aus Timings.
Edit: wenn ich die Anzahl der Cycles und die dabei übertragenen Bytes betrachte, brauche ich weder Latenz noch Bandbreite, da sich beide aus den Cycles ergeben:
- Latenz aus der Anzahl der Cycles je Vorgang
- Bandbreite aus der Anzahl der Cycles multipliziert mit der Anzahl der Bytes je Cycle
Zuletzt bearbeitet:
Ähnliche Themen
