Tiger Lake (10nm+, "Willow Cove" CPU-Kerne, Xe-Grafik, 2020)

[eccle]

Tiger-Lake-Achtkerner von Intel selber bestätigt:
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-1213-september-2020

Aber wann soll der kommen? Q3 2021?


https://i.ibb.co/5rxMNth/roadmap-intel.png
(https://ibb.co/R34vxZT)

[Iamnobot]

Computerbase hat den Test des 36 Watt (+Boost) Geräts jetzt um Werte eines weiteren Vorseriennotebooks mit 17W (+ Boost) ergänzt:
https://www.computerbase.de/2020-09/intel-tiger-lake-test/

[M4xw0lf]

1165G7 unter Linux vs Ryzen 4500 und 4700

https://www.phoronix.com/scan.php?page=article&item=intel-tigerlake-linux

[w0mbat]

Sieht gar nicht gut aus für Intel :(

[Blediator16]

Takt passt nicht.

https://openbenchmarking.org/embed.php?i=2010162-FI-TIGERLAKE72&sha=a55933512593&p=2

Verdächtig sind die wenigen Tests der neuen TGL Laptops trotzdem.

[dildo4u]

Der Vorgänger ging unter Dauerlast nicht auf 15 Watt im XPS sondern 24.


https://youtu.be/ZGE0AqibykA?t=199

[Blediator16]

Man darf Intel und deren Tests der Ref. Plattform nicht mehr glauben. Je mehr "real world" Laptops getestet werden, umso ernüchternder wird es.

Aus dem "roaring tiger" ist nur noch maximal ein Kater übrig geblieben. An Peinlichkeit für so ein riesen Unternehmen kaum zu überbieten.

[M4xw0lf]

Apropos roaring tiger vs Kätzchen - wo ist denn gmb geblieben? :freak:

[w0mbat]

In kurzen single-thread Szenarien auf einem gut gekühlten System ist TGL sicherlich sehr schnell, aber sobald die Last länger anliegt oder multi-thread gefragt ist, wird es problematisch für Intel.

Und dabei nutzt TGL schon Willow Cove und Intels 10nm "SuperFin". Ich ahne böses für RKL auf Cypress Cove und 14nm+++.

[DeadMeat]

Der Vorgänger ging unter Dauerlast nicht auf 15 Watt im XPS sondern 24.


https://youtu.be/ZGE0AqibykA?t=199

Boosted mit 45w , heizt sich auf 100°C und drosselt dann. Bravo Dell, und das bei einem 4Kerner.
Offenbar hat der TigerLake es auch so nicht so einfach wie gedacht und dann kommen die mit solchen Konstruktionen. Allerdings gabs das bei den 4k Ryzen Notebooks auch, macht es aber dennoch nicht besser.

[Der_Korken]

In kurzen single-thread Szenarien auf einem gut gekühlten System ist TGL sicherlich sehr schnell, aber sobald die Last länger anliegt oder multi-thread gefragt ist, wird es problematisch für Intel.

Das lässt die big-little-Strategie von Intel nur noch logischer erscheinen. Kompromisslose Singlecore-Leistung haben sie schon, wenn sie jetzt noch sparsame Kerne für MT dazupacken, können sie AMD in dem Bereich wieder angreifen. Im Moment müssen sie mit dem auskommen, was sie haben. Dass AMD mit Renoir so brutale Effizienz bringt, hatten die nicht auf dem Schirm.

[aufkrawall]

Wo siehst du ein Indiz, dass Intel mit little.BIG für schwere MT-Workloads gleichzeitig Leistung und Effizienz irgendwoher zaubern könnte?

[Troyan]

Weil effiziente Cores deutlich günstiger in der Fertigung sind und somit man a)mehrere verbauen und b) diese niedriger takten kann. Siehe dazu den ARM Markt, wo das genau von jeder Firma gemacht wird.

[aufkrawall]

Und wo entnimmt man, dass Intel mit einem fetten Cluster an little-Kernen (Tremont?) Zen 2/3 bei MT Paroli bieten könnte? Das ist überhaupt nicht ausgemacht.

[davidzo]

Und wo entnimmt man, dass Intel mit einem fetten Cluster an little-Kernen (Tremont?) Zen 2/3 bei MT Paroli bieten könnte? Das ist überhaupt nicht ausgemacht.

Das hat er auch nirgendwo behauptet.


Intel hat nur gemerkt dass man mit den Cove Kernen an einer Wand aufgeschlagen sind. Man kann die Kernanzahl und MT-Takt nicht hochfahren wie Zen und zwar nicht nur wegen der explodierenden TDP, sondern auch wegen der Diesize. Ersteres hat man im prinzip schon bei icelake vs skylake vs picasso gesehen, Icelake 4-kerner fallen in MT loads TDP-bedingt auf 1,x Ghz, viel niedriger als Picasso und Skylake. Wir haben das erst richtig gesehen als renoir da war, aber intel war das vom ersten Moment an bewusst dass man mit Cove Kernen in MT eine Wand trifft.

Intel muss völlig unabhängig von AMD Zen3 die beste Strategie finden mit der eigenen Technologie umzugehen. Man hat halt nur die Covekerne und die Monts. Und wenn Coves in MT beim Takt zu stark einbrechen, aber Monts immerhin munter weiter mehr Leistung pro Watt rauspumpen als die Coves, dann müssen es halt mehr Monts werden. Ein paar Coves braucht man aber noch für die ST Leistung, die bräche sonst zu sehr ein.

[aufkrawall]

Das hat er auch nirgendwo behauptet.

Eh, doch? Es ging um das Angreifen von AMD (durch Intel). Wo steht denn Tremont so bei MT-Last? Vielleicht mal der Diskussion irgendwelche Fakten zuführen?
Wurd hier schon völlig verdrängt, dass der Einsatz von little.BIG durch Intel vielleicht immer noch etwas mit der schlechteren Akkulaufzeit bei geringer Last vs. ARM zu tun haben könnte? :freak:

[Der_Korken]

Wo siehst du ein Indiz, dass Intel mit little.BIG für schwere MT-Workloads gleichzeitig Leistung und Effizienz irgendwoher zaubern könnte?

Die Leistung kommt über die Masse, die Effizienz über die kleinen, niedrig getakteten Kerne. Natürlich werden die kleinen Kerne nicht mit den Zen 3 (oder höher) Kernen mithalten können, dafür bekommt man (so zumindest der Plan) mehr davon unter. Ich will damit nicht sagen, dass das die überlegenere Strategie gegenüber Zen sein muss, aber mit den aktuellen Cove-Kernen als Basis ergibt der Plan mit big-little einfach viel Sinn. Man kann sich sicher nicht zu Unrecht über die aktellen Schluckspecht-Cove-Kerne lustig machen, aber sie werden langfristig ihren Zweck als ST-Lieferant wohl gut erfüllen. Den Rest wird man mit Alder Lake dann sehen.

Edit: Ich sollte den Post auch mal abschicken und nicht ne halbe Stunde auflassen:freak:

Eh, doch? Es ging um das Angreifen von AMD (durch Intel). Wo steht denn Tremont so bei MT-Last? Vielleicht mal der Diskussion irgendwelche Fakten zuführen?
Wurd hier schon völlig verdrängt, dass der Einsatz von little.BIG durch Intel vielleicht immer noch etwas mit der schlechteren Akkulaufzeit bei geringer Last vs. ARM zu tun haben könnte? :freak:

Moment. Ich habe nur gesagt, dass Intel AMD wieder bei MT-Leistung angreifen kann mit big-little, von Tremont habe ich nichts gesagt. Es ist ja nicht gesagt, dass das direkt mit der ersten Iteration gelingt (wobei Alder Lake schon Gracemont wäre, von dem wir noch gar nicht wissen wie schnell er wird). Die ST-Leistung von Intel ist nach wie vor sehr gut, d.h. big-little ist für mich der logischste Schritt, um bei MT wieder aufzuholen.

[HOT]

Eh, doch? Es ging um das Angreifen von AMD (durch Intel). Wo steht denn Tremont so bei MT-Last? Vielleicht mal der Diskussion irgendwelche Fakten zuführen?
Wurd hier schon völlig verdrängt, dass der Einsatz von little.BIG durch Intel vielleicht immer noch etwas mit der schlechteren Akkulaufzeit bei geringer Last vs. ARM zu tun haben könnte? :freak:
Das kann aber auch andere Gründe haben, z.B. den Ringbus. Wenn die Tremont-4-Kern-Cluster als nur ein Hop da dranhängen, wäre das für den Ringbus ein 10-Kerner, effektiv aber ein 32-Thread-Prozessor. (Tremont hat doch SMT, oder?)
Ich glaube, Intel hat einfach versucht, mit dem eigenen Baukasten das beste Ergebnis hinzubekommen. Heraus kam halt der big.LITTLE-Ansatz. Hinzu kommt noch, dass die .cove-Kerne offenbar auch sehr "fett" geraten sind. Bei Tiger Lake ist es klar, die großen Caches gepaart mit dem auf Hochleistung getrimmten Fertigungsprozess kostet halt verhältnismäßig viel Energie. Deswegen hat Renoir ja auch nur 4MB.

[Lehdro]

Der Sinn hinter dem little.BIG ist uns sicher allen klar, nur irgendwie wird sich das unter 10nm einfach nicht in die Praxis umsetzen lassen, wenn schon 4 Cove Kerne soviel (oder gar mehr) verbraten wie 8(!) heruntergestutzte Zen 2 Kerne. Da hilft dann auch das dranflicken von 4 effizienten Monts nicht mehr weiter, weil das Grundgerüst schon vorher am Wackeln ist. Intel muss die Fertigung in den Griff kriegen, damit das ganze Konzept aufgeht. Oder halt die großen Kerne per se effizienter ausrichten, damit da noch Platz ist für mehr davon, oder halt mehr Monts.

Im Desktop ist das alles kein Problem - wobei die Monts dort aber auch eher deplatziert sind - im Mobile Bereich ist das ganze aber eine Todsünde, weil man jetzt schon hintendran ist.

[Der_Korken]

Die Frage ist wie viele von den Cove-Kernen man am Ende wirklich braucht. Vielleicht sind zwei Cove-Kerne für Mobile schon genug, wenn man noch 8 Mont-Kerne dazupackt, die sich bei MT dazuschalten. Spiele skalieren auch heute oft noch mäßig über mehr als 4C/8T hinaus, d.h. für Desktop würden 4 Cove-Kerne gepaart mit 8 oder 16 Mont-Kernen eine gute Combo ergeben. Aber das wird langsam OT und gehört eigentlich in den Alder-Lake-Thread.

[Nazar]

Das lässt die big-little-Strategie von Intel nur noch logischer erscheinen. Kompromisslose Singlecore-Leistung haben sie schon, wenn sie jetzt noch sparsame Kerne für MT dazupacken, können sie AMD in dem Bereich wieder angreifen. Im Moment müssen sie mit dem auskommen, was sie haben. Dass AMD mit Renoir so brutale Effizienz bringt, hatten die nicht auf dem Schirm.

Ist die "kompromisslose" SC Leistung bei Intel nicht mit einem "Timer" versehen oder bin ich da falsch informiert? :confused:
Soweit mir bekannt ist, kann die maximale SC Leistung nur maximal für 2 Minuten anliegen, danach wird runtergetaktet. :confused:
Fakt ist aber, dass Intel leider mit dem offensichtlichen Selbstbetrug weiter macht.
Die Vorstellung vom neuen mobilen "Tiger" war an Peinlichkeit kaum noch zu überbieten. Dieses rumgehacke auf AMD, fürchterlich.
So lange die komplette Führungsriege bei Intel nicht ausgetauscht wird, wird Intel weiter am eigene Ast sägen.
Ich komme wirklich nicht über diese peinliche Vorstellung von Intel hinweg.
Wie kann man sich als Unternehmen, in alle Öffentlichkeit, nur so bloßstellen? War denen wirklich nicht klar, dass der Schund aufgedeckt wird? Glauben die ihren Mist wirklich? Traurig. :frown:

[y33H@]

In 15W wird der SC-Takt quasi durchweg gehalten ... davon ab bist du viel zu emotional, auch AMD will nur dein Geld.

[dildo4u]

Das ganze scheint eher ein Dell Problem zu sein dieser Fokus unbedingt Apple beim Formfaktor schlagen zu wollen beißt sie jetzt in den Arsch, Apple geht jetzt auf ARM aber diese Option ist vermutlich nix für Dell.
Laut dem von mir verlinkten Test wird das XPS13 unangenehm Warm selbst mit dem 15 Watt TDP Limit, also kein Plan was dort die AMD Modelle mit 6 oder 8 Cores lösen könnten.

[HOT]

Die Frage ist wie viele von den Cove-Kernen man am Ende wirklich braucht. Vielleicht sind zwei Cove-Kerne für Mobile schon genug, wenn man noch 8 Mont-Kerne dazupackt, die sich bei MT dazuschalten. Spiele skalieren auch heute oft noch mäßig über mehr als 4C/8T hinaus, d.h. für Desktop würden 4 Cove-Kerne gepaart mit 8 oder 16 Mont-Kernen eine gute Combo ergeben. Aber das wird langsam OT und gehört eigentlich in den Alder-Lake-Thread.
Das klappt bei anderer Software vielleicht, aber bei Spielen sind die Tremont ein Problem, da sieht erheblich länger für Berechnungen brauchen als die cove-Kerne. Spiele sind sehr Datenlastig und laufen in Echtzeit, was sehr viel Synchonisation bei MT benötigt und wenn man das gleichzeitig nutzt werden die cove-Kerne auf die mont-Kerne warten müssen. Man sieht ja schon, dass AMDs CCX mehr Latenzen erzeugen als Intel Ringbus, das ist ja der Grund, warum die Skylake-Derivate trotz erheblich niedrigerer IPC schneller bei Spielen sind als Zen2, wie soll das erst bei mont-Kernen werden. Am besten deaktiviert man die mont-Kerne komplett bei Spielen aus meiner Sicht.
Bei der PS3 hat man ähnlich gedacht damals, mit der Folge, dass die PS3 für Spiele sehr oft nur ein ein-Kerner war...

[davidzo]

Das klappt bei anderer Software vielleicht, aber bei Spielen sind die Tremont ein Problem, da sieht erheblich länger für Berechnungen brauchen als die cove-Kerne. Spiele sind sehr Datenlastig und laufen in Echtzeit, was sehr viel Synchonisation bei MT benötigt und wenn man das gleichzeitig nutzt werden die cove-Kerne auf die mont-Kerne warten müssen. Man sieht ja schon, dass AMDs CCX mehr Latenzen erzeugen als Intel Ringbus, das ist ja der Grund, warum die Skylake-Derivate trotz erheblich niedrigerer IPC schneller bei Spielen sind als Zen2, wie soll das erst bei mont-Kernen werden. Am besten deaktiviert man die mont-Kerne komplett bei Spielen aus meiner Sicht.
Bei der PS3 hat man ähnlich gedacht damals, mit der Folge, dass die PS3 für Spiele sehr oft nur ein ein-Kerner war...

Naja, die meisten Spiele sind Latenzgetrieben, profitieren also von Cache, Speicherbandbreite und core to core Bandbreite. Mit sehr breiten Cores können sie dagegen kaum etwas anfangen. Die "Verbesserungen" der Cove kerne wie 512bit AVX-Einheit, zusätzliche Integereinheit und zusätzliche loas/stores werden in den meisten Spieleengines nicht durchschlagen.
Dass die Spiele auch auf kleinen Cores recht vernünftig skalieren mag auch an den Konsolen liegen, aber das war auch vorher schon so. An Skylake vs Zen2 sieht man ja gut dass die breitere Architektur von Zen2 kaum durchschlägt solange die Cache-Latenzen nicht mitspielen.
Ein gut angebundener Mont-Core mit zugriff auf einen großen cachepool dürfte da gar nicht mal so schlecht performen.

Außerdem haben Spiele immer noch fast immer nur einen Hauptthread und dazu diverse weniger fordernde Nebenthreads, das ist also fast ein Idealszenario für heterogene Cores.

Spiele gehören aber sowieso nicht zum Einsatzzweck von Ultrabooks. Da sind eher browsing Benchmarks wie Octane, XPRT, basemark angesagt und da reicht ein einzelner cove-kern wohl.



BTW, Den OEMs scheint auch bewusst zu sein dass Tigerlake eher zu budget Notebooks passt, sonst wird der noch seltener als Icelake über die Ladentheke gehen: https://www.anandtech.com/show/16179/at-deals-dell-inspiron-14-5000-10-percent-off

$649 für ein convertible, das ist eine klare Ansage an das IdeaPad Flex 5, Yoga 6 und Co, entry Renoir labtops die in derselben Preisklasse wildern.

[Rampage 2]

Bei der PS3 hat man ähnlich gedacht damals, mit der Folge, dass die PS3 für Spiele sehr oft nur ein ein-Kerner war...

Kannst du das etwas detaillierter erläutern?

R2

[HOT]

https://www.techpowerup.com/273516/intel-tiger-lake-based-pentium-and-celeron-to-feature-avx2-an-instruction-the-entry-level-brands-were-deprived-of

Scheinen Tiger Lakes in den Desktop zu sickern. Vielleicht will man Skylake endlich insgesamt aus dem Verkehr ziehen.


davidzo
du gehst leider überhaupt nicht auf den entscheidenden Punkt ein, nämlich, dass der Windows Schedular nicht damit umgehen kann und deshalb die .mont-Kerne bremsend wirken dürften, wenn sie für Spiele belegt werden, da sie schlicht und ergreifend langsamer sind als .cove-Kerne. Daher wird es eine Priorisierung geben, die zuerst den 1. Thread der .cove-Kerne belastet, danach den 2. Thread der .cove-Kerne und erst danach die .mont-Kerne belasten wird. damit lässt sich das größte Desaster abwenden in Spielen.
Dass Spiele wenig rechenlastig sind ist hier komplett irrelevant, denn die Leistung beeinflusst das nicht, die .mont bleiben langsamer. Dafür sind Spiele sehr datenlastig und die Threads erfordern viele Synchronisationen. Das Problem dabei ist, dass es eine Echtzeitanwendung ist. Man müsste Kontrolle über den Schedular übernehmen können, was bei Windows nicht geht (derzeit) als Applikationsentwickler, das würde die .mont-Kerne erheblich nutzbarer machen.

Rampage 2
Cell besteht ja auch einem PPC-Kern und bis zu 8 kleinen IO-Rechenkernen. Leider sind die Rechenkerne derart langsam und schwer anzusteuern IIRC, dass das kaum handhabbar war in Spielen.

[Undertaker]

Woher stammt denn der Mythos, dass der Windows Scheduler damit nicht umgehen kann? Auch wenn Lakefield als Pipecleaner zu sehen ist und diversen Limitierungen unterliegt (nur ein Big Core, unter Volllast nur als 0+4 Core ausgelegt etc.): Das Scheduling auf den großen bzw. die kleinen Kerne funktioniert mit einem aktuellen Win10 mittlerweile super, auch für nicht angepasste Uraltsoftware. Selbst das seelige SuperPi, welches keine CPU der letzten 20 Jahre kennen dürfte, läuft automatisch auf dem Big Core.
Ansonsten stimme ich dazidzo zu, für Spiele sind in der Regel nur einzelne Kerne wirklich limitierend. Wenn die performant sind und der ganze Kleckerkram mit Teillast auf den "lahmen" Rest abgewälzt wird, dürfte das kaum einen Performanceunterschied zu einer klassischen non-Hybrid-CPU machen. Allerdings erheblich die Effizienz steigern... ;)

[davidzo]

Ich denke auch bis dahin geht noch soviel Zeit ins Land dass wir durchaus mit Anpassungen des Schedulers rechnen können. Intel ist ja nicht der erste der deswegen bei Microsoft anklopft (AMD Zen1 anyone?) und gegenüber Linux hat man mittlerweile einen erheblichen Rückstand, Microsoft wird das also sowieso schon mal auf die Roadmap gesetzt haben.
Insbesondere wenn jetzt Intel mit 80% Marktdominanz das fordert dass der scheduler feingranularer auf die vorhandene Hardware eingeht wir man sich nicht mehr wehren können das mal an zu fassen.
BTW, selbst Microsofts Windows-on-Arm Liebelei ist langfristig darauf angewiesen dass man irgendwie mit big cores und small cores sinnvoll umgehen kann.

Ja, Lakefield ist de facto ein SDV für Alderlake, so kann man das auch sehen.

[reaperrr]

https://www.techpowerup.com/273516/intel-tiger-lake-based-pentium-and-celeron-to-feature-avx2-an-instruction-the-entry-level-brands-were-deprived-of

Scheinen Tiger Lakes in den Desktop zu sickern. Vielleicht will man Skylake endlich insgesamt aus dem Verkehr ziehen.
Genauer lesen:

"Both are mobile chips with 15 W TDP, (...)"

[Mr.Scott]

Mit welcher älteren GTX Karte könnte man die große Xe Grafik vergleichen?
Evtl eine GTX 680?

[davidzo]

Eher gtx 670 niveau. Wenn es hoch kommt dann eine GTX1050 bzw. 960, 770.

[davidzo]

Hatten wir eigentlich schon den Tigerlake deepdive wo Anandtech festgestellt hat dass Willow Cove in vielen Bereichen spürbare performance regression gegenüber Sunny (EDIT: hier stand Capress, ist natürlich sunny gemeint) Cove hat?

IPC improvements of Willow Cove are quite mixed. In some rare workloads which can fully take advantage of the cache increases we’re seeing 9-10% improvements, but these are more of an exception rather than the rule. In other workloads we saw some quite odd performance regressions, especially in tests with high memory pressure where the design saw ~5-12% regressions. As a geometric mean across all the SPEC workloads and normalised for frequency, Tiger Lake showed 97% of the performance per clock of Ice Lake.


https://www.anandtech.com/show/16084/intel-tiger-lake-review-deep-dive-core-11th-gen/8

Ich hatte bisher den Eindruck das Tigerlake im schlechtesten Fall 1:1 die IPC von Icelake erreicht, bzw. in Cachesensitiven Benchmarks besser abschneidet durch den vergrößerten und exklusiven L2.

Es scheint aber genau umgekehrt zu sein, in memory bound applications liegt Icelake vorne.


Es wird immer wieder darüber geredet wie wichtig der Ringbus für die Spieleperformance der letzten Intel Generationen sei, dabei wird der private, inklusive L2 cache vergessen, der dazu auch erheblich beigetragen hat.

Ein 256 kleiner privater, inklusiver L2 Cache mit sehr niedrigen latenzen (12 cycles) ist was Intel Architekturen seit Nehalem in Spielen so schnell macht.

Bei Sunny Cove stieg die Latenz schon auf 13cycles, bei Tigerlake ist er 25 cycles und exklusiv. Ich kann mir gut vorstellen dass der 512kb cache von Sunny die Hitrate deutlich verbessert und die 1ns penalty damit egal sind, aber 26 Cylces? Das ist schon eine Harte nuss...


Die bisher kolportierte Darstellung von Willow Cove als 125% IPC (basierend auf Mebiuw/ 3DC Tabelle) gegenüber Skylake ist damit nicht haltbar. Es müsste eher gleichauf oder 3% unterhalb der 118% von Sunny liegen.

Spannend wird ob Cypress Cove denn die 118% von Sunny erreicht, immerhin erbt er die cache struktur mit dem schnellen inklusiven Cache.
Ohnehin kommen diese 18% im Durchschnitt in Spielen natürlich weniger an, da die generell eher mit Latenzen und Hitrate skalieren als mit der breite des Cores oder gar neuen Instruktionen wie AVX-512 und Vektor-AES.

[Der_Korken]

Du schreibst im ersten Satz Cypress Cove (Rocket Lake), meinst aber Sunny Cove (Ice Lake) oder?

Dass der L1 nicht mehr im L2 inkludiert sein wird, wusste ich noch gar nicht. Das ergibt für mich auch keinen Sinn, denn der L2 hat ja mehr Platz denn je für die L1-Lines. Oder meinst du bzw. Anand, dass der L2 nicht mehr im L3 inkludiert ist? Dass ergibt schon eher Sinn. Und ja, es kann durchaus ein Faktor bei der Spieleleistung sein. Ich habe mich bei Zen 2 schon gefragt, warum AMD das nicht macht. Der L3 würde von 16 auf 14MB schrumpfen, aber es vereinfacht die Kohärenz und man muss nicht alles aus dem RAM neu laden, wenn ein Prozess innerhalb eines CCX verschoben wird.

Wo hast du die 25 cycles für den L2 her? Anand vermutet 14 anhand von Latenzmessungen.

[davidzo]

die 25 kommen von hardwaretimes: https://www.hardwaretimes.com/intels-willow-cove-core-tiger-lake-is-basically-sunny-cove-w-more-cache-identical-decode-eus-and-bp/

aber stimmt, anandtech hat da andere Werte. Dann verstehe ich aber nicht wieso Anandtech in memory bound applications eine regression misst wenn die caches doch schneller (L1) bzw. nicht langsamer (L2) und größer geworden sind?
Ist das nur der die Latenzverschlechterung des L3 die da so stark durchschlägt?

[Loeschzwerg]

Endlich ein neues Lebenszeichen zur 11ten NUC Generation "Panther Canyon":
https://www.computerbase.de/2020-12/nuc-11-performance-q1-2021-tiger-lake-mini-pc/

[dildo4u]

8 Core Tiger Lake Frequenzen.

https://videocardz.com/newz/intel-11th-gen-core-tiger-lake-h-specifications-leaked

[smalM]

i7-11800H GB5-Werte (via Twitter (https://twitter.com/TUM_APISAK/status/1371788461640851456)):

https://browser.geekbench.com/v5/cpu/6972694
https://browser.geekbench.com/v5/compute/2553417

[robbitop]

Die Taktraten sehen für mobile CPUs auch nicht so schlecht aus. 4,9 GHz.

[Gipsel]

Die Taktraten sehen für mobile CPUs auch nicht so schlecht aus. 4,9 GHz.Ist nicht viel anders als bei Zen3 (boostet bis 4,8GHz bei den H-CPUs) und ist eigentlich auch kein Wunder, da bei single-Core Last die TDP nicht limitiert (anders als bei der 15W U-Serie). Na mal sehen, welche Taktraten die bei Allcore-Last halten (wenn die TDP nicht überfahren wird). Die Base-Takte sehen schon recht niedrig aus verglichen zu Zen3 (2,1GHz für 11900H vs. 3,2GHz beim 5800H [der 5900HS hat 3 GHz Basetakt bei 35W statt 45W]). Aber das muß ja in der Praxis nicht so eklatant ausfallen.

[CrazyIvan]

Bei GB5 dürfte AVX512 wieder relativ stark durchschlagen. Aber das passt schon. TGL ist einfach stark und auch im Hinblick auf Effizienz meines Erachtens deutlich besser, als hier gern behauptet wird. Je nach Anwendungsfall eine starke Konkurrenz für Cézanne.

[mironicus]

Die Werte von Geekbench nach mehrmaligen Durchlauf würde mich eher interessieren. Denn ein einzelner Test dauert nur 2 Minuten und in dem Zeitraum können die meisten Notebooks ein Turboprofil mit erhöhter TDP laufen lassen, die bis zu doppelt so hoch wie die normale TDP sein kann.

[robbitop]

Bei GB5 dürfte AVX512 wieder relativ stark durchschlagen. Aber das passt schon. TGL ist einfach stark und auch im Hinblick auf Effizienz meines Erachtens deutlich besser, als hier gern behauptet wird. Je nach Anwendungsfall eine starke Konkurrenz für Cézanne.
Statt RKL-S hätte man besser TGL-S veröffentlicht. Aber ggf sind die 10 nm Kapazitäten einfach zu eng, so dass man die besten Produkte dort einführt, wo die höchsten Margen sind. Mobile und Server.

[HOT]

Würd ich auch sagen und ich denke, RKL wird vor allem aus Kapazitäts- und Yieldgründen weiterhin in 14nm gefertigt werden. Denen bleibt schlicht nichts anderes übrig.

[CrazyIvan]

Sehe ich genau so wie ihr beiden.
+ Vermutlich war man sich bei Super-Fin nicht so sicher - hat sich ja mittlerweile als sehr deutlicher Sprung erwiesen.

[Locuza]

[...]
Es wird immer wieder darüber geredet wie wichtig der Ringbus für die Spieleperformance der letzten Intel Generationen sei, dabei wird der private, inklusive L2 cache vergessen, der dazu auch erheblich beigetragen hat.

Ein 256 kleiner privater, inklusiver L2 Cache mit sehr niedrigen latenzen (12 cycles) ist was Intel Architekturen seit Nehalem in Spielen so schnell macht.
[...]
Du schreibst im ersten Satz Cypress Cove (Rocket Lake), meinst aber Sunny Cove (Ice Lake) oder?

Dass der L1 nicht mehr im L2 inkludiert sein wird, wusste ich noch gar nicht. Das ergibt für mich auch keinen Sinn, denn der L2 hat ja mehr Platz denn je für die L1-Lines. Oder meinst du bzw. Anand, dass der L2 nicht mehr im L3 inkludiert ist? Dass ergibt schon eher Sinn. Und ja, es kann durchaus ein Faktor bei der Spieleleistung sein. Ich habe mich bei Zen 2 schon gefragt, warum AMD das nicht macht. Der L3 würde von 16 auf 14MB schrumpfen, aber es vereinfacht die Kohärenz und man muss nicht alles aus dem RAM neu laden, wenn ein Prozess innerhalb eines CCX verschoben wird.

Wo hast du die 25 cycles für den L2 her? Anand vermutet 14 anhand von Latenzmessungen.

Nur als Einwurf, der L2$ ist seit Nehalem weder inklusive noch rein exklusive, es können Cache Lines vom L1$ im L2$ landen, aber es wird nicht eine vollständige Kopie geführt.
Es ist ein Non-Inclusive-Cache-Design.
Der L3$ war dagegen seit Nehalem Inklusive und hat die Daten der unteren Cache-Stufen kopiert, was sich mit Tiger Lake nach über einer Dekade geändert hat (nun auch Non-Inclusive), da die privaten L2$ nun so massiv geworden sind.

Bei Zen2/3 hätte man über ein ähnliches Design wie bei >= Nehalem nachdenken können, allerdings ändert man die ganze Infrastruktur nicht so einfach von Heute auf Morgen und es muss starke Gründe für einen Wechsel geben, denn das es sich wirklich lohnt ist schließlich nicht garantiert.
Die effektive Cache-Größe ist kleiner und man muss schauen wie hoch die Verwaltungskosten von einer anderen Lösung sind und wo die Vor- und Nachteile sind.
AMD's aktuelles exklusive L3$ Design ist auch relativ zu damals gut aufgestellt.
Es ist eine zentrale Verwaltungszone, die neben den L3$ Daten und direkten Crossbars bzw. was auch immer jetzt AMD bei Zen3 verwendet, noch Shadow Tag Macros implementiert hat, welche die Tags&States von den lokalen L2$ speicher, damit muss man nicht direkt alle L2$-Leitungen bei einem Miss belästigen und kann energetisch das viel günstiger auf L3$-Ebene lösen.
Darüber hinaus soll mit Zen4 der private L2$ auf 1MiB verdoppelt werden, was ein inklusives design auch wieder weniger attraktiv machen kann.

[dildo4u]

Tiger Lake 6/8 Core Intel Folien


https://videocardz.com/newz/intel-11th-gen-core-tiger-lake-h-notebook-series-specifications-have-leaked

[fondness]

Tiger Lake 6/8 Core Intel Folien


https://videocardz.com/newz/intel-11th-gen-core-tiger-lake-h-notebook-series-specifications-have-leaked

AMD schafft sowas mit 15 Watt, Intel braucht mal eben das 2-3 fache trotz 10nm.

[BlacKi]

und jetzt?^^

was meinst du mit 15w?
in dem test
https://abload.de/img/intele1ktc.png

und :"the 5900HS is configured to a TDP of 35W".

[Blediator16]

Er meint die U CPUs. Ich nehme an, dass Intel auch <35W 8 Kerner bringen wird.

[Lehdro]

in dem test

Das ist kein Test, sondern Marketing. Übrigens wird das krass im GPU Limit hängen, bei beiden Prozessoren. Ist immerhin nur eine 3060 mobile verbaut. Lieber auch echte Tests warten.

[CrazyIvan]

Er meint die U CPUs. Ich nehme an, dass Intel auch <35W 8 Kerner bringen wird.
Nicht vor Alder Lake. Und dann auch nicht so, wie Du es meinst, sondern 2+x

[HOT]

Bei der CPU mag ich wie heftig überdimensioniert die Plattform ist. Das wär sogar viel für Desktop-Systeme.

Lt. Ian wird Tiger Lake refresht, also wird das evlt. erst mal nix Alder Lake im Mobilsegment. Alder Lake H könnte sein in > 1 Jahr.

[KarlKastor]

Das sieht genauso aus wie ein es Desktop Plattform. Fast identisch zu Rocketlake.
Hätten sie dann auch gleich im Desktop bringen können. :D

[Fusion_Power]

Die Xe iGPU hingegen ist wirklich ganz schön geschrumpft im Vergleich zu den bisherigen Tiger Lake Mobile CPUs. Da haben die "kleinen" CPUs aber eindeutig die Nase vorn. Kann natürlich verstehen dass man die schnelleren Chips dann natürlich auch ehr mit dedizierten GPUs benutzt und ne iGPU in Gaming Notebooks keine Rolle mehr spielt.

[KarlKastor]

Sieht man ja bei AMD. Es gibt so gut wie keine H-CPU die nicht mit einer extra GPU ausgeliefert wird. Und dort ist die IGP sogar recht leistungsfähig.
Gut jetzt ist Intel ein bisschen stärker im Business Segment, aber im Grunde denke ich, dass das eine richtige Entscheidung war.

[dildo4u]

Das ist kein Test, sondern Marketing. Übrigens wird das krass im CPU Limit hängen, bei beiden Prozessoren. Ist immerhin nur eine 3060 mobile verbaut. Lieber auch echte Tests warten.
Die Mobile AMD Modelle sind langsamer als Desktop(weniger Cache) und der Intel hat weniger Kerne was innerhalb der 35 Watt besseren Takt erlaubt.
Da wurde vermutlich bewusst der i5 genommen.

Der alte Intel i9 ist immer noch Gameing King vermutlich weil er massiv mehr Strom nimmt als AMDs Modelle.

https://youtu.be/XC5PPazhpg4?t=401

Tiger Lake 8 Core wird extrem konkurrenzfähig sein dafür aber absurde Preise aufrufen.

2200$ mit 3060, 2500$ mit 3070, 3000$ mit 3080.

https://videocardz.com/newz/msi-ge76-raider-gs66-stealth-gf76-thin-and-gl76-leopard-laptops-with-tiger-lake-h-cpus-pictured

[davidzo]

Immerhin läuft da nichts mehr mit angezogener Handbremse.
HT und 3200mhz RAM für alle CPUs, selbst den kleinsten 11260H.

Der Baseclock ist auch höher als ich erwartet habe, immerhin hat CometLake mit den "kleineren" Kernen gerademal 2,4Ghz in der Spitze beim 9980HK und 10980HK.

Wenn man dann allerdings sieht dass die Frequenz auf TDP unterhalb vom Baseclock liegt, dann fühlt man sich schon ein bisschen verarscht. Baseclock ist doch eigentlich die garantierte minimale Taktrate bei TDP - was ist passiert? Bei welcher TDP schaffen die denn jetzt den Baseclock, 45W?

[CrazyIvan]

Wenn man dann allerdings sieht dass die Frequenz auf TDP unterhalb vom Baseclock liegt, dann fühlt man sich schon ein bisschen verarscht. Baseclock ist doch eigentlich die garantierte minimale Taktrate bei TDP - was ist passiert? Bei welcher TDP schaffen die denn jetzt den Baseclock, 45W?
LOL, die bei Intel haben echt Nerven, sowas auf die Folie zu schreiben. Aber ja, Dein Schluss ist der naheliegendste. Mit Baseclock werben und mit cTDP verkaufen.

[stinki]

Ich denke auch, die angegebenen Baseclocks beziehen sich auf 45W bei den H Modellen.
Beim HK könnte es auch mehr als 45W sein (aber weniger als cTDP von 65W).

Aber immerhin, das sind jetzt die ersten 8-Core Intel Chips in 10nm für den Massenmarkt.
Da kann man schon mal die Sektkorken knallen lassen ;-)
Hätte fast nicht mehr geglaubt, dass ich das noch erleben darf :-)

[BlacKi]

nicht mehr lange, dann gibts 24t, natürlich von intel ;)

[fondness]

nicht mehr lange, dann gibts 24t, natürlich von intel ;)

24? Haben die kleinen Kerne kein SMT?

[Piefkee]

24? Haben die kleinen Kerne kein SMT?

Nein die kleinen haben kein SMT

[davidzo]

Interessanter Beifang bei Igors letztem DG2 leak:

Tigerlake H45 hat einen ca. 255mm2 großen DIE (angenommen es ist gleich breit wie TGL-H35/U, also 10,7mm):

https://www.forum-3dcenter.org/vbulletin/attachment.php?attachmentid=75270&stc=1&d=1620385399

[Triskaine]

Nein: Locuza's Twitter (https://twitter.com/Locuza_/status/1349074210166075393)

Diese Backside BGA Abschätzungen liegen tendenziell ziemlich daneben, dass kann man sich schenken.

[CrazyIvan]

Nur 180mm²? Hätte mehr vermutet. Damit herrscht faktisch Gleichstand zu Cézanne - mal abgesehen vom 2. Die bei TGL auf dem Package.

[y33H@]

Es sind auch mehr(tm) :biggrin:

[davidzo]

Nein: Locuza's Twitter (https://twitter.com/Locuza_/status/1349074210166075393)

Diese Backside BGA Abschätzungen liegen tendenziell ziemlich daneben, dass kann man sich schenken.

Hm, ist das überhaupt dasselbe package? Bei Tigerlake-8C scheint ja der i/o DIE zu fehlen, das wäre also leicht erklärbar wenn es auch ein anderes package ist. Der Dieshim außen herum ist schonmal anders, der radius wirkt kleiner bzw. das package größer?!

[y33H@]

TGL-H45 hat keinen On-Package-PCH, zudem andere Fassung, genauer BGA 1787 statt BGA 1449.

[Triskaine]

Okay, ich nehme alles zurück. TGL-H (https://twitter.com/SteakandChickn/status/1391583749943533569/photo/1) ist unerwartet fett, primär wegen dem riesigen Uncore/System Agent. Dürften >220mm² sein.

[dildo4u]

Bin gespannt ob der 8 Core die selbe fette IGP hat, G7 kann recht hilfreich gegen AMD sein.

jJedsO2YO6w

Weil einige ja immer noch fragen wie Intel Quads Heute sinnvoll sein können, Vega IGP saugt einfach AMD ohne extra Ampere GPU kann man eigentlich vergessen, da Quicksync und co einfach zu mächtig sind.

[davidzo]

TGL-H45 hat keinen On-Package-PCH, zudem andere Fassung, genauer BGA 1787 statt BGA 1449.


Oh, okay dann war ich auch beim Package falsch, das wird keine 46.5 x 25mm mehr sein! Wobei Igors Bild sogar Tigerlake U sein könnte - soviel zu den Backside BGA Abschätzungen :freak:

[YfOrU]

Bin gespannt ob der 8 Core die selbe fette IGP hat, G7 kann recht hilfreich gegen AMD sein.


TGL-H hat wie Rocket Lake 32EUs: https://videocardz.com/newz/intel-11th-gen-core-tiger-lake-h-notebook-series-specifications-have-leaked

[dildo4u]

Ah hab verpasst das die 24mb Cache haben, das könnte erklären warum er so groß ist.

[Leonidas]

Raichu @ Twitter
Tiger Lake-H Die-Shot
https://twitter.com/OneRaichu/status/1391997167187894274

https://pbs.twimg.com/media/E1FeBstVIAANj0m?format=jpg

[dildo4u]

107 Watt Boost :eek:


https://i.ibb.co/b5YfgGx/22-1080-be29ba94.jpg (https://ibb.co/Wv7TWRQ)

https://www.computerbase.de/2021-05/tiger-lake-h-45-fuer-notebooks-gibt-es-jetzt-10-nm-cpus-mit-bis-zu-8-kernen/

[Der_Korken]

107 Watt Boost :eek:


https://i.ibb.co/b5YfgGx/22-1080-be29ba94.jpg (https://ibb.co/Wv7TWRQ)

https://www.computerbase.de/2021-05/tiger-lake-h-45-fuer-notebooks-gibt-es-jetzt-10-nm-cpus-mit-bis-zu-8-kernen/

Spiele-Performance sieht gut aus. Gegenüber Rocket Lake hat man eben den "echten" Willow Cove und vor allem 1,25MB L2 pro Kern und 24MB L3. Das Teil wäre die bessere Desktop-CPU gewesen als Rocket Lake. Gerade der größere L3 kann gut was ausmachen. Man sieht oft, dass bei AMD die Modelle bei Gaming sehr dicht zusammenliegen und die großen Modelle sich eher durch mehr TDP oder minimal höhere Maximaltaktraten durchsetzen (sofern es nicht zu wenige Kerne sind bei den kleinen Modellen). Bei Intel ist der Leistungsabfall deutlich größer, was imho am teildeaktivierten L3 liegt.

[dildo4u]

Produktion scheint meh zu sein sieht da eher nach RL aus.


https://youtu.be/pAmdkdd-mpI?t=836

[mironicus]

Bei AMD könnte aber auch die Tatsache das die Mobile-GPU mit weniger Lanes angebunden ist als bei Intel für die geringere Performance sorgen. Da liegen Rocket Lake und Zen 3 sonst nicht so auseinander, bzw. sind praktisch gleich.

[dildo4u]

Der Cache sollte die größere Rolle spielen, es war auffällig wie schlecht die Latenzen von RL waren ein Rückschritt zum Vorgänger, das hat man hier mit mehr Cache als AMD ausgeglichen.

[davidzo]

NDA ist gefallen: https://www.computerbase.de/2021-05/tiger-lake-h-45-fuer-notebooks-gibt-es-jetzt-10-nm-cpus-mit-bis-zu-8-kernen/


Hier das News Briefing mit allen Folien und Tabellen seitens Intel: https://www.intel.com/content/www/us/en/newsroom/news/11th-gen-core-mobile-h.html#gs.13tkis

Oh oh intel, bei keinem einzigen gamingtest steht das was von der CPU TDP oder sogar Chassisgröße. Das Zephyrus G14 ist in erster Linie Kühlung/TDP limitiert, kein Problem das mit einem 11400H (45W?) zu schlagen wenn der Prozessor ggf. unbegrenzt TDP hat und man das im CPUlimit testet.
Immerhin haben sie dem AMD System meist mehr Grafik-TDP gegeben, aber eine mobile RTX3080 ist bei FullHD schon krass CPU limitiert, da ist es wahrscheinlich eher abträglich wenn die GPU der CPU soviel TDP klauen darf.

Im Content creation bereich haben sie einen 10980HK mit 155W 3080 gegen einen 5900HX mit 130W GPU antreten lassen. Wieso diesmal eine andere Plattform und nicht den Legion 9000 wie in den anderen Tests mit gleicher CPU? Das weiß nur Intel...

Also die Herstellerbenchmarks sind mal wieder wertlos. werde wir warten müssen!

[dildo4u]

Die 3080 ist der Star in dem Video von Intel 60fps in 4k ist krank für ein Laptop.

[Fusion_Power]

Bin ich der Einzige, der 100W CPU's und fette 2080er RTX Grafikkarten in dünnen Laptops etwas overkill findet? Zumindest für lärmempfindliche Menschen wie ich einer bin. :ugly: Oder kann man so nen Boliden dann unter Last wirklich noch leise kühlen? :uponder:

[Lehdro]

Bin ich der Einzige, der 100W CPU's und fette 2080er RTX Grafikkarten in dünnen Laptops etwas overkill findet? Zumindest für lärmempfindliche Menschen wie ich einer bin. :ugly: Oder kann man so nen Boliden dann unter Last wirklich noch leise kühlen? :uponder:
Nein, kannst du nicht. Bei "dünnen Laptops" kommst du irgendwann an die Grenzen der Physik. Die sind hier eindeutig überschritten, zumindest wenn man auf die Lautstärke etwas wert legt. Solange das Kühlkonzept aber Hand und Fuß hat, kann man mit ggf. vorhandenen Presets oder etwas manueller Nachhilfe vernünftige Kompromisse finden. Out of the Box laufen die Dinger meist in ihrer maximal Konfiguration - Turbine ahoi.

[fondness]

NDA ist gefallen: https://www.computerbase.de/2021-05/tiger-lake-h-45-fuer-notebooks-gibt-es-jetzt-10-nm-cpus-mit-bis-zu-8-kernen/


Hier das News Briefing mit allen Folien und Tabellen seitens Intel: https://www.intel.com/content/www/us/en/newsroom/news/11th-gen-core-mobile-h.html#gs.13tkis

Oh oh intel, bei keinem einzigen gamingtest steht das was von der CPU TDP oder sogar Chassisgröße. Das Zephyrus G14 ist in erster Linie Kühlung/TDP limitiert, kein Problem das mit einem 11400H (45W?) zu schlagen wenn der Prozessor ggf. unbegrenzt TDP hat und man das im CPUlimit testet.
Immerhin haben sie dem AMD System meist mehr Grafik-TDP gegeben, aber eine mobile RTX3080 ist bei FullHD schon krass CPU limitiert, da ist es wahrscheinlich eher abträglich wenn die GPU der CPU soviel TDP klauen darf.

Im Content creation bereich haben sie einen 10980HK mit 155W 3080 gegen einen 5900HX mit 130W GPU antreten lassen. Wieso diesmal eine andere Plattform und nicht den Legion 9000 wie in den anderen Tests mit gleicher CPU? Das weiß nur Intel...

Also die Herstellerbenchmarks sind mal wieder wertlos. werde wir warten müssen!

Wenn Intel sowas aufführen muss, ist das schonmal ein guter Hinweis, dass ein fairer Vergleich nicht zu ihren Gunsten ausgehen würde.

[Fusion_Power]

Nein, kannst du nicht. Bei "dünnen Laptops" kommst du irgendwann an die Grenzen der Physik. Die sind hier eindeutig überschritten, zumindest wenn man auf die Lautstärke etwas wert legt. Solange das Kühlkonzept aber Hand und Fuß hat, kann man mit ggf. vorhandenen Presets oder etwas manueller Nachhilfe vernünftige Kompromisse finden. Out of the Box laufen die Dinger meist in ihrer maximal Konfiguration - Turbine ahoi.
Sogar "dicke Laptops" werden laut wie ein startendes Flugzeug mit solchen CPU/GPUs drinnen. Ich lese mir oft die Testberichte auf Notebookcheck durch, da wird auch die Lautstärke der geräte gemessen. Da kann der Zocker-Bolide noch so teuer sein, leise sind sie fast nie unter Last, trotz 3x Lüfter, Vapor-Chamber und massig Heatpipes und was die sonst noch mit rein packen.
Manuell drosseln geht sicher aber dann verschenkt man halt Leistung für die man eigentlich teuer bezahlt hat.

Mit ein Grund warum ich bei Notebooks schon länger auf die sparsameren 10-28W Tiger Lake CPUs und deren Xe GPUs geworfen habe. Eventuell noch ne mobile MX450 Grafikkarte, gut is.

[Tarkin]

https://www.reddit.com/r/Amd/comments/n9zmsu/tiger_lakeh_vs_ryzen_5000h_review_on_the_same/

Chinesisches Review...

für Cezanne 45W Performance in CB15 benötigt TGL rund 80% mehr Leistungsaufnahme - tolle Wurst

[Der_Korken]

https://www.reddit.com/r/Amd/comments/n9zmsu/tiger_lakeh_vs_ryzen_5000h_review_on_the_same/

Chinesisches Review...

für Cezanne 45W Performance in CB15 benötigt TGL rund 80% mehr Leistungsaufnahme - tolle Wurst

Ist ja eigentlich nichts neues. Bei der absoluten Performance pro Kern sah Intel immer gut aus, da entspricht der Sprung von Skylake auf die Coves dem Sprung von Zen 2 auf 3. Aber dafür saufen die Intel-Kerne deutlich mehr, um auf die Performance zu kommen, während AMD relativ früh gesättigt ist und aus mehr Verbrauch keine Mehrleistung mehr generiert. Enttäuschend ist vielleicht, dass es nicht mehr 7nm vs 14nm ist, sondern 7nm vs 10nm SF und der Rückstand von Intel immer noch so groß ist.

[bbott]

Was erwarten hier einige wenn Intel wirklich mit:
Mobile 45-65W
Desktop 125W
hausieren geht, besser zu sein als AMD?!

Option:
a) Man benötigt 125W um AMD (105W) leicht zu schlagen
b) Man benötigt 125W um mit AMD gleich zu zeihen.

Mit 95W hätte ich die CPUs als überlegen bzw. sehr gut konkurrenzfähig eingeschätzt, aber so sieht es mMn nach einem Patt bis wir schlagen ein ca. 1 Jahr altes AMD Produkt gerade so aus.

Die High-Speed Cores werden soviel Strom benötigen, dass man die kleinen Cores braucht damit der Stromverbrauch nicht ausufert. Sonst müsste Intel mit (8-)12 vs 16 Cores (AMD) antreten, das sieht auf dem Papier nicht gut aus.

Jahrelang hat Intel die 15W CPUs überall groß propagiert, dann mussten schon die 25W herhalten nun sind es 45W CPUs, welche im Rampenlicht stehen.

Welche Warnlampen müssen denn noch angehen, dass Intels 10nm (immer noch) nicht wirklich läuft?! Erst mit Intels 7nm wird es wieder wirklich Interessant.

Ich persönlich halt nichts von Big.Little im Desktop, selbst im Notebook wird es nicht so viel bringen ganz einfach, weil im 14/15" Notebook der größte Verbraucher das Display ist. Im Smartphone ist die CPU im Verhältnis zum Display auch ein größerer Stromverbraucher.

[dildo4u]

https://www.reddit.com/r/Amd/comments/n9zmsu/tiger_lakeh_vs_ryzen_5000h_review_on_the_same/

Chinesisches Review...

für Cezanne 45W Performance in CB15 benötigt TGL rund 80% mehr Leistungsaufnahme - tolle Wurst
So lange die Kühlung es abführen kann ziemlich Banane die ganzen X86 Gameing Modelle kacken ab sobald man den Stecker zieht.
Das ist deutlich problematischer in Ultra Books die man tatsächlich Mobil benutzt.

[fondness]

Ist ja eigentlich nichts neues. Bei der absoluten Performance pro Kern sah Intel immer gut aus, da entspricht der Sprung von Skylake auf die Coves dem Sprung von Zen 2 auf 3. Aber dafür saufen die Intel-Kerne deutlich mehr, um auf die Performance zu kommen, während AMD relativ früh gesättigt ist und aus mehr Verbrauch keine Mehrleistung mehr generiert. Enttäuschend ist vielleicht, dass es nicht mehr 7nm vs 14nm ist, sondern 7nm vs 10nm SF und der Rückstand von Intel immer noch so groß ist.

Naja, bisher hieß es halt schon immer es liegt am Fertigungsprozess. Jetzt hat man die neueste 10nm Auskopplung, die laut allem was bekannt ist sehr gut mit TSMC 7nm vergleichbar ist, und man ist nicht mal annähernd konkurrenzfähig. Man sollte nicht vergessen das ist eine Intel-Folie! Bei <45W, was die Folie gar nicht darstellt sieht es vermutlich noch deutlich schlechter aus. Vermutlich reicht ein 15W Ryzen um den 45W Intel zu schlagen, das ist unfassbar ineffizient. Sie haben ja noch Glück, dass sie CPUs entwickeln, wo die Leistungsaufnahme kein so großes Thema ist. Wenn ich eine GPU-Architektur habe, die derart ineffizient ist, brauch ich gar nicht erst auf den Markt kommen.

[dildo4u]

X86 ist hier wie da Unbrauchbar auf Akku, 5800u fällt von +50% auf 15.
Wenn ein Mobile Performance wichtig ist muss man Apple kaufen.


https://www.pcworld.com/article/3616668/tested-is-ryzen-5000-battery-performance-really-that-bad.html

[KarlKastor]

Ist die Folie wirklich echt?
Warum sollte Intel das präsentieren wollen?

[dildo4u]

Intel hat kein Problem das so zu zeigen die Folie ist auch Echt.


https://images.idgesg.net/images/article/2021/04/intel_11th_vs_ryzen_4000u-100886359-orig.jpg

[CrazyIvan]

Ist die Folie wirklich echt?
Warum sollte Intel das präsentieren wollen?
Die von Tarkin gepostete Folie ist NICHT von Intel. Sie ist von irgendeinem Waibo-User. Deswegen schrieb Tarkin das ja auch.

@dildo4u
Bei der Folie geht es nicht in erster Linie um einen Vergleich der Leistungsaufnahme sondern darum, dass AMD bzw. die OEMs bei AMD-Prozessoren gern die Leistung im Akkubetrieb drosseln - vorrangig durch weniger schnelles Ramp-Up der Frequenzen. Und damit hat Intel auch nicht Unrecht - kann ich sehr gut mit meinem 4700U reproduzieren. Ob das nun als Skandal taugt, bleibt jedem selbst überlassen.

[fondness]

Okay, mea culpa, sah aus wie eine offizielle Folie durch das Intel Logo mit Seitenummer unten. Trotzdem, deswegen sind die Ergebnisse ja nicht falsch.

[CrazyIvan]

@fondness
Ja genau. Ist zwar nur ein erster Datenpunkt, aber nichtsdestotrotz enttäuschend. Ich hätte eigentlich erwartet, dass TGL-H bei niedriger TDP besser performt, da 8 Kerne bei niedriger Frequenz deutlich effizienter sein müssten als 4 bei hoher. Die scheinen einfach bei weitem nicht so gut nach unten zu skalieren wie Renoir/Cézanne - ein Baustein mehr für das Gesamtbild zu BIG.little.

[Matrix316]

X86 ist hier wie da Unbrauchbar auf Akku, 5800u fällt von +50% auf 15.
Wenn ein Mobile Performance wichtig ist muss man Apple kaufen.


https://www.pcworld.com/article/3616668/tested-is-ryzen-5000-battery-performance-really-that-bad.html

Ich glaube das würde sogar fast jeder machen, wenn du erklärst, wie man alle X86 Windows Anwendungen nativ unter ARM MacOS installieren kann? =)

[dildo4u]

War M1 mit Emulation nicht schneller als die Intel Modelle?

[Lehdro]

War M1 mit Emulation nicht schneller als die Intel Modelle?
Teilweise schneller als Skylake. Der zumindest langsamer als TGL ist, der hingegen ineffizienter als Cezanne ist. Da drehst du dich doch eher im Kreis.

[dildo4u]

Teilweise schneller als Skylake. Was zumindest langsamer als TGL ist, der hingegen ineffizienter als Cezanne ist. Da drehst du dich doch eher im Kreis.

Hat das XPS hier nicht Tiger Lake?Zen 3 Mobile ist auch um 1500 SC.

https://youtu.be/pVfQ9e1PhAY?t=293

Niemand holt Apple ein AMD bringt erst 2022 5nm Chips, Apple ist dann schon weiter.

[Sunrise]

Hat das XPS hier nicht Tiger Lake?Zen 3 Mobile ist auch um 1500 SC.

https://youtu.be/pVfQ9e1PhAY?t=293

Niemand holt Apple ein AMD bringt erst 2022 5nm Chips, Apple ist dann schon weiter.
Der M1 ist ja auch erst Apples erster Schuss, der A12Z war quasi der Prototyp, der M1 ist gerademal der erste Versuch. M2 usw. werden richtig heftig einschlagen, da gehe ich davon aus, dass Apple da ebenfalls Produktionsengpässe bekommt, wenn die neuen Macbooks kommen.

[Lehdro]

Hat das XPS hier nicht Tiger Lake?Zen 3 Mobile ist auch um 1500 SC.

https://youtu.be/pVfQ9e1PhAY?t=293

Niemand holt Apple ein AMD bringt erst 2022 5nm Chips, Apple ist dann schon weiter.
Geekbench :freak:

Wir haben noch immer keinen 1:1 Vergleich der nicht eine der beiden Seiten übervorteilt/benachteiligt. Was wir haben sind mehr oder minder sinnlose Benchsuiten (Geekbench, Spec) und Programme die teilweise erheblich von den Spezialrecheneinheiten profitieren. Wie willst du daraus einen fairen Vergleich machen?

Ja, der M1 ist wahnsinnig schnell und noch viel mehr effizienter als er schnell ist. Aber er ist sicherlich auch nicht der Weisheit letzter Schluss, auch weil er eben ein eigenes Ökosystem mit teilweise komplett anderem Fokus hat.

[dildo4u]

Das fand ich mal interessant hier wurde der Intel auf 18 Watt Spec eingeschränkt, Akkulaufzeit saugt immer noch kein Plan wie das geht.

https://youtu.be/JnnGmpVGIbo?t=596

[Platos]

Naja, der durchschnittliche Stromverbrauch wird wohl trotzdem hoch sein.

[fondness]

War M1 mit Emulation nicht schneller als die Intel Modelle?

Er war dort schneller, wo halt Apps wie Geekbech in den großen L1 Cache rein gepasst haben. Also schön langsam wird die Apple Huldigung etwas lächerlich. Ja, sie sind Energieeffizienter, was bei 5nm LP vs. 7nm HP auch keinen Kunst ist. Ansonsten ist da sehr viel Weihrauch der Apple-Jünger in der Luft. Die IBM Prozessoren waren laut Apple-Jünger auch angeblich stets überlegen, und natürlich gab es auch da die passenden Benchmarks, bis Apple selbst eingestehen musste, dass die IBM-Produkte nicht konkurrenzfähig sind und auf Intel wechselte.

[dildo4u]

Warum sollte es den Enduser jucken wer welche Fertigung nutzt?
Früher konnte man mit dem Argument kommen das Apple überteuert ist.
Das kann man imo Heute nicht sagen alles was Konkurrenzfähige Displays nutzt ist auch bei 1000€+ im x86 Bereich.
Was Sinn macht da Apple nicht mehr Intels absurde Margen mittragen muss.

[Iamnobot]

Er war dort schneller, wo halt Apps wie Geekbech in den großen L1 Cache rein gepasst haben. Also schön langsam wird die Apple Huldigung etwas lächerlich. Ja, sie sind Energieeffizienter, was bei 5nm LP vs. 7nm HP auch keinen Kunst ist. Ansonsten ist da sehr viel Weihrauch der Apple-Jünger in der Luft. Die IBM Prozessoren waren laut Apple-Jünger auch angeblich stets überlegen, und natürlich gab es auch da die passenden Benchmarks, bis Apple selbst eingestehen musste, dass die IBM-Produkte nicht konkurrenzfähig sind und auf Intel wechselte.
Sehr richtig. Dazu kommt, dass viele "Single-Core"-Vergleiche SMT nicht nutzen und deshalb unbrauchbar sind.
https://www.igorslab.de/warum-apples-m1-single-core-vergleiche-grundlegend-fehlerhaft-sind-mit-benchmarks-gastbeitrag/

da Apple nicht mehr Intels absurde Margen mittragen muss.
Im Zusammenhang mit Apple einfach nur ;D

[dildo4u]

Gucke einfach hier alles was 1000€ kostet und 400Nits schafft ist 1080p im X86 Bereich, Apple 2560*1600.

https://geizhals.de/?cat=nb&v=l&hloc=at&hloc=de&sort=p&bl1_id=30&xf=13696_400

Intel hatte Apple massiv abgezogen was logisch ist da AMD im Notebook keine Rolle spielte bis 2020, sie hatten keine andere Option um die Preise zu drücken.

[CrazyIvan]

@Iamnobot
Das SMT-Argument habe ich bereits mehrfach gehört und halte es ehrlich gesagt für eine ziemlich steile These. In meinen Augen werden hier Problem, Lösung und Workaround unzulässig mit einander vermischt.
Das Problem sind erst einmal nicht parallelisierbare Workloads. Dass es diese in der Praxis gibt und sie auch prinzipbedingt sind, ist hoffentlich Konsens. Zur Vermessung dieses Problems dienen ST-Benchmarks.
Apple hat nun eben eine Architektur fabriziert, die in dieser Domäne sehr stark ist - und das auch nicht erst seit M1. Erwiesenermaßen stärker als die Konkurrenz. Und das ist die derzeit beste Lösung für das Problem.
Intel und AMD schaffen es nicht, die verfügbaren Ressourcen eines Kerns gleichermaßen gut in Arbeit zu halten. Stattdessen nutzen sie SMT als Workaround für ein ganz anderes Problem - nämlich der Maximierung der Auslastung. Lösungen durch Problemverschiebungen sind zwar generell sehr beliebt, aber im Grunde sind es billige Tricks.

[basix]

Intel hatte Apple massiv abgezogen was logisch ist da AMD im Notebook keine Rolle spielte bis 2020, sie hatten keine andere Option um die Preise zu drücken.


Die Preise bei den M1 Notebooks sind aus zwei Gründen relativ attraktiv:

Günstige Herstellungskosten. Der M1 und LPDDR5 wird für Apple günstiger zu haben sein als Intel CPU + DDR4. Und eine AMD dGPU haben sie auch nirgends mehr drin und deutlich weniger Variantenvielfalt bei der Ausstattung. Neben der günstigeren HW sind darum auch einige neue Econonomy of Scale Hebel dazugekommen.
Marktanteile. Apple will Mac Marktanteile ausbauen, was mit zu hohen Preisen einfach nicht geht. Da aber günstige Herstellungskosten dazu kommen, stimmt die Marge immer noch.

[Sunrise]

Die Preise bei den M1 Notebooks sind aus zwei Gründen relativ attraktiv:

Günstige Herstellungskosten. Der M1 und LPDDR5 wird für Apple günstiger zu haben sein als Intel CPU + DDR4. Und eine AMD dGPU haben sie auch nirgends mehr drin und deutlich weniger Variantenvielfalt bei der Ausstattung. Neben der günstigeren HW sind darum auch einige neue Econonomy of Scale Hebel dazugekommen.
Marktanteile. Apple will Mac Marktanteile ausbauen, was mit zu hohen Preisen einfach nicht geht. Da aber günstige Herstellungskosten dazu kommen, stimmt die Marge immer noch.

Der wichtigste Grund ist, Entwickler auf die Plattform bringen, um so wieder eine Art Lock-In zu schaffen (ist ja bei Apple generell so). Da zieht vor allem der Hebel Kosten, aber auch möglichst wenig Variabilität (siehe Konsolen-SoCs).

Ob Intel da jetzt mit Tiger Lake oder Alder Lake Fortschritte macht ist dann garnicht mehr wichtig. Solange man so eng HW und SW verzahnen kann, ist alles nur eine Frage der Zeit, da kann niemand gegenhalten, außer man macht etwas Konkurrenzfähiges eben noch billiger oder schafft Mehrwerte.

Die x86-Welt zeichnet sich eben dadurch aus, dass sie offener ist. Dadurch bleibt das letzte Fünkchen Effizienz eben aus, aber das hat natürlich weiterhin auch seine Vorteile.

[Iamnobot]

Intel und AMD schaffen es nicht, die verfügbaren Ressourcen eines Kerns gleichermaßen gut in Arbeit zu halten. Stattdessen nutzen sie SMT als Workaround für ein ganz anderes Problem - nämlich der Maximierung der Auslastung. Lösungen durch Problemverschiebungen sind zwar generell sehr beliebt, aber im Grunde sind es billige Tricks.
Egal wie man diese "x86-Lösung" bewertet muss man aber festhalten, dass ein Großteil der Tests diese essentielle Funktion - mit teils bemerkenswertem Performance-Impact - schlicht brach liegen lässt und somit jeden neutralen Vergleichsversuch von vornherein verunmöglicht.

Der wichtigste Grund ist, Entwickler auf die Plattform bringen, um so wieder eine Art Lock-In zu schaffen (ist ja bei Apple generell so). Da zieht vor allem der Hebel Kosten, aber auch möglichst wenig Variabilität (siehe Konsolen-SoCs).
Genau das. Beim Intel-Umstieg war das genau so. Damals waren die Einstiegspreise etlicher Modelle (bspw. 13" Macbook Pro, Mac Mini, Mac Pro) verglichen mit den letzten Intel-Modellen vorm ARM-Umstieg wesentlich günstiger - und dabei ist noch gar nicht berücksichtigt, dass die letzten Intel-Einstiegsmodelle alle komplett unzeitgemäße RAM/SSD-Ausstatungen aufwiesen und größtenteils verdongelt waren.
Mit irgendwelchen Intel-Margen - wie manche hier fabulieren - haben die Apple-Endkundenpreise absolut nichts zu tun.
Oder liegen die mickrigen Standardausstattungen und Aufpreise für SSD/RAM auch nur an den Margen der gierigen Speicherhersteller? :freak:

[basix]

Der wichtigste Grund ist, Entwickler auf die Plattform bringen, um so wieder eine Art Lock-In zu schaffen (ist ja bei Apple generell so). Da zieht vor allem der Hebel Kosten, aber auch möglichst wenig Variabilität (siehe Konsolen-SoCs).

Korrekt. Dritter Grund ;) Dieser setzt zumindest die anderen zwei voraus.

[isgrimm]

Warum sollte es den Enduser jucken wer welche Fertigung nutzt?
Früher konnte man mit dem Argument kommen das Apple überteuert ist.
Das kann man imo Heute nicht sagen alles was Konkurrenzfähige Displays nutzt ist auch bei 1000€+ im x86 Bereich.
Was Sinn macht da Apple nicht mehr Intels absurde Margen mittragen muss.


https://www.mediamarkt.de/de/product/_asus-zenbook-13-oled-ux325ea-kg327t-2712302.html

Naja ich würde wohl hier eher zu so etwas greifen anstatt für das entsprechende Mac Book Air mit dieser Ausstattung ca. 1600€ zu bezahlen. Auflösung ist geringer aber dafür OLED aber auch 400nits.
Ich sehe für meinen Einsatz aber auch kein Vorteil durch Mac OS, aber das muss ja jeder selber entscheiden.
Generell ist es halt so das nur die totale Grundausstattung preislich attraktiv ist

[dildo4u]

Die CPU saugt halt mit AMD kostet das Ding 300€ mehr warum auch immer ich kann mir nicht vorstellen das das an AMD liegt.

https://geizhals.de/asus-zenbook-13-oled-um325ua-kg004r-pine-gre-90nb0tr1-m00890-a2477830.html

[amdfanuwe]

Die CPU saugt halt mit AMD kostet das Ding 300€ mehr warum auch immer ich kann mir nicht vorstellen das das an AMD liegt.

https://geizhals.de/asus-zenbook-13-oled-um325ua-kg004r-pine-gre-90nb0tr1-m00890-a2477830.html
Intel 4C/8T 28W Windows Home vs AMD 6C/12T 15W Windows 10 Pro
https://geizhals.de/?cmp=2477830&cmp=2513679&cmp=2472873&active=1

[Badesalz]

Intel und AMD schaffen es nicht, die verfügbaren Ressourcen eines Kerns gleichermaßen gut in Arbeit zu halten. Stattdessen nutzen sie SMT als Workaround für ein ganz anderes Problem - nämlich der Maximierung der Auslastung.Ich muss zugeben mir fehlt wohl das Wissen dazu, um zu verstehen, welchen generelle Unterschiede es zwischen "verfügbaren Resourcen eines Kerns gleichermassen gut in Arbeit zu halten" und "Maximierung der Auslastung" gibt.
Ohne Frage eine interessante These aber. Falls mich also jemand aufklären könnte...

Gleichzeitig hab ich aber doch noch soviel Wissen, um zu erkennen, daß Betriebssystem und die Entwicklungsumgebung - allem voran der Compiler - für obiges eine signifikantere Rolle spielen, als die dauernd herbeifantasierten magic-like Eigenschaften des M1.
Wobei hier bei der Energieeffizienz die 5nm natürlich durchschlagen.

p.s.:
SMT sehe ich eher neutral. Ich könnte auch gut ohne Leben. Vor allem, wenn ich noch kleine Kerne dabei habe die in worst-cases den großen noch zusätzlich unter die Arme greifen können.
Andererseits aber ging der Eckert-Mauchly Award 2018 an Susan Eggers, weil sie sich (mit Hank Levy) in den 90ern (!) SMT einfallen lies. Die IEEE Computer Society befand in ihrem Teil der Würdigung, daß dies eines der bedeutendsten Beiträge zur Komputerarchitektur der letzten 30 Jahre ist.

Ist ja nicht so, daß es irgendwas mit x86 zu tun hat oder nur da genutzt wird.

[CrazyIvan]

@Iamnobot
Das kommt darauf an, was man vergleichen will. Möglicherweise ist das nur meine subjektive Meinung, aber das Ziel eines ST-Benchmarks besteht IMHO darin, die Leistungsfähigkeit nicht parallelisierbarer Workloads AKA genau eines Threads zu vermessen. Und dabei nützt SMT schlicht und ergreifend nix. Das wiederum kommt doch bei MT zum Einsatz, was absolut fair ist.
Du möchtest anscheinend vermessen, wieviel ein Kern bei beliebig vielen Threads leisten kann - das ist legitim, aber eben ein völlig anderes Ziel.

@Badesalz
Versteh mich nicht falsch. Ich finde SMT großartig.
Was ich sagen wollte: Apple hat ein sehr breites Design und schafft es, dieses auch mit nur einem Thread sehr gut auszulassen, wohingegen AMD und Intel das anscheinend mit nur einem Thread nicht so gut gelingt.
Die Ursache scheint tatsächlich in der ISA zu finden zu sein und hat nichts mit "magic" zu tun - siehe hierzu https://www.anandtech.com/show/16226/apple-silicon-m1-a14-deep-dive/2
Und die Energieffizienz ist bei 5nm nun auch nicht so wahnsinnig viel besser als bei 7nm.

[amdfanuwe]

Die Ursache scheint tatsächlich in der ISA zu finden zu sein und hat nichts mit "magic" zu tun -
Die Ursache liegt eher darin, wie gut der Prozessor auf den Anwendungsfall angepasst ist.
That’s quadruple the per-cycle throughput of Intel CPUs and previous AMD CPUs, and still double that of the recent Zen3, of course, still running at lower frequency. This might be one reason why Apples does so well in browser benchmarks (JavaScript numbers are floating-point doubles).
In weniger Float kritischen Anwendungen dürfte die Effizienz dann nicht mehr so gut sein. Apple hat offensichtlich die iPhone Nutzung ordentlich analisiert und den Prozessor daraufhin optimiert.
WEB Apps haben eben eine andere Ressourcennutzung als HPC, Office oder embedded Apps. Eierlegende Wollmilchsau Architekturen gibt es halt nicht. Ist immer ein Kompromiss.
Edit:
SMT nutzt in Situationen, in denen die Ressorcen des Kerns durch einen Thread nicht gut ausgelastet sind.
Nützt aber auch nichts, wenn ein Thread den Kern schon zum qualmen bringt.
Dicker + kleiner Kern ändert daran nichts, dass beim dicke Kern die Ressourcen brachliegen wenn der Thread diesen nicht richtig auslasten kann.
Hängt also wieder am Anwendungsfall, ob die Threads sich ergänzen und einen Kern gut auslasten können oder sich gegenseitig behindern und SMT dann sogar negativ auffällt.

[CrazyIvan]

@amdfanuwe
Ich meinte folgende Auszüge:

Featuring an 8-wide decode block, Apple’s Firestorm is by far the current widest commercialized design in the industry.
[...]
Other contemporary designs such as AMD’s Zen(1 through 3) and Intel’s µarch’s, x86 CPUs today still only feature a 4-wide decoder designs (Intel is 1+4) that is seemingly limited from going wider at this point in time due to the ISA’s inherent variable instruction length nature, making designing decoders that are able to deal with aspect of the architecture more difficult compared to the ARM ISA’s fixed-length instructions.
[...]
A +-630 deep ROB is an immensely huge out-of-order window for Apple’s new core, as it vastly outclasses any other design in the industry. Intel’s Sunny Cove and Willow Cove cores are the second-most “deep” OOO designs out there with a 352 ROB structure, while AMD’s newest Zen3 core makes due with 256 entries, and recent Arm designs such as the Cortex-X1 feature a 224 structure.

Den M1 auf einen Web-Prozessor zu reduzieren ist IMHO ganz schön kurz gesprungen. Ich könnte Dir nun Spec und Co. verlinken - aber das kennst Du ja alles. Deshalb verstehe ich nicht, wieso Du diese Behauptung in den Raum stellst.

[amdfanuwe]

Den M1 auf einen Web-Prozessor zu reduzieren ist IMHO ganz schön kurz gesprungen.
Heißt ja nicht, dass er für anderes nicht taugt.
War nur ein Beispiel wo die Javaskript Stärke herkommt.
Amazons ARM Prozessor hat die gleiche ISA, dürfte aber etwas anders aufgebaut sein. Es gibt halt nicht eine Architektur, die für alle Anwendungsfälle optimal ist.
Deswegen gab es ja auch immer Erweiterungen (Verschlüsselung, SSE AVX512...) und Architekturänderungen (mehr Kerne, effizienter, schneller) um neue Anwendungsfälle besser bewältigen zu können.
Letztendlich entstanden die neuen ARM Designs, weil Intel für die jeweiligen Anwendungen nichts optimales geliefert hat und zu teuer war.
Da ist irgendwann die Schmerzgrenze erreicht und man macht etwas eigenes optimaleres.

[Badesalz]

SMT nutzt in Situationen, in denen die Ressorcen des Kerns durch einen Thread nicht gut ausgelastet sind.
Nützt aber auch nichts, wenn ein Thread den Kern schon zum qualmen bringt.Wow. Ok. Danke für deine Ehrlichkeit. Bisher war ich irgendwie der Meinung - frag mich jetzt aber auch nicht warum - daß du die meisten Sachen schon recht brauchbar blickst.

@CrazyIvan
Auch dir ;) danke für die Aufklärung:
- 8-wide decode block
- ARM ISA’s fixed-length instructions
- 630 deep ROB out-of-order window
- Neon
- 192KB L1I, 128KB L1D pro Core und shared 12MB L2
- 4266 DDR4 mit auf dem Package
- und die Icestorms, von denen ja nicht gesagt ist, daß sie ausgeschaltet sind, wenn die Firestorms powern müssen...
- exzessiv gut dadrauf ausgelegter Compiler
- mit dabei eine ImageProcessingUnit, ein Videocoder/decoder und noch ein richtiger DSP dazu.

Nun gut. Damit wäre ja einiges geklärt. Und weniger magic. Das ist dann schon nahezu erwartungsgemäß bei den Eckdaten :usweet:
Abschliessend (wegen OT)
https://github.com/neurolabusc/AppleSiliconForNeuroimaging

[Der_Korken]

Angesichts der massiven Eckdaten der Firestorm-Kerne frage ich mich, wodurch Intels Cove-Kerne so viel verbrauchen. Bisher konnte man ja sagen, dass die gegenüber Skylake aufgebohrten Buffer-Größen (ROB, Load/Store-Queues, Scheduler) da ihren Anteil haben. Das wäre konsistent damit, dass Zen 2/3 sparsam ist UND von den genannten Specs her näher an Skylake als an den Coves dranliegt. Wenn man sich jetzt aber den M1 anguckt, dann kann es das aber irgendwie nicht sein. Sind Frontend und Decoder die Stromfresser und die Effizienz von Apple kann mit x86 gar nicht erreicht werden? Oder bräuchte es einen Umbruch hin zu Niedrigtakt-Designs mit entsprechend kurzer Pipeline, quasi wie bei P4 -> Nehalem? Mich würde an der Stelle mal interessieren, wie sich ein M1 in CPU-limitieren Spielebenches schlagen würde. Schlägt die IPC da immer noch so durch oder ist der ILP in Spielecode zu schlecht und das Ding würde durch den Takt gebremst?

[amdfanuwe]

daß du die meisten Sachen schon recht brauchbar blickst.

Hat jeder seine Spezialitäten. Meine Kenntnisse stammen noch aus der Single Core Zeit, ARM Firmwareprogrammierung und allgemeinem Interesse.

Hab auch lange nicht verstanden wieso X86 so verbreitet ist. In der Industrie spielen halt mehr Parameter als Leistung und Preis eine Rolle.

[CrazyIvan]

Angesichts der massiven Eckdaten der Firestorm-Kerne frage ich mich, wodurch Intels Cove-Kerne so viel verbrauchen.
Ganz ehrlich: Das wüsste ich auch gern :wink:
Klar, der M1 taktet mit nur 2/3 eines TGL oder Cézanne - und ja, mit steigendem Takt steigt der Verbrauch exponentiell. Und 5nm ist ca. 20% effizienter als 7nm. Aber für mich erklären diese beiden Faktoren noch nicht gänzlich, warum M1 mit 6-10w ST-Verbrauch in etwa soviel leistet, wie die beiden genannten Architekturen bei mindestens doppeltem Verbrauch.
Zur Ehrenrettung kann man immerhin anführen, dass Renoir in der MT-Effizienz nicht so wahnsinnig weit von M1 entfernt ist.
Bin wirklich gespannt, ob sich Apple für den Mac Pro weiter aus dem Frequenz-Sweet-Spot herauswagt, oder einfach nur mehr Kerne ranklatscht.
Zur Spieletauglichkeit. Die Logik sagt mir, dass der M1 theoretisch sehr spieletauglich sein müsste. Nur hindert ihn aktuell das Ökosystem.

[Iamnobot]

@Iamnobot
Möglicherweise ist das nur meine subjektive Meinung, aber das Ziel eines ST-Benchmarks
Offensichtlich willst du lediglich sehr spezielle Last-Situationen - Single Thread - vergleichen. Kann man machen. Mit einem neutralen Leistungsvergleich eines Kerns jeweils verschiedener CPUs/Architekturen hat das dann aber nichts zu tun (weil eben eine äußerst relevante Fähigkeit des Kerns einer Architektur brach liegt), genau das geben aber etliche Reviews vor abzubilden.

[fondness]

Angesichts der massiven Eckdaten der Firestorm-Kerne frage ich mich, wodurch Intels Cove-Kerne so viel verbrauchen. Bisher konnte man ja sagen, dass die gegenüber Skylake aufgebohrten Buffer-Größen (ROB, Load/Store-Queues, Scheduler) da ihren Anteil haben. Das wäre konsistent damit, dass Zen 2/3 sparsam ist UND von den genannten Specs her näher an Skylake als an den Coves dranliegt. Wenn man sich jetzt aber den M1 anguckt, dann kann es das aber irgendwie nicht sein. Sind Frontend und Decoder die Stromfresser und die Effizienz von Apple kann mit x86 gar nicht erreicht werden? Oder bräuchte es einen Umbruch hin zu Niedrigtakt-Designs mit entsprechend kurzer Pipeline, quasi wie bei P4 -> Nehalem? Mich würde an der Stelle mal interessieren, wie sich ein M1 in CPU-limitieren Spielebenches schlagen würde. Schlägt die IPC da immer noch so durch oder ist der ILP in Spielecode zu schlecht und das Ding würde durch den Takt gebremst?

IMO:
- Apple hat ein sehr breites Design, aber halt auch einen low Power 5nm Prozess plus sehr niedrige Taktraten. Die betreiben das Ding vermutlich mit sehr viel niedrigerer Spannung.
- AMD hat ein relativ schmales Design mit kleinen Kernen, aber dafür hohe Taktraten.
- Intel hat ein breites Design mit dicken Kernen und noch dazu sehr hohen Taktraten. Das wäre ja an und für sich kein Problem, nur wenn die IPC dann nicht mal mit AMD mithalten kann hat man natürlich ein Problem.

[HOT]

Ist das nicht extremer Äpfel/Birnen-Vergleich mit dem M1? Apple hat doch viel weniger Einschränkungen und auch keine Kompatiblitätsprobleme beim Design des M1 gehabt. Die konnten doch machen was sie wollte, während AMD und Intel auf PC-Standardisierung festgelegt sind.

[CrazyIvan]

Offensichtlich willst du lediglich sehr spezielle Last-Situationen - Single Thread - vergleichen. Kann man machen. Mit einem neutralen Leistungsvergleich eines Kerns jeweils verschiedener CPUs/Architekturen hat das dann aber nichts zu tun (weil eben eine äußerst relevante Fähigkeit des Kerns einer Architektur brach liegt), genau das geben aber etliche Reviews vor abzubilden.
So unterschiedlich sind die Ansichten. Single Thread ist in meinen Augen alles andere als speziell. Aus Sicht eines Software-Entwicklers interessieren grundsätzlich nur zwei Fragen in dem Kontext: Wie schnell kann ein gegebener Prozessor genau einen Thread verarbeiten (nicht parallelisierbarer Workload)? Und wie schnell beliebig viele Threads (parallelisierbar)? Alles dazwischen ist im Grunde völlig schnuppe. Natürlich orientiert man sich an den im Markt verfügbaren Kern-/Thread-Anzahlen, da mehr Threads auch immer einen gewissen Verwaltungs-Overhead erzeugen. Aber niemand "optimiert" auf SMT.
Ich empfinde wiederum den "Leistungsvergleich pro Kern" als ziemlich arbiträr. Aber das habe ich ja alles bereits lang und breit ausgeführt. Insofern soll es mich nicht stören, wenn in Zukunft mehr "pro Kern" gemessen wird, solange das nicht zulasten der ST-Messungen geht.

[Badesalz]

Natürlich orientiert man sich an den im Markt verfügbaren Kern-/Thread-Anzahlen, da mehr Threads auch immer einen gewissen Verwaltungs-Overhead erzeugen.Geht so. Wir leben aktuell in der core-flood Era (oder auch thread-flood).
Die Threadanzahl auf dem Markt bildet nicht unbedingt das ab was die Software damit allgemein anfangen kann. Die Software-Marktsituation und die Hardware-Marktsituation sind was MT angeht recht durchwachsen im direkten Vergleich (bis auf Spiele mittlerweile).

Aber niemand "optimiert" auf SMT.Geht das so wirklich? Was sind da die Entwicklertools für in den Umgebungen? Hat man nicht einfach meist nur bisschen Glück (7-zip) oder bisschen Pech (Winrar) mit seinem Code? =)
Und das OS kann imho zum größten Teil alles versauen, wenn es die Threads einfach nur wild streut. Was grad bei der Geschichte mit den CCDs tödlich sein kann.

Allgemeine Analyse im Link. Die ich aber grad außerhalb der synthetischen Benches auch recht mies finde. Optimalerweise, wegen eben der Sw-Basis, sollte man dafür eher 8c/16t nehmen. Idealerweise 4c/8t. Wenn man die Vorteile/Nachteile vom SMT herausfinden will, nimmt man keine 16c/32t CPU und fährt dann Software drauf die größtenteils schon ihre Mühen hat 8 Threads voll zu bekomen.
Wenn man SMT in der x86-Welt aus der rein technischen Sicht analysieren will, muss man sich halt einen 3300X besorgen. Aus einer praktischen, sollte man sich erstmal anschauen was praktisch grad so am meisten in den PCs werkelt.
Aber gut. Komplett sinnlos ist der Test nicht. Nur halt streckenweise recht durchwachsen
https://www.anandtech.com/show/16261/investigating-performance-of-multithreading-on-zen-3-and-amd-ryzen-5000/2

Offensichtlich willst du lediglich sehr spezielle Last-Situationen - Single Thread - vergleichen. Kann man machen. Mit einem neutralen Leistungsvergleich eines Kerns jeweils verschiedener CPUs/Architekturen hat das dann aber nichts zu tun (weil eben eine äußerst relevante Fähigkeit des Kerns einer Architektur brach liegt), genau das geben aber etliche Reviews vor abzubilden.Was ist das denn für "äußerst relevante" Fähigkeit des Kerns, wenn man ST fährt, die dann brach liegt? Nicht weniger interessante Frage ist aber warum man poetisch drumherum redet statt es einfach zu erzählen. Manche Leute sind schon ziemlich seltsam...

MT betrifft das System. Immer. ST betrifft aber jeden Benutzer nicht weniger stark als MT. Von daher wäre es mir persönlich neu, daß ein ST-Load eine "sehr spezielle Last-Situation" ist.
Mal von der Nuance abgesehen, daß MT sich größtenteils aus den jeweiligen STs zusammensetzt :usweet:

@HOT
Na hoffentlich kann man das in diesem Thread jetzt auch endlich klären. Ich suche seit Jahren (!) schon nach den Punkten die aufzuzählen sind, wenn es um "Kompatibilitätsprobleme", "Einschränkungen" und x86-64 geht. Und nach der "PC-Standardisierung", die dem x86 anscheinend wie ein Klotz am Bein lastet.
Was ist das alles? Meinst du jetzt mit all dem, das A20-Gate? :ugly2:

Wobei, wer nochmal stellte schon fest, daß der M1 inkompatibel zum A4 ist? :tongue:

[Der_Korken]

IMO:
- Apple hat ein sehr breites Design, aber halt auch einen low Power 5nm Prozess plus sehr niedrige Taktraten. Die betreiben das Ding vermutlich mit sehr viel niedrigerer Spannung.
- AMD hat ein relativ schmales Design mit kleinen Kernen, aber dafür hohe Taktraten.
- Intel hat ein breites Design mit dicken Kernen und noch dazu sehr hohen Taktraten. Das wäre ja an und für sich kein Problem, nur wenn die IPC dann nicht mal mit AMD mithalten kann hat man natürlich ein Problem.

Wenn Apple einen speziellen Low-Power-Prozess verwendet, müssen sie dafür etwas anderes geopfert haben, z.B. Taktbarkeit. Das heißt, ein auf high performance getrimmter M1 würde leistungstechnisch allen anderen CPUs (mit gleichem Core Count) gnadenlos davonziehen.

Ansonsten ist es ja so: Wenn man SMT laufen lässt, sind Zen 3 und Willow Cove wieder absolut konkurrenzfähig. Offensichtlich liegt bei einem Thread pro Kern ca. 20-25% der Rechenleistung brach, während Apple die genutzt bekommt (es sei denn Firestorm legt durch SMT nochmal genauso zu und Apple hat es einfach nur noch nicht implementiert). Auf der anderen Seite hat Firestorm doppelt so viele ALU-Ports wie Zen 3 und Willow Cove (korrigiert mich wenn ich falsch liege), aber 2/3 des Taktes. Somit nutzen letztere ihre theoretische Rechenleistung sogar besser aus, aber entweder sind deren ALUs oder das drumrum zu "fett" und der Ansatz skaliert nicht gut, sonst würde man statt mehr Kerne lieber innerhalb der Kerne stärker in die Breite bauen.

Nach der jahrelangen Stagnation auf IPC-Seite war ich davon überzeugt, dass Architekturen wie Skylake bereits so dicht am Optimum sind, dass nur noch minimale Steigerungen mit immensem Aufwand möglich wären. Irgendwann ist der ILP einfach erschöpft, wenn zu viele Branches in der Pipeline sind und sich durch harte Datenabhängigkeiten Barrieren im Code aufbauen, die die OoOE ausbremsen. Nach den Firestorm-Kernen ist man davon aber noch weit entfernt.

Ist das nicht extremer Äpfel/Birnen-Vergleich mit dem M1? Apple hat doch viel weniger Einschränkungen und auch keine Kompatiblitätsprobleme beim Design des M1 gehabt. Die konnten doch machen was sie wollte, während AMD und Intel auf PC-Standardisierung festgelegt sind.

An welche Einschränkungen denkst du genau? Bei den CPU-Kernen ist es höchstens der Befehlssatz an sich. Konkret die variable Instruktionslänge, Altlasten durch uralte Befehle (für die man trotzdem Decode-Logik aufbringen muss) und generell vielleicht ein effizient genutzter Code-Space (d.h. Instruktionen sind länger). Schon möglich, dass das zum Problem wird, aber dann müssten Intel und AMD mittelfristig auch auf ARM umsteigen, um nicht abgehängt zu werden. Und gerade Intel hätte diese Probleme längst erkannt haben müssen, dann Skylake ist bald 6 Jahre alt und ist immer noch mehr oder weniger state-of-the-art. An irgendwas muss Intel die ganzen Jahre doch gebastelt haben.

Aus Sicht eines Software-Entwicklers interessieren grundsätzlich nur zwei Fragen in dem Kontext: Wie schnell kann ein gegebener Prozessor genau einen Thread verarbeiten (nicht parallelisierbarer Workload)? Und wie schnell beliebig viele Threads (parallelisierbar)?

Würde ich auch so sehen. Die Leistung eines Kerns ist eher von technischem Interesse. Spätestens wenn nochmal jemand ein CMT-Design á la Bulldozer baut, wird es schwer überhaupt zu definieren was genau ein "Kern" ist.

[CrazyIvan]

Geht das denn so wirklich? Was sind da die Entwicklertools für? Hat man nicht einfach meist nur bisschen Glück (7-zip) oder bisschen Pech (Winrar) mit seinem Code? =)
Und das OS kann imho zum größten Teil alles versauen, wenn es die Threads einfach nur wild streut. Was grad bei der Geschichte mit den CCDs tödlich sein kann.

Meines Wissens geht das nicht - das war genau mein Punkt :wink: Aber anscheinend glauben nicht wenige, dass so etwas ginge.
Als Entwickler kann ich erst einmal nur versuchen, meinen Workload sinnvoll auf möglichst viele Threads zu verteilen. Auf welchem physischen oder logischen, big oder little Kern dann was läuft, entscheidet allein der Scheduler.
Zum Rest Deines Beitrags: :up:

[Sunrise]

Wenn Apple einen speziellen Low-Power-Prozess verwendet, müssen sie dafür etwas anderes geopfert haben, z.B. Taktbarkeit. Das heißt, ein auf high performance getrimmter M1 würde leistungstechnisch allen anderen CPUs (mit gleichem Core Count) gnadenlos davonziehen.
Der Aufbau ist genau auf die Prozesseigenheiten ausgelegt, die Prozesseigenheiten sind auf den Aufbau ausgelegt. Wenn du etwas an diesen starken Abhängigkeiten änderst, läuft etwas aus dem Ruder und wird plötzlich brutal ineffizient.

Apple ist breit und taktet (relativ) niedrig, bzw. nutzt auch noch Big-Little um das abzufedern, während hier größtenteils bzw. sogar ausschließlich mit “vollwertigen”, identischen Kernen vergleichen wird.

Wenn du das Design insgesamt höher takten und auch viel schneller machen willst, reicht dir alleine der High-Performance-Prozess aber nicht, du generalisierst mir das zu stark. Mal davon ab, dass der hohe Takt dann wieder verpufft, wenn du nicht dafür sorgst, dass alles immer ausreichend gefüttert wird. Wir landen immer wieder beim Design/Aufbau…

Wenn du ein sehr leichtes Auto mit viel Hubraum hast, das sehr schlechte Bodenhaftung hat, benötigst du sehr viel Energie und hast einfach nur sehr hohe Verluste aber die Leistung “kommt nicht auf die Straße”. Nur, um das mal greifbarer zu machen.

Ja, sie werden wohl schneller sein, keine Frage. Apple hätte auch die Ressourcen, das umzusetzen. Allerdings fraglich, ob das noch ihrer DNA entspricht und ob das nicht eher (siehe Intel) zu einer Verwässerung ihrer Ausrichtung führt.

[aufkrawall]

Meines Wissens geht das nicht - das war genau mein Punkt :wink: Aber anscheinend glauben nicht wenige, dass so etwas ginge.
Als Entwickler kann ich erst einmal nur versuchen, meinen Workload sinnvoll auf möglichst viele Threads zu verteilen. Auf welchem physischen oder logischen, big oder little Kern dann was läuft, entscheidet allein der Scheduler.

Ist das wirklich so? Dann hätte es seit einem OS-Update für den Windows-Scheduler ja nie wieder niedrigere fps mit HT on vs. off in irgendeinem Spiel gegeben.
Was passiert denn, wenn man als Entwickler die App die Cores 0 und 1 anfordern lässt?

[=Floi=]

Den M1 auf einen Web-Prozessor zu reduzieren ist IMHO ganz schön kurz gesprungen.

Weil es ARM ist und man das mit geringer leistung bei wenig watt assoziiert. Ich muss mich da auch erst selbst umgewöhnen.

[Badesalz]

Der Aufbau ist genau auf die Prozesseigenheiten ausgelegt, die Prozesseigenheiten sind auf den Aufbau ausgelegt. Wenn du etwas an diesen starken Abhängigkeiten änderst, läuft etwas aus dem Ruder und wird plötzlich brutal ineffizient.Ich denke den Spielraum haben sie bis 45W noch, um bei ggf. schlehteren Perf/W Werten mit der absoluten Leistung ausreichend zu überzeugen.

Andererseits hat so ein Versuch beim 24" iMac nicht stattgefunden, gegenüber dem Air. 1701/7379 zu 1736/7429 im Geekbench. Kann aber auch gut sein, daß sie die Takte (und dei TDP) nicht so skalieren können, weil z.B bei Gears des DDR4 ein Verhältnis zum Rest behalten wollen und das nicht mitzieht.

[fondness]

Wenn Apple einen speziellen Low-Power-Prozess verwendet, müssen sie dafür etwas anderes geopfert haben, z.B. Taktbarkeit. Das heißt, ein auf high performance getrimmter M1 würde leistungstechnisch allen anderen CPUs (mit gleichem Core Count) gnadenlos davonziehen.


So kann man das natürlich nicht sehen. Ein Design ist auf eine bestimmte Taktrate ausgelegt. zB würde ein M1 never ever mit 5Ghz laufen, ohne das Apple die Cache Latenzen massiv beschneiden müsste, was natürlich wieder deutlich IPC kostet. Daher sind Taktvergleiche auch Unsinn.

Aber ja, sie opfern durch den LP Prozess natürlich taktbarkeit, das geht Ihnen auf, weil sie mehr IPC raus holen. Bleibt die Frage, ob Apple diesen Vorsprung halten kann, oder ob AMD und Intel da nicht schnell wieder dran sind und der Taktvorsprung bleibt. Man darf nicht vergessen, AMD hat Zen fast aus der Konkursmasse heraus entwickelt und Intel hat einfach nur ihr Monopol ausgesessenes. Dass das was M1 IPC mäßig liefert mit x86 nicht möglich sein soll, halte ich für BS.

[Badesalz]

So kann man das natürlich nicht sehen. Ein Design ist auf eine bestimmte Taktrate ausgelegt. zB würde ein M1 never ever mit 5Ghz laufen, ohne das Apple die Cache Latenzen massiv beschneiden müsste, was natürlich wieder deutlich IPC kostet. Daher sind Taktvergleiche auch Unsinn.Ich glaub Unsinn ist es das zu sagen und nicht wissen ob und dann wie stark der M1 ein bisher gedrosseltes Design ist. Wenn man dafür aber gleich die totsichere Keule mit "5Ghz" zieht, dann kann man ja totsicher nicht falsch liegen :wink:
Wem außer dir selbst bringt so ein Beitrag etwas?
3.8Ghz, gehen auch totsicher nicht? :tongue:

Bleibt die Frage, ob Apple diesen Vorsprung halten kann Ja? Für wen bleibt das eine Frage? Sowas ist eine strategische Sache und das MUSS mind. solange halten, wie lange auch die x86 Ära gedauert hat. Das macht man nicht für 3 Jahre. Sie haben also alles mögliche abgewogen und dieses beschlossen. Ob sie sich verzettelt haben könnten? Sehr unwahrscheinlich. Den Beweis für die Kompetenz die CPU-Entwicklungen für die nächsten 10 Jahre abschätzen zu können, haben sie mit der Entwicklung des M1 bewiesen. Das verzahnt sich automatisch. Die Kompetenz ist allgemein da. Der M1 ist ja kein Apples glücklicher Zufall.

Ob sie immer soviel schneller bleiben können? 50:50. Mit Sicherheit aber werden sie auch bei nur gleicher Leistung entscheidend weniger Watt dafür verpulvern. Für das was sie machen ist das in jedem Modell sehr wichtig.

[Der_Korken]

Der Aufbau ist genau auf die Prozesseigenheiten ausgelegt, die Prozesseigenheiten sind auf den Aufbau ausgelegt. Wenn du etwas an diesen starken Abhängigkeiten änderst, läuft etwas aus dem Ruder und wird plötzlich brutal ineffizient.
So kann man das natürlich nicht sehen. Ein Design ist auf eine bestimmte Taktrate ausgelegt. zB würde ein M1 never ever mit 5Ghz laufen, ohne das Apple die Cache Latenzen massiv beschneiden müsste, was natürlich wieder deutlich IPC kostet. Daher sind Taktvergleiche auch Unsinn.


OK, vielleicht habe ich mich falsch ausgedrückt: Wenn von "low power 5nm" die Rede ist, dann klingt das für mich so als würden Intel und AMD kein "low power" nutzen, d.h. entweder verschenken sie unnötig Effizienz oder Apple hätte noch ne gute Ecke schneller sein können, wenn sie gewollt hätten.

Sowas ist eine strategische Sache und das MUSS mind. solange halten, wie lange auch die x86 Ära gedauert hat. Das macht man nicht für 3 Jahre. Sie haben also alles mögliche abgewogen und dieses beschlossen. Ob sie sich verzettelt haben könnten? Sehr unwahrscheinlich. Den Beweis für die Kompetenz die CPU-Entwicklungen für die nächsten 10 Jahre abschätzen zu können, haben sie mit der Entwicklung des M1 bewiesen. Das verzahnt sich automatisch. Die Kompetenz ist allgemein da. Der M1 ist ja kein Apples glücklicher Zufall.

Imho spielt die Stagnation von Intel hier auch eine große Rolle. Dadurch haben sie sich die Konkurrenz in Form von AMD und Apple überhaupt erst aufgebaut. Hätte Intel so weitergemacht wie vorher mit Conroe, Nehalem und Sandy Bridge, wäre es für AMD und Apple vielleicht aussichtslos gewesen dagegen zu konkurrieren. Hätte hätte.

[Badesalz]

@Der_Korken
Unwahrscheinlich, daß es möglich wäre, auch wenn sie die Herstellungsprozesse nicht versemmelt hätten. Sie hätten sonst auch nur das machen können was Apple gemacht hat. Massiv die Breite erweitern (ne, nicht die Anzahl der Kerne ;))
Ja natürlich spielt die Stagnation eine Rolle. DIE Rolle sogar. Das ist in meiner Ausführung als Selbstverständlich zu verstehen =)

LowPower ist ein großes Thema imho. Als ich letztens eine echte Firewall und ein Storage baute, die gestern genauso schnell zu sein brauchten wie sie es übermorgen sollen - und das mit ECC bauen wollte + wirtschaftlich-sinnvoll - musste ich bis auf Ivy zurück, also Xeon v2. Weil es sehr schwer fiel etwas optimaleres zu finden als den 1220L v2 und den 1265L v2.

edit:
Ah ja. Ich warte immeroch auf die 7-zip_arm64 Benches. Etwas also wo die ganzen special units sich nicht einmischen.

[Denniss]

Bitte mal wieder zurück zu Tigerlake. Danke

[Badesalz]

Bitte mal wieder zurück zu Tigerlake. DankeScheint wohl... nicht der Rede wert zu sein :usweet:

Bin raus ;)

[CrazyIvan]

Ist das wirklich so? Dann hätte es seit einem OS-Update für den Windows-Scheduler ja nie wieder niedrigere fps mit HT on vs. off in irgendeinem Spiel gegeben.

Das Problem bei SMT ist, dass der Wechsel zwischen den Threads auf dem gleichen Core eben Overhead erzeugt. Und wenn die Belegung ungünstig ist, dann leidet möglicherweise der zeitkritischste Thread darunter. Das ist zum einen etwas, dem man durch Optimierung des Schedulers in Grenzen begegnen kann und zum anderen ist es eine Frage der Implementierung von SMT auf dem Prozessor selbst.
Wie Badesalz ein paar Posts vor Deinem bereits verlinkt hat, ist das aber bei Zen3 und sicher auch TGL kaum noch oberhalb der Messtoleranz.

Insofern ist SMT IMHO uneingeschränkt empfehlenswert. Ich empfand das seitens AMD auch als ziemlichen "Dick Move", die Produkte bei Renoir via SMT ja/nein zu segmentieren. Noch dazu, da in Europa kaum SKUs mit SMT kaufbar waren. 4600u & 4800u gab es abseits von Einzelaktionen wie bspw. Der konfigurierbaren Lenovo IdeaPads praktisch nicht.

Was passiert denn, wenn man als Entwickler die App die Cores 0 und 1 anfordern lässt?
Zunächst: Ich kann nicht für alle Programmiersprachen dieser Welt sprechen, sondern nur für C#. Und da kannst Du das von Dir beschriebene schlicht nicht.
Du kannst nur Deinen Workload in eine sinnvolle Anzahl von Threads splitten und dann den Scheduler die Kontrolle übernehmen lassen. Und das macht aus Sinn, denn Du kennst ja den konkreten Prozessor, auf dem die Applikation laufen wird, nicht. Und gerade bei x86 gibt es unzählige Konstellationen. Deine Anwendung soll halt auf nem 1C/1T laufen, aber auch auf 1C/2T, oder 64C/128T oder gar auf 8C/16T BIG + 8C8T little.

Die Komplexität der Parallelisierung besteht eigentlich aus zwei Dingen: Du musst den kritischen Pfad finden. Und Du musst auf dem kritischen Pfad möglichst viele rechenintensive Segmente finden, die keinerlei Abhängigkeiten zu einander aufweisen (https://de.m.wikipedia.org/wiki/Abh%C3%A4ngigkeitsanalyse). Das letztere ist der entscheidende Teil. Denn möglicherweise musst Du den Algorithmus ändern, um Abhängigkeiten zu entfernen und überhaupt sinnvoll segmentieren zu können. Und wenn der kritische Pfad mit marktüblicher Hardware "schnell genug" ist, dann sparst Du Dir den ganzen Aufwand, denn es ist obendrein fehleranfällig.


Nun aber zügig BTT
Ich bin wirklich gespannt auf unabhängige und seriöse Tests. Ich mag noch nicht glauben, daß TGL mit 8C im Teillastbereich wirklich so mies ist, wie es der Waibo User dargestellt hat.
Außerdem frage ich mich, ob es ähnliche Produkte wie bspw. dieses hier. (https://geizhals.de/lenovo-yoga-slim-7-pro-14ach5-light-silver-82ms0026ge-a2496548.html?hloc=at&hloc=de&v=e) mit TGL 8C geben wird. Gerade im Business-Bereich dürfte seit Renoir die Nachfrage stark in Richtung 8C gehen. Insofern sollte das fast schon Pflicht sein.

[Badesalz]

Wie Badesalz ein paar Posts vor Deinem bereits verlinkt hat, ist das aber bei Zen3 und sicher auch TGL kaum noch oberhalb der Messtoleranz.Bei Zen3? Wann hat denn schon wer von denen behauptet etwas an SMT optimiert zu haben? ;) HAt sich da je was zwischen Ivy und Skylake getan? (was nicht eh auf die restlichen Optimierungen zurückzuführen wäre)

Bei Anand gibts übrigens trotzdem auch noch paar ganz böse Ausreißer nach unten.

Nun aber zügig BTT
Ich bin wirklich gespannt auf unabhängige und seriöse Tests. Ich mag noch nicht glauben, daß TGL mit 8C im Teillastbereich wirklich so mies ist, wie es der Waibo User dargestellt hat.
[...]
Gerade im Business-Bereich dürfte seit Renoir die Nachfrage stark in Richtung 8C gehen. Insofern sollte das fast schon Pflicht sein.In welchem Buisness? (ernst und normal gefragt =))

[CrazyIvan]

Bei Zen3? Wann hat denn schon wer von denen behauptet etwas an SMT optimiert zu haben? ;)
Bei Anand sind aber trotzdem noch paar ganz böse Ausreißer nach unten.

Ja, aber das sind wirklich edge cases. Wer sowas macht, der setzt sich auch mit der Frage auseinander, ob ihm SMT was nützt. Deiner Kritik an der gewählten Plattform stimme ich übrigens zu - dadurch sind die Spieletests im Grunde irrelevant.

In welchem Buisness? (ernst und normal gefragt =))
Gar nicht mal rational. Eben dieses "haben wollen", wenn bereits in der Office-Kiste des Sachbearbeiters für 500€ ein 6-8 Kern-Ryzen läuft.

[Badesalz]

Naja. Geht so. Der Sachbearbeiter weiß garnicht was drin ist und den IT interessieren nur die laufenden Kosten.
Ich kann mich schon seit Jahren nicht erinnern wer bei uns wegen zu lahmen Rechner gemault hat und das nicht an einer schon halbkaputten Platte oder einer halbkaputten Netzwerkverbindung lag. Oder Lüfter putt und CPU zu warm.

Das Thema Leistung ist hier im "Officebetrieb" ausgestorben. Nur CAD/CAM und die Datenanalytik fragt ab und zu nach irgendwas. Das aber auch schon nur halb so oft als früher.

[dildo4u]

Die i9 Modelle nutzten vermutlich zu viel Vcore für 5Ghz Boost, der 11800H sieht deutlich besser aus.


The Core i7-11800H with a 35 W cTDP trails by about 11% in Cinebench R23 compared to the Ryzen 9 5900HX but is on par with the Ryzen 9 5900HS.(35Watt TDP)

https://www.notebookcheck.net/Intel-Tiger-Lake-H-now-official-first-benchmarks-indicate-Intel-finally-closing-the-multithread-performance-gap-with-AMD-Ryzen-5000.537971.0.html

[Denniss]

Echte Benchmarks abwarten die unter kontrollierten Bedingungen ablaufen und nicht irgendwelche Daten aus dem Netz abgeifen und daraus Schlüsse ziehen.
Merke: Traue keinem Benchmark den du nicht selber gefälscht hast :biggrin:

[CrazyIvan]

Anandtech TGL-8C Performance Review:
https://www.anandtech.com/show/16680/tiger-lake-h-performance-review

[HOT]

Also 10nm+Cove hat echt ein Verbrauchsproblem. Dafür, dass 10nm TSMCs N7 entsprechen soll ist das immer noch ziemlich na ja. Das ist jetzt quasi die 3. 10nm-Generation und die 3. enstzunehmende CPUs in dem Bereich, mit teils starker Ressourcenvermehrung seit Ice Lake, der Welpenschutz ist hier so langsam mal vorbei. Da waren der Erwartungen glaub ich echt höher. Für Alder Lake heißt das mMn nichts Gutes.

Im Anand-Review find ich die Corelatenzen bemerkenswert, also Ringbus vs. AMDs 8C CCX.

[Denniss]

ab einer gewissen Taktfrequenz fangen die Tigerlakes das große Saufen an, im Idle scheinen die ja recht sparsam zu sein.

[davidzo]

Die CPUs sind konkurrenzfähig und werden gekauft werden.

Dass sie in echten Partnerdesigns dann meist thermisch limitiert sind, merkt der Ottonormalverbraucher nicht. Solange die CPU bei 65Watt den 5980HX sowohl single- als auch Multitreaded schlagen kann, gucken die Leute nicht genau hin ob er bei einer im tatsächlichen Design implementierten 35Watt TDP gute 20% hinten liegt. Wozu auch, die CPUs sind für die meisten Client workloads schnell genug dass man den Unterschied nicht merkt.

Damit werden es weiterhin nur Nerds und Schnäppchenjäger sein, die sich einen AMD Labtop holen.

[mironicus]

Damit werden es weiterhin nur Nerds und Schnäppchenjäger sein, die sich einen AMD Labtop holen.

Ne, es wird gekauft was gerade auf Lager ist. Die Knappheit von GPU-Chips betrifft auch Laptops, und da ist es wohl egal ob man ein Ryzen 5000-Laptop mit RTX-Grafik oder eine Intel-Version holt. Intel zieht jetzt vielleicht gleich, aber bis auf USB4-Support sehe ich jetzt keinen zwingenden Grund, ein Intel-Laptop zu bevorzugen.

[Mandalore]

Kann mir jemand kurz sagen wie sich Tiger Lake nun gegen Zen 3 schlägt? IPC mäßig (also Single) und Multi Thread?

Sind viel zu viele Benchmarks und zu verschieden 🥴

[Badesalz]

Also 10nm+Cove hat echt ein Verbrauchsproblem. Dafür, dass 10nm TSMCs N7 entsprechen soll ist das immer noch ziemlich na ja.An sich eher N8.5 oder? ;) Aber das war und ist wie immer nur die Dichte...

Im Anand-Review find ich die Corelatenzen bemerkenswert, also Ringbus vs. AMDs 8C CCX.An welcher Stelle? Ich fand das Meer an roten Feldern beim 11980 (Core2Core) fast schon erschreckend.

Linear chain ist auch so ein Hammer :freak:

[Unicous]

Kann mir jemand kurz sagen wie sich Tiger Lake nun gegen Zen 3 schlägt? IPC mäßig (also Single) und Multi Thread?

Sind viel zu viele Benchmarks und zu verschieden 🥴

Single Thread öfter vorn (meist jedoch in synthetischen Benchmarks), MT meist abgehängt von Zen 3, wenn nicht gerade AVX512 oder AES genutzt wird.

Hinzu kommt, dass 45W (bzw. 65W) vs. 35W verglichen wird.

Hier zeigt sich auch mal wieder was Geekbench für ein schrottiger Benchmark ist:

Unfortunately we are not going to include the Intel GB5 results in this review, although you can find them inside our benchmark database. The reason behind this is down to AVX512 acceleration of GB5's AES test - this causes a substantial performance difference in single threaded workloads that thus sub-test completely skews any of Intel's results to the point of literal absurdity. AES is not that important of a real-world workload, so the fact that it obscures the rest of GB5's subtests makes overall score comparisons to Intel CPUs with AVX512 installed irrelevant to draw any conclusions. This is also important for future comparisons of Intel CPUs, such as Rocket Lake, which will have AVX512 installed. Users should ask to see the sub-test scores, or a version of GB5 where the AES test is removed.

To clarify the point on AES. The Core i9-10900K scores 1878 in the AES test, while 1185G7 scores 4149. While we're not necessarily against the use of accelerators especially given that the future is going to be based on how many and how efficient these accelerators work (we can argue whether AVX-512 is efficient compared to dedicated silicon), the issue stems from a combi-test like GeekBench in which it condenses several different (around 20) tests into a single number from which conclusions are meant to be drawn. If one test gets accelerated enough to skew the end result, then rather than being a representation of a set of tests, that one single test becomes the conclusion at the behest of the others, and it's at that point the test should be removed and put on its own. GeekBench 4 had memory tests that were removed for Geekbench 5 for similar reasons, and should there be a sixth GeekBench iteraction, our recommendation is that the cryptography is removed for similar reasons. There are 100s of cryptography algorithms to optimize for, but in the event where a popular tests focuses on a single algorithm, that then becomes an optimization target and becomes meaningless when the broader ecosystem overwhelmingly uses other cryptography algorithms.

Deswegen rolle ich immer die Augen wenn dildo4u mit seinen dämlichen GB-Score Vergleichen kommt und meint das wäre über alle Plattformen und Architekturen vergleichbar.:rolleyes::rolleyes::rolleyes:

[Badesalz]

Hier zeigt sich auch mal wieder was Geekbench für ein schrottiger Benchmark ist:Jetzt bin ich bisschen verwirrt. Dachte das ist so klar, daß man nichtmal mehr darüber spricht :|

[dildo4u]

Benches sehen gut aus für Gameing Core To Core Latenz geringer und höste Single Core Leistung.
So lange die Kühlung es abkann ein Rundes Produkt da eh alle Gameing Notebooks komplett einbrechen wenn man den Stecker zieht.
Ich sehe da kein Vorteil für Ryzen, eher ein Problem das sie kein Modell haben was im Single Core so hoch wie ihre Desktop Modelle gehen.

https://youtu.be/haQvx43J0AI?t=511

Ich wette die Intel Benches sind ziemlich Realistisch was das Gameing angeht, ich erwarte durch die Bank besser Performance da AMD sehr zurückhaltend ist was SC Turbo angeht.

[mboeller]

Anandtech TGL-8C Performance Review:
https://www.anandtech.com/show/16680/tiger-lake-h-performance-review

hab ich Watte auf den Augen?

3,8GHz bei 65w und nur 2,8GHz bei 35w

[dildo4u]

hab ich Watte auf den Augen?

3,8GHz bei 65w und nur 2,8GHz bei 35w
3.3 vs 2.8 laut Spec.Nich vergessen die Dinger haben AVX 512 was den Takt massiv reduziert nicht vergleichbar mit AMD.

https://i.ibb.co/jvs8w9m/tigerlake.png (https://ibb.co/3yQTF52)

[mboeller]

Damit werden es weiterhin nur Nerds und Schnäppchenjäger sein, die sich einen AMD Labtop holen.

dann kann man sich vielleicht endlich mal ein Ryzen Notebook kaufen, außer die Hersteller behandeln AMD auch weiterhin so stiefmütterlich.

[CrazyIvan]

@davidzo
Damit wirst Du schon recht haben. Im großen und ganzen darf von "vergleichbarer" Leistung gesprochen werden und die angeblich bereits 1 Mio. ausgelieferten Einheiten lassen eine deutlich bessere Verfügbarkeit als bei Cézanne erwarten - das wohl derzeit wichtigste Verkaufsargument. Würde mich wundern, wenn AMD seit Launch überhaupt 1 Mio. Cézanne hergestellt hätte.

[fondness]

3.3 vs 2.8 laut Spec.Nich vergessen die Dinger haben AVX 512 was den Takt massiv reduziert nicht vergleichbar mit AMD.

https://i.ibb.co/jvs8w9m/tigerlake.png (https://ibb.co/3yQTF52)

LOL, wenn etwas nicht verwendet wird, dann wird das bei jeder halbwegs modernen Architektur power-gegated und fertig. Jetzt hier so zu tun als wäre AVX512 der heilige Gral und ein Chip dürfte deswegen mal eben das doppelte verbrauchen ist absolut lächerlich. Was Intel hier abliefert ist schlicht und einfach nicht konkurrenzfähig bei vergleichbarer TDP, trotz 10nm. Und das würde ja noch viel hässlicher werden, wenn Intel hier nicht ein 65W Modell liefern würde.

[dildo4u]

Ich hab nur gesagt das es nicht vergleichbar ist und wie beim 5800U das bessere Produkt bringt dir nichts wenn der Anwender keine Auswahl hat.
Wird sind jetzt im Mai und es gibt fast gar nix mit Zen3 zu kaufen.
Und AMD wusste das sie nicht genug Chips haben daher nutzen Modelle wie 5700U Zen 2.

[robbitop]

Vergleiche sind im mobile Bereich auch leider nur sehr begrenzt möglich.

Die Variabilität ist einfach enorm aufgrund:

- TDP Konfiguration
- Kühlung
- RAM Takt
- RAM Latenzen

Das kann selbst bei der gleichen CPU schnell mal 20% und mehr (Performance) Variabilität ausmachen.
Zen 3 scheint pro Core sparsamer - je enger die TDP ist, desto besser steht er im MT da.

Es wäre IMO interessant gewesen, wenn TGL-H im Desktop gekommen wäre. Ich bin mir relativ sicher, dass er besser als RKL gewesen wäre. Schneller und sparsamer. Wahrscheinlich nicht so sparsam wie Zen 3 - aber weniger durstig als RKL. :D

Im Desktop hätte man beide besser vergleichen können. Im Mobile - je enger die TDP ist - ist Zen 3 schwer zu schlagen.

[HOT]

Na ja, wenn man sich die Performance auch bei 65W+ anschaut, wäre der Performancegewinn ggü. Rocket Lake sehr begrenzt gewesen bei wahrscheinlich deutlich weniger Durchschnittstakt. Man versteht so langsam, warum Intel Rocket Lake dazwischenschob.

[robbitop]

Na ja, wenn man sich die Performance auch bei 65W+ anschaut, wäre der Performancegewinn ggü. Rocket Lake sehr begrenzt gewesen bei wahrscheinlich deutlich weniger Durchschnittstakt. Man versteht so langsam, warum Intel Rocket Lake dazwischenschob.
Von 65W bis zu dem Verbrauch eines offenen RKL ist es aber noch ein gutes Stück. :D Noch einiges an Luft, um den All Core Takt deutlich nach oben zu ziehen.
TGL-H zeigt, dass 5 GHz grundsätzlich möglich sind. RKL liegt bei 5,3 GHz. Das sind nur 6 % Differenz.
RKL performt pro Takt etwas schlechter als man es annehmen würde, wenn man sich SC vs SKL im Notebook anschaut. Für mich sieht es so aus, als hätte man bei dem Backport Federn lassen müssen. Entsprechend wäre TGL im Desktop nicht uninteressant gewesen IMO.

[HOT]

Der Ertrag nimmt doch übelst ab. Man sieht ja, wieviel mehr Strom die mobile Variante schon verbraucht. Da kannst natürlich noch 50W draufschmeißen, der Effekt verpufft aber ziemlich. Ich bin davon überzeugt, dass Tiger Lake an 1-2 Stellen schneller gewesen wäre, aber im Durchschnitt wird der hohe Takt bei RKL mehr bringen. Die Designs sind ja viel fetter als SKL, daher explodiert der Verbrauch auch schneller als bei SKL.

[robbitop]

Ein offener RKL verbraucht doch eher ~200W+ IIRC, oder? Und dort greift doch ganz klar das gleiche Prinzip des sinkenden Grenzertrags (Takt und Leistungsaufnahme). Man sollte schon Gleiches mit Gleichem vergleichen. ;)
Ob jetzt 5,3 GHz relativ zu 5 GHz als "hoher Takt" gelten soll, finde ich zweifelhaft. In meinen Augen ist das eher marginal. Ich würde mich nicht wundern, wenn man TGL voll öffnen würde, wie man es bei RKL tat nur geringfügig weniger Takt bei rum kommen würde.
Pro Takt erwarte ich von Willow Cove deutlich mehr als von Cypress Cove (einmal wegen des Backports und einmal wegen der deutlich größeren Caches).

[Triskaine]

Pro Takt erwarte ich von Willow Cove deutlich mehr als von Cypress Cove (einmal wegen des Backports und einmal wegen der deutlich größeren Caches).

Pauschal ist das nicht so. Evtl. in Anwendungen die von der anderen/größeren Cache Hierarchie von Willow Cove profitieren, wobei es auch andere Szenarien gibt wo diese von Nachteil ist.

Auf Instruktionsebene (Latenz und Durchsatz) sind Sunny Cove, Cypress Cove und Willow Cove im übrigen bis auf ganz wenige Ausnahmen identisch. Soweit man das an extern messbaren Architekturcharakteristika fest machen kann ist der Backport vollständig und ohne Einschnitte vorgenommen worden.

Im Anandtech Review macht der 11980HK (5GHz 1T Max.) 612 Punkte im CB R20 1T, mein 11700K (ebenfalls 5GHz 1T Max.) schafft 609. Im Desktop mit aufgerissen Power/Temperatur/Plattform Limits würde TGL-H vllt. an den 11900K rankommen, gerade so.

Ein Hypothetischer TGL-H im Desktop hätte gegenüber RKL eigentlich "nur" den Vorteil besserer Effizienz und hier und da marginal besserer Performance. Gegenüber Zen 3 im Desktop wäre er keine größere Offenbarung als RKL es ist...

[fondness]

Ein offener RKL verbraucht doch eher ~200W+ IIRC, oder? Und dort greift doch ganz klar das gleiche Prinzip des sinkenden Grenzertrags (Takt und Leistungsaufnahme). Man sollte schon Gleiches mit Gleichem vergleichen. ;)
Ob jetzt 5,3 GHz relativ zu 5 GHz als "hoher Takt" gelten soll, finde ich zweifelhaft. In meinen Augen ist das eher marginal. Ich würde mich nicht wundern, wenn man TGL voll öffnen würde, wie man es bei RKL tat nur geringfügig weniger Takt bei rum kommen würde.
Pro Takt erwarte ich von Willow Cove deutlich mehr als von Cypress Cove (einmal wegen des Backports und einmal wegen der deutlich größeren Caches).

Dir ist aber schon klar, dass du jetzt 10nm vs. 14nm vergleichst?

[Badesalz]

Was genau schrieb denn HOT, fondness?

[dildo4u]

Pro Takt erwarte ich von Willow Cove deutlich mehr als von Cypress Cove (einmal wegen des Backports und einmal wegen der deutlich größeren Caches).

Tiger Lake H skaliert tatsächlich gut nach oben, wäre ok für Desktop leider bekommen wir die ja nicht.

https://youtu.be/ot9z0N2z67I?t=863

[robbitop]

Dir ist aber schon klar, dass du jetzt 10nm vs. 14nm vergleichst?
Ja. Das ist aber gar nicht der Punkt. Der Punkt ist, wäre ein offener TGL-H schneller gewesen als RKL. Und meine Vermutung ist ja. Der Kern ist moderner und der 10 nm Prozess mag nicht ganz an die Taktraten des 14nm Prozesses heran kommen, sollte aber den Durst der Kerne etwas reduzieren, so dass man im Desktop schon an grob 5 GHz herankommen sollte, wenn die TDP offen genug ist.

[aufkrawall]

Ist nur die Frage, ob das wegen des Shrinks beim immer noch hohen Verbrauch nicht lauter wäre. Die Arch ist einfach veraltet, da reißt es die Fertigung imho überhaupt nicht.

[robbitop]

Du meinst, weil die Energiedichte höher ist? Müsste man sehen. Grundsätzlich hat man das wahrscheinlich eher deshalb nicht gemacht, da 10 nm Kapazität nicht unbegrenzt verfügbar war und man diese lieber für die margenträchtigere Bereiche genutzt hat (Server und mobile).
Ich bin mir relativ sicher, dass TGL-H ansonsten das bessere Produkt gewesen wäre.

In Bezug auf "veraltet" bin ich mir nicht sicher was du meinst. Willow Cove ist der neuste Core, der von Intel verfügbar ist.

Aber ja die Coves sind deutlich stromhungriger als die Zen Cores. Es gibt keine Garantie, dass das sich bei Golden Cove ändern wird. Der Kern ist nochmal neuer und die Fertigung ist nochmal eine Stufe neuer (10 nm Superfin Enhanced :D).

[Distroia]

@ robbitop

Du solltest schon zwischen gut und schlecht parellelisierbaren Anwendungen unterscheiden. Bei Single Core hat der 14 nm Prozess Vorteile bei der Taktbarkeit, bei besser paralleisierbaren Anwendungen schlägt dann die Energieeffizenz des 10 nm Prozesses durch. Es wäre aber ganz schön traurig, wenn Tiger Lake bei Multicore nicht schneller wäre. Neue Architektur und neuer Fertigungsprozess, da darf man schon etwas mehr erwarten. Vor allem, da in nicht allzuferner Zukunft AMD dank 5 nm wieder den klaren Fertigungsvorteil haben dürfte, den sie vor Intels Umstieg auf 10 nm gehabt hatten.

[robbitop]

In beiden Fällen sollte TGL-H schneller sein. MT und ST. 10 nm zeigt in TGL, dass zu 14 nm nur noch sehr wenig fehlt in Bezug auf maximale Takrate. 5 statt 5,3 GHz. Das ist marginal und kaum noch erwähnenswert.

[HOT]

Meine güte, wie oft denn noch :freak:. Dass der hohe Turbotakte hat, heißt doch nicht, dass er all-Core ähnlich hoch takten würde. Was nützt es denn, wenn er nur 200MHz Turbo-Takt hat aber im Durchschnitt die Takte 500MHz niedriger ausfallen.

[robbitop]

Meine güte, wie oft denn noch :freak:. Dass der hohe Turbotakte hat, heißt doch nicht, dass er all-Core ähnlich hoch takten würde. Was nützt es denn, wenn er nur 200MHz Turbo-Takt hat aber im Durchschnitt die Takte 500MHz niedriger ausfallen.
Der Turbo Takt zeigt, dass die Cores es grundsätzlich können, wenn das Power Budget da ist.
Wie gesagt, wenn man es öffnet wie bei RKL sollte der Fakt gegeben sein.
Das war bei CML im mobile auch nicht anders. 5,3 GHz Turbo und 2,4 GHz Basis Takt. Wie CML im Desktop voll geöffnet taktet, wissen wir ja.

[dildo4u]

TL für Desktop könnte kommen.

https://videocardz.com/newz/intel-quietly-launches-11th-gen-core-10nm-tiger-lake-desktop-cpus-including-core-i9-11900kb

[BlacKi]

vermutlich nur eine weitere mobile version, siehe FCBGA1787.

ausserdem pcie 3.0.

[Unicous]

Wurde von Intel schon angepasst, VCZ hat es auch schon geupdatet.

[BlacKi]

bei intel steht immernoch desktop. https://ark.intel.com/content/www/us/en/ark/products/215570/intel-core-i9-11900kb-processor-24m-cache-up-to-4-90-ghz.html

[Unicous]

Intel has updated its Ark, and replaced desktop with mobile.

*shrug*

[dildo4u]

Hier Update 2 das Ding soll eine Custom Lösung für SFF Systeme sein.

https://www.computerbase.de/2021-05/intel-core-i9-11900kb-tiger-lake-mit-65-watt-fuer-den-desktop-aufgetaucht/

[Leonidas]

*shrug*

Nochmal upgedated: Nun steht über "Desktop" da.

[dildo4u]

Tiger Lake U Modell mit 5Ghz Boost kommt.

https://videocardz.com/newz/intel-announces-tiger-lake-refresh-core-i7-1195g7-and-i5-1155g7-cpus


:lol: Die Benches gegen ihre eigene CPU im Macbook.

https://wccftech.com/intel-provides-better-gaming-experience-than-100-of-apple-mac-laptops/

[Iamnobot]

Der Basistakt der neuen Modelle bei 28W ist um 100 MHz niedriger als bei den direkten Vorgängern :freak:

https://www.computerbase.de/2021-05/intel-tiger-lake-ur-der-erste-refresh-bringt-bis-zu-300-mhz-mehr-turbo-takt/