Odpověď na názor

Asi takto: já si právě myslím, že úhelný kámen celého řešení je ten scheduler. Jen si vem, jak MS nechtěl upravovat svůj scheduler ve Windows, a to je prosím scheduler, který je součástí jádra Windows, takže má detailní informace o procesech. Navíc se bavíme o řešení schedulingu pro více než 16 jader, ale stejných, nebo velmi podobných jader, lišících se jen dosahovanou frekvencí v zátěži, a to je řádově jednodušší problém než řešit, jestli to hodíš na Davida nebo Goliáše.

A teď si to celé posuň na úroveň baremetalu, kdy už vlastně ani pořádně nevíš, jestli ty instrukce, které zrovna provádíš, jsou instrukce kódu kernelu, aplikace, nebo ovladače, protože ti chybí ten kontext, který má jádro OS. Je docela možné, že ty avizované úpravy od MS ve Windows půjdou právě tímto směrem, prostě se nějakým semaforem bude "tagovat" důležitý kód - ale to je jen moje spekulace. Jinými slovy, procesor buď bude "odhadovat" co je třeba vykonat přednostně, nebo bude mít "noty" na totéž, pak ale bude třeba spolupráce s OS (a to zase bude problém s Linuxem a BSD, aspoň dočasně). Je samozřejmě taky možné, že v případě MT zátěže se výkon Biga omezí na výkon Littla, čistě kvůli power obálce celého CPU, to si ale nemyslím, že bude pravděpodobné řešení, protože by pak celý koncept skončil jako svého druhu lepší ST turbo a nebyl by potřeba HW scheduler.

Tak jak tak je to IMHO hodně zajímavé řešení a jsem zvědavý, jak to bude reálně řešeno a hlavně zda to bude fungovat (univerzálně - to by asi byla lambáda, nebo pouze specificky, případně vůbec - tomu moc nevěřím)