Jen jedna drobnost, pokud MBP s Intelem mel spatne resene chlazeni, tak s M1 ma temer identicke (takze stejne spatne), tedy srovnani je uplne na miste:
https://www.ifixit.com/News/46884/m1-macbook-teardowns-something-old-something-new
A to je jeste MBP na obrazku pro ty mene zrave Intely, tedy s 1 ventilatorem, pro ty vice zrave jsou v tom tele ventilatory 2. :-)
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.
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.
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.
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...
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.
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 :).
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.
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 :D
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? :)
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.
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.
Slabsi jadra v AL jsou Gracemont. Cili umi vsechno vcetne AVX2(-VNNI). Cili, pokud vase aplikacka pozaduje AVX512, pojede jen na silnejsich jadrech. Pokud neco min, pojede i na slabsich.
Navic se obavam, ze tady vznika boure ve sklence vody, protoze si myslim, ze prvotni AL bude ciste notebookova zalezitost. Do desktopu pujde v 22/23 a tam si myslim, ze to bude bez slabsich jader. https://www.dsogaming.com/wp-content/uploads/2020/10/Intel-Alder-Lake-AVX-AVX2.jpg
@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.
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.
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.
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.
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.
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.
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 :).
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...
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.
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: 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")
@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.
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ě?
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.
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).
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".
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.
"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.
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...
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.
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.
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.
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.
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.