Administrace komentářů

Mě se teda tahle technologie moc nezdá, protože třeba v tom Denveru minimálně to vede k dost nevyrovnanými výkonu, když kód tomu JIT optimalizátoru nesedne. Ale hlavně proto, že mi to přijde koncepčně překomplikovaný. Místo toho, aby kód dostalo CPU hned, tak se nejdřív prohání softwarovým zpracováním. Program místo jednou zpracovává dvakrát, ačkoliv primárním cílem je zde úspora energie.

Jako asi to v mnoha případech může fungovat, protože tlustý OoO jádra mají taky velkou spotřebu a tohle řešení se asi může někdy vlézt do toho prostoru mezi OoO a jednoduchým in-order jádrem. Ale přijde mi to jako drbání levou rukou za pravým uchem. To bych asi radši viděl větší uplatnění čistých VLIW procesorů, kde by odpadl ten komplikovanej frontend a překlad a o optimalizaci by se staral kompilátor softwaru, takže by to bylo ještě úspornější (i když tam je ten problém, že kompilátor nedokáže na rozdíl od OoO logiky řešit cache miss a prodlevy v přístupu do paměti, které jsou při běhu programu kompletně nedeterministické - to je asi ghlavní důvod, proč out-of-order princip zvítězil).

Jakou hodnotu má ta schopnost zpracovávat víc instrukčních sad, to si nejsem moc jistej. Technicky je to hrozně zajímavý, ale na trhu po tom asi poptávka moc není.

Ale určitě by bývalo bylo lepší, kdyby ten čtvrtý hráč na poli x86 CPU dál existoval, a kdyby i ta VIA měla větší úspěch a lepší postavení (u té je mi zase líto, že se ta CPU zpolitizovala tím, jak do toho vstoupila ČLR). Bylo by to všechno zajímavější, myslím.