HW novinky: první důkaz faktického Intelova monopolu v hi-end x86 desktopu (diskuse)

[mca]

To je dost mozne, ale stejne tak za tim muze byt i historie z prichodu s2011 - Core i7-38xx/39xx vcetne Xeon E5-16xx (C1), kteru se dost dobre nepovedl - s limitem i7 32GB RAM a absenci VT-d i pro Xeon E5-16xx, kterou opravil Intel az s prichodem C2.

I tak je dnes vykon CPU tak vysoky, ze neni vlastne ani kam bezhlave spechat (ja vim, schytam to), kdyz to brzdi SW a nejsem si jisty, jestli je o co stat s polotovary. Vsak ani IvyBridge nebylo bez problemu. Stacilo zmenit slovo "nepovedene" na "vlastnost".

[Michal Kubeček]

Pro Intel hovoří i to, že prostě v desktopu nebývá tak dobře zužitkováván vyšší počet jader, obvykle jsme rádi za optimalizace pro dvě jádra a chrochtáme blahem za optimalizace pro čtyři

Já bych si ani netroufl sázet na to, že se to v dohledné době (řekněme do pěti let) nějak výrazně změní. Přeci jen vývojářů a gentooistů není tak moc, takže tlak na vyšší výkon ve vícejádrovém provedení by mohl přijít jen kdyby začaly ve větší míře paralelně fungovat hry. A ty se zatím podle všeho zaměřují spíš na vytížení high-end grafických karet než vícejádrových procesorů.

[little.owl]

+1

Navic se mi zda, ze transformaci puvodne jednojadrove zamerenych aplikaci na vicejadrove vyvojari zatim nezvladaji a je to plne race conditions. Zrovna ted jako ohlavka cekam na novy ARM linker, ktery sice dokaze nove vyuzit vice jader, ale obcas se nahodne kousne, saturuje dve jadra na 100% a pak uz nic. Uzasne na automatickem build serveru.

[Michal Kubeček]

To mi připominá, že bych se mohl zase podívat, jestli už konečně vyšel PovRay 3.7… a nevyšel.

[Sten]

Ono je k něčemu dobré mít vícevláknový linker, který stejně musí linkovat přes globální (tj. neustále zamykanou) tabulku?

[little.owl]

V praxi ne, CPU scaling je naprosto mizerny. U dvou jader to cini asi 20-25% uspory casu na vetsim C++ projektu a dale uz to moc neroste. Tedy pokud se to nehryzne. Kdyby linkovani probihalo paralelne s kompilaci melo by to urcite smysl - jako kdysi v tinicc, ale tady krom pocatecni analyzy symbolu v object souborech asi nic paralelne nebezi - takze SSD predstavuje vetsi prinos.

[Pavel Píša]

Vzhledem k tomu, že se v rámci LinkTimeOptimization vlastně do linkeru přenáší veškerá zodpovědnost za převod a optimalizace z "obecného" RTL/syntax tree do finální binární podoby, tak je možné, že se vlastně jedná o náhradu řízení celého řetězce make, gcc, ld jen samotným ld. Pak je možné, že paralelizace linkerem řízené kompilace má smysl (po tom, co jsou po optimalizaci určené volací konvence/API funkcí). Trošku mě ten posun tradičního C programování, kdy má člověk po kontrole kódu v *.o jistotu, že i ve finální aplikaci bude v pořádku, děsí. Ale C++ inline se v collect kompiluje již dlouho a pokud chce C technologie využít některé možnosti, které dává Java a C#, tak je to nejspíš posun správným s směrem. Dalším krokem je mezikód a kompilace při instalaci podle aktuálního profilu CPU. Opět nevím, jestli to nepřinese víc škody než užitku, ale výkonnostní zisk by mohl být - alá Gentoo. Je ovšem otázka, jestli nakonec není nejlepší krok zpět a standardně distribuovat aplikace/balíčky pouze v textové zdrojové podobě. To je čisté Gentoo. Ale LTO stejně zbude.

[little.owl]

tak je možné, že se vlastně jedná o náhradu řízení celého řetězce make, gcc, ld jen samotným ld.

Tak daleko to jeste u techto komercnich embedded kompilatoru neni. U nas build system je napsan v cmake->make, kompilator a linker jsou stale nezavisle entity. Linker dela zakladni LTO - inlining, dead code elimination, reordering codu kvuli optimalizaci callu. Asi casove nejnarocnejsi je eliminace duplikovaneho templated kodu v C++, rozdil mezi linkovanim C a C++ projektu je obrovsky v radu stovek procent. Cast techto kroku podle me nabizi prostor k paralelizaci i ve vetsi mire, nez je to aplikovane dnes.

Trošku mě ten posun tradičního C programování, kdy má člověk po kontrole kódu v *.o jistotu, že i ve finální aplikaci bude v pořádku, děsí.

Ano, mam z toho stejny pocit.

[kip]

Na dvou místech textu o Ivy Bridge-E je "&nsbp;".

[Luboš Doležel (Doli)]

Díky, asi si na to přidám regexp do skriptu

[David Ježek]

ještě tam přidej na "&nbs;p", další můj obvyklý překlep ;)

[Bedňa]

Intel toho už nakecal. 48 jadier x86, LOL.

[AsciiWolf]

Co máš proti kvalitnímu topení (nejlépe při použití s Gentoo) na zimu?

[Bedňa]

Mne sa páči ako sa jadráci o procesore od Intelu, ktorí ešte ani nieje na svete sa vyjadrili, že tak zastaralú architektúru podporovať nebudú

[Atom321]

Kdo tvrdí, že to bude x86?

[nyan]

standardni pokus o levne PR nad projektem z labu (jednim z buhvikolik, z kterejch uspeje tak 1%) - delaj to i jine firmy, a hodne casto

[Sten]

Za 5 až 10 let, tomu bych i věřil. AMD má už dneska 16jádrové procesory a do dvou let plánuje 32jádrové, takže až Intel bude mít 48 jader, AMD jich bude mít 64 nebo víc (teda pokud do té doby nezkrachuje).

[Ovocníček]

V současnosti má AMD veřejnou roadmapu jen na rok 2013. Co přijde potom, je ve hvězdách. Dvacetijádrový Opteron (dva pětimodulové čipy) měl být, ale byl zrušen. Dost pochybuju, že do dvou let budou mít 32 jádro.