Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsRyzen 8000G: AMD liefert endlich fehlende Daten zu Zen 4c nach
Jetzt ist Ihre Meinung gefragt zu Ryzen 8000G: AMD liefert endlich fehlende Daten zu Zen 4c nach
AMD bringt ab nächster Woche neue Ryzen-8000G-CPUs auf den Markt, von denen einige Modelle sowohl mit Zen-4- als auch Zen-4c-Kernen ausgestattet sind. Mittlerweile hat AMD die fehlenden Taktraten für Zen 4c nachgeliefert.
Bitte beachten Sie: Der Kommentarbereich wird gemäß der Forenregeln moderiert. Allgemeine Fragen und Kritik zu Online-Artikeln von PC Games Hardware sind im Feedback-Unterforum zu veröffentlichen und nicht im Kommentarthread zu einer News. Dort werden sie ohne Nachfragen entfernt.
Die Verfügarbarkeit sollte von Anfang an recht gut ausfallen. Die CPUs sind teils schon lagernd bei den Großhändlern, aber vor dem 31.01. wird nix verkauft. Der 8500G liegt dort brutto bei rund 190 €.
Vollwertige Kerne brauchen deutlich mehr Fläche und Energie pro Rechenleistung. Man nimmt das in Kauf, weil man die hohe sequentielle Leistung haben will. Je paralleler eine Last aber wird, desto weniger Sinn ergibt das. Deswegen ist das Konzept, ein paar sehr schnelle und teure Kerne mit einer größeren Menge, kleiner und billiger Kerne zu ergänzen durchaus sinnvoll, weil man so mehr parallele Leistung bei gleichen Kosten realisieren kann, ohne die sequentielle Leistung zu verlieren.
AMDs c-Kerne verfügen über den gleichen Funktionsumfang wie die "normalen" Kerne. Nur sind die C-Kerne halt kompakter angeordnet und benötigen zur Anbindung längere Banen. Dadurch können die c-Kerne nur mit geringerem Takt laufen als die normalen. (Das wurde alles mal rund um die neuen EPYCs erklärt.) DIe C-Kerne benötigen für die gleiche Leistung, gleichem Takt wie bei den normalen Kernen, weniger Energie. Ergo sind sie effizienter.
Intels e-Kerne bieten nicht den gleichen Funktionsumfang wie deren p-Kerne. Sie können also weineswegs als effizienter als die p-Kerne bezeichnet werden. Die Intel e-Kerne verbrauchen einfach nur weniger Energie.
Und für den Einsatz in kompakten (mobilen) oder Klein-Systemen (wie einem kleinen NAS oder Office-PC) machen CPUs mit dem Ansatz zur Genügsamkeit durchaus Sinn. Darüber hinaus haben ja nicht alle Ryzen 8000G auch c-Kerne verpasst bekommen. ->Was ich Schade finde. Der 8500G hat nur 10 (bzw. 14) PCIe-Lanes. Der 8700G immerhin 16 (bzw. 20).
Mir fehlt ein Gegenprodukt zum N100 mit 6W.
Für (kleine) Kisten als Datenarchiv und Mediastation und hier und da mal surfen oder Daten verschieben und Entpacken etc. kann man so etwas super gebrauchen.
Dafür sind mit teure Prozessoren mit dann 15-25W Minimum auch schon zu viel des Guten.
Wie wäre es denn z.B. mit einem ganz einfachen 2C-Minichip für ein Appel und ein Ei?
Dazu ein kostengünstig produziertes (Mini)ITX Board ohne Zusatzchip.
Damit hätte man auch etwas bezahlbares für arme Länder und Personen.
Da - muss ich sagen- hat Intel irgendwie etwas mehr mitgedacht.
Die c (vermutlich für compact) Kerne sind architektonisch identisch zu den großen Kernen. Im Unterschied zu Intel, die bigLITTLE als Ansatz verfolgen, wo die e-Cores ein anderes Featureset haben und über kein SMT verfügen, verfolgt AMD quasi den bigBIGGER-Ansatz.
Vorteile:
Keine neue Architektur notwendig, man optimiert nur die vorhandene hinsichtlich der Chipfläche auf Kosten von Takt
Der Scheduler hat keine Probleme mit dem Umsortieren wenn von Anwendungen Befehlssatzerweiterungen angefragt werden, die der E-Core gerade nicht hat(Intel hat das Problem ja auch bereits erkannt und versucht die E-Cores in der Hinsicht wieder näher an die P-Cores zu bringen).
Leistungsmäßig liegt man wohl pro c-Kern irgendwo zwischen E und P Kernen
Nachteil:
So effizient, wie eine von vorn herein auf Effizienz optimierte Architektur bei "echten" E-Cores wird man nie sein.
Wie mies das Scheduling sein kann ohne ausgefeilte Softwarelösungen sieht man ja am 7950X3D und 7900X3D. Durch die starke Asymmetrie beim Cache kommt man da schon in Teufels Küche, wenn nicht alles optimal läuft und OS und Anwendung aufeinander abgestimmt sind. Den nicht experimentierfreudigen wird da ja bereits eher zum 7950X geraten, weil da halt alles gleich ist. Und da geht es nur um schnöden L3-Cache.
Bei bigLITTLE-Ansätzen wie Intel AlderLake und RaptorLake kommt da noch das Befehlssatzproblem hinzu, wenn man in den Bereich kommt, wo der Scheduler aussteigt. Man bekommt dann zwar nach Schluckauf die volle Leistung(und surft nicht weiterhin auf dem falschen CCD herum, wie beim 79xxX3D), aber optimal ist das ganze nicht.
Fakt ist aber nach wie vor, dass man vor allem den Leerlaufverbrauch senken möchte(da ist AMD den noch ein wenig hintenan, wegen des Chipletansatzes) und die Zen4/Zen4c-Idee halte ich für gut geeignet das anzugehen, ohne die Nachteile von bigLITTLE zu haben.
Mir fehlt ein Gegenprodukt zum N100 mit 6W.
Für (kleine) Kisten als Datenarchiv und Mediastation und hier und da mal surfen oder Daten verschieben und Entpacken etc. kann man so etwas super gebrauchen.
Dafür sind mit teure Prozessoren mit dann 15-25W Minimum auch schon zu viel des Guten.
Wie wäre es denn z.B. mit einem ganz einfachen 2C-Minichip für ein Appel und ein Ei?
Dazu ein kostengünstig produziertes (Mini)ITX Board ohne Zusatzchip.
Damit hätte man auch etwas bezahlbares für arme Länder und Personen.
Da - muss ich sagen- hat Intel irgendwie etwas mehr mitgedacht.
Nein. Die Techniken ähneln sich nicht mal ansatzweise.
Intels E-Cores sind eine Eigenentwicklung und sie sind viel kleiner und haben weniger als die halbe Leistung eines P-Cores, zudem fehlen einige wichtige Komponenten wie z.B. HT und AVX.
AMDs Ansatz ist quasi weiterhin ein vollwertiger "P"-Core, nur die Anordnung wurde auf Platz anstatt auf Taktrate hin optimiert, zudem wurde meine ich etwas vom Cache weggelassen, die allgemeine Leistungsfähigkeit ist aber dennoch weiterhin gegeben.
Wie sich die Leistung tatsächlich verhält, wird man ja bald in Tests sehen können.
Aber man kann sich sicher sein, dass dann 4 oder gar 8 C-Cores einer viel höheren Anzahl an E-Cores von Intel entsprechen werden, was je nach Spiel und Anwendung natürlich mal stärker oder geringer ins Gewicht fallen wird, je nachdem, was dem E-Core gegenüber dem P-Core mehr noch als bei den C-Cores wegrationalisiert worden ist.
Der Vorteil bei den E-Cores dürfte vielleicht sein,d ass diese im Idle udn Niedriglastbereich weniger Strom als Basis ziehen werden als ein komplexerer Chip wie der C-Core.
Jener ist dafür in der Entwicklung einfacher und kostengünstiger, worauf AMD ja doch sehr achtet, weil denen in der Vergangenheit oft immer das Geld für solche Zusatzausgaben gefehlt hat und man sparsamer als die Konkurrenz wirtschaften muss.
Die c (vermutlich für compact) Kerne sind architektonisch identisch zu den großen Kernen. Im Unterschied zu Intel, die bigLITTLE als Ansatz verfolgen, wo die e-Cores ein anderes Featureset haben und über kein SMT verfügen, verfolgt AMD quasi den bigBIGGER-Ansatz.
Hast du eine Quelle dafür, dass die E-Cores ein anderes Featureset haben? Ich habe nur mal was davon gehört, dass die irgendeine AVX-Ausbaustufe nicht in Hardware unterstützen. Das müsste aber "von außen" nicht zwingend einen Unterschied machen, dank Microcode könnte man den Befehl ja trotzdem ausführen können, es dauert dann halt nur länger. Bei dem Thema ist allgemein wichtig, zwischen der Mikro- und Makroarchitektur zu unterscheiden.
Die Unterschiede in der Mikroarchitektur zu Zen 4 sind wohl deutlich geringer als die von Intels P-Cores zu E-Cores, aber es gibt sie schon. Scheinbar wurde hauptsächlich am Cache gespart. Es ist weniger L3-Cache vorhanden und es wird kompakterer, langsamerer SRAM verwendet. Würde mich aber nicht wundern, wenn AMD den Weg noch weitergeht und die C-Kerne noch mehr stutzt.
Es ist irgendwie schon komisch, dass die leistungsstärkeren iGPUs (zb. 680M/780M) bisher ausschließlich den verlöteten CPUs von AMD vorenthalten wurden, und es bis zur 8000er Serie gebraucht hat, bis solche iGPUs auch in den gesockelten Desktop kommen.
Die gibts auch von AMD, zumindest "halbwegs", als "Mobile-CPUs". Und soweit ich sehe, bisher überwiegend in "China-Mini-PCs". Der N100 zieht ja eigentlich auch keine 6W, sondern eher 10-12W (und je nach Config ggf. noch mehr).
Du musst bei solchen "AMD-Minis" halt manuell die TPD begrenzen, damit die CPU nicht mehr als zb. 10W oder 15W verbraucht, dann sollten sie ähnlich sparsam wie N95/N97/N100/N305 sein. Aber du kannst bei AMD halt auch noch aufs Gas drücken, und bei Bedarf mehr Leistung (über mehr Watt) abrufen. Das geht bei den "kleinen Intels" halt nicht wirklich. Und außer dem N305 (8C/8T) haben die anderen Ns ja auch nur 4C/4T, wohingegen die kleinen AMD-APUs auch 6C/12T und 8C/16T bieten. Plus, bei AMD sind es vollwertige Kerne.
Aber ja, so was "richtig Kleines" gibts bei AMD (noch?) nicht.
Wie wäre es denn z.B. mit einem ganz einfachen 2C-Minichip für ein Appel und ein Ei?
Dazu ein kostengünstig produziertes (Mini)ITX Board ohne Zusatzchip.
Damit hätte man auch etwas bezahlbares für arme Länder und Personen.
Da - muss ich sagen- hat Intel irgendwie etwas mehr mitgedacht.
Aktuell, fundiert und übersichtlich: PC Games Hardware berichtet über Grafikkarten, CPUs, PC-Spiele und Gamer-PCs. Im Extreme Forum bekommen Sie PC-Hilfe.
preisvergleich.pcgameshardware.de
Alle mit N100. Warum nicht mit N97, und warum zum Teufel nicht mit N305? Gerade letzterer sollte doch die beste Wahl für extrem sparsame "Allround-Minis" sein, die mit N100 noch ein kleines bisschen schwächeln (gerade bei manchen Webseiten).
Zumal es solche Lösungen, und in zahlreichen Variationen, ja gibt, aber eben nur in China (zb. Aliexpress).
Da gibts auch richtig gute NAS-Boards mit N100 oder N305 (oder älter mit J4xxx/N5095/N5105 usw). Und schon bei den Mini-PCs sieht man ja, dass der Bedarf sogar relativ groß ist (siehe Verkaufszahlen einzelner Mini-Systeme auf Ali, die auch mal mit "10.000+" angegeben sind).
Aber da schwingt halt immer ein wenig der schlechte Geschmack des quasi nicht existenten Supports mit. Wenn man so ein Mainboard/Mini-PC kauft, gibts idR nicht mehr als das Release-BIOS und die Release-Treiber (wobei man Treiber vom China-Hersteller ja eh nur für relativ unkritische Systemkomponenten [zb. SMBus-Chip usw] braucht - die idR auch ziemlich stabil laufen, wenn sie zum Release laufen [also nach Erhalt der HW direkt alles testen, um ggf. noch den 15-Tage-Käuferschutz von Ali in Anspruch nehmen zu können] - und für den Rest nimmt man ja eh Treiber von AMD, Intel oder Realtek).
Aber vielleicht baut AMD das Angebot mit den neuen "kleinen" Kernen ja noch aus. Selbst ein 1c/2T oder 2c/4T würde ja für sehr viele Einsatzzwecke optimale Leistung bringen. Gerne auch verlötet auf winzigen Boards.
Genau um solche Sachen geht es. Man kann das alle natürlich mit nicht geeigneter Hardware brute-forcen, das dauert aber in der Regel wesentlich länger und man bekommt irgendwann auch Probleme mit dem pipelining und der branch prediction. Dazu noch der geringere Takt, mit mehr wäre das unter Umständen bei leichteren Berechnungen kompensierbar.
Wer es selber probieren möchte kann mit dem Intel SDE rumspielen, um Befehlssätze vorzugaukeln. Die Performance ist OK, aber nicht der Brüller.
Intel hat vor ein paar Monaten mal ein Interview gegeben, warum man bestimmte Befehlssätze auch bei den P-Cores nicht aktiviert(insbesondere AVX-512), obwohl vorhanden: Einfach um dem Scheduler nicht noch mehr Probleme zu machen. Das meinte ich, als ich oben von den Bestrebungen seitens Intel sprach, P und E Cores wieder mehr anzugleichen.
Genau um solche Sachen geht es. Man kann das alle natürlich mit nicht geeigneter Hardware brute-forcen, das dauert aber in der Regel wesentlich länger und man bekommt irgendwann auch Probleme mit dem pipelining und der branch prediction.
Dauert zwar länger, aber es kommt immer drauf an, was man macht, wie viel länger es dauert. Ohne Fließkommaeinheit Fließkommazahlen berechnen ist z.B. ein größeres Problem, als AVX512 mit einer 256- oder 128-Bit-SIMD-Einheit auszuführen. Ich weiß jetzt auch nicht, was das für Auswirkungen auf das Pipelining und die Branch-Prediction haben könnte.
Intel hat vor ein paar Monaten mal ein Interview gegeben, warum man bestimmte Befehlssätze auch bei den P-Cores nicht aktiviert(insbesondere AVX-512), obwohl vorhanden: Einfach um dem Scheduler nicht noch mehr Probleme zu machen.
Scheinbar ist das wohl für moderne Scheduler kein großes Problem aber Intel will ja mit AVX10 auch AVX512-Support mit kleineren Registern realisieren, so dass es da keine Diskrepanzen mehr gibt.
AMDs Ansatz ist quasi weiterhin ein vollwertiger "P"-Core, nur die Anordnung wurde auf Platz anstatt auf Taktrate hin optimiert, zudem wurde meine ich etwas vom Cache weggelassen, die allgemeine Leistungsfähigkeit ist aber dennoch weiterhin gegeben.
Cache wurde im Vergleich zum Zen-4-Vollausbau weggelassen, den die Epycs und die Ryzen-7000-CPUs verwenden. Aber in den APUs kommt sowieso nur eine Schmalspurausgabe mit halbiertem L3-Cache zum Einsatz. Bei Ryzen 8000 unterscheiden sich Zen 4 und Zen 4c daher nur durch den deutlich niedrigeren Takt letzterer (Zen 4c maximal 3,7 GHz, Zen 4 im gleichen Prozessor 5,0 GHz und bis zu 5,1 GHz in anderen 8000er-Modellen; bis zu 5,7 GHz in Ryzen 7000)
Hast du eine Quelle dafür, dass die E-Cores ein anderes Featureset haben? Ich habe nur mal was davon gehört, dass die irgendeine AVX-Ausbaustufe nicht in Hardware unterstützen. Das müsste aber "von außen" nicht zwingend einen Unterschied machen, dank Microcode könnte man den Befehl ja trotzdem ausführen können, es dauert dann halt nur länger. Bei dem Thema ist allgemein wichtig, zwischen der Mikro- und Makroarchitektur zu unterscheiden.
Gracemont und Crestmont (die aktuellen E-Core-Architekturen) unterstützen im Gegensatz zu Redwood Cove und Raptor Cove (die aktuellen P-Kerne) maximal AVX2 und kein AVX512. Allerdings ist aus genau diesem Grund AVX512 in den aktuellen Core-Modellen auch deaktiviert. Somit nutzen dort ebenfalls alle Kerne den gleichen, älteren Befehlssatz – auf was anderem würde der Windows-Scheduler auch gar nicht laufen.
Gracemont und Crestmont (die aktuellen E-Core-Architekturen) unterstützen im Gegensatz zu Redwood Cove und Raptor Cove (die aktuellen P-Kerne) maximal AVX2 und kein AVX512.
Allerdings ist aus genau diesem Grund AVX512 in den aktuellen Core-Modellen auch deaktiviert. Somit nutzen dort ebenfalls alle Kerne den gleichen, älteren Befehlssatz – auf was anderem würde der Windows-Scheduler auch gar nicht laufen.
Ich habe zwar irgendwo was davon gelesen, dass ein Scheduler das prinzipiell können könnte, aber ich sehe da auch jede Menge Fallstricke. Dann wohl doch lieber eine Emulation im weitesten Sinne, wie das mit AVX10 wohl auch vorgesehen ist.
