Intel Arrow Lake-S ohne Hyper-Threading: Leak bestätigt erste Gerüchte zu Core Ultra 200

Was ja genau auch geschehen ist (seitens Intel bzgl der E-Kerne). Was für Probleme siehst du da genau ?
Nicht erst bzgl. der e-Kerne, schon die Intel Turbo Boost Max Technology 3.0 brauchte eine Unterstützung durch Windows 10 ab der entsprechende Version um den besten Kern maximal zu boosten und ab den RYZEN 3000 war es dann bei AMD genauso:
So neu ist die Zusammenarbeit zwischen der CPU über einen Software wie z.B. den Chipsatztreiber und dem Task Scheduler also nicht. Dies fing an, als die CPU Hersteller die maximalen Boosttakte ab Werk so hoch gesetzt haben, dass nicht mehr alle, sondern nur noch die besten Kerne der CPU diese erreichen.
Dort gibt es seit einer Zeit eine Multithread Version. Diese wurde unter Windows 10 bei mir immer dummerweise auf den E-Cores ausgeführt.
Dann schau mal auf die Priorität der Threads die auf die e-Kerne geschoben wurden. Wenn diese unterhalb Normal ist, dann ist es normal und das vorgesehene Verhalten (zumindest von Win 10), dass diese nur auf den e-Kernen laufen.

Aber ja, im HPC Umfeld werden Threads gerne an die (virtuellen) Kerne der CPU gepinnt, um die Verluste durch Kontextwechsel zu vermeiden. Da man dort sowieso in aller Regel die ganzen Kerne voll auslastet, sind diese Kontextwechsel durch den Task Scheduler irgendwo auch recht unsinnig. Dafür ist man dort dann aber eben auch bereit die SW auf die jeweilige Plattform zu optimieren und muss nicht wie im PC Umfeld mit Consumer Software mit allen erdenklichen Plattformen der letzten Jahre rechnen. Was man da teils rausholen kann, zeigt das Beispiel in dieser News:

Jedesmal wenn ein Thread von einem Core auf einen anderen verlagert wird, werden die Cacheinhalte ungültig und müssen neu geladen werden, und das kostet nicht unerheblich Zeit
So pauschal stimmt dies nur für die L1 und L2 Caches, aber nicht,wenn es um den L3 Cache geht. Da hängt es von der Architektur der CPU ab bzw. wie viele NUMA Nodes es gibt, ob auch der Inhalt des L3 ungültig wird. Bei den meisten Intel Desktop CPUs gibt es einem gemeinsamen L3 für alle Kerne und damit wird dieser nicht ungültig, bei AMD wird er nur ungültig, wenn die Kerne auf unterschiedlichen CCX liegen.

Durch HT hat man auf jedem Core bereits einen wartenden Thread, so dass man dadurch die negativen Effekte durch einen schlechten Kontextwechsel abmildern kann.
Dafür hat jeder Thread dann aber effektiv nur halb so viel Cache zur Verfügung, da sich ja beide Threads des Kerns die Caches teilen müssen.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Um mit einem AMD 32 Kerner mitzuhalten,
Du zitierst meinen Kommentar, in welchen ich von 32 Threads schreibe und du schreibst von 32 Kerne. Insofern ist es mir völlig egal was du meinst meinen zu müssen.
Es geht bei diesen Thema darum, dass wahrscheinlich kein HT bei Intel mit Arrow kommt. Also schrieb ich, dass wenn die Architektur der E Kerne zugelegt haben, können die 16 E Kerne nun klar und deutlich stärker sein, als 16 HT Threads von AMD. Letztlich nur eine Vermutung von mir mit meiner Meinung die besagte, dass ich wegen der Spekulation kein HT bei Arrow nicht spekulieren würden, dass AMD besser sein wird.
und man sollte auch nicht direkt E-Kerne oder HT deaktivieren weil "Experten" wie Nighteye und DTX das meinen
An welcher Stelle schrieb ich man solle HT und E Kerne deaktivieren? Neben Leute diffamieren und diskreditieren verbreitest du nun auch noch Lügen.
 
Zuletzt bearbeitet:
HT Threads von AMD also 🤡.
 
@Infi88

Ach ich Idiot. Bei Persönlichkeiten die andere diffamieren und diskreditieren und abfällig als Experten beurteilen hätte ich wissen müssen, dass folgende Meinung zu diesem Thema intellektuell nicht erfasst werden kann.

Die E-Kerne sind doch bei Arrow auch eine neue Architektur. Und wenn diese eben in der Leistungsentfaltung zugelegt haben, ist kein HT notwendig um mit den 32 Threads bei AMD mitzuhalten.
Arrow soll anscheinend als 8+16 Kerne in der höchsten Ausführung kommen. Ohne HT also 24 Kerne, 24 Threads. Granite hat in der höchsten Ausführung 16 Kerne + HT, also 32 Threads.
Meine Meinung war einfach nur, dass ich jetzt nicht spekulieren würde, dass kein HT bei Arrow gegenüber Granite, Arrow deswegen weniger Leistung in Multi-Anwendungen haben muss.

Ich habe also nicht deine Art und Weise des dümmlichen Gelabers angewendet, um die Konkurrenz schlecht zu schreiben, sondern eine abwartende Haltung eingenommen.
Wie kann man eigentlich nur noch so krankhaft in jegliche Richtung emotional eskalieren, wenn es um CPUs von AMD und Intel geht, wie du es machst?
 
o_O Wird einem "Leak" eigtl auch ein reales Szenario mit einem funktionierendem Sample u dessen unabdingbarer Featuretests vorausgesetzt, oda haben die se net alle und sind bis zum letzten nda/cda wirklich so queer daß absolut keine Info's nach außen dringen, ich meine, ist ja auch eine Art Stachelei wenn man es bereits besser weiß u dennoch nicht teilen mag...:unsure:

Aber stimmt schon, diesmal siegt die Vernunft und Geduld und die bereits gegebene Leistung und Softwarelösungen für bessere Frames. Gibt es schon wieder neue Softwareupdates für mehr frames oder bessere Latenzen, oder kann man zB HT bei einem 14700 nicht noch "besser" machen um in-Game auch besser abzuschneiden? Ich begrüße wirklich jeden Frame mehr, hauptsache ich bekomme es installiert 8-)
 
HT Threads von AMD also 🤡.
https://de.wikipedia.org/wiki/Simultaneous_Multithreading HT is der Marketing Begriff von Intel, es ist im Prinzip SMT angepasst auf Intels Architektur.

Da Intel im Consumer Bereich Jahrzehnte lang Marktführer war und da auch genug Marketing gemacht hat kann das schon passieren das man HT als synonym dafür verwendet.
So wie viele Menschen Tempo für Taschentücher als Begriff verwenden oder Zewa für Küchenrolle etc.
 
Weiterer Daten-Leak zu Arrow Lake:

Was fehlt wären noch die Turbotaktraten oder gibt es dazu auch schon Infos?
 
Weiterer Daten-Leak zu Arrow Lake:

Was fehlt wären noch die Turbotaktraten oder gibt es dazu auch schon Infos?
Ja sehr wenig cache ? https://www.notebookcheck.com/Leak-...n-Intel-Arrow-Lake-U-H-HX-und-S.847892.0.html
 
HT is der Marketing Begriff
Das ist nur von der Lüge ablenken, die Infi88 ausgesprochen hat. Denn seine Lüge begründet Infi88 aus folgenden Kommentar.
Die E-Kerne sind doch bei Arrow auch eine neue Architektur. Und wenn diese eben in der Leistungsentfaltung zugelegt haben, ist kein HT notwendig um mit den 32 Threads bei AMD mitzuhalten. Persönlich würde ich jetzt nicht wahllos spekulieren, dass durch kein HT die Konkurrenz mit HT besser gestellt ist.
Es wird jedenfalls spannend.

An welcher Stelle des dick markierten Textes will man lesen, ich hätte geschrieben...
und man sollte auch nicht direkt E-Kerne oder HT deaktivieren weil "Experten" wie Nighteye und DTX das meinen
...man solle E Kerne und oder HT deaktivieren. Überhaupt, wie soll man bei einem Produkt, was angeblich ohne HT kommen soll, HT deaktivieren?
Es ist eben typisch für Persönlichkeiten die andere diffamieren, diskreditieren und Lügen verbreiten, dass diese Persönlichkeiten dann keine Einsicht haben können, sondern versuchen abzulenken mit inhaltlichen Blödsinn.
Infi88 ist krankhaft emotional eskalierend, wenn er auch nur den Hauch eines Gefühls verspürt, Intel könnte negativ beurteilt werden.
 
Am ende entscheid doch nur der Bumms der hinten rauskommt. So lange man wenigstens 6 - 8 Threads hat (Egal ob Physikalisch oder virtuell) das reicht meistens sehr gut aus für die übliche Parallelisierung der Rest ist kaum relevant. Nur IPC/CACHE mehr oder weniger, ob die mit SMT oder ohne zustande kommt ist weniger relevant.

@Holzmann wir werden dann sehen ob die so Rentable sind :bigok:
Beitrag automatisch zusammengeführt:

Das könnten die Rentable Units ausbügeln, sofern sie denn bei Arrow schon aktiviert sind!?
Ich bin mir nicht sicher ob die Rentable Units das ausbügeln können. Prinzipiell sehe ich nur den Vorteil das Rechenleistung die eigentlich nur auf 1 Thread aufgrund der Programmierung möglich ist, jetzt auf die Nachbaren mit verteilt wird. Im Prinzip ein Hardwareseitiges Multithreading.

Das Heißt wenn ich eine Instanz von einem Server habe der auf 1 Kern läuft würde dieser die Leistung limitieren, wenn aber die Nachbar kerne gerade nichts zu tun haben könnte die Architektur die Arbeitsüberlastung auf die Nachbarn übertragen - für das Programm muss dessen Design nicht umgeschrieben werden um auf mehrere Kerne verarbeitet zu werden.

Edit: Natürlich heißt das auch das der Nachbar Cache auch mit genutzt werden kann. Der L2 Cache wird dadurch bei Rentable Units zumindest in der Theorie als Speicherpool behandelbar den sich die Kerne teilen können.
Die Frage is halt ob das ähnliche dem Intel APO bei Raptor Lake dann von Intel quasi von Hand profile erzeugen muss dafür um die Software optimal auszulasten ob hier mittel Deep Learning die Optimierung er Auslastung dynamisch erfolgt. Sprich es ist notwendig beim User Software zu hinterlegen die ähnlich bei Antivirus Software "Pattern Updates" nachliefert.
 
Zuletzt bearbeitet:
Gibt es schon wieder neue Softwareupdates für mehr frames oder bessere Latenzen, oder kann man zB HT bei einem 14700 nicht noch "besser" machen um in-Game auch besser abzuschneiden?
Wie sollte dies denn möglich sein? Games lasten sowieso selten alle Kerne voll aus und meist haben sie einen Thread der alle koordiniert und damit limitiert die Geschwindigkeit mit der diese Thread abgearbeitet werden kann, dann auch die fps. Daher sollte er besser alleine auf einem Kerne laufen und sich die Rechenleistung dieses Kerns nicht auch noch mit einem zweiten Thread teilen müssen.

Das Heißt wenn ich eine Instanz von einem Server habe der auf 1 Kern läuft würde dieser die Leistung limitieren, wenn aber die Nachbar kerne gerade nichts zu tun haben könnte die Architektur die Arbeitsüberlastung auf die Nachbarn übertragen
Wohl nicht auf die Nachbarn, es ist in dem was bisher so durchgesickert ist, von Kernpaaren die Rede und damit kann nur ein Nachbar seine Verarbeitungseinheiten an den anderen Kern ausleihen, sofern er diese eben nicht selbst braucht.

Natürlich heißt das auch das der Nachbar Cache auch mit genutzt werden kann. Der L2 Cache wird dadurch bei Rentable Units zumindest in der Theorie als Speicherpool behandelbar den sich die Kerne teilen können.
Das ist eine interessante Frage und ob dies geht, dürfte von der Architektur der Caches und davon abhängen, welche Einheiten sich ein Kern denn von seinem Nachbar überhaupt ausleihen kann. Vielleicht beschränkt sich das ja nur auf die Integer und FP Einheiten, zumindest in der ersten Version und später werden es mehr Einheiten. Aber selbst dies dürfte eine Menge bringen. Schau Dir an was Intel bei der Skymont Architektur der e-Kernen von Lunar Lake optimiert hat, da gibt es von allem mehr, vor allem mehr Verarbeitungseinheiten wie Int und FP Einheiten und am Ende stehen dann 38% mehr IPC bei Int und 68% mehr IPC für FP raus. Bei Lion Cove gibt es auch mehr Int und FP Einheiten, in beiden Fällen natürlich noch mehr Optimierungen wie längere Out-of-order Einheiten, mehr Load- und Store, etc, aber man stelle ich vor was für eine IPC Steigerung alleine mit einer Verdoppelung der Int und FP Einheiten möglich wäre, ohne dass der Kern deswegen größer wird, nur weil man die Einheiten des Nachbarkerns mitbenutzen kann.

Jede Architektur ist ja immer ein Kompromiss, mehr Einheiten machen die Kerne größer, sie brauchen also mehr Platz, denn man besser für andere Dinge wie z.B. vielleicht mehr Cache oder eben für die ganze CPU für mehr Kerne nutzen könnte. Es müssen also immer Kompromisse gemacht werden und Rentable Units hätten da eben den großen Vorteil einem Kern mehr Verarbeitungseinheiten verfügbar zu machen, ohne seine Größe entsprechend wachsen zu lassen.

Die Frage is halt ob das ähnliche dem Intel APO bei Raptor Lake dann von Intel quasi von Hand profile erzeugen muss dafür um die Software optimal auszulasten
Nein, die sollte sich nur auf den Task Scheduler beschränken und der erhält ja schon heute von Thread Director Hilfe bei der Entscheidung welche SW Threads er auf welche Kerne packen soll. Der wird dann künftig in dem Fall das nicht alle Kerne ausgelastet sind, dann darauf achten, dass von benachbarten Kernen einer möglichst wenig Last bekommt, damit er eben möglichst oft auch freie Einheiten hat, die er seinem Nachbar ausleihen kann. Das ist dann ähnlich wie bei HT, da sollten ja möglichst auch nicht die beiden virtuellen Kerne eines physikalischen Kerns ausgelastet werden, wenn andere physikalische Kerne gar keine Last haben.
 
Da steht nichts neues drin, die 5,5GHz geistern schon lange durch die Gerüchteküche und der letzte Satz wonach die "Taktfrequenzen .. bis zu 700 MHz im Vergleich zur 14th Gen sinken", stimmt so nur bedingt, da vermutlich später noch ein KS nachgeschoben wird, der dann über 5,5GHz packen sollte. Es sind also eher 500MHz weniger, wenn man den Core Ultra 9 285K mit dem 14900K vergleicht und dies werden die 14% mehr IPC mehr als kompensieren.
 
Dazu kommt noch, dass der Basistakt signifikant ansteigen soll
Das war ja auch zu erwarten, denn Arrow Lake macht bei der Fertigung ja einen gewaltigen Sprung von Intel 7 auf Intel 20A und überspringt damit zwei Prozesse: Intel 4 und Intel3. Alles andere als ein gewaltiger Sprung bei der Effizienz wäre da eine (negative) Überraschung. Der Basistakt bezieht sich ja auf den Takt bei Last auf allen Kernen wobei die Leistungsaufnahme dann ungefähr der TDP entspricht. Die Frage ist halt immer, welche Last der Hersteller da genau nimmt, mein 13900K hatte bei CB23 4,3GHz auf den P Kernen (3,4GHz auf den e-Kerne) bei 125W und ist aber nur mit "Performance-core Base Frequency: 3.00 GHz" und "Efficient-core Base Frequency: 2.20 GHz" angegeben.
 
Für Intel scheint AI mit Arrow Desktop noch kein großes Thema zu sein. 13 TOPS NPU. Phoenix Desktop hat ja schon 16 TOPS.
 
Immerhin 13 TOPS, was soll den Ryzens 9000 NPU so bieten?
 
Mit Granite Ridge kommt keine NPU.
Wenn der Marktführer keine hohe NPU Leistung im Desktop aktuell sieht, scheint es nicht so dringend zu sein. Wer auf AM5 eine NPU wünscht, muss aktuell Phoenix wählen. Mit einem möglichen Strix Point für AM5, wären 50 TOPS möglich.
Allerdings muss AMD auf dem Gebiet Software sich deutlich weiterentwickeln. Was zumindest aktuell von AMD auch ausgesprochen wird.
Wie ich schon schrieb, scheint es für den Desktop noch keine Rolle zu spielen, wenn schon Intel nur Meteor Leistung bieten wird mit 1851. Arrow-S wird wohl nur deswegen eine NPU haben, weil Arrow auch im Notebook landen wird. Lunar bietet 48 TOPS. Im mobilen Markt greifen also beide an.
 
Laut dem Podcast mit Volker sieht Volker keine großen Unterschiede in der Leistungsentfaltung zwischen Arrow und Granite. Es wird wohl so sein wie Raptor gegen Raphael.
 
Finde ich gut, so hat man immer noch die Möglichkeit trotz defekter GPU den Rechner zu nutzen.
 
Was sich für mich noch nicht so ganz erschließen tut für was brauche ich die 13 Tops ??? bzw will ernst haft jemand KI mit einer CPU füttern etc ?

Jede halbwegs normale GPU bietet ein 5-10 mal mehr
 
Was sich für mich noch nicht so ganz erschließen tut für was brauche ich die 13 Tops ??? bzw will ernst haft jemand KI mit einer CPU füttern etc ?
So geht es mir auch, aber außer dem Copilot+ habe ich keine Anwendung gefunden. Erstmal soll es den sowieso nur für Notebooks geben und nach dem was ich darüber gelesen habe, scheint er mir wenig Sinn zu machen.
 
eben copilot nutze ich auch und das wars und dazu brauche ich keine Hardware etc also dieses KI Feature was Intel anpreisen tut gibt für mich wenig sinn
 
für was brauche ich die 13 Tops ?
Zum einen kommt Arrow auch ins Notebook und zum anderen wurde die NPU von Meteor übernommen 11 TOPS mit etwas höheren Takt nun 13 TOPs. Da es aber wie du schon geschrieben hast, eine GPU deutlich besser kann, sieht sowohl Intel mit den 13 TOPS, als auch AMD mit 0 TOPs bei Granite keine Notwendigkeit für den Desktop. Weil man eben Grafikkarten verwenden kann.
 
Zusammen mit der iGPU sind es bei Arrow Lake mutmaßlich 37 TOPS, denn 24 soll die iGPU haben.

Damit die Copilot+ Features laufen verlangt MS nach 40+ TOPS.
 
Finde ich gut, so hat man immer noch die Möglichkeit trotz defekter GPU den Rechner zu nutzen.
Finde ich nicht gut, denn es gibt dann keine günstigere Variante mehr. Die iGPU kostet Geld, ich brauch sie nicht.
 
Finde ich nicht gut, denn es gibt dann keine günstigere Variante mehr. Die iGPU kostet Geld, ich brauch sie nicht.

Und ich finde es gut, beim 14700K(F) sind es ca. 25 Euro Unterschied, die sind es mir für den Fall der Fälle wert.
 
Komische Argumentation, für Dich ändert sich ja nichts. Wieso findest Du etwas gut, was Dich gar ich betrifft, anderen aber ein Vorteil genommen wird.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh