News Intel Arrow Lake: Weitere Infos zu CPU und Chipsatz der neuen Plattform

[PS828]

Intel muss halt den HT Nachfolger ans laufen kriegen. Ich glaube auch nicht das sie einfach verzichten wenn sie die Performance unbedingt für Arrow lake brauchen

 

[latiose88]

So so,die kommende CPU hat also ne NPU.Naja ich verwende nur ne ältere Software.Weis nicht so recht.Denke mal nicht das diese rechenintensive alte Software damit was anfangen kann.Und dann am Ende auch noch weniger Leistung haben.Also Hypertrading also HT darauf spricht meine Software verdammt gut an.Nur ab einer gewissen Anzahl an Kerne dann im Negativen,aber so viele hat Intel ja nicht.Von daher sehe ich da noch keine Probleme des Auslastungs Problems.Die Schranke kommt ja erst noch. Bei den Threadripper sehe ich die Schranke,so weit wird es bei Intel so schnell nicht kommen.Vielleicht aber halt in der Zukunft mal,wer weis.

HT also abzuschalten,halte ich also für ein Fehler.Wäre das so und dem NPU ,dann sehe ich da ein Minus an Leistung,es sei denn Intel schafft dann im gleichen Zug 7 ghz oder mehr an Allcore Takt,dann kann Intel die Nachteile ausgleichen.Wäre aber nen teures Opfer das Intel da dann machen könnte.Es wird sehr teuer erkauft und der hohe Takt erzeugt mehr Abwärme,höheren Stromverbrauch.So viel kann man also durch ein Verzicht von HT nicht mal ansatzweise abfangen,durch mehr Takt.

Ergänzung (24. Januar 2024)

Aber solange man nicht kräftig bei der Architektur umrührt (mehr Cache wird kommen, aber das ein ich damit nicht), wird man eben nur quf, nicht überholen

Ja aber nur der Tatsache wenn die Anwendung wirklich noch mehr Cache davon Profitiert.Wenn die Software nicht mehr von noch mehr Cache Profitiert,wie auch von NPU nicht profitiert,dann wird es kein gleichstand geben können,dann wird Intels neue kommende CPU der neuen AMD CPU unterlegen sein und dann würde es eher schlecht für intel sein.Nur mehr Cache kann nicht das Allheilmittel für mehr CPU Leistung sein.
Das kann ich mir echt nicht vorstellen.Klar Games sind gewiss die Gewinner,aber dann außerhalb davon eher halt nicht.
Ich weis das Handbrake,Xmedia Recode usw nicht von noch mehr Cache Profitieren.Sieht man ja gut an die X3d CPUS das noch mehr Cache kein Wundermittel ist. Wäre das anderst,dann würde ich ja nichts dazu sagen.Mir wäre auch lieber wenn mehr Cache zu mehr Leistung führen würde.Aber bei Programmen kann man eben nicht Zaubern.

 

[mae]

Aber solange man nicht kräftig bei der Architektur umrührt

Wenn die neuen P-Kerne kein SMT/HT haben, spricht das dafuer, dass sie kraeftig bei der Mikroarchitektur umruehren.

 

[WinnieW2]

So funktioniert das aber nicht, die CPU kann die "Rechenaufgabe" mal nicht eben vierteln und auf andere CPUs verteilen. Es gab mal eine Ankündigung einer CPU die sowas können soll, damit hätte man belibig viele Cores auslasten können (so der feuchte Traum) aber die ist wie so vieles im Sand verlaufen.

Das ist genau das was Intel bei zukünftigen CPUs mit einer Neuauflage seines Thread Directors und den Rentable Units plant, eine Art Reverse Hyper Threading.
Wann diese kommen sollen steht noch nicht ganz fest. Intels Forschungen sind allerdings was das betrifft schon recht weit.

Das wirds wohl sein, sie haben ja schon beim erscheinen von Spectre gesagt das um das zu beheben eine Architekturänderung erfordert, vielleicht haben sie es nicht in den Griff bekommen.

So wie ich die Sache verstanden habe wäre für eine vollständige Behebung von Spectre ein von Grund auf neues OoO Konzept notwendig, sprich eine von Grund auf neu entwickelte x86-64 Architektur.

Eine tragische Ironie ist z.B. dass Intel SGX in die CPUs implementiert hat um die Verarbeitung von dieser sicherer zu machen, allerdings hat sich mittlerweile herausgestellt dass SGX sogar ein Sicherheitsrisiko darstellt und so hat Intel SGX bei neuen Rechnern standardmäßig per BIOS/UEFI deaktiviert.
SGX und Hyper Threading sind in Kombi wohl ein noch größeres Risiko.

 

[Nixdorf]

ich drücke mich manchmal ungschickt aus, aber dort wollte ich hin.

Kam auch an. 😀

Wenngleich das beides in seiner Pauschalität nicht stimmt.

Auch richtig. Intel wechselt ja mit Arrow Lake auf dem Desktop auch auf Chiplets Tiles. Wenn die Kerne separat sind, ist zumindest der Yield ein geringeres Hindernis als zuvor, wenn man mehr Kerne liefern will. Allerdings muss man sagen, dass da schon sehr spezielle Anwendungsfälle kommen müssen, bevor man auf dem Mainstream-Sockel von 8P+32E profitieren würde. Jedenfalls ist dann aber auch der womögliche Wegfall von HT kein Hindernis mehr, wenn die Multi-Core-Performance dennoch hoch bleiben soll.

Aber solange man nicht kräftig bei der Architektur umrührt

Es gibt da ja die Gerüchteküche zu "Rentable Units", zu denen Volker hier das Patent verlinkt hat. Die Idee ist da, dass bei mehreren parallel ankommenden Threads ermittelt wird, welche Abschnitte besonders rechenintensiv sind und welche nicht. Die rechenintensiven können von P-Cores deutlich schneller bearbeitet werden, die anderen laufen auch auf den E-Cores gut. Dann verteilt man die Abschnitte der Threads entsprechend an die geeigneten Cores und die Threads werden insgesamt schneller abgeschlossen. Der Scheduler kann die Abschnitte auch auf mehrere E-Cores pro P-Core aufteilen. Mit diesem Verfahren erhöht man die Auslastung der Kerne und kann pro Thread einen höheren Schub als mit Hyperthreading erzielen. Es ist aber auch klar, dass dieser große Leistungszuwachs mit der Erkennung dafür geeigneter Aufgaben durch den Scheduler steht und fällt, und man ihn längst nicht in allen Situationen sehen wird.

 

[BAR86]

Es gibt da ja die Gerüchteküche zu "Rentable Units", zu denen Volker hier das Patent verlinkt hat.

Ja, die Idee die Arbeit auf "echte" Cores auszulagern ist ja nicht neu und wird immer wieder diskutiert.
Man könnte auch argumentieren, dass Bulldozer mit den "halben" Kernen ja auch in die Richtung ging.

Ergänzung (24. Januar 2024)

Wenn die neuen P-Kerne kein SMT/HT haben, spricht das dafuer, dass sie kraeftig bei der Mikroarchitektur umruehren.

Bleibt abzuwarten ob das dann so ist.
Und ob man nicht einfach HT "abschaltet" und auslagert.
Dann ist immer noch kein großer Umbau am Core notwendig

 

[latiose88]

Also bei 8+32 könnte ich mir auch ht abschalten bzw weg lassen auch durchaus gut vorstellen. Denn so schlecht sind die e kerne nicht, sind ja sogar besser die e Kerne als ht bzw smt so könnte man es ja sehen.
Es sei denn Intel Entwickler ht weiter, dann sieht es anderst aus. Wenn nun das neue ht zu 60 % von einem Kern entsprechen würde, wäre das eine weiter Entwicklung. Die Leistung würde dann ansteigen. Allerdings ab einer gewissen Kern Menge dann wieder verpuffen weil dann die meisten Programm Probleme damit hätten umzugehen.

Es wird sich also zeigen wie es in dieser Hinsicht weiter gehen würde. In meinem Fall egal ob ausreichend e Kerne also mehr oder verbesserte HT, beides führt am Ende zu mehr Leistung.
Und freilich wenn man nun die jeweiligen Aufgaben nun an 32 e kernen legt, die latenz sinkt sehr stark und ein hin und her wechseln wird verhindert.

Wenn das nicht reicht kann man es ja auch fest, also ne feste Anzahl an kernen der jeweiligen Software legen mit process lasso und schon wären 32 e kerne ne super sache. Mit einer Software alleine wäre es ja ohnehin nicht möglich so einfach 32 kernen auszulasten.

Mir ist schon klar das 32 e kernen gegen einen 24 Kerner ohne smt/HT nur höchtens gleich stand herrscht bzw nen kleiner Rückstand. Wie viel würde sich schon zeigen.

 

[Nixdorf]

Man könnte auch argumentieren, dass Bulldozer mit den "halben" Kernen ja auch in die Richtung ging.

Das Hauptproblem von Bulldozer war der Mangel an Decodern. Was die Module gar nicht erst erreicht, das kann man auch nicht aufteilen. Die Architektur war einfach schlecht ausbalanciert. Mit späteren Revisionen wurde das besser, aber richtig toll waren die Module nie. Aber wir schweifen ab.

 

[eastcoast_pete]

Was gerade beim Thema "Leistung in Spielen" relevant ist bzw sein könnte: die Ein Kern (Single Core) Leistung, die oft (aus guten Gründen) bei Gaming Tests von CPUs angeführt wird, ist ja genau genommen nicht die Leistung des leistungsstärksten Kernes, sondern die maximale Single Thread Leistung, die eine CPU bereitstellen kann. Und daher weiß man im Moment noch nicht, ob und wie gut oder schlecht sich Arrow Lake hier im Vergleich mit Zen 4 oder Zen 5 schlagen wird. Für maximale Single Thread Leistung ist HT ja entweder Wumpe oder sogar nachteilig.

Ich habe mir schon öfter gewünscht, daß zukünftige x86/x64 CPUs hier einen (1) besonders performanten P Kern hätten, so wie zB die großen Snapdragon SoCs das auch machen. Dem Kern können dann die Threads zugewiesen werden, die viel Leistung wollen und auch Priorität haben Die SD SoCs haben ja einen X3 bzw X4 Kern, der deutlich schneller ist als die anderen großen Kerne (710 usw), und daher auch mehr Fläche im Silizium und mehr Strom brauchen darf. Wäre interessant, wenn Intel und AMD sich auch sowas überlegen. Der eine große Kern kann ja auch extra L1 und L2 bekommen, kostet zwar Fläche, aber für einen Kern (anstatt 4 oder 8) ist das noch eher vertretbar.

Wenn's hier jemand weiß ob das versucht wird, bzw auch warum daraus trotzdem nichts geworden ist, bitte reinstellen!

 

[BAR86]

Wenn's hier jemand weiß ob das versucht wird, bzw auch warum daraus trotzdem nichts geworden ist, bitte reinstellen!

Das Problem ist halt das Scheduling. Bei Spielen hast du so viele unterschiedliche Dinge die parallel laufen (KI, Physik, Audio, Weltenberechnung...), dass du zwar einen schnellen und einige weniger schnelle Kerne haben kannst, aber allein beim "welche Aufgabe ist nun die aufwändigste/wichtigste..." etc wirds schwierig.
Spieleengines in den Frühen 2000ern haben so funktioniert, dass es eigentlich einen großen Mainthread gab und ein paar nette Nebenaufgaben, aber das ist halt veraltet.
Im Prinzip sollte es einer Spieleengine egal sein, wie "stark" ein Kern ist und einfach alles ordentlich threaden, dann kann man das "auf die CPU" werfen und die Kerne die grad frei sind kümmern sich drum. Doom Eternal macht so etwas, weshalb es (bis zu einer gewissen Kernanzahl) gut mit den Kernen skaliert, egal ob P-Kerne, E (bzw. C bei AMD) oder gar nur Hyperthreading.

 

[Nixdorf]

Damit ist diese Angabe also darauf bezogen, dass ein Zen-4c-Kern der einzig aktive ist.

Der von @brommer1 netterweise verlinkte erste Test zum 8500G entkräftet diese Befürchtungen. Die Zen-4c-Kerne takten bei All-Core-Loads allesamt auf die in der Spezifikation genannten 3700 MHz.