-
ComputerBase erhält eine Provision für Käufe über eBay-Links.
News Intel Nova Lake: Cache-Größen der Core Ultra 400 entschlüsselt
- Ersteller MichaG
- Erstellt am
- Zur News: Intel Nova Lake: Cache-Größen der Core Ultra 400 entschlüsselt
LeckerRK
Lieutenant
- Registriert
- Aug. 2009
- Beiträge
- 514
Intel zu blöd zum Programmieren ... um den vollen Level 3 Cache zu nutzen müssen alle Cores und Kerne aktiv sein E core c core y core abc core ... ob 16 kerne oder 54 spielt absolut keine Rolle weil es dafür für einen normal Verbraucher keine Software gibt die es nutzen kann und Spiele auf gar keinen Fall ....^^
Intel hatte mal die besten CPU`s aber das ist schon ewig lange her.Ich empfehle nur noch AMD X3D oder X3D2.
Ergänzung ()
Intel hatte mal die besten CPU`s aber das ist schon ewig lange her.Ich empfehle nur noch AMD X3D oder X3D2.
Ergänzung ()
https://www.ebay.de/itm/26763997017...teo_ad=2856993&cto_pld=oK2MGF0QAADL3aG1JmYM3wBAR86 schrieb:
Zuletzt bearbeitet:
lynx007
Rear Admiral
- Registriert
- Feb. 2011
- Beiträge
- 5.755
Ist das nicht falsch herum? Sorry mein Littleman ist etwas her... Ich habe noch nicht mein HelloWorld in Asmbler auf meiner Todo Abgehackt... ab ich muss doch als Dev definieren, wo was auf welchen Kern läuft... und das war ja auch anfangs ein riesen Problem, weil das so einfach lange über OS nicht so sauber funktionierte, weshalb auch, hau mich nicht tot wen ich total käse oder die falsche CPUs nenen, aber war das nicht ein Problem von manchen Threadrippern, weil eben der code random über kerne geschubst wurde... was schlecht für die bit latenz war?!mae schrieb:
und ich weiß, intel arbeit daran, das sheduling vom OS weg zu nehmen... zumindest bilde ich mir das ein... ist das schon hier der case? Aber woher weiß dann bei komplexen code, wo wie was welchen timefrime bruacht... das steht ja nicht gehash? oder wird das mit gehashed? sprich der hash bildet meine anforderungen ab?
Deshalb ist ja auch Multithreading in gaming oft nicht Ideal gewsen... weil dann sogar kernteile, lociceinheiten sich um sachen stritten, und die entscheidungen länger gedauert haben , als wen es sauber, in einem strang nacheinander abgehandelt wurde...???mae schrieb:
Ich habe erhlic h gesagt überhaupt kein plan darüber. ich habe letztens nen vid über Atari 500 Nerds gesehen, die in asembler nen Videos Demo realisieren.... und schon dort alle achtung... Aber mich intressiert das schon irgendwie... weil scheinbar die notwendigkeit von Asembler nie total auszusterben scheint. Aber ich bin da ncoh gefühlt 5 jahre von meinem HelloWorld weg.mae schrieb:
Aber wer stellt die hirachie auf.... macht das der Compiler? ist der compiler allein dafür verantwortlich, das alles auf die richtigen Kerne landet?mae schrieb:
Ja das ist aber der punkt wo ich bis strugle nach neuman-archetektur... aber vermutlich bin ich wieder total falsch oder ganz woanders... ist wohl auch unnätzes wissen für jeden der niemals an nem Reisbrett für Chipfertigung arbeitet.... wie das genau organiseirt ist....mae schrieb:
aber das ist asembler ebende... oder geht das auf compiler ebene? ich halt son pythen/Jawa dau.....mae schrieb:
aber man merkt schnell, alles was mit effizens zu tun hat geht richtung c und asembler... NIcht wirklcih wen man jetzt gaming bleibt... und das nur benchmarks anschaut.... da kommt man nicht viel in kontakt mit asembler und c hardware nahen sachen... Wen man im Datencenter arbeitet... sieht das sicher anders aus... bzw gibt ja auch viele Usecases wo Intel kreise um AMD ziehen soll.... Mich interessierte mich nur wie das gehandelt bekommen das "zuviele köche...." alles zum stottern bringen. Bin gespannt auf die testsmae schrieb:
@LeckerRK Wird aber nicht. Und du wirst so oder so immer das Problem haben, dass ein Kern auf CCD1 was vom Cache auf CCD2 haben wollen könnte. Besonders bei Spielen wird es sehr schwierig sicherzustellen, dass dem nicht so ist. Du wirst also auch da Latenz Probleme haben.
Mit anderen Worten es ist für 99% der Anwender in komplett sinnloses Produkt. Es macht nur Sinn wenn du zwei separate Instanzen von etwas was den riesen Cache mag hast. Mit anderen worten es ist super für Spiele server. Das ist aber auch alles.
Mit anderen Worten es ist für 99% der Anwender in komplett sinnloses Produkt. Es macht nur Sinn wenn du zwei separate Instanzen von etwas was den riesen Cache mag hast. Mit anderen worten es ist super für Spiele server. Das ist aber auch alles.
Welche dann wahrscheinlich so viel Energie verbrauchen und Abwärme produzieren, dass du (deutlich) stärker limitiert wirst.DarkStarXxX schrieb:
Multithreaded Anwendungen profitieren stärker von der P/E-Kombi, wenn man die CPU nicht mit Strom bombadieren kann/will. Und Spiele profitieren von so vielen Kernen erst gar nicht. Nova Lake und Zen6 werden dann hoffentlich durch spezifische Benchmarks zeigen, welche wenigen Spiele von mehr als 8 Kernen überhaupt (irgendwie oder nennenswert) insbesondere abseits besseren Taktfrequenz-Binnings profitieren können.
Man sollte sich nicht ständig auf die Auflösung beschränken. Die Auswahl der Spiele und der Wunsch mit einer Mindest-FPS rendern zu wollen sind viel wichtiger.MCCornholio schrieb:
Hardware Unboxed hat erst kürzlich mit neuen Intel CPU Benchmarks der letzten 10 Jahre gezeigt, dass selbst ein 7700K noch 60 fps erreichen kann. Selbst in CP2077, HZD-Remastered und Spiderman 2 sind bis zu 100 fps möglich! Mit Zen3 und Alder Lake/DDR4 erreicht man je nach Spiel und eigenen Ansprüchen locker über 120 fps.
3D V-Cache ist vieles, aber nicht billig. xDlynx007 schrieb:
LeckerRK
Lieutenant
- Registriert
- Aug. 2009
- Beiträge
- 514
Der Test hat nicht viel gebracht nur den Stromverbrauch in die Höhe getrieben,ich sehe das momentan als sinnlos an ,aber in Zukunft wenn der Dual Cache richtig arbeitet und vor allem Spiele und Programme den nutzen daraus ziehen können,wäre es eine Lösung ohne hohem Stromberbrauch.12nebur27 schrieb:
@LeckerRK ich kann dir jetzt schon versprechen, dass das nicht in der Zeit kommt in welcher der Prozessor relevant ist, selbst wenn es irgendwann kommen sollte.
Es gibt da zwei Szenarien für die es relevant sein könnte.
Szenario 1:
1 CCX betreibt das Spiel und wenn sein L3 Cache voll ist, dann packt er das halt in den L3 vom anderen CCX. In der Theorie ist das ganz nett, in der Praxis halt nicht wirklich hilfreich, weil wir die unglaubliche Latenz haben über das Infinity Fabric darauf zuzugreifen. Das Fabric ist da ne richtig lame Ente. Ja, ist ein bissel schneller als ein dram Zugriff aber nicht genug als das das ein ernsthaftes Kaufargument für Endkunden sein wird. Dafür müsste die Zugriffszeit deutlich runter gehen (und du kannst da ja auch noch nen miss haben und musst dann nachdem du da den miss hattest zum dram gehen). Über so eine Lösung können wir anfangen zu reden wenn das fabric mal viel viel schneller ist.
Szenario 2:
Beide CCXs arbeiten zusammen die Spiel Arbeitslast ab. Damit das überhaupt relevant wird braucht es erstmal eine signifikante Anzahl an Spielen, die derartig gut parallelisierbar sind, dass sie signifikant von mehr Multicore performance als 8 Zen 5 kerne profitieren können. Zusätzlich dazu müssen die dann auch noch sehr viel von dem extra Cache profitieren können. Und sobald wir diese Konstellation haben fällt aber recht schnell auf, dass man ein ziemlich kompliziertes Konstrukt hat und man eigentlich wahrscheinlich recht viele daten sowohl in dem einen CCX als auch in dem anderen vorhalten will, denn das nervigste wäre ja, dass ein Kern von CCX 1 was aus dem l3 von CCX 2 haben will (und umgekehrt), besonders, wenn es sich im eine Anwendung handelt die extrem mit Cache Zugriffszeit skalliert. Das kann aber in dieser Konstruktion recht schnell passieren.
Kurzum, warum sich solche Kopfschmerzen machen, wenn du auch einfach mehr Kerne in ein CCX tun kannst und untersuchen kannst, ob z. B. zusätzlich eine Verdopplung des L3 caches auf besagtem CCX weitere Sprünge in der Performanz erlauben? Und selbst wenn irgendwann mal trotzdem L3 auf 2 CCX mainstream wird, dann ganz sicher nicht mit der IF Latenz von Zen5.
Es gibt da zwei Szenarien für die es relevant sein könnte.
Szenario 1:
1 CCX betreibt das Spiel und wenn sein L3 Cache voll ist, dann packt er das halt in den L3 vom anderen CCX. In der Theorie ist das ganz nett, in der Praxis halt nicht wirklich hilfreich, weil wir die unglaubliche Latenz haben über das Infinity Fabric darauf zuzugreifen. Das Fabric ist da ne richtig lame Ente. Ja, ist ein bissel schneller als ein dram Zugriff aber nicht genug als das das ein ernsthaftes Kaufargument für Endkunden sein wird. Dafür müsste die Zugriffszeit deutlich runter gehen (und du kannst da ja auch noch nen miss haben und musst dann nachdem du da den miss hattest zum dram gehen). Über so eine Lösung können wir anfangen zu reden wenn das fabric mal viel viel schneller ist.
Szenario 2:
Beide CCXs arbeiten zusammen die Spiel Arbeitslast ab. Damit das überhaupt relevant wird braucht es erstmal eine signifikante Anzahl an Spielen, die derartig gut parallelisierbar sind, dass sie signifikant von mehr Multicore performance als 8 Zen 5 kerne profitieren können. Zusätzlich dazu müssen die dann auch noch sehr viel von dem extra Cache profitieren können. Und sobald wir diese Konstellation haben fällt aber recht schnell auf, dass man ein ziemlich kompliziertes Konstrukt hat und man eigentlich wahrscheinlich recht viele daten sowohl in dem einen CCX als auch in dem anderen vorhalten will, denn das nervigste wäre ja, dass ein Kern von CCX 1 was aus dem l3 von CCX 2 haben will (und umgekehrt), besonders, wenn es sich im eine Anwendung handelt die extrem mit Cache Zugriffszeit skalliert. Das kann aber in dieser Konstruktion recht schnell passieren.
Kurzum, warum sich solche Kopfschmerzen machen, wenn du auch einfach mehr Kerne in ein CCX tun kannst und untersuchen kannst, ob z. B. zusätzlich eine Verdopplung des L3 caches auf besagtem CCX weitere Sprünge in der Performanz erlauben? Und selbst wenn irgendwann mal trotzdem L3 auf 2 CCX mainstream wird, dann ganz sicher nicht mit der IF Latenz von Zen5.
@12nebur27
Ich habe ein Szenario wo man gut sieht das es einen Vorteil gibt .aber nur wenn man auf die mit höheren Auflösung die Videos schaut ansonsten nicht. Denn Video zum videoumwandeln ist nicht gleich ein Video.
Video 1 mit Video 2 gleichzeitig bei 720x576i skaliert mit Takt + Latenz und besonders bei RAM aber nicht bei Cache
Video 3& 4 in 720p
Beide gleichzeitig und beide profitieren bei rund 5 % bei jedem Cache voll.
Video 5&6 auch wenn es nur von 4k auf full HD herunter skaliert bestimmt mit noch mehr Prozente weil das sehe ich ja gut das die Leistung massiv heim 265k abwärts geht.
Und hier die Threads Video 1 & Video 2 haben jeweils 18 Threads
Video 3&4 haben 22 Video Threads
Video 5 und so hat dank der Huber skalieren 30 Software Threads. Der extra Cache bremst massiv den 265k weil er zu wenig l3 Cache hat.
Hier würde der Doppel Cache mit Sicherheit massiv steigern.
Die Auslastung bei HD war ja schon bei 95 % gewesen. Bei 720x 576i waren es 84 % Auslastung.
Mir selbst gehört der 9950x3d2 nicht. Aber liegen die Ergebnisse vom dieser CPU vor.
4k auf full HD würde zu lange dauern. Das kann ich nicht machen für den Test ,es sei denn ich will wirklich lange das laufen lassen.
Was ich damit sagen will ist man sieht hier eindeutig welche Auswirkungen ein Quell Video hat bei der CPU Auslastung und auch ob es von dem extra l3 profitiert oder nicht.
Wegen ein paar Handvoll davon würde ich mir dennoch keinen 9950x3d2 gönnen weil sobald das durch ist dann ist es wieder vorbei.
Und ich habe als ich das getan hatte den 265k sehr gut ausgelastet gehabt. Ein zweites davon würde wohl die Zeit massiv erhöhen. Zumal die Temperatur ja eh nicht mehr niedrig waren.
Sind solche Infos für dich dennoch Interessant ?
Ich habe ein Szenario wo man gut sieht das es einen Vorteil gibt .aber nur wenn man auf die mit höheren Auflösung die Videos schaut ansonsten nicht. Denn Video zum videoumwandeln ist nicht gleich ein Video.
Video 1 mit Video 2 gleichzeitig bei 720x576i skaliert mit Takt + Latenz und besonders bei RAM aber nicht bei Cache
Video 3& 4 in 720p
Beide gleichzeitig und beide profitieren bei rund 5 % bei jedem Cache voll.
Video 5&6 auch wenn es nur von 4k auf full HD herunter skaliert bestimmt mit noch mehr Prozente weil das sehe ich ja gut das die Leistung massiv heim 265k abwärts geht.
Und hier die Threads Video 1 & Video 2 haben jeweils 18 Threads
Video 3&4 haben 22 Video Threads
Video 5 und so hat dank der Huber skalieren 30 Software Threads. Der extra Cache bremst massiv den 265k weil er zu wenig l3 Cache hat.
Hier würde der Doppel Cache mit Sicherheit massiv steigern.
Die Auslastung bei HD war ja schon bei 95 % gewesen. Bei 720x 576i waren es 84 % Auslastung.
Mir selbst gehört der 9950x3d2 nicht. Aber liegen die Ergebnisse vom dieser CPU vor.
4k auf full HD würde zu lange dauern. Das kann ich nicht machen für den Test ,es sei denn ich will wirklich lange das laufen lassen.
Was ich damit sagen will ist man sieht hier eindeutig welche Auswirkungen ein Quell Video hat bei der CPU Auslastung und auch ob es von dem extra l3 profitiert oder nicht.
Wegen ein paar Handvoll davon würde ich mir dennoch keinen 9950x3d2 gönnen weil sobald das durch ist dann ist es wieder vorbei.
Und ich habe als ich das getan hatte den 265k sehr gut ausgelastet gehabt. Ein zweites davon würde wohl die Zeit massiv erhöhen. Zumal die Temperatur ja eh nicht mehr niedrig waren.
Sind solche Infos für dich dennoch Interessant ?
LeckerRK
Lieutenant
- Registriert
- Aug. 2009
- Beiträge
- 514
Beim DUAL X3D Cache wäre die Lösung ,wenn man ein Bild vor Augen hat am Monitor beim Zeitstillstand ,das der erste X3D Cache ließt und der zweite X3D schreibt ,was DUAL erst seinen Sinn gibt und die Geschwindigkeit,also beim Zeitstillstand wäre aus beiden X3D Cache von der CPU da mehrere Kerne vorhanden sind, zu lesen und aus zu führen,wenn ein Programmierer eines Programms sich darauf spezialisiert wird es extrem viel schneller, in Spielen kann man das dann im Menü einstellen oder nicht ,dann mit AMD Software ...12nebur27 schrieb:
Ähnliche Themen
