Rostoucí počet jader CPU si v budoucnu vyžádá změny v OS (diskuse)

[Aleš Kapica]

Tak to je fakt "objev". O tomto problému se už nějaký ten rok známo, že od určitého počtu jader začne snižovat výkon jejich režie.

[Michal Fecko]

Multiparalelne programovanie je v plienkach... uz par rokov...

[Tomáš Veselý]

Před 7-ti lety jsem si říkal, k čemu mi bude předmět jako Paraelní Algorytmy. Během posledních let mi je už jasné, že to co se dříve využívalo jen u superpočítačů, bude chleba běžného programátora.

Změny si vyžádá nejen OS ale i architektura PC(Armu, a jiných).

V budoucnu se možná budou počítače víc a víc blížit lidkému mozku(milióny jader, které spolu neustále komunikují, ale přímý přístup bude jen k těm na okrají, které data přepošlou, nebo zpracují dál).

[Heron]

V budoucnu se možná budou počítače víc a víc blížit lidkému mozku(milióny jader, které spolu neustále komunikují, ale přímý přístup bude jen k těm na okrají, které data přepošlou, nebo zpracují dál).

Connection Machine?

[vain]

7-ti lety

Tak ty si kruťák =) +1

[Zdenek.Z]

Vynalézavost lidí v pitvoření pravopisu nezná hranic. (Lidi, napsat číslovku fakt není žádná věda.)

[Petr Tomášek]

Spíš demence jazykových puristů a orthofanatiků nezná mezí

Ano „7-ti“ je překlep, ovšem „7mi“ je naprosto logický zápis, který respektuje všechny tradice evropské typografie. To jenom v „Ústavu“ sedí blbečci, kteří si myslí, že musí ostatním diktovat, jak tzv. „správně“ psát...

[Jendа]

JJ, taky si to myslím. Už se tady o tom poslední dobou debatovalo minimálně ve 4ech diskuzích a ne jen s 1ím člověkem.

[Jendа]

ne jen s 1ím člověkem.

Tím jsem chtěl říct, že minimálně se 3emi.

[Petr Tomášek]

Kontrolní otázka: když angličané píšou „3rd“, je to taky špatně?

[Jendа]

Možná tím chtějí vyjádřit, že to není číslovka normální, ale řadová. Asi jako my píšeme tečku.

A vůbec, zkus mi vyskloňovat číslovky od 1 do 10.

[Sten]

Aha, takže takový Angličan vlastně psáts lépe, než většina Čechů dělat? Jiný jazyk míts jiná pravidla

[Martin Mareš]

"7mi" ty tradice typografie zrovna moc nerespektuje, protože opakuje "m", které se už vyskytuje v té sedmičce.

[Petr Tomášek]

Ano, tuto hovadinu najdeme např. v „poradně ÚJČ“, je to ovšem naprostý nesmysl, který vyplývá z totální neznalosti oné evropské tradice typografie a způsobu, jak v ní (především ve středověku) fungovaly zkratky.

Asi o tom konečně budu muset napsat do blogu, do té doby zkuste meditovat o tom, proč angličané zkracují „third“ jako „3rd“, přestože „r“ patří ke kořeni (viz „three“)...

[pavlix]

Ona ta angličtina taky nemá stejnou tradici jako čeština :). Ale to už je patrné na těch řadových číslovkách.

[Petr Tomášek]

Naopak! Je to uplně stejná tradice, která se táhne od pozdní antiky/ranného středověku (např. v řečtině a koptštině), stopy stejné tradice najdeme např. v češtině 15-16. století a její pozůstatky dodnes nalezneme už ve zmíněných anglických řadových číslovkách (stejně jako ve francouzských), nebo např. ve znaku „№“.

To jen čeští „koumáci“ a pseudo-lingvisti museli přijít s něčím „extra“...

[Martin Mareš]

stopy stejné tradice najdeme např. v češtině 15-16. století

Kde třeba?

(Speciálně u řečtiny bych si dovolil analogii s popisovaným případem zpochybňovat, protože klasická řečtina nic jako naše číslovky neměla.)

[pavlix]

Těch francouzských jsem si plně vědom, ale ta analogie je naprosto netrefená... a to o české tradici versus anglické to nijak nevyvrací.

[Jendа]

Na tohle jsem si už zvykl, ale algorytmus…

[Michal Vyskočil]

Já bych naopak řekl, že lidé ve firmách jako Cray, anebo Teradata a jiných tohle mají zmáknuté už pár desítek let. V zásadě jde spíš o to, kdy a v jaké podobě se podobné techniky dostanou do "upstreamu", to jest Java, C#, anebo C++.

[pc2005]

Jj tohle už bylo zkoumáno během vývoje Connection machine, ale i třeba u transputeru. Tam vznikl i speciální jazyk na programování Occam.

[lertimir]

To ne, transputery jsou slepá cesta, před 15 lety jsem s nimi pracoval. Ta koncepce datových toků mezi jednotlivými jádry je pomalá. mnohem zajímavější je to co se používá u superpočítačů a to že jeden procesor zapíše do nějaké části paměti data, pak dá jinému signál a ten k ní má přístup. má pak všechny data a hned. A to hlavní co mají superpočítače proti desktopu není ani tak paralelizace jako vektorovost, tedy efektivní násobné současné provádění stejné operace velké množině dat.

[pc2005]

To není imho tak pravda. Jak rychlý by bylo tehdejším alternativním procesorem na stejném výkonu zapisovat do sdílený RAM? Jestli se nepletu, tak long SIMM (poslední 486 a Pentia) měly hodiny tak 50MHz, v 80. letech to muselo být mnohem míň.

[Sten]

V C++ tohle rozšíření (plně kompatibilní s ISO C++) již existuje, jmenuje se to Threading Building Blocks (TBB), případně lze přejít z C++ na Charm++. Ono je to spíš o lidech, že o těchto možnostech neví

[Trained.Monkey]

Je otazka jestli bude tolik jader potreba. Desktopovy vykon podsledni dobou stagnuje, spise se posouva zpet (Atom).

[Jezekus]

Desktop dosahl takoveho vykonu, ze pro spousty lidi (kancelare, bezne doma) je ho prilis a je to vykoupeno zbytecne velkym odberem el. energie. (Procesory se nudi ale presto hrejou)
Zacina se objevovat to, co jsem tvrdil ja uz pred 2 lety, ze beznemu BFU staci pro praci obycejna PIII, par okamziku na to se objevila pod nazvem Atom (lehce nadsazeno samozrejme). Potrebny vykon napr. na HD dekodovani se presunul na GPU a tudiz CPU muze byt pomerne "line", ale na druhou stranu usporne.
Kdo potrebuje vykon na desktopu sahne po high-endu pripadne postavi workstation osazeny multisocketem.

[Heron]

Desktopový výkon se přesouvá na servery.

[bohyn]

nejak sem si nevsim masivni migrace na servery.

[Jendа]

Já si docela všiml, ale je prováděno tak nešikovně, že je výkon potřeba jak na straně serveru, tak na straně klienta…

[bohyn]

Pokud jsou tím myšleny služby jako Google docs atd tak tam je server ve funkci datového uložiště (dokumentu i aplikace). Pokud je myšlen hype kolem cloudů tak to je jen konsolidace serverů, pro desktop je to zatim naprd.
Web se třeba naopak od svého vzniku neustále přesouvá ze strany serveru na klienty.

[vlk]

Já bych řekl, že není ani potřeba tolik paměti. 640kB by mělo stačit.

[klusik]

To řekl B. Gates, ne?

[jv]

Ono to je nepravdiva 'legenda', ktorej ludia radi veria.

[pacholik]

to sem si taky myslel, ale jestli není legenda to že to je legenda ;)

[Sten]

Je legenda, že to řekl. Řekl totiž, že rozšiřují 64 KiB [limit 16-bitového počítače] na 640 KiB [paměť nad tou adresou byla vyhrazena pro ostatní zařízení, např. videokartu], což by mělo vystačit nejméně na deset let. Nakonec to nestačilo ani šest let

[Sten]

Ano, bude. U desktopů se projevuje to, že většinu času se ten výkon (který topí), neprojeví. Dnes se to řeší tak, že se v době potřeby vyššího výkonu prostě čeká, až to ten procesor uchroupá. Pokud ale budete mít 48 líných jader, která bude možné libovolně vypínat a zapínat, tak dojdete ke stavu, kdy v případě potřeby můžete (paralelní) výkon zvednout (komprese filmu, spouštění Excelu, ...), na druhou stranu většinu času tam prostě poběží jenom jedno (málo žravé) jádro. Samozřejmě to bude znamenat úplně předělat způsob práce jader operačních systémů a vůbec začít daleko více prosazovat paralelní programování (TBB by měly být součástí STL). Osobně si myslím, že tenhle přístup ještě zrychlí kvůli mobilům a netbookům, kde je každý watt výrazně znát, na druhou stranu čas od času je potřeba větší výkon (např. pro augmented reality)

[Sten]

A ještě mě napadá jedna vychytávka, která by se mohla hodit i pro současné aplikace: více různě výkonných jader, která lze nezávisle vypínat

[Jardík]

TBB neznám, ale v novém C++ standardu, který by tu měl být přiští rok, bude "podpora" threadingu.

[Sten]

Ono tam bude v podstatě to samé, co je v Boost Threads. Což je ale stále sekvenční přístup k řešení problémů, s tím, že se někde explicitně řekne, že to má řešit více vláken, a pak se explicitně řeší jejich synchronizace. TBB oproti tomu program rozděluje na jednoduché tasky zapojené do pipeliny, takže celé programování probíhá paralelně a díky tomu i výsledný kód dokáže běžet na mnohem více procesorech s nižší režií

[JS]

Ja jsem skodolibe zvedavy, kdy se podari paralelnimu programovani prizpusobit nektere ulohy, ktere chceme resit, zejmena ty, kde je nejaka interakce s uzivatelem.

[Radek Miček]

V takových případech lze použít speculative execution.

[Joelp]

že by se blížil kernel 3.0 (nebo aspoň 2.7) :D

[iq]

Myslis paralelne nebo seriove?

[alblaho]

No řekl bych, že více než Moorův zákon nás v budoucích letech bude zajímat zákon Amdahlův.

Problém je, že krom multimedií je to s paralelizací bledé. Start excelu rychlejší už nebude.

A paralelizačním knihovnám nevěřím taky, protože z toho by se programátor taky mohl zbláznit. Spíš bych to viděl na implicitní paralelizaci a transakční paměť (STM) ala Haskell.

[Ladicek]

Já na transakční pamět nevěřím, jsou to jen takové lepší zámky (a nutnost při velkém návalu transakci několikrát opakovat mi přijde pekelná), vůbec to neřeší ten principiální problém s přemýšlením o implementaci, ve které se ať už zámky nebo transakce používají ve více vrstvách. Jestli víš co myslím.

Implicitni paralelizace, to beru, ale jako směr výzkumu Z toho, co se už používá, se mi líbí čistě událostní přístup (ala Node.js) nebo komunikující procesy (ala Erlang). Přemýšlel jsem, jestli by se tyhle dvě věci nedaly nějak zkombinovat, ale na nic zajímavého jsem nepřišel.

[Radek Miček]

Já na transakční pamět nevěřím, jsou to jen takové lepší zámky

IMO hlavní výhoda STM je, že není tak náchylná na chyby. Navíc STM umožňuje skládat malé atomické operace do větších.

[Ladicek]

Jo. Takový mírný pokrok v mezích zákona Výkonnostní dopady si hodnotit netroufám.

[alblaho]

Já jsem zase skeptický k Erlangu (nebo k aktorům obecně). Je to dobré, když chceš napsat chat pro půl miliardy lidí. Ale jak chceš něco urychlit, když nemáš tu půlmiliardu entit, která si přímo říká o paralelizaci.

Nevím kde jsou limity STM a na jaké problémy ten Haskell už teď funguje a na jaké to nepůjde nikdy. Vím jen to, že tu paralelizaci musí řešit stroje.

Celkem vzato jsem pesimista. I když teď mě napadá, že lidský mozek má jen pár hlavních "vláken" a s tím vystačí*. Takové ty věci jako analýza 35Gbps co teče z oka dáme už dnes, protože to paralelizovat jde. A nebo budeme muset počkat na kvantové počítače.

*Podle nějakého blábolu na Slashdotu k němuž existuje N protiblábolů.

[pc2005]

No řekl bych, že více než Moorův zákon nás v budoucích letech bude zajímat zákon Amdahlův.

Problém je, že krom multimedií je to s paralelizací bledé. Start excelu rychlejší už nebude.

No teoreticky by mohl, jak se bude snižovat příkon obvodů a zvyšovat jejich složitost, tak se pak můžeme dostat do stavu, kdy bude všechno v NVRAM ramdisku, takže se Excel nebude načítat vůbec .

[Martin Mareš]

Amdahlův zákon ledaskdo cituje, ale přitom je to jen pavědecká konstrukce, která nemá s realitou nic společného. Je totiž postaven na předpokladu, že každá úloha se skládá ze dvou částí, z nichž jedna není paralelizovatelná vůbec, zatímco ta druhá libovolně.

Skutečnost je ovšem taková, že na téměř každý problém (výjimkou je třeba nalezení lexikograficky minimální z nejkratších cest v grafu nebo konstrukce DFS očíslování stromu) známe nějaký efektivní paralelní algoritmus, jen u různých problémů je režie té paralelizace různá (a to výrazně).

Jenže většina lidí, kteří dneska programují "vícejádrově", umí jenom vzít sekvenční algoritmus a paralelizovat v něm pár jednoduchých cyklů. To samozřejmě na většinu problémů nestačí, skutečné paralelní algoritmy obvykle k problému přistupují úplně jinak. Už od 80. let na to máme docela pěknou teorii, je na čase, abychom se jí inspirovali.

[Martin Mareš]

Implicitní paralelizace je krásná myšlenka, jen už 30 let nikdo neví, jak na to. V podstatě to jediné, co se umí, je triviální pattern matching, který vyhledává známé vzory v kódu a nahrazuje je známými paralelními algoritmy. Zbytek je slavný otevřený problém v teorii složitosti (P=polyLOGSPACE).

[Hynek (Pichi) Vychodil]

Jak tady čtu tuhle diskusi, tak na mě padá depka. Člověk by dostal pocit, že bude ještě dlouho trvat, než lidem dojde, že SMP není řešení a systémy s opravdu hodně jádry musí mnohem více vypadat, tak jak dnes vypadají clustery. To znamená architekturu NUMA. Zabijákem paralelního zpracování je sdílená paměť a zamykání. Vždyť už dnes se stačí podívat na všechny ty L1, L2, L3, L4, ... LX cache mezi výpočetním jádrem a RAM. Stačí se podívat na všechny ty spinning lock, problémy s poskakováním řádek cache mezi jádry už dnes. Message passing je řešení. Já vím, že transputery a occam jsou odstrašující příklad. Ale je potřeba si uvědomit, v jaké době to vzniklo a provedení bylo otřesné. Uklidňuje mě, že diskutující na ABCLinuxu nejsou výkvět světového vývoje ať už HW tak i SW. Problém je, že dnes výrobci HW přizpůsobují HW špatnému konceptu vývoje SW a vývojáři SW se musí potýkat s HW navrženým na špatný SW. Bude trvat ještě mnoho let a vyplýtvá se ještě mnoho miliard dolarů na vývoj a výrobu koncepčně zastaralých systémů jak na straně HW tak i SW. IT průmysl má hroznou setrvačnost. Message passing se na úrovni HW používá už dnes třeba například právě k invalidaci řádek cache mezi jádry. Jenže výrobci HW tyto věci musí držet transparentní pro zastarale napsané OS. Vývojáři o něco progresivnějšího OS se různými triky snaží tyto vrstvy prorazit a využít lépe HW, ale navenek to musí zase transparentně zakrýt pro zastarale napsaný SW. No a nakonec nejhůře dopadnou vývojáři SW, kteří se snaží prorazit všechen ten balast dohromady. Depresivní, ale naštěstí jsou jisté pozitivní deviace. Například jazyk Erlang a pokusy s jeho použitím na HW třeba s 1024 jádry. Je potřeba si uvědomit, že čím větší paměť tím pomalejší a není problém udělat sběrnici pro interprocesorovou komunikaci s řádově větší propustností než má přístup do globální RAM. Je to jen o změně myšlení, což se ale nakonec ukazuje jako největší překážka. Změnit stereotypy v myšlení lidí, změnit výuku programování a designu HW, změnit vývojové nástroje je nakonec ten největší problém. Že je IT progresivní odvětví, pche. Přechod od strojového kódu k ASM trval víc jak 20 let. Přechod od ASM k vyšším jazykům trval 20 let. Přechod od C k Javě trval dalších 20. Dalších 15 let trvalo než si alespoň někteří lidé uvědomili, že je to zastaralý koncept a některým to nedošlo dodnes. Dalších 20 let trvalo než alespoň část vývojářů přešla od Javy k vyšším jazykům byť nad JVM. Nejméně dalších 20 let bude trvat, než si lidé uvědomí že je zastaralá samotná koncepce JVM. Samozřejmě se tu bavím o mainstremu. LISP už tu máme od 60. let. Smalltalk od 70. let. Erlang je tu od 80. let. Podobně je to v HW. Jak dlouho bude trvat, než dojde ke skutečné multi core revoluci je ve hvězdách. Ještě ani nezačala.

[Ondrej 'SanTiago' Zajicek]

Člověk by dostal pocit, že bude ještě dlouho trvat, než lidem dojde, že SMP není řešení a systémy s opravdu hodně jádry musí mnohem více vypadat, tak jak dnes vypadají clustery. To znamená architekturu NUMA.

No a oni take tak vypadaji, alespon u AMD. Multiprocesorove (multisocketove) pocitace od AMD funguji jako NUMA uz pekne dlouho.

[Hynek (Pichi) Vychodil]

Ano, to je přesně to, o čem mluvím. Výrobci HW už to (rozuměj message passing, hierarchické paměti, izolované jednotky) dnes dělají, protože to ani jinak nejde. Jenže to pak stejně musí maskovat pro vrstvy nad tím, protože ty na to nejsou připravené. Stejně to, ale moc nepomáhá, protože to přinejmenším jde poznat na výkonu, takže se píší optimalizované algoritmy na cache, řeší se poskakování řádek cache mezi jádry a podobně. Přitom svět, fyzický svět, funguje úplně jinak. Výrobci SW to zdůvodňují tím, že takové programování je složitější. Blbost, sdílená paměť, zámky, mutexy, thready jsou složitější. Je to jen historický nános. Člověk dnes a denně žije a je zvyklý fungovat ve světě, kde žádná sdílená paměť neexistuje. Dnes a denně plánuje a koná (rozuměj vymýšlí a realizuje algoritmy), které fungují bez sdílení paměti a zámků. Dnes a denně, každému z nás nepřijde divné, že když chci vědět jestli osoba B, zná nějakou informaci, tak se jí prostě zeptám a dovím se to až mi to odpoví. Celá lidská společnost funguje na tomto principu. Tenhle způsob "programování" je pro nás přirozený.

[m;)]

Grand Central Dispatch