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.
So interessant das Konzept auch ist, die Werbung mit niedriger TDP hat sich Intel recht frisch ziemlich verbrannt ^^
so ist der erste Gedanke eher "Soso, 7W? Also sowas wie bis zu 20W bis es zu heiß wird und ab dann so viel wie im Temperaturlimit drin ist?"
Auch wenn hoffnung besteht dass das hier weniger drastisch ist weil andere Zielgruppe ^^'
Aber wehe Multiarch CPUs schwappen ins Desktopsegment, dann werden wir uns alle noch die Corehopping-Probleme aus der frühen dualcorezeit zurückwünschen. Zumindest unter Windows sehe ich da wenig chancen solange Kontestwechsel das Lieblingshobby des Schedulers sind. Ich bezweifle zumindest dass das schneller geht als innerhalb der gleichen Architektur.
Man müsste wohl eher mal CB auf 2 Threads bzw 1 physischen Core limitieren. Ich denke aber dass ein Quad Atom bei ähnlichem Takt deutlich mehr Renderleistung bringt als ein 1C + SMT. Sonst würde Atom an sich auch keinen Sinn machen und man würde 1 Core Kern nehmen.
Guter Ansatz von Intel.
Hauptsache die 4 Atom Kerne sind nicht zu schwach. Nicht das nach 2 Jahren die Anwendungen und das OS soviel Rechenleistung benötigen das fast alles nur noch auf den einen Bigcore laufen will.
Aber Intel steckt da noch in den Kinderschuhen und ich denke das sich das Konzept als gute Alternative zu ARM entwickeln wird.
@yummycandy
Nur ist Foveros stand heute eine Prozessarchitektur... Also Kann ich mir schon vorstellen, dass Intel die Compute Core Stapeln wird, aber Big.Litte macht da eben keinen Sinn..Dafür müsste Intel auch mal eben 90% des Softwaremarktes umstellen, und der Processsheduler in Windows endlich nicht mehr auf Stand 2000 sein xD (Okay Billy, er ist nicht ganz so schlecht, aber fast)
Jetzt tust du Windows aber doch unrecht^^
Bei Zen2 wird mit jedem neuen Thread der nächst best taktende Core ausgewählt
best CCD > best CCX > best Core
best CCD > best CCX > 2nd best Core
...
Guter Ansatz von Intel.
Hauptsache die 4 Atom Kerne sind nicht zu schwach. Nicht das nach 2 Jahren die Anwendungen und das OS soviel Rechenleistung benötigen das fast alles nur noch auf den einen Bigcore laufen will.
Endlich mal wieder, in meinen Augen, richtig Geiles von Intel. Sehr gut! Viel Konkurrenz belebt das Geschäft und nutzt uns Kunden. AMD soll ja auch noch in die Mobile Ecke schielen und zumindest die Marke Radeon mit Samsung zusammen anbieten. Bin gespannt auf die nächsten Jahre.
Also ich will deinen Enthusiasmus ja nur ungern bremsen, aber so toll war das Big/Little Prinzip bei ARM jetzt auch nicht.
Ob das Stapeln von Dies jetzt aber der Trick für Intel wird wir 14nm weiter verwendet werden kann, da bin ich jetzt echt gespannt. Wie gut das sieht sollten wir ja dann bald in Samsung Geräten sehen.
Ob das Stapeln von Dies jetzt aber der Trick für Intel wird wir 14nm weiter verwendet werden kann, da bin ich jetzt echt gespannt. Wie gut das sieht sollten wir ja dann bald in Samsung Geräten sehen.
Ob das Stapeln von Dies jetzt aber der Trick für Intel wird wir 14nm weiter verwendet werden kann, da bin ich jetzt echt gespannt. Wie gut das sieht sollten wir ja dann bald in Samsung Geräten sehen.
This means that the logic areas of the chip, such as the cores and the graphics, sit on a 10+ nm die, while the IO parts of the chip are on a 22nm silicon die, and they are stacked together.
Es gibt genauso wenig Anwendungsfälle, die 100+Threads fast ohne Interprocesskommunikation abwickeln können und am Schluss rennt man sowieso immer "Amdahl's law" folgend in die Sättigung: https://en.wikipedia.org/wiki/Amdahl's_law
Was dann auch ein Grund ist, wieso früher oder später nicht mehr sinnvoll ist noch mehr kleine Cores aufs Die zu brennen anstatt weniger Großer.
Alles was Rednern, Virtualisierung usw angeht liegt aber schnell dem AMD Ansatz besser, da quasi vieles auf einzelne Numa Ebene innerhalb eines CCX / Chiplets ablaufen kann.
So lang innerhalb eines CCX abbildbar ist, funktioniert das ganz Wunderbar, das stimmt. Alles was jedoch mehr CPU benötigt muss entweder mit Nachteilen aufgrund von Latenzen zwischen den Numa nodes rechnen, oder aber man muss die Software anpassen, dass sie Teilaufgaben von sich aus sinnvoll auf Nodes verteilt. Letzteres bedeutet aber auch, dass man CPU-Zeit auf eben diese Verteilung und wenn nötig Synchronisierung werfen muss.
Ist dem so? Gibt's da Quellen dazu?
Wenn Intel jetzt hier angibt dass die 4 Kerne die etwa so groß sind sie der 1 Big Core und etwa 80% leisten... Weiß nicht ob das SMT und ein großer Kern wirklich ausgleichen kann.
Ja Quellen, den Kurs zum verteilten Rechnen habe ich nebenbei besucht (nicht auf Note) und nur Handwerkliches mitgenommen und nicht sooo viel Theorie. Die Quellenlage ist bei mir entsprechend dünn. In Erinnerung habe ich aber noch, dass das starten einiger hundert Threads unter Java um eine Aufgabe zu erledigen fast 1 zu 1 mit der Anzahl der CPU Kerne skalierte (ok waren nur 4 ) und immer noch recht gut mit den 4C+4T vom SMT. Bei 128Threads und entsprechenden häufigen Kontextwechseln zwischen den Threads gab es keine Einbußen außerhalb der Messungenauigkeit. Ergo, Kontextwechsel sind vergleichsweise billig.
Ansonsten ist SMT ja der Trick, dass wenn ein Prozess auf Daten warten muss, die Rechenwerke mit dem Prozess des virtuellen Kernes ausgelastet werden können. Bei Kontextwechseln zwischen Prozessen, muss die CPU meist darauf warten, dass die Daten des neuen Prozesses aus einer hohen Cacheebene oder gar dem Hauptspeicher kommen. Diese Wartezeit kann ein Prozess eines virtuellen Kernes wunderbar nutzen. Die Kosten/Wartezeiten eines Kontextwechsels werden damit im Regel wunderbar versteckt.
Das mag ggf vor Jahren so gewesen sein als der Big Core noch deutlich stärker war. Aber jede Iteration bringt weniger, doppelt so viel Cache bringt nur wenige % usw...
Klar, dicke Kerne rennen genauso wie eine Masse an kleinen Kerne in div. Sättigungseffekte. Genauso wie "Little" bei CPU heutzutage bedeutet, dass das von der Komplexiztät der CPUs sind, die vor 10-20Jahren monströse Absurditäten waren. Die Diskussion ob man in "Little" Cores vielleicht doch AVX2 hineinsteckt kommt ja nicht von ungefähr. Dabei war AVX2 das super Feature von Haswell.
Denke die Peak Performance ist kleinen Einheiten immer besser. Deswegen hat ne GPU ja auch was Flops abgeht weit mehr auf dem Kasten und ist bei vielen Aktionen deutlich fixer als ne CPU aus noch so großen Kernen.
Eine GPU hat super Leistung wenn man fröhlich Matritzen ohne viel Entscheidungen/Sprünge berechnen will. Aber wehe dem ist nicht so, und die Matritzen sind nur dünn besetzt oder Gott bewahre es sind viele Verzweigungen/Sprünge im Code..
Zudem bei GPUs in der Regel nur sehr grob angesteuert werden. Laut https://en.wikipedia.org/wiki/Graphics_Core_Next#CU_scheduler fressen AMD GPUs mit GCN maximal 64Threads (wavefronts) auf einmal und vergleichbare Nvidia Karten derer nur 32 (warps).
Umgekehrt bedeutet das aber auch, jeder Thread auf der GPU dutzende bis hundert ComputeUnits (oder das Äquivalent von Nvidia) auslasten muss um optimale Performance und Effizienz zu erreichen.
Für Aufgaben wie Datenbanken, Webserver, Compiler, Textprocessing etc. pp. sind solche Designs entsprechend ungeeignet.
Ergänzung ()
Kann mir auch vorstellen dass man zB mit wenig Kernen bei AVX klar kommt, bei anderen Tasks aber eher mehr kleine Kerne ohne AVX vorteilhaft wäre.
Wird je nach spezifischen Anwendungsfall in die eine oder andere Richtung gehen. Im Zweifelsfall kann aber ein dicker Kern die spezifischen Aufgaben für dicke Kerne sehr gut abwickeln und viele kleine Dinge immer noch gut. Wohingegen Cluster auf kleinen Kernen den Kleinkram sehr gut können, aber an Aufgaben für Dicker nur schlecht. Wo der AVX512 Brocken 512bit Daten je Takt verarbeiten kann, müsste einzelner kleiner Kern dafür 4 oder mehr Takte aufwenden.
5 Jahre ist soweit in der Zukunft, da versagt jede Glaskugel. Vielleicht haben wir ja in 5 Jahren auch Einfamilienhäuser mit eigenem AKW im Keller oder Vorgarten. Oder eine neue Batterietechnologie macht stromsparende CPUs überflüssig.
Ein smarter Scheduler ist von MS aber ganz sicher nicht kein, schlank und schnell.
Intel wird und muss das auch vernünftig mit der Hardware unterstützen sonst wird es ein Desaster für sie, wie sie es schon mit dem ersten Pentium MMX (kam auch aus Haifa) erlebt haben.
Das hat für heutige Verhältnisse unglaublich lange gedauert, bis ein Windows das gut unterstützt hat.
Glücklicher Weise kann und darf man ja hier bei Linux und ARM lunschen, da stehen die Vorzeichen etwas günstiger. Man muss ja kein Rad neu erfinden, nur von einem fast runden Vieleck noch ein paar abschleifen.
Das Potential ist auf jeden Fall vorhanden und so neu ist die Idee von übereinander gestapelten Einheiten (Hochhäuser z.B.) ja nun auch wieder nicht.
Man sollte nur nicht versuchen, jeder Wohnung einen eigenen Treppenaufgang plus Fahrstuhl einzubauen.
Für extrem niedrige Leistungsaufnahme in Kleinstgeräten könnte es schon sinnvoll sein, für die Klasse darüber sicher nicht mehr.
Man nehme z.B. einen 4700U zum Vergleich: 8 vollwertige Kerne bei 2GHz Basis und 15W - wohlgemerkt inkl. Uncore - die hohe Leistungsaufnahme rührt in erster Linie nicht von den BigCores her (zumindest auf AMD Seite), sondern vom zu hohen Takt.
Ergo: wenn man mit vielen Cores was anfangen kann und will: besser auf niedrigeren Takt und höhere IPC setzen, als auf unnötig komplexe und fehleranfälligere Kontrukte bauen.
Natürlich ist das zweitere fürs Marketing interessanter (man kann 4x soviele kerne bei gleicher Fläche bewerben) aber die "Real World Performance" kann da nicht mithalten).
Wirkliche Vorteile sehe ich da ausschließlich im Gesamtkonzept auf kleinstem Raum mit minimalen Standbyverbrauch - und diese Vorteile spielen nur bei Kleinstgeräten eine tragende Rolle
Wobei selbst da erst bewiesen werden muss, dass sie auch effizient bei niedriger Auslastung, also >Standby zu werke gehen können...
Bläst man die Struktur auf (z.B. Faktor 3) erhält man somit 3/12 Kerne bei ~20W - 4800U: 8/16 15W+RAM
ich denke, da braucht man kein Prophet sein, um erahnen zu können, welches Konzept besser performen wird
und homogener eingesetzt werden kann
Tablets/Smartphone/Computestick etc. - möglicherweise hui, ansonsten....
spannend ist es technisch allemal - und das wird auch nicht das letzte Wort von Intel gewesen sein / außerdem vermute ich stark, dass auch von AMD im Kleinstleistungsbereich bald noch was kommen wird... mit Jaguar war man seinerzeit ja (leider nur) kurzfristig auch ganz gut unterwegs - für damalige Verhältnisse wohlgemerkt
aber natürlich darf man sich da auch nicht verzetteln und zuviele Fronten gleichzeitig aufmachen, dafür fehlt einfach die nötige Substanz
Das ist natürlich eine sehr interessante Entwicklung! Ich würde jetzt gerne in die Zukunft blicken können um zu schauen ob der Trend im mobilen Sektor weiterhin Richtung ARM gehen wird oder ob die klassichen x86-64-Prozessoren sich an die neuen Bedürfnisse / Verhältnisse anpassen können.
Hast du zwei separate Chips, musst du Leitungen zwischen diesen verlegen und die sorgen für Verzögerungen. Hast du einen einzelnen Die oder direkt aufeinander gestapelte, dann hast du viel kürzere Verbindungen und so einen Latenzvorteil.
Prinzipiell ja. Der Speicher geht in diesem Fall aber den längeren Weg übers Package, also wie mans vom 2,5D Stacking schon kennt. Unter "echtem" 3D Stacking stelle ich mir eher einen riesigen Cache vor, der direkt auf dem Compute Die sitzt und auch tatsächlich angebunden ist.
Das ist ja immer noch Skylake Architektur von 2015.
Cannon Lake von 2018 kann LPDDR4. und der hätte auch schon deutlich eher kommen sollen. Die Fertigung hat LPDDR4 so weit verzögert.
Apollo Lake ist von 2016 und kann auch mit LPDDR4 umgehen. Der ist halt noch von Anfang an in 14 nm geplant gewesen und hat sich nicht verzögert.
Ergänzung ()
Kolu schrieb:
Wieso unterstützen die Mobile CPUS von AMD und Intel nie den neuesten RAM-Standard? LPDDR5 RAM ist schon lange verfügbar und würde vor allem bei Lakefield unglaublich viel Sinn machen. Ist die Entwicklungszeit einfach so unglaublich lang oder ist es einfach zu aufwendig im Nachhinein ein neuen RAM Standard zu integrieren?
Lakefield wird ziemlich lang in der Entwicklung gedauert haben. Deswegen ja auch nur Sunny Cove.
LPDDR5 word ja von ersten simplereren Produkten erst Anfang dieses Jahres unterstützt.
Bei Intel war es der Architekturstau aufgrund der 10 nm Problematik. Bei AMD generell sehr begrenzte Entwicklungskapazität zu dem Zeitpunkt.
Vielleicht kann ja Tiger Lake LPDDR5. Entsprechende Gerüchte gab es ja schon. Würde der GPU Performance ordentlich helfen.
) und immer noch recht gut mit den 4C+4T vom SMT. Bei 128Threads und entsprechenden häufigen Kontextwechseln zwischen den Threads gab es keine Einbußen außerhalb der Messungenauigkeit. Ergo, Kontextwechsel sind vergleichsweise billig.
![[wege]mini](https://pics.computerbase.de/forum/avatars/m/778/778975.jpg?1575883542){kind=avatar}
