Vlákno názorů ke zprávičce Jak Intel zpomaluje AMD procesory od Karel - 1. Jádrem celého „problému“ není nic jiného než struktura: If...
-
Karel (neregistrovaný)
1. Jádrem celého „problému“ není nic jiného než struktura:
If Intel A then
Elsif Intel B then
Elsif Intel C then
Else
…AMD má problém s tím, že Intel nepřidává žádné IFy pro AMD nebo jiné výrobce, prostě na ně kašle a generuje kód, který prostě funguje.
2. Intel complier nepátrá ani tak po schopnostech procesoru, jako spíše po jeho označení. Proto má i Intel řadu procesorů, které spadnou do kategorie „Else“ nebo se úmyslně vydávají za jiný typ procesoru (byť papírově slabší). V každém případě je IF přes typ procesoru mnohem spolehlivější než nějaký obecný IF na počet násobiček, dostupnost SSE apod. Intel má dost vlastních zkušeností (a jeho zákazníci bohužel také), že se stejná věc v různých typech procesoru chová dostatečně jinak na to, aby to působilo problémy. Nehledě na to, že několik IFů na typ procesoru a natvrdo napsaný kód je nesrovnatelně jednodušší na vývoj/ladění/údržbu než kód programu pokoušející se reagovat na kombinaci několika parametrů.
3. Z pohledu Intelu je to velmi složitá situace. Někteří vývojáři se na svém blogu zmínili o tom, že by teoreticky bylo možné místo podle typu procesoru skutečně používat jeho vlastnosti, ale bylo by to méně průhledné a hůře testovatelné. Když máte IF podle typu procesoru, tak to prostě na daném typu ověříte a máte jasno. Když by IF byl podle počtu násobiček, tak to musíte testovat na desítkách konfigurací. A nedej bože aby to na nějakém AMD procesoru zhavarovalo a AMD zažalovalo Intel za to, že jejich překladač úmyslně generuje nefungující kód. Výmluvy o nestandardní kombinaci parametrů procesoru by pochopitelně nikoho nezajímaly. Samozřejmě, že se jedná o technicky řešitelný problém. Ale proč by měl Intel investovat nemalé peníze do řešení problému, který se jeho netýká a v důsledku by pomohl hlavně jeho konkurenci? Napadá mně jediný – tlak zákazníků. Ti ale moc netlačí.
4. V neposlední řadě je pak potřeba poukázat na fakt, že Intel má ve svém překladači řadu míst, kde využívá specifického chování svých procesorů. Může si to dovolit, protože chování procesoru zná a má to jak otestovat (IF na typ procesoru). O procesorech konkurence podrobné informace nemá a tak do těchto experimentů ani nejde.
Krátce řečeno, titulek zprávičky by neměl být „Jak Intel zpomaluje AMD procesory“, ale „Jak Intel ždíme Intel procesory a na AMD kašle“. Podle mně je jediná správná cesta přijít s překladačem, který by dokázal využít AMD podobným způsobem jako překladač od Intelu Intel. Jenže zatím nic takového není a tak vyhrává Intel procesor provozující aplikaci přeloženou Intel překladačem. Je to rychlé (optimalizace pro Intel) a spolehlivé (otestováno Intelem na Intelu). Ano, ono ani na AMD by to nemuselo být tak pomalé ale… kdo ten překladač napíše?
-
Ad 2) Bohužel právě kód obsahující ify přes konečný výčet SOUČASNÉHO stavu žalostně selhává v budoucnu. Protože vývoj se nezastaví a v ifu může být jen minulý stav do kompilace programu. Právě pro takové programy, které se spoléhají na ify z konečného výčtu se pak zhusta vydávají často i binární patche, protože v budoucnost často přestávají fungovat, nebo špatně.
Ale nikdo nikomu nebrání třeba psát programy způsobem:
if (linux_version == 1.00.00)
a narvat si tam x ifů třeba na zjištění namísto detekce přímo požadované vlastnosti.
Nicméně právě ify podle čísla procesory selhávají nejvíce. Možná budou fungovat 4.1.2010, ale pokud program neustále nebudu znovu a znovu překládat co pár měsíců a neustále neupgradovat kompilátor, tak postupně během krátké doby program začne běžet neoptimálně tak jako tak. Následně je pak nutné falšovat čísla procesoru a další nepěkné věci.
To co obhajujete je nejhorší hnus po funkční stránce co může být.
Závěr:
Intel kompilátor nekašle na AMD procesory, protože ZÁMĚRNĚ penalizuje neIntel procesory. Ač mohu souhlasit se 4), nemohu souhlasit s postupem 2), protože jako člověk s 20 lety praxe vím, že toto je záměr a nic než snaha poškodit konkurenci na úkor uživatelů, který se v praxi chová hůř a má horší vlastnosti – zejména i pro budoucnost přeloženého programu.
-
Ad 3) Jinak řečeno, prostě program přeložený na Intel kompilátoru jednoduše přestane fungovat na budoucích modelech Intel procesorů, protože to jednoduše neotestovali na (tehdy neexistujcích) modelech. To jste chtěl říci?
Jinak řečeno, v Intelu jsou totální nekňubové, kteří by se měli namísto vývoje kompilátoru vrátit k lopatě, pokud bych měl přijmout 3).
-
BLEK. (neregistrovaný)
Ano, je to opravdu tak. Ten kód vygenerovaný ICC testuje nejen GenuineIntel, ale i verzi „family“ na 6 nebo 15. Když je „family“ kód jiný, tak taky vypne SSE optimalizace.
Důsledek je ten, že Intel nemůže vyrobit procesor s žádným jiným „family“ kódem (protože pak by se na tom spousta programů přeložených ICC zpomalila). Procesory Core2 mají stále „family“ rovnou 6, a rozlišovat mezi nimi se může pouze podle čísla „model“. A v datech vrácených z CPUID se udělalo nové políčko, „extended family“, podle kterého se právě ty nové architektury mají identifikovat (zatím ho používá jen AMD, Intel v něm vrací 0).
-
BLEK. (neregistrovaný)
Napadlo mě, že toto chování mělo možná nějaký důvod. Kromě procesoru PentiumPro/2/3 s family kódem 6 a Pentium 4 s kódem 15 totiž existovalo ještě Itanium s kódem 7.
Itanium zpracovávalo IA32 instrukce přes mikrokód, který byl velmi pomalý (Itanium 700MHz bylo v režimu emulace IA-32 rychlé údajně asi jako Pentium 100MHz). Itanium nemělo SIMD architekturu, přesto podporovalo SSE1. Dá se tedy předpokládat, že ten mikrokód to SSE1 emuloval po jednotlivých částech registrů a mohlo to být ještě pomalejší než kód bez SSE.
Intel se možná domníval, že Pentium 4 je poslední procesor architektury IA-32 a že poté už bude Itanium tak vyspělé, že všechny další procesory budou IA-64 ( http://www.theregister.co.uk/…_make_moves/ ), a tak dal Pentiu 4 číslo 15 (nejvyšší číslo, co do toho „family“ políčka jde uložit) a Itaniu číslo 7 (s vizí, že v dalších verzích Itanií se ro bude zvětšovat na 8, 9, 10…). To by vysvětlovalo ten skok v číslování i snahu ignorovat SSE na neznámých procesorech.
No, dopadlo to tak, že z Itania 2 byl mikrokód pro emulaci IA32 odstraněn, protože se ukázalo, že je pomalejší než just-in-time kompilátor. A Itanium se neprosadilo, protože je složité, tedy velké, drahé a pomalé.
-
BLEK. (neregistrovaný)
Že by se Intel rozhodoval podle typu procesoru (různý kód pro Pentium 4 a Pentium M), to je podle Agnera pouze na jednom místě v jeho knihovnách. Jinak se vždy rozhoduje podle vlastností procesoru — t.j. přečte si ty bitíky, zda procesor má SSE, SSE2, SSE3 atd. a podle toho použije danou funkci. Jenomže on ty bitíky ignoruje, pokud procesor není Intel.
Nikdo po Intelu nechce, aby optimalizoval svůj překladač na AMD. Co po něm chtějí je, aby AMD záměrně neškodil — t.j. aby vyhodil ten test, zda je procesor Intel.
