Intel Core i9: první 32nm šestijádrový procesor již příští rok

Ještě by to chtělo podpořit optimalizaci programů a her, aby využili opravdu všech možností a jader procesoru. Ovšem s tím Intel toho moc už neudělá.

Mimochodem, nějak si upravte to zobrazování OS a prohlížeče. Nechci mít Vistu označovanou jako XP.

Nebudeš kvůli tomu spát?

Ja mam zas na cudny prehliadac

Nejdřív se to musí ujmout a pak přijdou optimalizace.

Neznám programátora (resp. firmu, která by něco programovala) jen tak, do zdi. S podporou něčeho, co masy nevyužijí.

Mimochodem, aplikaček, které podporují paralelní zpracování, těch už pomalu přibývá. Jsou to dnes dvě zásadní otázky pro platformu Windows - přejít na 64-bit (což vypadá, že se s w7 podaří) a podpora vícejaderných CPU.

Aplikace, které dokážou využít více jak dvě jádra, prakticky nexistují a sotva budou, protože normální úlohy jako psaní textu, emailů nebo práci s internetem nelze nijak rozumě paralelizovat. Určité využití se nabízí jen ve velmi specifických odvětvích, jako CAD, zpracování grafiky nebo videa. Tohle je ale segment, který výrobcům procesorů negeneruje žádné výrazné zisky.

To ale přeci není pravda. Pár příkladů:

píšete text, paralelně se kontroluje gramatika

děláte v excelu, paralelně se přepočítává celý sheet

děláte cokoliv, paralelně si systém může provádět co chce

Dnes se s přehledem využijí dvě jádra i při kancelářské činnosti. Čtyři jádra se ještě nezaplní, ale rozdíl od dvou jader znát je.

Ve chvíli, kdy programátoři budou cíleně vymýšlet, jak paralelizovat, tak to bude ještě lepší.

Máte dojem, že to neutáhne jednojádro?

- Pište něco ve Wordu a dívejte se, co se děje se zátěží CPU, prakticky nula. Koupíte si kvůli tomu šestijádro?

- Viděl jste někdy normální Excelovou tabulku? Neříkám, že neexistuje něco, co dá CPU pohulit, ale normální uživatel na to sotva kdy narazí. Koupíte si šestijádro kvůli tomu, že jednou možná (mě se to za deset let ještě nestalo) dostanete v Excelu tabulku, která se bude dlouho přepočítávat?

- Paraleleně provádět co?

Dvě jádra ještě beru, protože občas dokáže kousnout počítač i start Průzkumníka nebo jiné aplikace. Můžete tedy v klidu přepnout do jiné, když se vám nechce čekat. Tím ale využití více jader na desktopu končí.

Co mají jako programátoři cíleně vymýšlet, když ani vy sám nemáte jediný rozumný příklad? Většina činosti na desktopu má bohužel striktně sekvenční charakter.

1) Sestijadro zatim nemiri do desktopu, ale spis mezi pracovni stanice.

2) I dnes, se toho v pocitaci chvilemi deje docela dost - trebas na pozadi bezi TimeMachine a SpotLight si spokojene indexuje. A aby toho nebylo malo, tak si kazdy otevreny tab v browseru shrabne sve, protoze v nem bezi nejaky javascript a flash.

3) A pak naimportujete fotky z digitalu, a najednou je tu prace pro spoustu jader.

Rekl bych, ze zatim jde dobrou cestou intel v i5 a i7 CPUs. Pokud staci jedno vlakno, tak se jedno z jader pretaktuje a ostatni vypnou. Odpovida to tomu, co je dnes potreba. Chvili vysoky singlethreaded vykon, chvilemi vice jader.

1) Ale výhledově je tady snaha výrobců čipů tohle řešení marketingově prosadit, protože trh pracovních stanic je ve srovnání s desktopem zanedbatelně malý. Ze strany výrobců je to pochopitelné, protože výroba výkonějších jednojader není z čistě fyzikálních důvodů už nadále možná. Problém na straně SW je bohužel v tom, že ten paralelismus nelze využít.

2) Co běží na pozadí, je při zátěži procesoru okolo 5% úplně jedno. Podívejte se do Taskmanageru. I kdybyste nakrásně dokázal ten potenciál využít, je to k ničemu, protože vám pořád bude hučet ventilátor nebo rychle docházet baterie.

3) Čistě ten import je snad limitován rychlostí přenosu, případně schopností fotoaparátu posílat data, ne? A co se editace týče, je to opět případ pro speciální aplikace. Rozhodně žádný mainstream, který vytváří poptávku po výkonějších vícejádrech.

Na trhu je už nějakou dobu hra, která by měla při svém chodu využívat čtyři jádra procesoru (-ů?), ale jaksi měla potíže vytížit tři; čtvrté jádro bylo vždy 100 % nevyužité.

Z českých škol: „Internet je to modré e na ploše, po jehož spuštění se zobrazí Seznam internetu.“

Ale u 4+ jader to uz pomalu zacina vyzadovat zmenu mysleni programatora. Soustredit se na imutable data, nepouzivat synchronizace, mozna i opustit jazyky jako Java a C# (nebo nedejboze C/C++) a pozuit Scalu, F#, Haskell... Misto threadu actors...

OMG, co jste myslel tim nedejboze C/C++ ?

Se ani nedivim, ze je vetsina programu tak priserne pomalych, kdyz jsou napsany v necem jako Java a C#, nedejboze ve vami uvadenych jazycich . Kdyz chcete mit kvalitne optimalizovany program, tak napred musite mit "rychly" jazyk. Idealni je kombinace C++ a assembleru (pro rucne vektorizovane odrolovane smycky). Potom ani nemusite paralelizovat, protoze jeden thread je vetsinou tak rychly, ze plne vytizi vsechny sdilene zdroje (pametova propustnost atp.) . Ale chapu, ze tohle neni pro kazdeho a ti dnesni "lepici kodu" se snad ani nedaji nazyvat programatory. A vysledky podle toho bohuzel casto vypadaji .

Tohleto je celkem zábavné čtení. Už jste někdy programoval?

Myslim, ze uz asi jo . Nezda se vam na tom neco ? Muj kod je bezne 5 az 10 krat rychlejsi nez vyplodek bezneho kompilatoru, takze tak strasne to snad zase nebude... . Mimochodem, delam na SW, pro ktery je dobra optimalizace primo zivotne dulezita konkurencni vyhoda, takze si nemuzu dovolit flakat se a produkovat nejake splacaniny v pohodlnych interpretovanych jazycich a spolehat se na kdovijake pofiderni neoptimalizovane knihovny...

Víte, už jenom tyhlety řeči, jak je váš kód skoro desetkrát rychlejší. Co k tomu dodat? Jste si jistý, že používáte ten správný kompilátor? Dnešní kompilátory nejsou tak hloupé, jak by se na první pohled mohlo zdát. Ale dejte konkrétní příklad, ať víme, v čem mají autoři kompilátorů ještě potenciál k zlepšování. Silně pochybuju, že něco najdete.

Dále, pokud byste byl skutečně programátor, tak byste věděl, že tyhle optimalizace mají v reálném životě minimální význam. Kromě toho, že na celkovém běhu aplikace se to obvykle nijak znatelně neprojeví, je tady ještě celá řada dalších faktorů. Z dnešního pohledu totiž není nejdůležitější jenom optimalizování aplikace, ale především rychlost jejího vývoje, rozšiřitelnost, modulárnost, možnosti portability a především cena vývoje. Pokud nejste schopen vidět tyhle věci jako celek, tak silně pochybuju, že jste měl s programováním kdy co do činění.

Bez urazek prosim .

Treba VS2005 a GCC. Desetinasobne zrychleni je zmereno. Samozrejme pri rucnim vyuziti SSE (2, 3, 4.1) s unrolled loops, predikates (tedy omezeni vetveni), zarovnanymi pametovymi pristupy a prefetchingem. Kompilator rozumne vektorizovat neumi (krome Intelackeho, ale ten zas nepodporuje Opterony). Maximalne tak dokaze produkovat skalarni SSE2 kod, ale to je tak maximalne dvojnasobne zrychleni. Napr.: Soucasne CPU dokazou vykonavat az 32 (i celkem komplexnich) integer (8bit) operaci v jednom taktu. Kompilator nema sanci se k tomuhle priblizit (pracuje prilis obecne). Nedokaze totiz cely blok kodu preskupit a nahradit jednou slozitejsi instrukci. Clovek ano. Je to trochu hlavolam, ale jde to. Portatibilita je dobra - podpora vsech x86 a x64 systemu (assembler bezi stejne na kazdem OS). Ano, drobna nevyhoda je v dobe vyvoje, ale to je vynahrazeno kvalitou. Nejlepsi auta jsou taky vyrabena rucne a zakaznici cekaji v poradnicich...

"na celkovém běhu aplikace se to obvykle nijak znatelně neprojeví," - dovolte abych se zasmal . To bych se pak na to fakt asi mohl vykaslat ne ? :) A s tou cenou vyvoje - kdyz je vysledny produkt kvalitni a rychly, tak se vyssi cena za vyvoj vyplati. Je rozdil, jestli zakaznik na vysledek ulohy ceka hodinu nebo cely den. Cas jsou penize a v nekterych oborech obzvlast.

Na druhou stranu chapu, ze treba pro obycejne firmy delajici bezny "kancelarsky" nebo ucetnicky soft je trochu overkill snaha o maximalni optimalizaci (mnou uvadene priklady jsou fakt extrem). Jen jsem chtel rict, ze tyhle sestijadra jsou pro bezne smrtelniky uplna zbytecnost, kdyby se trosku optimalizovalo a neprogramoval kazdy jouda, co umi psat na klavesnici. Treba prave ve VS2005 se mi stava, ze na high-endove masine se obcas cuka i psani textu (!!!). Tohle zvladaly pocitace pred 40-ti lety (a mozna i driv)...

- SSE kompilátor C++ samozřejmě umí. Pokud vím, minimálně ten od Intelu nebo MSVC2008. Použijí se akorát speciální knihovny a přepínače a kód je pak možné psát bez použití assembleru, čistě jako volání funkcí. Ještě si to zjistěte, než se tady bude ohánět argumenty ohledně možností dnešních kompilátorů. Navíc SSE není úplně typický příklad, srovnáváte hrušky a jabka.

- Dovolte abych se zasmál. Platí se tomu, kdo zboží nabídne rychleji. U velkých nebo dokonce státních zakázek pak platí úplně jiná kritéria. Optimalizace se dají vždycky udělat až na základě ohlasů. Celkem by mě zajímalo, co za aplikaci vyvýjíte?

- Na tom účetnictví je krásně vidět, že efekt optimalizace se přeceňuje. Pokud bererte velmi úzkou skupinu aplikací pro CAD, grafiku, nebo zpracování videa, tak tam ten kód samozřejmě optimalizován je, včetně využití vámi uvedených instrukcí.

Přeceňujete svoje schopnosti a zbytečně podceňujete joudy

- k te posledni vete: mozna to znelo trosku arogantne, ale myslel jsem to tak, ze znam spoustu lidi, co pracuji jako programatori a pritom maji tak zaklady programovani na VSE a udelali nejake ty HTML stranky. Naucit se optimalizovat neni nic sloziteho. Je to dokonce jednodussi, nez paralelizovat pro multicore.

- nerikal jsem, ze kompilatory SSE neumi, samozrejme ho umi, ale to je tak asi vsechno. Prave clovek, co nema sajnu o optimalizaci si proste mysli, ze tohle jen staci zapnout. Kdyz si to disassemblujete, tak zjistite, jake hruzy ten kompilator produjuje. SSE primo v high-level jazyce jsou tzv. "intrinsics". Bohuzel to ma spoustu nevyhod (bugy, neaktualnost, prenositelnost, trojoperandova syntaxe, takze tam kmpilator musi strkat spoustu MOVu atp.), takze radeji volim primou formu - asm. Ale je to urcite jedna z moznosti. Lepsi tohle, nez nic :).

-no jo, statni zakazky - tak to chapu, ze na vyslednou kvalitu se dlabe :). Nasi zakaznici radeji nekoupi vubec, nez aby koupili smejd. A obsluha daneho SW ma tak vysoke platy, ze jejich casem neni radno plytvat :). Sice tohle nejde genralizovat, ale myslim, ze kazdy by ocenil, kdyby nemusel na neco stale cekat. Treba ja na prekladac...

-ono i v tom ucetnictvi je nekdy potreba rychlost - treba pri vytvareni rocnich prehledu atp., ale uznavam, ze to neni stezejni. Konkretni vec, na ktere delam vam bohuzel neprozradim. Jsem vazany NDA (ne, nedelam si srandu), ale dalo by se to zaradit do vami zminovane skupiny :).

-tohle byl nejspis muj posledni pripsevek tady - muj cas taky neni neomezeny...

To by bylo na delsi vysvetlovani, ale ve zkratce: Ne, pro 80+% problemu nemate pravdu.

A v trosku delsim podani: Runtime jazyku, jako je Java umi delat prekavapive dobre optimalizace, protoze zna hodne informaci z runtime (coz C, Fortran... pochopitelne nemohou). Nekdy je vysledny kod lepsi nez C, nekdy ne (samozrejme, ze rucne psany asm to temer vzdy vyhraje, ale je to nehorazne draha sranda, ktera se vyplati pro male kousky kodu, hotspots, a jen v minimalnim mnozstvi projektu).

To, co maji C, C++, Java... spolecne jsou mutable data, coz je pro budouci mnohojadrovy vyvoj mor (v C je to jeste o chlup horsi kvuli pointerum). Proto je ted najednou vsude tolik projektu, ktere si berou inspiraci z neproceduralnich jazyku (Hlavne z rodiny ML, Haskellu... Lispem je AFAIK inspirovana jen Clojure) a stavi svou filosofii trochu jinak. Uvidime, jak to dopadne, je to o dost jine mysleni, nez dosud, ale nejspis je to cesta, jak mohou slusni (tedy ne mizerni, ale taky ne hvezdni) programatori psat slusne paralelizovatelny kod a nezblaznit se.

V zasade s vami souhlasim. Problem je prave v tom, ze se dneska uprednostnuje kvantita nad kvalitou a stale zrychlovani HW nenuti "bezne" programatory k nejakym optimalizacim. Kdyby kvalita kodu byla stale stejna jako napr. v dobach 8-bitovych pocitacu, tak by dnes nebyly vicejadrove CPU pro bezny SW vubec potreba. Je mnohem jednodussi zoptimalizovat hlavni smycku algoritmu a prepsat ji treba do SSE4.1 (+ SSE2 pro zpetnou komp.) a dosahnout rekneme 6-nasobneho zrychleni na kazdem modernim CPU, nez ji slozite paralelizovat a dosahnout zpomaleni na jednojadru a dvojnasobenho zrychleni na ctyrjadru .

me se zas nejvic libi, ze v tovarne Intel maj na pocitacich samolepky AMD, fakt podareny video, jako by si u intelu neverili a radeji vyrobu prenechali "konkurenci", pekne...