Diskussion zu: News des 16. September 2024

[Leonidas]

Link zur News:
https://www.3dcenter.org/news/news-des-16-september-2024

[RoNsOn Xs]

Nur ein gaaanz kleiner Hinweis zur Rechtschreibung: "muß" ist egentlich veraltet. Du schreibst im Konjunktiv auch "müsste".
Ansonsten tolle Arbeit im Allgemeinen! :)

[Gast]

Ich glaube mal die Latenz hat sich nicht um den Faktor ~1 Mio reduziert, sondern eher um Faktor 2-3;)

Latenzen zwischen den beiden CCDs von vorher 180-190ms auf nunmehr um die 75ns zurückgingen

[ENKORE]

Kleiner Tippfehler bei den CCD-Latenzen, es ging von 180ns auf 75ns, nicht 180ms.

[digidoctor]

Zum Text:

Es ist ganz sicher effektiv, sich lange Videos auf der Suche nach Informationen anzuschauen. Es ist lediglich nicht sehr effizient.

[Gast]

Zum Text:

Es ist ganz sicher effektiv, sich lange Videos auf der Suche nach Informationen anzuschauen. Es ist lediglich nicht sehr effizient.

Es ist auch effizient wenn man sich das Video nebenher ansieht.

[Sweepi]

Nebenbei ansehen kann effizienter sein, meistens macht man dann aber mehrere Dinge so ineffektiv, dass auch die Effizienz sinkt.

[Platos]

AMD fixt das Produkt wieder mal nach dem Launch (bezüglich der Latent)

[Lehdro]

Es bleibt noch zu beweisen wie hoch die Performanceunterschiede nach dem Zen 5 "Fix" sind. Der nicht einmal 1% höhere Cinebench Score überzeugt mich jetzt nicht gerade, das ist Messungenauigkeit. Bei einer generellen Latenzverringerung von fast >50% erwarte ich da schon mehr. Einfachster Test: Zen 5 mit 2x CCD im Gaming ohne CCD Priorisierung, da sollte das deutlich sichtbar sein.

Solange bleibe ich da eher an der Theorie hängen, dass das Problem der Latenz an der Art und Weise des Tests liegt und eben nicht genereller Natur ist.

[Gast]

Der nicht einmal 1% höhere Cinebench Score überzeugt mich jetzt nicht gerade, das ist Messungenauigkeit.


Logisch, dass Cinebench davon kaum profitiert.
Aber ja generell ist davon nicht viel zu erwarten, CCD zu CCD Latenzen sind ja generell schlecht, würde das so viel Performance kosten, würden ja alle Multichip-CPUs generell schlecht skalieren.


Bei einer generellen Latenzverringerung von fast >50% erwarte ich da schon mehr. Einfachster Test: Zen 5 mit 2x CCD im Gaming ohne CCD Priorisierung, da sollte das deutlich sichtbar sein.


Was sollte das beim Gaming großartig bringen, wenn kein Game > 8 Cores sinnvoll einsetzt?


Solange bleibe ich da eher an der Theorie hängen, dass das Problem der Latenz an der Art und Weise des Tests liegt und eben nicht genereller Natur ist.

Wenn der selbe Latenztest eine Verbesserung zeigt kann es nicht an der Testmethode liegen.

[Freestaler]

CB ist meiner Mening nach wohl eines der schlechtesten Dinge für die Lantenzrelevanz. Was soll da gross zwischen den CCD umhergehen? Rechnet ja jeder thread für sich alleine. Und dies für einige Sekunden. Wenn am Anfang und am Schluss je 75ns gewohnen werden, geht dies einfach nicht ins Gewicht. Kein andere Thread warte wirklich mit seiner arbeit auf nen anderen.

[Sweepi]

Genau, zu erwarten wären Gewinne eher bei Anwendungen, die sehr viele sehr kurze Prozesse/Threads starten, oder viel IPC (https://en.wikipedia.org/wiki/Inter-process_communication) betreiben.
Hat hier jemand Beispiele?

[Leonidas]

Ich glaube mal die Latenz hat sich nicht um den Faktor ~1 Mio reduziert, sondern eher um Faktor 2-3;)

Garantiert nicht! Aber ich hab schön gelacht bei diesem Posting bzw. dieser Wortwahl.


Latenzen zwischen den beiden CCDs von vorher 180-190ms auf nunmehr um die 75ns zurückgingen

Logisch. Gefixt.

[Gast]

Mein Tipp ist, in die automatisch generierten Untertitel zu schauen, wenn man eine bestimmte Info in einem Video sucht. :)


147
00:06:19,520 --> 00:06:24,840
4070 results are based on the found

148
00:06:22,039 --> 00:06:26,880
addition model which is clocked almost a

149
00:06:24,840 --> 00:06:30,240
percent about a percent lower than the

150
00:06:26,880 --> 00:06:32,639
gigabyte windforce OC version that I've

151
00:06:30,240 --> 00:06:34,360
purchased here so the clock speeds are

[Leonidas]

Ich hätte einfach der Transcription folgen sollen, die ist sogar nach Kapiteln unterteilt. Wäre einfach gewesen, es richtig zu machen. Wie gesagt mein Fehler.


Nur ein gaaanz kleiner Hinweis zur Rechtschreibung: "muß" ist egentlich veraltet. Du schreibst im Konjunktiv auch "müsste".

Ich fand es in dem Augenblick besser, die alte Schreibweise zu verwenden. Nach dem "muß" kommt ein Bindestrich als Unterteilung zu einer entweder/oder-Situation. Da macht sich das schärfer aussehende "ß" als letzter Buchstabe vor der Unterteilung besser, um den Gegensatz beider Satzteile auch optisch bestmöglich zu verstärken.

[Zossel]

Im Mix aller Benchmarks dürfte sich der Performance-Effekt allerdings in Grenzen halten, ein Nutzer im Overclock-Forum zeigt nur +1% Mehrperformance unter dem Cinebench R23. In der Vielzahl kleinerer Patches dürfte sich die Performance von Ryzen 9000 dennoch noch beachtbar bewegen – was damit (leider) den zum Launch aufgestellten Performance-Stand entwertet.

Da findet ja quasi keine Synchronisation statt und die Größe der Jobs ist ja auch quasi beliebig wählbar. Sowas skaliert auch locker über mehrere Computer.

[Zossel]

Solange bleibe ich da eher an der Theorie hängen, dass das Problem der Latenz an der Art und Weise des Tests liegt und eben nicht genereller Natur ist.

Ich hatte doch die Quellen des Testtools verlinkt, das ist alles andere als eine Black Box über die man nur spekulieren kann. Das kann man sauber runterbrechen und analysieren.

https://www.forum-3dcenter.org/vbulletin/showpost.php?p=13615181&postcount=1301

[Sweepi]

zu den Untertiteln: Hat jemand einen Tipp/Addon/Webseite, wo diese in "lesbarer" Form präsentiert werden? Die yt transcript hat so ziemlich den schlimmsten Einstellungen für Zeilenabstand und Wörter pro Zeile, die man sich vorstellen kann.

[Lehdro]

Was sollte das beim Gaming großartig bringen, wenn kein Game > 8 Cores sinnvoll einsetzt?
Ganz einfach: Weil ohne Priorisierung die Latenz heftig reinhaut. Eine doppelt so hohe Latenz demzufolge heftiger. Hier geht es nicht um die absolute Performance, sondern die relative Performance untereinander um zu sehen wie sehr sich das ganze auswirkt.

Also beide Tests ohne PPM Driver, aber mit unterschiedlichen AGESAs. Ootb, springen die Threads bei den Dual CCDs CPUs beim Gaming hin und her. Quasi worst case.

Wenn der selbe Latenztest eine Verbesserung zeigt kann es nicht an der Testmethode liegen.
Wenn der Test eine spezifische Abfrage stellt testet man eben nur das: Diesen spezifischen Fall. Der y-Cruncher Autor schreibt folgendes dazu: (https://www.overclock.net/posts/29367758/)
That was faster than I thought. I guess I can say this now that it has happened. One of the lead architects told me that the latency regression was because they changed a bunch of tuning parameters for Zen5. It helped whatever workloads they were testing against, which is why they did it. But now that the reviews are out, they realized that the change looked really bad for synthetics. So they were going to roll it back. But they said "it would take a while" due to validation.

Ich hatte doch die Quellen des Testtools verlinkt, das ist alles andere als eine Black Box über die man nur spekulieren kann. Das kann man sauber runterbrechen und analysieren.

Bleibt im Endeffekt alles Spekulation bis mal endlich jemand wirklich relevantes testet. Es ist egal was und wie du synthetisch benchmarkst, wenn die Praxis anders aussieht, siehe die Aussage von dem AMD Lead Architect oben.

[Gast]

Ganz einfach: Weil ohne Priorisierung die Latenz heftig reinhaut. Eine doppelt so hohe Latenz demzufolge heftiger.



Du brauchst keine Priorisierung, die Betriebssysteme lassen schon lange automatisch Threads zum selben Prozess auf einem CCX.


[/QUOTE]

[Lehdro]

Du brauchst keine Priorisierung, die Betriebssysteme lassen schon lange automatisch Threads zum selben Prozess auf einem CCX.

Ist halt nacherwiesenermaßen Unfug was du da erzählst. (https://www.computerbase.de/2024-08/amd-ryzen-9-9900x-9950x-test/#abschnitt_alte_windows_und_softwareprobleme_neu_aufgelegt) Nicht ohne Grund gibt es für die 2 CCD Zen 4 X3Ds und jetzt auch für die 2 CCD Zen 5 den PPM Treiber von AMD, der dafür sorgt dass das eben so passiert wie gedacht: Ein CCD wird schlafen (Core Parking) gelegt für das Spiel, damit nur ein CCD genutzt werden kann und kein CCD-Hopping betrieben wird. (https://www.anandtech.com/show/21524/the-amd-ryzen-9-9950x-and-ryzen-9-9900x-review)

Als ehemaliger 1800X, 2950X und 5950X Nutzer kann ich dir aus der Praxis berichten, dass CCX/CCD Hopping durchaus real ist.

[Sweepi]

Ganz einfach: Weil ohne Priorisierung die Latenz heftig reinhaut. Eine doppelt so hohe Latenz demzufolge heftiger. Hier geht es nicht um die absolute Performance, sondern die relative Performance untereinander um zu sehen wie sehr sich das ganze auswirkt.

Also beide Tests ohne PPM Driver, aber mit unterschiedlichen AGESAs. Ootb, springen die Threads bei den Dual CCDs CPUs beim Gaming hin und her. Quasi worst case.

Man könnte die Threads eines Spiels über die CCDs verteilen. Das wäre ein interessanter Test, sind Spiele bekannt, wo die Threads sich gegenseitig viele Daten zuschieben bzw. wo mehrere Threads auf die gleichen Datenstrukturen zugreifen?


Wenn der Test eine spezifische Abfrage stellt testet man eben nur das: Diesen spezifischen Fall. Der y-Cruncher Autor schreibt folgendes dazu: (https://www.overclock.net/threads/official-zen-5-owners-club-9600x-9700x-9900x-9950x.1811777/page-53?post_id=29367748#post-29367748)

Der Link führt bei mir zu einem anderen Beitrag, dieser hier funktioniert für mich: https://www.overclock.net/posts/29367758/


Bleibt im Endeffekt alles Spekulation bis mal endlich jemand wirklich relevantes testet. Es ist egal was und wie du synthetisch benchmarkst, wenn die Praxis anders aussieht, siehe die Aussage von dem AMD Lead Architect oben.

Um die Spekulation zu minimieren, das hier wird im "CoherencyLatency" Benchmark getestet:



while (current <= 2 * latencyData->iterations) {
if (_InterlockedCompareExchange64(latencyData->target, current, current - 1) == current - 1) {
current += 2;
}
}


Dokumentation:
https://learn.microsoft.com/en-us/windows/win32/api/winnt/nf-winnt-interlockedcompareexchange64
https://learn.microsoft.com/en-us/cpp/intrinsics/interlockedcompareexchange-intrinsic-functions?view=msvc-170


Mehr Boilerplate:


// Run all to all, skipping testing a core against itself ofc
// technically can skip the other way around (start j = i + 1) but meh
for (DWORD i = 0; i < numProcs; i++)
{
for (DWORD j = 0; j < numProcs; j++)
{
latenciesPtr[j + i * numProcs] = i == j ? 0 : RunTest(i, j, iter);
}
}

float RunTest(unsigned int processor1, unsigned int processor2, uint64_t iter)
{
LatencyData lat1, lat2;
float latency;

*bouncy = 0;
lat1.iterations = iter;
lat1.start = 1;
lat1.target = bouncy;
lat2.iterations = iter;
lat2.start = 2;
lat2.target = bouncy;

latency = TimeThreads(processor1, processor2, iter, lat1, lat2, LatencyTestThread);
return latency;
}

float TimeThreads(unsigned int processor1, unsigned int processor2, uint64_t iter, LatencyData lat1, LatencyData lat2, DWORD (*threadFunc)(LPVOID))
{
struct timeb start, end;
HANDLE testThreads[2];
DWORD tid1, tid2;

testThreads[0] = CreateThread(NULL, 0, threadFunc, &lat1, CREATE_SUSPENDED, &tid1);
testThreads[1] = CreateThread(NULL, 0, threadFunc, &lat2, CREATE_SUSPENDED, &tid2);

if (testThreads[0] == NULL || testThreads[1] == NULL)
{
fprintf(stderr, "Failed to create test threads\n");
return -1;
}

SetThreadAffinityMask(testThreads[0], 1ULL << (uint64_t)processor1);
SetThreadAffinityMask(testThreads[1], 1ULL << (uint64_t)processor2);

ftime(&start);
ResumeThread(testThreads[0]);
ResumeThread(testThreads[1]);
WaitForMultipleObjects(2, testThreads, TRUE, INFINITE);
ftime(&end);

int64_t time_diff_ms = 1000 * (end.time - start.time) + (end.millitm - start.millitm);
float latency = 1e6 * (float)time_diff_ms / (float)iter;

fprintf(stderr, "%d to %d: %f ns\n", processor1, processor2, latency);

CloseHandle(testThreads[0]);
CloseHandle(testThreads[1]);

// each thread does interlocked compare and exchange iterations times. divide by 2 to get overall count of locked ops
return latency / 2;
}

DWORD WINAPI LatencyTestThread(LPVOID param)
{
LatencyData *latencyData = (LatencyData *)param;
uint64_t current = latencyData->start;
while (current <= 2 * latencyData->iterations)
{
if (_InterlockedCompareExchange64(latencyData->target, current, current - 1) == current - 1) {
current += 2;
}
}

return current;
}

[Gast]

Ein CCD wird schlafen (Core Parking) gelegt für das Spiel, damit nur ein CCD genutzt werden kann und kein CCD-Hopping betrieben wird.


Du willst kein Core-Parking wenn du keinen X3D hast.


Als ehemaliger 1800X, 2950X und 5950X Nutzer kann ich dir aus der Praxis berichten, dass CCX/CCD Hopping durchaus real ist.

Damals waren die Betriebssysteme auch noch nicht upgedatet.

[Lehdro]

Man könnte die Threads eines Spiels über die CCDs verteilen. Das wäre ein interessanter Test, sind Spiele bekannt, wo die Threads sich gegenseitig viele Daten zuschieben bzw. wo mehrere Threads auf die gleichen Datenstrukturen zugreifen?
CFX postet auf Twitter öfter mal Ergebnisse ohne/mit manueller Zuweisung auf bestimmte CCDs. Ich kann mal schauen ob ich da ein paar Extrembeispiele finde in seinen Postings, er nutzt dafür "Thread Affinity" über CapFrameX.

Der Link führt bei mir zu einem anderen Beitrag, dieser hier funktioniert für mich: https://www.overclock.net/posts/29367758/
Mea culpa, habe es mal korrigiert, danke!

Um die Spekulation zu minimieren, das hier wird im "CoherencyLatency" Benchmark getestet:
Das geht mir leider schon etwas zu weit für meinen simplen Verstand gerade :freak:
Du willst kein Core-Parking wenn du keinen X3D hast.

Sieht AMD anders.

Damals waren die Betriebssysteme auch noch nicht upgedatet.
Du kannst das gerne mit einem 5950X oder 7950X unter Win 11 testen, das Resultat bleibt: Es wird recht wild rumgethreaded wenn keine Eingriffe vorliegen.

[Exxtreme]

Damals waren die Betriebssysteme auch noch nicht upgedatet.

WinDOS macht es trotzdem und verteilt die Threads wild wie es grad passt. Deshalb gibt es ja auch in der Xbox Gamebar die Option, dass man Spiele extra als Spiele markiert wenn diese nicht erkannt werden.

[MiamiNice]

Der nicht einmal 1% höhere Cinebench Score überzeugt mich jetzt nicht gerade, das ist Messungenauigkeit. Bei einer generellen Latenzverringerung von fast >50% erwarte ich da schon mehr.

Man müsste das mit Software testen die tatsächlich auf die Core to Core Latenz angewiesen ist. CB ist das nicht. CB skaliert auch schlecht mit Ram Latenz. CB und Blender sind die perfekten Beispiele für Software in der es fast nur auf die Kerne ankommt (Menge + IPC + Takt). Keine Core to Core Latenz weil keine Daten zwischen den Kernen ausgetauscht werden. Keine Ram Latenz da der Prefetcher sich nicht "vergreifen" kann. Es steht von 0 bis 100 Prozent fest welche Daten als nächstes verarbeitet werden müssen. Es gibt keine Abhänigkeiten von Ergebnissen anderer Kerne.

Deswegen hat AMD bei Zen 1 Release auch genau diese Art Software gewählt (Blender + AMD Logo). Es zeigt quasi 0 die Leistungsfähigkeit von CPUs unter normalen Arbeitseinsatz. Quasi ein irrelavanter synthetischer Test.

PS: Star Citizen würde wahrschinlich gut ausschlagen bzgl. C2C Latenz. Jedes Game welches mehr Kerne nutzt als in einem CCD vorhanden sind.

[bad_sign]

Als ehemaliger 1800X, 2950X und 5950X Nutzer kann ich dir aus der Praxis berichten, dass CCX/CCD Hopping durchaus real ist.
Beim 5950X hatte ich damit nie "Probleme".
CPPC enabled im BIOS und Win10. Von Dez 20 - April 23 in Nutzung

"Probleme": Games blieben die allermeiste Zeit auf CCD0, CCD1 hat fast nie eine Auslastung angezeigt.

Quasi ein irrelavanter synthetischer Test.

Nicht irrelevant, sondern nur aussagekräftig für Tile-based-rendering.
Fürs zocken schaue ich auch keine AVX512 Benchmarks an, oder für CPU Tests keine GPU Tests :)

Idealerweise versteht man sein Anwendungsgebiet und sucht entsprechende Tests auf.

[Gast]

Sieht AMD anders.



Das selbe AMD das dir sagt du sollst dein Windows neuinstallieren wenn du deine CPU wechselst und bis heute weder einen vernünftigen installer noch uninstaller zustande bringt.

AMD sollte Eingriffe ins Betriebssystem besser den Profis überlassen.

[Zen-Flop 5%]

Selbst beim global führenden AMDfactory - aka Mindfactory :D - hat man seit Release nur einen ganzen Wafer an zen 5 Chiplets für Desktop Ryzen 9000 verkauft.

Bin dennoch optimistisch und warte ab, bis einige Ryzen 9900X/9950X Besitzer (oder Reviewer/Tester) mit vorheringen und jetzigem AM5 Agesa dies gegentesten.
Dann weiß man auch ob dies alles nur Schönmalerei ist und blos dem Äußerlichen dient (synthetische Tests), wie den einen führenden Architekten hier zitiert.

Ich vermute aus Zen-Flop 5%, wird nun Zen-Flop 6% für die ineffiziente 2-CCD Grütze mit altbackenem pcb copper wiring.
Fürs Spielen aus 2 %, vllt. 3 %?
:D

Nova Lake 2027, Zen 6, mit 16-P Kernen und besserem Packaging, kann nicht früh genug erscheinen.

[Zen-Flop 5%]

Beim 5950X hatte ich damit nie "Probleme".
CPPC enabled im BIOS und Win10. Von Dez 20 - April 23 in Nutzung

"Probleme": Games blieben die allermeiste Zeit auf CCD0, CCD1 hat fast nie eine Auslastung angezeigt.
...
Schlecht gelogen.
Habe selbst eine 2-CCD Ryzen 5000 Grütze. Ob Win 11 22H2, 23H2, ob nun 24H2 mit all den Wunder-Updates, ob im UEFI die beiden CPPC Optionen aktiviert, ob Windows Gamebar einwandfrei läuft und alle Spiele als solche gekennzeichnet sind, ob AMDs Chipset-Treiber ordentlich installiert ... die Kern-Auslastung bei Spielen psringt ständig zwischen CCD0 und 1 hin-und-her.

Ob bei älteren Spielen aus <2010, oder nun neueren von >2020.
Das der zweite CCD also fast nie eine Auslastung zeigt, ist gelogen.

https://youtu.be/1gMh3ljtTLY?feature=shared&t=214
Hier ist übrigend ein Youtuber - nein, nicht der übliche Fake-Benchmark Kanal mit erlogenen oder schlecht durchgeführten Tests, sondern ein ganz guter - der dass nun sehr CPU-anspruchsvolle Space Marine 2 mit Ryzen 3700X, 5900X, 7700X und 7800X3D mehrfach getestet hat.

CCD1 beim Ryzen 5900X deaktiviert (SMT aber an), hat etwas bessere Durchschnitts- und 1 % FPS. Sieht man auch am Frametime-Balken oben im Video.
Sein Windoof 11 ist die Pro-Version, aktuell gepatched, samt neuesten Grafiktreibern.



Ich habe dies mit einigen Spielen selber getestet. CCD1 deaktiviert (SMT aber an), steigt die durchschnittliche CPU-Frequenz von ~ 4500 - 4550 MHz auf 4650 - 4700 MHz und ich beobachte bei älteren Spielen eine höhere GPU-Auslastung.

Bei neueren Spielen, deaktiviere ich im UEFI das SMT (es sind dann 12 Kerne/12 Threads). Ich beobachte das verglichen mit 12 Kernen/24 Threads, auch hier die durchschnittliche CPU-Frequenz etwas ansteigt, samt GPU-Auslastung.

Sollte bei Ryzen 7000 & 9000 auch nicht anders sein.
Fazit: Das überteuerte und ineffiziente AMD-Gemelke mit der 2-CCD Grütze und uraltem pcb copper wiring von x900X/x950X, hier sollte man entweder einen CCD deaktivieren, oder SMT.
;)

[Zossel]

Nur ein gaaanz kleiner Hinweis zur Rechtschreibung: "muß" ist egentlich veraltet. Du schreibst im Konjunktiv auch "müsste".

Seit wann ist deutsche Rechtschreibung konsequent regelbasiert oder orthogonal oder kongruent?

[Zossel]

Du willst kein Core-Parking wenn du keinen X3D hast.

Ist Core-Parking ein Windowism?

[Zossel]

Man müsste das mit Software testen die tatsächlich auf die Core to Core Latenz angewiesen ist. CB ist das nicht.
Deswegen hat AMD bei Zen 1 Release auch genau diese Art Software gewählt (Blender + AMD Logo). Es zeigt quasi 0 die Leistungsfähigkeit von CPUs unter normalen Arbeitseinsatz. Quasi ein irrelavanter synthetischer Test.

PS: Star Citizen würde wahrschinlich gut ausschlagen bzgl. C2C Latenz. Jedes Game welches mehr Kerne nutzt als in einem CCD vorhanden sind.

Du spricht oben von anderer Software, die später als für den "normalen Arbeitseinsatz" notwendig betrachtet werden.

Warum benennst du diese Software nicht?

[ryan]

Das Royal Core Projekt wurde aufgelöst. Hat Leonidas das verpasst? Der linkedin Eintrag mit Royal/Cobra stammt aus dem Jahr 2023 und ist somit wertlos, weil Royal Core erst diesen Sommer aufgelöst wurde. Davon abgesehen verstehe ich nicht wie man auf Cobra als Nachfolger kommt wenn Royal und Cobra zusammenstehen. Das liest sich eher nach einer Variante von Royal Core. Und Royal Core ist das Projekt, die Kerne wären anders benannt wurden. Nova Lake bekommt Coyote Cove im übrigen.

[Leonidas]

Nicht mal MLID hat geschrieben, das Royal Core im kompletten abgelöst wurde. Es wird lt. MLID nur nicht bis zur letzten Stufe gebracht.

[ryan]

Nicht mal MLID hat geschrieben, das Royal Core im kompletten abgelöst wurde. Es wird lt. MLID nur nicht bis zur letzten Stufe gebracht.


Was heißt nicht mal MLID? Der interessiert mich nicht. Ich rede von sicheren Quellen, die bislang immer richtig lagen und seriös sind, was man von MLID nicht behaupten kann. Und wo bitte hat MLID nicht davon gesprochen, Beast Lake wäre Geschichte?



Laut Moore's Law Is Dead (MLID) wurde Intels Beast Lake Architektur gestrichen.
https://www.notebookcheck.com/Intel-spaltet-angeblich-Jim-Kellers-revolutionaeres-Royal-Core-Projekt-auf-und-stoppt-Beast-Lake.872443.0.html

Hä? Bei dir stehts noch drin!

Auch haben sich ehemalige Mitarbeiter geäußert, hier muss niemand auf MLID zurückgreifen und sollte das auch nicht tun. Naja mir egal, keine Lust wieder den Aufklärer zu spielen, du bist eh zu stur um das einzusehen. Wirst halt wieder falsch liegen. Keiner erwartet Royal Core, nur der Newsschreiber vom 3dcenter nicht, wie typisch. Deine Roadmaps kann man nicht für voll nehmen.

[MiamiNice]

Du spricht oben von anderer Software, die später als für den "normalen Arbeitseinsatz" notwendig betrachtet werden.

Warum benennst du diese Software nicht?

Weil jeder einen anderen Workflow an seinem PC hat und andere Programme nutzt. Aber der Punkt ist, dass CB nur taugt um einen Wert abzufragen, nämlich die reine Power eines oder mehrerer Kerne mit linearen Code. Das ist speziell und kann nicht die C2C Latenz Verbesserungen zeigen.

Nicht mal MLID hat geschrieben ...

Wann hört ihr endlich auf diesem und anderen Scharlatanen die Miete zu zahlen?

[Leonidas]

Was heißt nicht mal MLID? Der interessiert mich nicht. Ich rede von sicheren Quellen, die bislang immer richtig lagen und seriös sind, was man von MLID nicht behaupten kann. Und wo bitte hat MLID nicht davon gesprochen, Beast Lake wäre Geschichte?

https://www.notebookcheck.com/Intel-spaltet-angeblich-Jim-Kellers-revolutionaeres-Royal-Core-Projekt-auf-und-stoppt-Beast-Lake.872443.0.html

Hä? Bei dir stehts noch drin!

Auch vollkommen zu Recht. MLID hat nix von "Beast Lake ist gestrichen" gesagt. Er bezog das auf "Beast Lake Next". Original-Aussage hier:
https://www.3dcenter.org/news/news-des-3-september-2024

Das sagt nicht aus, das MLID richtig liegt. Aber es sagt aus, dass lt. MLID "Beast Lake" tatsächlich noch kommen soll. Was andere dazu falsch abschreiben, kann ich nicht beeinflußen.