Unikl procesor Intel Alder Lake s 14 jádry a 20 vlákny (inu, big.LITTLE). Takt až 4,7 GHz

63

Procesory Alder Lake by mohly být hodně zvláštní: budou mít DDR5, PCIe 5.0 a také si budete moct koupit model s 14 jádry, ale 20 vlákny. Taky by ale měly mít prvotřídní jednovláknový výkon: uniklý čip běžel na 4,7 GHz při výrazně zlepšeném IPC, a to je jenom ES vzorek.

V březnu Intel vydá desktopové procesory Core 11. generace „Rocket Lake“. Ty by měly výrazně navýšit jednovláknový výkon díky nové architektuře Cypress Cove s vysokým IPC, která bude něco mezi jádry procesorů Ice Lake a Tiger Lake. Ale bude to pořád na 14nm procesu. Pokud ale vyhlížíte 10nm procesor s lepší efektivitou, možná už na konci tohoto roku by Intel mohl mít procesory Alder Lake (Core 12. generace) s platformou LGA 1700 a pamětí DDR5, které toto přinesou.

A zřejmě to budou procesory hodně zajímavé. Intel má opět vylepšit IPC, takže by jednovláknový výkon měl poskočit výrazně ještě proti tomu, co dosáhne Rocket Lake. Také to ale budou procesory s hybridní big.LITTLE skladbou jader, podobnou SoCům v mobilech. Díky tomu zdá se vzniknou hodně zajímavé konfigurace: podle vzorku, který teď unikl na internet, by například mohlo být v nabídce 14jádro, které by poskytovalo zvláštních 20 vláknem. To vypadá dost bizarně, ale vedle toho stejný ES vzorek také slibuje hodně pěknou frekvenci.

Zvláštní Alder Lake-P v Geekbench

Procesor se objevil v databázi Geekbench a jde zatím o ES vzorek, tedy CPU, které neodpovídá reálnému prodejnímu modelu. Platforma je označená Intel AlderLake-P LP4x RVP, což znamená, že jde asi o prototyp notebookové platformy (s pamětí LPDDR4x) a testovací desku používanou k vývoji. Procesor tedy není varianta určená pro desktopy (která by mohla mít vyšší výkon).

Vzorek má podle detekovaného názvu oficiálně frekvenci pouhých 800 MHz, což je zdá se základní frekvence. Otázka je asi, zda je to základní takt u velkých jader architektury Golden Cove, nebo spíš u malých jader Gracemont. Ale ať tak nebo tak, maximální boost ukazuje, že ve skutečnosti bude CPU mít víc páry, než by základ indikoval. Geekbench registroval při běhu frekvenci boostu 4,7 GHz. Což je hodně slibné, jde-li pořád jen o ES. Takto víme, že minimálně 4,7 GHz procesory Alder Lake pro notebooky dosáhnou, a je i šance, že půjdou výš.

Procesor Alder Lake P v databázi Geekbench CPU
Procesor Alder Lake-P v databázi Geekbench, parametry CPU (Zdroj: Geekbench)

Detekce pamětí cache vypadá hodně zvláštně, procesor by podle ní ale měl obsahovat 24 MB L3 cache. Dále L2 cache velkých jader by asi mohla být stejná jako u Tiger Lake: je uvedeno 1,25 MB. Také L1 cache by mohla být beze změny: Geekbench hlásí 48 KB pro data a 32 KB pro instrukce.

Tento benchmark ale není vybaven na to, aby ukazoval, kolik má CPU velkých a kolik malých jader. Jak už bylo řečeno, konfigurace je hodně nezvyklá: 14 jader, ale 20 vláken. To je proto, že velká jádra budou umět SMT/HT (dvě vlákna), ale malá jádra ne (jen jedno vlákno). Z toho vychází, že tento procesor bude mít patrně šest velkých jader, která dávají 12 vláken, a osm malých jader celkem dávajících zbývajících osm vláken.

Výkon bude asi zajímavé benchmarkovat. Procesory Alder Lake by mohly sloužit jako podklad pro debaty o tom, zda je pro zajištění mnohovláknového výkonu lepší mít velká jádra s SMT, nebo zda se jeho komplexita a případné bezpečnostní důsledky nevyplatí a je lepší místo toho do procesoru nasázet vícero malých jader, jako to dělá Alder Lake (a momentálně také procesor M1 od Apple, i když s jen čtyřmi malými jádro to u něj není tak výrazné).

Vzorek procesoru Intel Alder Lake S Zdroj VideoCardz
Vzorek procesoru Intel Alder Lake-S pro socket LGA 1700 (Zdroj: VideoCardz)

Integrovaná grafika převzatá z Tiger Lake?

Geekbench ukazuje skóre jen pro integrovanou grafiku v OpenCL, nikoliv pro jádra CPU. Toto GPU procesoru Alder Lake-P má podle detekce stejných 96 EU a snad 768 shaderů jako grafika v Tiger Lake. Takt je 1,15 GHz. Dle některých úniků by architektura mohla být nezměněná (Xe LP první generace/Gen12 LP, kterou jsme podrobně rozebírali zde), ačkoliv dřív se očekávalo, že v Alder Lake bude už použita nová (Gen13). Je možné, že následující nová architektura GPU bude odsunutá až do procesorů Raptor Lake nebo 7nm Meteor Lake, které přijdou po Alder Lake.

Procesor Alder Lake P v databázi Geekbench integrované GPU
Procesor Alder Lake-P v databázi Geekbench, integrované GPU (Zdroj: Geekbench)

Protože je tento procesor jen ES vzorkem, musíte pamatovat na to, že jeho parametry neodpovídají tomu, jak budou vypadat sériové kusy. Jak takt CPU, tak takt integrovaného GPU mohou ve finále být vyšší a s tím i výkon. Jádra CPU se tak možná opět podívají na 5 GHz jako u Tiger Lake-H35. Každopádně s těmito zvláštními konfiguraci by Alder Lake měla být pozoruhodná procesorová platforma, neřkuli hodná jména, které jí Intel interně přiřadil.

Galerie: Úniky a informace k procesorům Intel Alder Lake

Zdroje: Geekbench, VideoCardz

Unikl procesor Intel Alder Lake s 14 jádry a 20 vlákny (inu, big.LITTLE). Takt až 4,7 GHz
Ohodnoťte tento článek!
4.6 (92.73%) 11 hlasů

63 KOMENTÁŘE

  1. a cielova skupina tohto cpu? v desktope je big.little to posledne ,co tam potrebujem. Hlavne ak bude pre vyuzitie avx-512 nutne vypnut little jadra. Potom to dopadne tak, ze na intel kremiku bude zaberat kopec miesta nielen zbytocna grafika, ale este aj uplne zbytocne little jadra.

    • Proč by se vyply malé jádra když se budou používat AVX instrukce? Naopak to může pomoct, procesy s AVX si poběží nerušeně na jádrech které je podporuji a zbytek bude padat na jádra, které AVX neumí.

      A to jestli člověk potřebuje big little? Nepotřebuje, ale on nepotřebuje ani hyperthreading, on nepotřebuje AVX, on nepotřebuje frekvenci, nepotřebuje nm, čipletyx či monolity… Člověk potřebuje výkon pro jeho workload. Pokud ho dostane tak mu je naprosto ukradené jakým způsobem je toho dosaženo.

      • lebo to tak nefunguje, o tom na akom jadre proces bezi rozhoduje operacny system a nie procesor, cize vsetky jadra musia podporovat vsetky funkcie, ak male jadra avx-512 nepodporuju a velke ano, tak male musia byt vypnute aby sa to dalo pouzivat

        • to nemá smysl vysvětlovat tohlencto, tady jedou úderníci bomby…

          Psal jsem o tom pod minulým článkem, oni si to představují jak Hurvínek válku.

          edit: napadá mě jen jedno řešení – emulace/virtualizace těchto instrukcí, ale to by bylo tak složité, že si to moc reálně nedovedu představit.

          • Staci trosku rozsirit OS. Pokud hodim proces s AVX512 na male jadro, dostanu illegal instruction exception. Podivam se jaka je to isn. Pokud AVX512 vim, ze aplikace pouziva AVX512 takze sup nastavit ji priznak a odted schdulovat jen na velkych jadrech.
            Jina moznost je scan binarky. Pred spustenim proscanuju a vim. Jiny pristup je jeste pouzit priznaky na PE+ nebo ELF (tj. na binarce aplikace). A rozsirit OS aby to pouzival + compiler/linker aby to signalizoval.
            Ja osobne to ale vidim na to prvni reseni, protoze nemusim zasahovat do prekladacu/linkeru a OS to muze podporovat sam o sobe.

            • Lepší by dle mne bylo když by proces při frontování říkal co vyžaduje, scheduler by pak přidělil proces na jádro, které splňuje požadavky pro jeho běh. To by řešilo i obrácený problém, aby nenáročný proces zbytečně nekončil na velkém jádru.

              Tohle už ale vyžaduje jak změnu scheduleru tak aplikace, ale ani jedno mi nepřijde jako nějaký nepřekonatelný problém.

              Ale to je asi to co popisuješ s těmi překladači. Programování pro OS je mi vzdálené, ale vím že je dnes běžné že si SW detekuje HW na kterém běží a dle toho nabízí různé možnosti, například zda se pro nějakou činnost použije akcelerace grafikou apod. 15 let starý Flight Simulator třeba běžně používal affinity mask, kteoru si navíc mohl uživatel v CFG souboru přizpůsobit svým potřebám.

            • No jo, ale to bys musel přinutit Microsoft a Linuse T. aby šáhli nejen do scheduleru. S ohledem na to, že ty Atomové nepodarky mají mít IPC pouhých 70% Skylaku soudím, že to nedává smysl se tím zaobírat.

              Stejně tak Jirkovy nápady, že by si proces „řekl“ o lepší jádro jsou z téhož ranku. Navíc to má jeden zásadní nedostatek: jednoduché applikace si vystačí s pár thready a pro soudobé 4-jádro (byť od Intelu nejsou žádný problém). Naopak náročné úlohy, které jsou masivně paralelizovatelné, si nedokážu představit, že část loadu pojede na atomových mrzácích a část si vyjedná „lepší“ jádra. Ono to nakonec skončí tak, že ti tyhle náročné úlohy vytíží na 100% ten výkonnější komplex a hejno mrzáčků se bude flákat, max. obsluhovat funkce OS.

            • Scan binarky obecne fungovat nebude. Predem nejde zjistit, co a jak presne pobezi. Pro soucasny SW/OS rozumne reseni neexistuje, ale mam jiste indicie, ze Intel pripravuje reseni pro budouci SW/OS, jak tyto instrukce explicitne zpristupnit (jestli uz pro Alder Lake fakt nevim). V defaultnim stavu ale budou pro velka jadra vyple, to je na 100%. Jestli pujdou zapnout po vypnuti malych jader (napr. v BIOSu) nevim, ale technicky by tomu nemelo nic branit. Mozna akorat to, ze dane CPU budou zmetky od vyroby :).

            • Tenhle problém, že malé jádro nebude mít AVX-512 (ale AVX2 jo, takže problém bude jenom AVX-512), zdá se nebude řešený v scheduleru/operačním systému. Nebo aspoň zatím.

              Myslím, že už unikly nějaké dokumenty Intel, podle kterých to zatím vypadá, že v případě, že bude Alder Lake mít aktivní malá jádra, se nekompatibilní instrukce u velkých jader deaktivují. Je možné, že se to bude dát přepínat v BIOSu, tedy v případě zájmu se v BIOSu vypnou malá jádra a AVX-512 se zapne.

              https://twitter.com/IanCutress/status/1355122473772191744

              Ale vypadá to, že minimálně zatím nebude povoleno mít ten režim s heterogenními jádry, zatím tedy asi OS tohle podporovat nebudou. Uvidíme v budoucnu.

            • JO:
              Cim vic nad tim premyslim, tim vic se mi to budouci zapnuti zda nerealne. Jsem sice dost velky silenec na to, abych mel pro kazdou narocnejsi fci vsechny verze od SSE2 az po AVX512, ale abych jeste resil scheduling ? Prestoze scheduler ve Win stoji za starou belu, tak by i tak byl nejmin 10x lepsi nez to, co bych vyplodil sam :). Ono se to mozna da udelat pro 1 nebo 2 thready, ale ne, kdyz jich mate treba 1000. A single-thread aplikace zase vetsinou tak moc nepotrebuji AVX512…

          • Už na konci 70. let existovaly k CPU i FPU, které byly na samostatném čipu. A světe div se (či možná spíše tynyte div se), už tenkrát dokazali vývojáři hardwaru a softwaru docílit toho, že kód, který běžel na CPU si dokázal odskočit vykonat instrukci do FPU.
            Když jsem na konci 80. let programoval v assembleru Z80 na ZX Spectru, dělaly se v něm úplná kouzla, ale kam se to hrabalo na to, když jsem v 90. letech psal programy v assembleru pro x86, fascinovalo mě, jaký je to slepenec, jak procesor přepíná režimy, jak startuje v reálném režimu, některé aplikace běží v chráněném režimu, kterých je několik variant. Jaká je obrovská nekompatibilita, jak člověk musí hlídat, co je k dispozici. S nástupem dalších a dalších generací procesorů, jsem se už nechytal. Těch instrukčních rozšíření bylo obrovské množství. Program musel hlídat, které může využít. Systém musel hlídat, jestli program nepoužije nějakou instrukci, která v daném procesoru neexistuje, aby tím nesestřelil i ostatní běžící aplikace.
            A pak o desítky let později přijde Limonádový Joe a tváří se, že je děsný problém docílit toho, aby vlákno bylo umístěno na takové jádro, které ho instrukčně zvládne.

            • Problem pro nove OS a nove aplikace by to byt nemusel, ale neni to proste zpetne kompatibilni, na cemz je cely x86 ekosystem zalozen. Pokud byste spustil soucasny OS se soucasnymi aplikacemi na CPU, kde kazde jadro ma jinou instrukcni sadu, skonci to bude crashem, nebo spatnym vykonem. Po updatu OS pak jen spatnym vykonem soucasnych aplikaci a narocnym vyvojem tech budoucich.

            • No já se nedivím, ale použití rozšířujícího koprocesoru pomocí volání nestandardního API nelze srovnávat s instrukční sadou CPU. Že mícháš tyhle dva naprosto rozdílné světy jen ukazuje, že vůbec nechápeš podstatu problému.

              Nejblíže k současnému stavu Alderu měl MacOS 7/8 (pokud se pamatuju dobře) s FatBinaries (tam ale šlo o dvě zcela binárně odlišné platformy a reálně se použila jen jedna část binárního blobu). U Amigy s PPC (kde to jelo dokonce dohromady 68K+PPC) to byla ještě větší haluz, kdy se buď kompilovalo pro daný CPU, nebo (později) emulovalo – jenže AmigaOS byl extrémně otevřený OS, kde si HW vendor třetí strany mohl dělat co chtěl.

              A jak píše xR, znamená to ve všech těchto případech SW podporu od výrobce aplikací, použití nadstandardního API, atd. atd.

            • soudruzi, já si jen tak laicky naivně rýpnu … dovolím si pochybovat, že by Intel vyšel s něčím, co nefunguje …

            • @gogo ale v Intelu a v Apple přece dělají nevzdělanci a kdejaký trouba z internetové diskuze má větší znalosti než armáda vývojářů v těch firmách, které to téma živí klidně desítky let. Ale jelikož to jde proti jejich iluzi co je nejlepší, tak to je špatně.

              Fakt nechápu že tam ti lidi dávno nedělají a nerozhodují o tom jaké produkty ty firmy budou vyvíjet a prodávat, když jdou evidentně všechny špatnou cestou.

            • Gogo: mno… co třeba DG1? 😁

              komplik: V Intelu aktuálně probíhá palácový převrat a Apple má svůj vlastní svět. Ok, jsem podle tebe trouba z internetové diskuse; tak uvidíme, jak to celé dopadne.

        • OS přiděluje procesy jádrům pouze pokud jako vývojář nebo uživatel neřeknu jaká jádra má proces používat a jaká ne.

          https://en.wikipedia.org/wiki/Affinity_mask

          Pro vývojáře není problém detekovat vlastnosti HW a dle toho s čím mají co do činění uzpůsobit chod aplikace, tohle už se děje dlouhá léta. Tzn. aplikace vyžadující AVX instrukce bude využívat těchto jader a ostatní nechá být, například správným nastavením affinity pro jednotlivé procesy nebo pokud to bude řešeno úpravou scheduleru, kde proces nahlásí co vyžaduje a scheduler se tomu přizpůsobí. Stejně tak bude možné přidělit proces právě na ty malá jádra, pokud vývojář či uživatel budou chtít.

          • Ale na tom CPU musi fungovat vsechny aplikace (vcetne uz existujicich) a ne jen ty, ktere jsou specialne napsane pro tento CPU. Vetsina vyvojaru ani netusi, jake presne instrukce jeho proces pouziva (skrz ruzne knihovny), natoz aby resili hodne slozitou detekci CPU a pridelovani threadu na jednotliva jadra. Od toho je OS. Tohle je komplexni a velmi tezko resitelny problem. Priklad z praxe – moje soucasne aplikace: Provedou instrukci CPUID a podle vysledku zacnou pouzivat podle potreby podporovane instrukce (SSE2-AVX512). Co se stane, kdyz se takova aplikace spusti na CPU s jadry s ruznou instrukcni sadou ? Kdyz bude spustena na malem jadre, CPUID vrati napr. jen SSE41 a tak AVX nebude nikdy vyuzito (ani kdyz ji OS prepne na velke jadro). Horsi to bude, kdyz se spusti na velkem jadre. Pak zdetekuje napr. AVX512 a ve chvili, kdy ji OS prepne na male jadro, tak bud bude crash, nebo to bude osetreno v OS a po vyjimce se presune „navzdy“ na velke jadro. Ale uz nikdy nepojede na zadnem malem, prestoze bude praci rozdelovat do poctu threadu odpovidajicim velkym+malym jadrum (podle CPUID). V obou pripadech pobezi neefektivne. A to je jen jeden maly konkretni priklad z praxe. Tech problemu bude vic. Jedine standardni reseni je jednotna instrukcni sada. Pro specialne naspane aplikace muze existovat jeste alternativni reseni se stinovymi CPUID a vlastnim rizenim procesu jak popisujete, ale s tim se ja teda drbat nebudu :).

            • Tohle je celkem rozumný komentář, který pojmenovává správně možné problémy.
              1. problém je, že vlákno si nadetekuje, že může používat nějaké instrukce a pak je použije v okamžiku, kdy poběží na malém jádře. Tenhle problém je snadno řešitelný. Malé jádro vyvolá výjimku, kterou OS vyřeší tak, že ho přesune na velké a poznamená si, že už ho na malé nemá nikdy (do ukončení běhu vlákna) dávat.
              2. problém je, že vlákno nadetekuje, že nějaká instrukční sada není k dispozici, protože zrovna běželo na malém jádře. Tento problém se softwarově řešit rozumně nedá. Ale dá se řešit naprosto v pohodě hardwarově a to tak, že i malé jádro hlásí, že umí všechny instrukce.

            • @Kgardas
              AL ma prijit do desktopu udajne uz v zari 2021..pokud tomu chceme verit.
              Ze znamych informaci, nema AL zatim vetsi konfiguraci ne 8 velkych jader. Pokud by orizl desktopy jen na tech 8 velkych, tak si sice v kategorii 4-8C pomuze, ale vse nad 8C zustane jeho rivalovy AMD. To podle mne dava jeste mensi smysl, nez ze tam ty male jadra necha.

            • pro kgardas:
              Se soucasnym OS by vsechny moje aplikace crashly. A nejspis by ani nenabootoval ten OS. Dovedete si predstavit tu aferu, ze by pro novy Intel CPU byl vyzadovan novy OS ? Ve firmach jsou stale bezne Windows 7… Intel si vzdycky zakladal na tom ze na jeho CPU jde stale jeste spustit napr. puvodni DOS a 35 roku stare aplikace a ted by to jen tak porusili ? A navic by pro to nebyl zadny duvod. Vykon mych aplikaci by byl ve vysledku stejne horsi (min pouzitelnych jader), nez na CPU s instrukcni sadou orezanou na uroven nizsich jader (obzvlaste, pokud budou mit AVX2).

            • @tombomino vzhledem k tomu že v desktopech je prodej 8+ jader velice malý, tak to zas taková tragédie nebude pokud bude existovat jen verze s 8 jádry. Sice to nedobije pozici nejvýkonnějších procesoru ale potřeby drtivé většiny userů to bez problémů splní. Nejprodávanější procesory jsou dnes 6 jádra následované 4 jádry. méně jader už fakticky nemá moc smysl kupovat z finančního hlediska. Ještě dlouhou dobu potrvá než se 8c procesory stanou podřadnými a finančně nevýhodnými natolik že se vyplatí koupit více než 8 jádrový procesor.

            • Komplik ty uz argumentujes jak za casu fanousku AMD, kdyz nemeli zadnou vykonou grafiku. Vzdyt preci RX480 je ten spravny mainstream a proda se jich nejvic :))

            • xR: tak jaký problém je vydat patch pro vaši palikaci která to vyřeší, až to začne být reálné?

              A pokud vaše aplikace poběží na nějakém procesoru hůře než na jiném procesoru, fajn, pak ten procesor asi není pro vaši aplikaci vhodný, to ale neznamená že pro spoustu jiných aplikací může být lepší a vyšší výkon zrovna nemusí být to co je od takového procesoru požadováno.

              Příklad ten Macbook Air s M1, je pasivně chlazený přitom má výkon lepší než jeho předchůdci a může mít pro některé úlohy srovnatelný či vyšší výkon jako stejně drahá konkurence. Zároveň ale může běžet 20 hodin na baterii pokud to je potřeba. Univerzálnost takového řešení může mít pro mnoho uživatele větší cenu než absolutní výkon, který obvykle nikde problém není pořídit pokud je skutečně potřeba.

            • komplik:
              O patche prece nejde. Jde o to, ze Intel prece nemuze vydat CPU, na kterem by crashovaly soucasne aplikace a nejspis by ani nenabootavaly nektere soucasne OS. Oni si nemuzou dovolit jen tak porusit zpetnou kompatibilitu. To by byl megaprusvih. Intel neni Apple, kde si kupujete CPU dohromady s OS.

            • komplik: OMG. Problém to je, a velký. Kdo mu zaplatí čas a práci? Kdo zaplatí udržování dvou verzí?

              Apple s M1 tu moc nevytahuj – srovnáváš to proti dalšímu Applu, který měl blbě řešené chlazení a samozřejmě Intel procesor. A výkon „navíc“ jde za lepším výrobním procesem a HW akcelerací.

            • xR: videl jste ten obr? Je tam napsano, ze AL hybrid nepodporuje AVX-512. Preedpokladam, ze pokud bude AVX-512 ve vetsich jadrech, tak se bude muset spec. zaptnout. Cili, zadne nenabootovaci OS, zadne crash aplikace.
              pro tombomino: priklanim se spis k nazoru, ze to byla zamena notebookovych AL a omyl novinare. Neocekavam desktop ekvivalent AL drive nez v 2022.

            • kgardas:
              Bavime se o potencialni situaci, kdy by kazde jadro podporovalo to, co umi. Nekteri tvrdi, ze by to slo a nemusely se ty male jadra vypinat v BIOSu. Pravda je takova, ze by to (teoreticky) slo jen pres specialni explicitni podporu OS a aplikaci, do ktere se momentalne nikdo nehrne. Minimalne pro veskery soucasny SW tak bude AVX512 na velkych jadrech vyple a mozna to tak i bohuzel zustane navzdy (mysleno pro Alder Lake).

        • A myslíš že 14 velkých jader stačit bude? Vždy záleží na workloadu konkrétního uživatele, někomu to bude málo, někomu to bude příliš. Kdyby to mělo stačit vždy všem, tak tu nepotřebujeme mít hromady různých konfigurací.

            • Jak souvisí Intel, potažmo nějaká cena za jakou intel vyrábí s výkonem a tím jestli to někomu stačí nebo ne?

              Snad tu řešíme big little konfiguraci a dle tebe její zbytečnost, neřešíme tu Intel a jeho výrobní náklady.

              Big little se tu vyrábí už dlouho, funguje a funguje skvěle. Pokud si člověk koupí zařízení s procesorem který odpovídá jeho nárokům, je v pohodě a to i tehdy když nejvýkonnější jádro je v procesoru jen jedno. A víz případ nahoře. 4 velké a 4 malé jádra mohou někdy překonat i 8 velkých jader s SMT. Krásné bylo vidět že těch 4+4 jader stačí na to na co nestačí 8c/16t CPU podpořené grafickou kartou (HW encoding H265).

              Evidentně to takový problém není, jak se pořád někteří lidé snaží podávat.

            • komplik: souvisí to tak, že nikdo jiný tuhle pošahanou strategii u x86 nenasadil, a to ani „tragická“ VIA. Srovnávat big.little u ARMu, který je funkčně i filozofií někde úplně jinde (https://en.wikipedia.org/wiki/ARM_big.LITTLE ) — aspoň tohle si nastuduj, než začneč tlačit ty své nesmysly.

              BTW ARM nasadil tento koncept proto, že nechtěl/neuměl/nemohl vyvíjet plnohodnotný powermanagement v širokém spektru (a ono to paradoxně dává u mobilů smysl, protože drtivou většinu času (téměř) spí). Dělat tohle u PC je nesmysl (i když teda už je venku nový buzzword a pitomiovina jménem „Always On“)

            • U Armu to funguje, proč to nemůže fungovat na x86? že to zatím nikdo nenasadil? A to je problém, ten rozšířený access do paměti grafiky taky nikdo dlouhá léta nepoužíval a když se s tím příšlo tak se zjistilo že to může být fajn věc.

              Proč kdo co začal dělat je mi ukradené, Jako uživatel vidím přínos v tom že ve chvíli kdy nějaký proces nepotřebuje extra výkon, běží na energeticky nenáročné části CPU a když potřebuje výkon poběží na té energeticky náročnější ale výkonnější části. Mám tak oba světy v jednom. Můžu mít výkon a můžu mít energetickou efektivitu.

            • Komplik ty perlis..
              „ve chvíli kdy nějaký proces nepotřebuje extra výkon, běží na energeticky nenáročné části CPU“
              .. o to se ti u „x86“ stara prave power management, kdy jadra jedou na ruznych kmitoctech.
              „když potřebuje výkon poběží na té energeticky náročnější ale výkonnější části. Mám tak oba světy v jednom.“
              .. to mas stejne, protoze ta jadra se vybudi a budou se pak snazit jet na nejvyssi mozne frekvenci.
              Tynyt ti spravne napsal, ze koncept ARM B+L vychazel z toho, ze oni tehdy tak advancovany PM nameli/nechteli delat a je to primarne urceno i do jinych zarizeni, ktere funguji na bazi „24/7“, kde i ve ‚vypnutem stavu‘ stale komunikuji s okolim. Tohle v noteboocich nepotrebujes. Samzorejme do doby, nez te marketing te ktere firmy presvedci o opaku. Coz opet Tynyt spravne popsal novym „buzzwordem“.

            • tombo, tak se tedy rozepiš, proč to podle tvého názoru Intel dělá? Kdyby to udělalo AMD a nazvalo to „infinity core“, ječel bys, jak Viktorka …

            • „BTW ARM nasadil tento koncept proto, že nechtěl/neuměl/nemohl vyvíjet plnohodnotný powermanagement v širokém spektru (a ono to paradoxně dává u mobilů smysl, protože drtivou většinu času (téměř) spí).“
              Panoval ten názor, ale na druhou stranu se to prosadilo i u firem, které „to uměly“ a původně používaly to škálování výkonu velkých jader.
              Je asi možné, že v určitých polohách na té křivce výkonu/napětí/spotřeby specializované malé jádro dopadá líp, takže apriori asi to big.LITTLE zavrženíhodné není.

              Je otázka, jestli to Intel tady používá ze správných důvodů a správným způsobem, to uvidíme.

            • J.O.: právě proto píšu, že u ARMu to dávalo smysl, protože když pojede malý jádro na velmi nízké frekvenci vs. velký jádro na stejně nízké frekvenci, tak to u malých baterkových zařízení pár mWh úspory vyžmuňká. U počítačů to IMHO smysl nedává vůbec, protože větší výkon zbytečně propálím na zdroji, discích atd.

              Intel tímhle konceptem sleduje podle mého názoru jedinou věc: srovnat počet jader na konkurenci. On ví, že v PCmarku apod. ten výkon bude krásný (ST je jasný, MT bude ukazovat taky pěkná čísla tam, kde se bude jednat o jednodušší („proudovější“ typ zátěže). No a těžkotonážní zátěž typu CB apod. prostě hodí přes palubu a udělají z toho „AMD biased test“ případně to ještě poladí v Intel kompileru, aby si AMD moc nevyskakovalo.

            • to je zase blaf … proč by tedy místo 8 malých nedali 4 velké a bylo by vymalováno? Evidentně je to o něčem jiném …

            • To je přece logické: 4 velké budou mít horší výsledky v čistě MT zátěži. Musíš si uvědomit, že existují taky úlohy, kdy 8 prašivých jader podá výkon úplně stejný, jako 8 složitých (a bude pak vyšší, než výkon 4 složitých).

              Z toho taky plyne problém nekonzistentnosti takového výkonu – stačí, aby prašivé jádro mělo v některých úlohách nedostatek cache, nebo nepodporovalo dostatečně efektivní branch prediction a výkon se ti začne „nečekaně“ propadat – a může nastat i opačný případ, že 4 jádra plnotučná podají vyšší výkon.

            • Tipuju, že to dilema je spíš „4 malá jádra místo jednoho velkého“ něž „dvě malá versus nebo jedno velké“.

    • To se dozvíme až to bude blízko finálnímu vydání. Můžeme ale kouknout třeba na Apple. M1 procesory mají 4 silná a 4 slabá jádra a rozhodně to na výkonu nejde poznat, ten procesor bez problémů překonává 35-45W konkurenci Intelu i AMD a v případě Macbook Air dokonce pasivně chlazený. A to má pořád nevýhodu v tom že mnoho aplikací stále běží v emulovaném módu protože zatím nemají nativni ARM implementaci.

      • To je zase komentar..
        Tak jasne ze prekonava Predchozi generace Intelu, kdyz to byl X-let stary Skylake na 14nm a nepovedeny IceLake. Pokud ale srovnas M1 s novou generaci TL-U (35W) nebo Cezanne (35W) tak jsou si v ST rovnocene a v MT je Cezanne podstatne rychlejsi. Tak nesir zase bludy..
        Jabko potrebuje chip s vice velkymi jadry, protoze 4+4 na dnesni AMD a budouci TL-H nestaci.
        To ze ma lepsi efektivitu pod 15W.. jo to se jabku s M1 neda uprit, ale srovnani s 15/25W Cezanne zatim nezname.

        • ST a MT? A není podstatné jak odvádí kterou práci?

          https://www.youtube.com/watch?v=KE-hrWTgDjk

          Tady vidím že M1 je v například při H265 v handbrake i o 50% rychlejší než 4800H. 6c/12t 4500U překonává snad úplně ve všem a někde dokonce o více jak 100%, Takže 4 velké a 4 malé jádra mohou naprosto v pohodě stačit 6/8 velkým jádrům. Kolik by ty velká jádra dělala, kdyby byla pasivně chlazená? A kolik výkonu by to mělo aby ten laptop vydržel 20 hodin běhu na baterii…

          • To je snad jeste horsi komentar nez ten predchozi…
            „Tady vidím že M1 je v například při H265 v handbrake i o 50% rychlejší než 4800H.“
            .. sice srovnavas starsi Renoir,a le i tak to vidis dost spatne, protoze se divas na HW encoder a ne na SW encoder, ktery jde pres CPU. Spravny obrazek je tady komplikatore a M1 dostava naprdel velkym stylem. AMD je o 50% ruchlejsi, tedy presne naopak, nez co tu tvrdis 😀
            https://youtu.be/KE-hrWTgDjk?t=290
            „A kolik výkonu by to mělo aby ten laptop vydržel 20 hodin běhu na baterii…“
            .. to nikdo nevi a v principu nikoho ani nezajima, protoze na baterii nikdo videa nekonvertuje. Co se tyce office/web/lehkeho MT aplikace, z meho pohledu uzivatele notebooku, ktery na nich dela 20 let, tak jestli mi na office/web a lehci MT vydrzi 10 hodin nebo 15 je jedno, protoze jej mezi tim stejne vzcycky dobiju. Nerikam, ze neni lepsi mit delsi vydrz nez kratsi, ale je to bonus, bez ktereho se da vklidu obejit.

            Nechces pro zmenu zacit komentovat neco, cemu aspon trochu rozumis? 🙂

            • Já se dívám na dostupné stroje a dostupné srovnání a vidím že stroje vybavené Intelem a AMD v podobné cenové relaci na M1 ztrácí, ale, hlavně a to je ten největší point, přece mají jen 4 rozumná jádra 4 naprosto zbytečná nevýkonná. Přesto s těmi 4 nevýkonnými umí dát na frak 8 plnotučným jádrům AMD kterým dokonce sekunduje grafická karta.

              A kolik to vydrží na baterii nebo že to je tiché je dost důležité. Někdo třeba encoduje videa doma/kanceláří ale zároveň běhá celé dny mimo kancelář a potřebuje aby to zařízení vydrželo dlouho. Taky může uvítat že to je naprosto tiché, pokud to třeba používá k voiceoverům apod.

              Prostě vždy je podstatné jak daný stroj odvádí práci kterou po něm žádá uživatel, a ta práce může být různorodá, big little vybavené Apple macbooky odvádí svou práci výborně, ve výkonově jsou lepší než jejich předchůdci a nebojí se ani stejně naceněné konkurence. Takže nevidím vůbec žádný problém s takovými procesory. Jak se tu někdo snaží podávat.

            • Dalsi blabol..
              „Přesto s těmi 4 nevýkonnými umí dát na frak 8 plnotučným jádrům AMD kterým dokonce sekunduje grafická karta.“
              .. koukam, ze uz neumis ani odecistvysledky z grafu…
              On nekdo nekde v te diskusi tvrdi, ze kombinace 4+4 M1 chipu nemuze byt vykonna? Nikdo preci ani nerozporuje, ze Inteli 6+6 nemuze byt vykonne. Rozporuje se jen to, jestli to ma nejaky pridany efekt a jestli to neponese problemy, ktere pred tim nebyli.
              Ve zbytku si povidas akorat sam se sebou…

            • komplik: no jo, a proto lidi chtějí do notesů AMDčka Učkové řady, protože nežerou a zároveň mají výkonu na rozdávání. No a ti co jsou Intel-positive si počkají na Atomového Quasimoda jménem Alder lake.

              V desktopu je tahle fraška odepsaná rovnou – proč si komplikovat (aha, nomen-omen 😁) život Quasimodem, když můžu mít až 16 plnohodnotných jader co žerou velmi střídmě?

            • Tynyte 😀 tebe taky evidentně sere, že s tím nepřišlo jako první AMD … radost číst …

            • Gogo: naopak, já tohle považuju za úpadek klasického PC. Intel je ve svrabu, nemá moderní technologie a není schopen konkurovat standardní cestou (ač by správně měl), tak vymýšlí obezličky.

              Třeba se pletu, ale myslím si, že jakmile Intel dosáhne na funkční výrobní proces lepší než 14nm a zároveň překročí vlastní stín monolitické Core architektury (což jsou vzájemně spojené nádoby), tak celý koncept big.little zcela jednoduše nemá smysl a bude zahozen. Problém těchto zmetků je ten, že nic nedělají dobře: spotřeba bude i tak enormní, a výkon zdaleka nedosáhne na výkon 14 ekvivalentních a moderních plnotučných jader konkurence; a teď samozřejmě myslím jádra nepostižená extrémní spotřebou nedokonalého nebo obstarožního výrobního procesu. Jinými slovy, jak je možné, že 15W low-power AMD Ryzen má stejný výpočetní výkon jako rok starý quasi-65W Intel do desktopu? Chápeš tu Intelovu současnou tragédii v plné parádě? Já Aldera vidím jako upocený stop-gap ze všech možných ingrediencí, ne jako progresivní cestu vpřed.

            • ty perlíš, na tyto hlouposti ani nebudu reagovat 😀 … nechce se m i kopírovat jednu po druhé a adekvátně reagovat … ne, že by to nešlo, ale ten hrách a zeď … to je furt to samé …

            • Komplik – Na Apple se můžeš velice zjednodušeně dívat jako na herní konzoli. Uzavřený svět, který ti dovolí psát software mnohem blížeji na „železo“ a nemá problém zahodit nebo omezit zpětnou kompatibilitu – to si x86 svět nemůže dost dobře dovolit.
              Co se týče big.little, v jeho použití v klasickém desktopu moc smyslu nevidím. Laptop dejme tomu, ale zatím neznáme pořádně ani výkon, ani efektivitu, ani cenu a srovnání s přímou konkurencí.
              Big.little by z mého pohledu nebylo špatný třeba v NAS. Malá jádra by v klidu obhospodařovala běžný provoz – síťové služby, apod., velká by se rozjela třeba při streamování/transkódování videa.
              A že o big.little přemýšlejí i v AMD – viz jejich patent „Instruction subset implementation for low power operation“ https://www.freepatentsonline.com/10698472.pdf; na str. 6 přehazování úlohy z low- na high-feature procesor.

            • mikymauz: jj, jen bych doplnil, že už první odstavec první kapitoly toho dokumentu (str. 8) zmiňuje „battery powered mobile devices“ a SoC. Z mého pohledu to cílí na mobily/tablety, maximálně něco jako netbooky.

              Navíc jde spíše o „kopii“ původního řešení ARMu, tj. přesun workloadu mezi různě vybavenými a velkými jádry (tj. exkluzivní běh) s různě definovanou spotřebou.

              Jinak ale souhlas a potvrzuje to fakt, že pro dlouhodobý běh v šetřicím režimu se vyplatí mít extra malá jádra navíc.