Názory k článku
AMD s konceptem big.LITTLE až v roce 2024?
-
Postupně to přijde. Nejde jen o spotřebu, ale obecně o specializaci jader. Dnes tomu brání hlavně "cena" interconnectu (složitost roste až se čtvercem počtu jader), ale na low power platformách se tomu už začíná dařit.
Když bych měl desktop procesor se 128 jádry, tak bych určitě nechtěl, aby byla všechna stejná. Určtitě bych chtěl pár velmi úsporných na housekeeping (IRQ, DMA, úlohy s idle prioritou), pár specializovaných třeba na video, pár na integer/AL operace... a tak. Dost možná jednou sroste CPU a GPU, bude to prostě cluster s tisícem jader a třeba dvě třetiny budou floating point s rychlou pamětí ("GPU").
-
Tak práve pri 128 jadrách by som ich špecializovať nechcel. Tam by som to videl na scheduler, ktorý v idle všetko nahodí na čo najmenej jadier a zvyšné uspí a bude držať uspaté dovtedy, kým ich výkon nebude treba.
Maximálne ako špecializácia ako je dnes, CPU vs GPU, kde síce GPU má široký prístup do pamäte, ale s takou latenciou, že by to bolo pre CPU nepoužiteľné.
-
J ouda (neregistrovaný)
Tak když si vezmu jak desktop používám (zapnutý trvale, ale většinu času naprosto nevyužitý případně aplikace schopná běžet na posledním Atomu (remote desktop, citrix receiver, ssh)), tak mi koncept jednoho nežravého pomalého jádra + dalších výkonných, ale většinou vypnutých jader nepřijde nijak zvrácený.
-
Zvrácený určitě není, otázka spíš je, jestli to stojí za to. Tedy jestli by se tím opravdu ušetřilo tolik, aby to vyvážilo komplikace spojené s tou hybridní architekturou a samozřejmě i latence v případě, že je najednou potřeba výkonu víc. Pokud už se zvládne dynamické vypínání nevyužitých jader ve spolupráci se schedulerem, pak může být docela častá situace, kdy bych v tom hybridním konceptu musel volit mezi tím, jestli ten proces, který najednou potřebuje víc procesoru, nechat běžet na pomalém jádře nebo mu probudit rychlé a přemigrovat ho; oproti tomu u klasického procesoru ho prostě můžu nechat běžet kde je a nanejvýš přepnout na vyšší frekvenci.
-
J ouda (neregistrovaný)
Mě by klidně vyhovovalo i klasické, prastaré tlačítku Turbo (resp jeho modernější inkarnace v rámci power profilu).
Navíc nemyslím, že je ten problém v principu až takový těžký, už teď se v rámci power managementu řeší věci jako selective suspend u periférií, kde rozhodně nejde o nanosekundovou akci, a celkem to funguje. -
Tohle se už dnes běžně dělá právě na heterogenních platformách jako je big.LITTLE. V device tree jsou výrobcem definovány latence (jak dlouho trvá probuzení/odstavení, jak dlouho trvá rampa kmitočtu, jak rychle regulátor dodá vyšší napětí), paměťová hierarchie (aby bylo jasné, co má jakou cache, jestli bude nutné kopírovat data), a dnes i energetika ("Energy Model", cenové koeficienty jader, podle kterých se pozná jestli je lepší nechat task na pomalém jádře delší dobu, nebo ho přesunout na chvíli na rychlejší). Schedutil+EAS (Energy Aware Scheduling) s tím pracuje, díky systemd+cgroups má dost vstupních parametrů na nakrmení heuristik.
https://www.kernel.org/doc/html/latest/scheduler/sched-energy.html
