Názory k článku
Jak Intel zpomaluje AMD procesory

Otazka je jak moc nefer jednani intelu to je, je to preci jen jeho prekladac. Nikoho nenuti ho pouzivat. Stejne kraviny aplikuje EU na M$ kvuli prohlizecum, natvrdo bych poslal celou EU do prdele a na 6mesicu zastavil vydavani Windows pro Evropu.

Heh, pan je odbornik. Ono to zastaveni M$ produktu pro Evropu nechce prave a jedine Microsoft.

Ono by se totiz vubec nic spatnyho nestalo ba naopak. Trh by se ozivil a svet by fungoval dal i po Microsoftu a prave to si M$ nemuze dovolit :D

Neverte vsemu co se pise a zajimejte se taky o neco jinyho nez o IT at priste vidite spojitosti.

Neco jako volny trh, konkurence atp. to by Vam urcite melo neco rikat.

Poskozovani konkurence se deje porad a vsude na to nevidim nic divneho, ale aby se do neceho takoveho vkladala EU, kdyz podradna Opera(nikoliv funkcionalitou) neni schopna sama konkurovat a vyprosi si to soudne v tom vidim fakt neco shnileho.

Takze to poskodzovanie konkurenice je podla vas v poriadku? Tak by to malo byt? To, ze sa to takto deje, automaticky znamena, ze je to spravne? A kto by sa mal takymto pripadom zaoberat? Krajsky Sud v Ostrave?
A preco ja magor sa nad takymto nazorom rozculujem. Je predsa na prvy pohlad jasne, ze to vyliezlo z widlakovej hlavy ktora ma default setting klapky na ociach.

Nerika v poradku, jen ze se to deje pomerne bezne. Nebo Vam snad chovani Opery prislo v poradku? Prijde mi to jak zalovani na zakladni skole.

Velmi dobre jste to naznacil. Tady uz mladi lide, ne snad vsichni, to by byl uz konec relativniho kllidu a vyvoje a nastup krvevalecnictvi. Vzdyt to, jak pisete je videt uz i kolem nas. Vsuuuude. Bezohlednost, zlodejna neuveritelnych rozmeru, lide bez ohledu na vek mnoho mesicu mluvi a to naprosto vazne az rozlicene o defenestracich vlady, radnic Hradu ap. Kazen, moralka jsou dnes jen nadavky mezi takovymi jako byl prispevek, na ktery jste reagoval. Arogantni idioti svoji bezohlednosti a tuposti zenou tuto zemi stejne jako Zemi do totalni bezohledne totality. Pral bych tomu, nema se to, ale vychovny kopanec je velmi dobry pro cely zivot, aby neskoncil tragicky, aby na vlastnim kuzi, jak se rika, zazil. Zazil utisk tak, ze bude uvazovat o sebevrazde. Pak by to melo skoncit, aby nehavaroval jako lidska bytost. Jinak svoje toto psani opiram o sve zkusenosti ze zivota a ekonomie a mockrat jsem si v duchu i nahlas i v minulosti rikal, ze pro nektere lidi jsem zacal chapat tzv. stredovek a kata na namesti... A to take proto, ze pravo a jeho vykon ma slouzit jako vychovny prvek zivota lidskeho a spolecenskeho. Kultivovana spolecnost respektuje ohleduplna pravidla spol. jednani. Zlocinecka pakaz zna jen jedno pravidlo: "Sluz, nebo budes zabit!"

Tím, že říkáš podřadná Opera jenom dokazuješ, že na trhu software je něco špatně. Kdybych vyráběl auta a měl 1% z celosvětového světového trhu(řádově jako Opera), tak mě budou v televizi ukazovat a říkat jak jsem úspěšný. Ale na trhu se software musí člověk mít v jiných oborech téměř monopolní podíl(desítky procent), aby se o něm začalo vůbec mluvit.

… nadherna predstava a svet by zjistil, ze zivot je mozny i BEZ MICROSOFTU a jeho dokonalych programu. (viz.James Bond 007 / Tomorrow Never Dies)

Nojo ale icc to komercni prekladac, za ktery vyvojari plati nemale penize. Jste si jisty ze penalizovani AMD procesoru je popsane v licencnim ujednani? To jako kdyby MS schvalne modifikoval MS-DOS aby pod nim padaly programy od konkurence. MS si to tehdy mohl dovolit, protoze to tenkrat jeste bylo legalni. Ale dneska?

Ach jo. Kdy MS záměrně modifikoval DOS, aby pod ním padaly programy třetích stran (já si naopak pamatuji, jak MS do WIN95 dával hacky, aby tehdejší nekorektně napsané aplikace třetích stran nepadaly). A kdy to bylo legální?

Jinak ten překladač si lidi platí, aby optimalizoval co nejlépe pro konkrétní modely procesorů (i s využitím vlastností typu tenhle procesor má dvě FP sčítačky a jednu násobičku, a latence těch a těch instrukcí jsou takové a takové). Jestli jste si přečetl ten článek z odkazu ve zprávičce, tak tam píšou, že i na budoucích modelech Intelu ty programy pojedou úplně stejně (pomalu) jako dnes na AMD.

A ještě poučení na závěr: když chcete vymáčknout z procesoru maximum, tak to na něm taky testujte (výkonnostně). Pak na takovéhle problémy jistě přijdete.

On Intel se moc nechlubí tím, že je to jen pro procesory Intel (on totiž nedetekuje použitelné instrukční sady, ale „GenuineIntel“ – naschvál). Naopak mu vyhovuje, když se o ICC říká, že je to nejlepší překladač (ani slovo o háčcích), a na námitky/dotazy odpovídá mlžením nebo lhaním. O téhle věci se koneckonců ví už léta (viz odkazovaný článek).

Intel se taky moc nebrání tomu, když se s použitím tohoto nefér překladače kompilují benčmaárky…

… On Intel se moc nechlubí tím, že je to jen pro procesory Intel

Z dokumentace icc:

The -ax (Linux* and Mac OS* X) or /Qax (Windows*) option instructs the compiler to determine if opportunities exist to generate multiple, specialized code paths to take advantage of performance gains and features available on newer Intel® processors based on IA-32 and Intel® 64 architectures. This option also instructs the compiler to generate a more generic (baseline) code path that should allow the same application to run on a larger number of processors; however, the baseline code path is usually slower than the specialized code.

The compiler inserts run-time checking code to help determine which version of the code to execute. The size of the compiled binary increases because it contains both a processor-specific version of some of the code and a generic baseline version of all code. Application performance is affected slightly due to the run-time checks needed to determine which code to use. The code path executed depends strictly on the processor detected at run time.

Processor support for the baseline code path is determined by the processor family or instruction set specified in the -m or -x (Linux and Mac OS X) or /arch or /Qx (Windows) option, which has default values for each architecture.

Všimněte si prosím slov „newer Intel® processors“ a „processor-specific version“. Ale já vím, dokumentace se nečte.

… mu vyhovuje, když se o ICC říká, že je to nejlepší překladač

Kdo to říká, ať si to obhájí. Divil bych se, kdyby to Intelu nevyhovovalo, ale těžko můžete chtít, aby opravoval každý kec, který někdo pronese.

… použitím tohoto nefér překladače kompilují benčmaárky

V takovém případě by se mělo AMD ozvat a ukázat na ty benchmarky, které toto dělají. Asi těžko by pak někdo věřil procesorovému benchmarku, který je optimalizovaný na jeden (nebo několik málo) konkrétní(ch) procesor(ů).

Mám takový pocit, že jsi nepochopil to, na co reaguješ.

O MS-DOSu nevím, ale vím, že Microsoft vědomě modifikoval betaverzi Windows 3, aby zobrazovaly falešnou chybovou hlášku, pokud byly puštěny pod DR-DOSem. ( http://en.wikipedia.org/wiki/AARD_code )

a kde byl v te dobe linux ? :)) on nikoho nenutil pouzivat windows . a byl tehda nejaky rozumny OS pro PC ? Linux to nebyl takze leda tak OS2

lenze tam prepinac zapni SSE je v skutocnosti zapni SSE pre Intel procesory. pre nikoho ineho nie. vid http://www.federmann.cz/…k-2005-testy
ked je pouzity gcc tak Intel nema taky naskok pred AMD ako ked sa pouziva ICC ktory je pouzivany spolu s VSC++ na drvivu vetsinu projektov na windows.

To je jak rádio Jerevan: v tom článku nemá náskok Intel před AMD, ale před VIA, nepoužívá se tam gcc, ale mění identifikaci procesoru, obávám se, že ICC se používá na naprostou menšinu projektů. ICC má i přepínač „zapni SSE pro všechny“: pokud si zapnete kompilaci pro (dejme tomu) Pentium II, tak se použije (i na AMD). Pokud si ale zvolíte ten překlad pro více procesorů, tak to holt AMD nepozná a pustí to na něm obecný x86 kód (což je mimochodem kód asi na stejné úrovni, jak je přeložena naprostá většina balíků v Debianu pro i386 – tam se taky nějaká optimalizace pro lepší procesory neřeší).

Uz na zacatku jsem si rikal, jestli Vas tu s tim vecnym nepodlozenym nadavanim na gcc jako mizerny prekladac najdu. A hele, nektere veci se proste nemeni :)

… x86 procesor na sebe prozradí, co všechno umí, ikdyby to byla noname značka procesoru vyrobená Frantou Kubelkou v Ekvádoru.

Ale tady nejde o to, co umí, ale jak to umí. A to na sebe procesor (z Ekvádoru ani odjinud) neprozradí.

… puštění obecného x86 kódu podle starých standardů je ZÁMĚR, nikoli technický problém

Záměr je optimalizovat co nejvíc na konkrétní typ procesoru, to je vlastnost, kvůli které si to lidi mají kupovat.

… Používá se převážně na kompilaci testovací sw pro syntetické a aplikační testy výkonu procesorů. Pokud Intel takto podvádí, můžete si být jisti, že všechny recenze a testy (nebo převážná většina) měří špatně

To je ale chyba lidí, kteří ty benchmarky dělají. Oni mají zaručit, že výsledky jsou nestranné a dobře porovnatelné. Pokud benchmark, který má testovat procesory Intel, AMD a VIA uděláte tak, že vezmete kompilátor od Intelu (který se navíc ani moc netají jak to funguje), tak je to především vaše chyba. Pokud by třeba Intel podmazal SiSoft (nebo někoho jiného) aby k benchmarku použil kód generovaný jeho kompilátorem, tak by to bylo jistě nemorální (a dost možná nekalá soutěž). Ale zpovídat by se měli především ti, co ten benchmark vyrobili.

MMCH hraji občas hru, která se (ve svém intru) nepokrytě chlubí, že na optimalizaci její autoři spolupracovali s inženýry nVidie (hádejte, na jakých grafikách to pojede nejlíp). Je toto jakkoli nemorální? Samozřejmě, srovnávat výkon grafiky nVidia a grafiky ATI/AMD podle této hry nejde, ale uživatelům (ani konkurenci – jiným hrám ani jiným grafikám) se tím nijak neubližuje.

… Kde nic není, ani smrt nebere – to platí pro optimalizátor gcc

Mám jiné zkušenosti, viděl jsem dost programů, kde nastavení kompatibility na novější procesor pomohlo dost (hlavní je plánování instrukcí a CMOVxx, SSE a MMX pod gcc moc ne). Ale nechci vyvolávat flame, tady se asi neshodneme.

Ale i kdyby gcc bylo tak špatné, tak přece ten obecný kód co vyrábí icc je také optimalizovaný (dokonce možná používá vyšší instrukční sadu než gcc v defaultu). Takže pokud vezmu ty balíky z Debianu přeložené gcc -O2 bez -march nebo -mcpu, přeložím to icc -O2, tak bych si měl pomoct i na AMD, ne? Ano, nevyužiji plně potenciál svého procesoru, ale stejně si tak nepředstavuji „záměrné mrzačení“. (Anebo si přeložím icc kód jen pro Pentium II, ten na Athlonu XP běží taky a jeho potenciál vcelku využije)

Provadel jsem mereni pomoci raytraceru na intel xeon, pentium m, pentium III a dle mych mereni produkuji gcc i icc srovnatelny kod. Na PIII gcc vyhralo, napr. rekurzivni volani dokaze optimalizovat lepe.

Tomu Intel kompilátoru se pomocí přepínačů dá říct, jakou instrukční sadu má používat. Řekne-li se mu, že má používat SSE2, tak použije SSE2 na všech procesorech — ať Intel nebo AMD.

Jenomže ten kompilátor ty programy linkuje s vlasními knihovnami, co obsahují funkce jako např. memcpy, memset, a tyto funkce jsou napsány na několik verzí a rozhodují se podle CPUID (to memset má např. ještě dvě verze pro to, zda data jsou nebo nejsou v cachi). A tady je ten problém, že např. memset pro AMD nastavuje paměť postupně po jednom bytu. A memset pro Intel nastavuje pomocí SSE po 16 bytech. I když procesor AMD samozřejmě umí nastavovat paměť po 16 bytech taky.

Zastavit vydávání Widlí pro Evropu na šest měsíců? Kéž by to tak dopadlo! Aspoň bych si mohl vybrat z více notebooků, na kterém stejně bude jen Linux a neplatit za Widle.

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?

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).

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é.

Přes den se s Tebou nikdo nebaví, tak ses vybouřil tady? Zkus se vyjadřovat stručně a věcně, možná si nějaké kamarády najdeš.

Ž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.