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.
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.
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.
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…
Přesně tak. Takže když zahodíte výsledky všech – zejména syntentických – benchmarků procesorů, které kdekoli v médiích, či na internetu nejdete, pak je to asi jediné rozumné chování, které lze udělat.
Mimochodem, ač jsem kdysi o koupi icc uvažoval, nakonec jsem se rozhodl, že na něm nebudu vyvíjet právě z důvodů neférovosti vůči neIntel procesorům-
… 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(ů).
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 )
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ší).
…tak to holt AMD nepozná
Ani nemusí, protože každý x86 procesor na sebe prozradí, co všechno umí, ikdyby to byla noname značka procesoru vyrobená Frantou Kubelkou v Ekvádoru.
Tudíž puštění obecného x86 kódu podle starých standardů je ZÁMĚR, nikoli technický problém.
…obávám se, že ICC se používá na naprostou menšinu projektů
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ě a AMD a VIA procesory jsou ve skutečnosti výrazně výkonnější, než je v testech naměřeno a jsou daleko výraznějším konkurentem proti Intel procesorům.
…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ší
To raději nakomentuji. Neboť optimalizace gcc je tak mizerná, že ono je plus mínus jedno o co se pokouší gcc optimalizovat. Kde nic není, ani smrt nebere – to platí pro optimalizátor gcc. Nicméně čím lépe umí kompilátor optimalizavoat, tím výraznější rozdíly najdete proti vypnutí optimalizace. U gcc o nic nejde.
… Ani nemusí, protože každý x86 procesor na sebe prozradí, co všechno umí, ikdyby to byla noname značka procesoru vyrobená Frantou Kubelkou v Ekvádoru.
Jenže problém je v tom, že kód vygenerovaný ICC se podívá na CPUID číslo procesoru (a to při každém volání funkce) a když je to Intel a umí lepší instrukce, tak spustí rychlejší kód. Když podle toho čísla pozná, že běží na AMD tak i když procesor umí ty instrukce, tak spustí pomalejší kód.
Proto taky novější Intel procesory jsou upravené tak, aby se tvářily jako starší právě kvůli ICC.
Což je ale marketinkový záměr, jak zkriplit kompilátor, aby na neIntel procesorech běžel hůře. Protože dívání se na vendora procesoru a podobné jakožto hlavního rozhodovatele je zhruba stejné, jako kdyby do linux kernelu někdo umístil kód při startu Linuxu:
if (na_jine_partition_je_windows)
vkladej_cekaci_cykly_do_kernelu_Linuxu_a_bud_pomalejsi;
Následně by Linux vystoupil s tím, že Windows zpomaluje Linux.
Technicky k čtení vendora procesoru v cpuid není důvod. Ale marketinkově ano, není nad to podpořit mýtus, že Intel má rychlejší procesory (nejsem fanoušek AMD), a o to více to potěší, když pak se to objeví ve všech médiích v testech procesorů tento zfalšovaný výsledek celosvětově, protože Intel kompilátorem je většina syntetických/analytických testů testů kompilována.
Pokud někdo srovnává věci přeložené gcc (viz Debian a standardní kompilace) s icc, pak riskuje, že se špatná kvalita gcc vytáhne na světlo.
Pokud máte pocit, že je to nepodložené, očekávám od Vás důkazy o excelentní kvalitě gcc. Zatím všechny testy pro gcc dopadly dost špatně z hlediska optimality výsledného kódu. Jediné, co je horší je Borland kompilátor.
Takže očekávám ty důkazy kvality optimalizace gcc. Děkuji předem. :-)
Najdete si pro trollovani laskave nove tema…
http://eigen.tuxfamily.org/index.php?…
A podobnych i pro komplexni pripady vam najde Google spoustu.
To není nepodložené nadávání. Pan Ponkrác je můj nejoblíbenější autor moderních scifi pohádek o výpočetní technice. Bohužel píše na nesprávná místa(root, abclinuxu, fórum na builder.cz a možná i jinde), kde jeho výtvory neocení.
Z jeho tvorby bych kromě pohádky o gcc vypíchl pohádku o STL, pohádku o jádru linuxu a nepříliš známou, ale o to lepší sérii povídek o RISC procesorech(http://forum.builder.cz/read.php?…).
… 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)
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.
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).
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é.
Ž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.