Superpočítač Parallella (diskuse)

Diskuse byla administrátory uzamčena.

[Michal Fecko]

P.P.S. Všimněte si mé nové patičky .

While LED glows blue there is nothing to worry about.

[pc2005]

Ovšem nejlepší je ta jáma s robotožravými gekkony .

[mirec]

Ak by sa im podarilo v roku 2014 to 1K bola by to celkom pecka, na niektoré úlohy (ale aj tak tomu moc neverím). Reálne využitie však okrem rýchleho renderovania grafiky, seti ... nevidím. Bežné aplikácie sa nedajú len tak jednoducho rozsekať na viacej vlákien tak, aby bol rozdiel vo výkone markantný.

[pc2005]

Tak na obecné použití (kancelářské aplikace) stačí i skoro jednojádro.

[ovoce]

Jestli myslíte 1000 jader, tak to je odsouzené k nezdaru.

1) Potřebovalo by to nesmírně robustní propojovací logiku a přístup k datům (cache, sdílení, paměťové řadiče).

2) výkon neškáluje dokonale, ani zdaleka. Pokud fakt máte zájem psát ručně low-level kód, který by (zdárně!) dokázal rozkládat zátěž mezi 1000 jader, tak uděláte lépe, když použijete GPGPU. Dokonce byste si s tím asi našel slušnoupráci.

3) nikdo se nebude zahazovat s novou CPU architekturou, zejména když její upotřebitelnost je zabitá prvními dvěma body. Očekávejte nulovou softwarovou podporu. Ostatně jejich prezentace naznačuje, že software na to má jakože napsat nějaká komunita. Moc bych se divil, kdyby nějaká vznikla; těch pár chudáků, co to zkusí, moc lituju, že zmarní tolik času a možná peněz.

Takže jo, myslím, že byla chyba to koupit.

[pc2005]

Jj 1000 jader v SMP je prakticky nemožné. Už u cca 10 nastává škrcení přes společnou sběrnici. Jestli jsem to ale z nákresů tý parallelly pochopil správně, tak by to měla být síť, kde každý uzel bude mít svou malou operační paměť, takže posílat se budou jen výsledky.

Takže jo, myslím, že byla chyba to koupit.

To bylo na mě asi... To se ještě uvidí .

[dumblob]

Problem je, ze paralelnich programu je strasne po malu (mrkni na GNU nastroje a schvalne kolik jich bude paralelnich ). V GUI by to bylo velice prinosne, ale neznam zadnou knihovnu krome Fog, ktera by vykreslovala paralelne. Dokonce i dnes bezne pouzivane GUI frameworky casto nepouzivaji paralelismus (s tim uzce souvisi i prilis vysoka penetrace serializace dat - napr. X) a proto jsme svedky zasekavani apod.

Potrebujeme kvalitni jazyky, ktere maji zabudovany vysoce vykonny paralelismus a naucit programatory to pouzivat vsude kde to jenom lze (coz je kupodivu mnoho pripadu). Dnes se procesy a i vlakna povazuji porad za tezkopadne a pomale (spusteni a uklizeni je narocne jak pro programatora, tak pro operacni system). Porusit tento fenomen se snazili kluci z Googlu s Go, ale penetrace je take minimalni . Jinak treba v C je paralelismus az od C11.

Je to proste beh na dlouho trat a nyni takto vysoce paralelni procesor je vhodny pouze pro specialni pouziti, jinak bude jeho vykon nevyuzit (degradovan) . Ano, vim, ze k Parallelle dodavaji vlastni kompilator C, ale co s tim nadelas, kdyz tento nebude schopen automatizovane paralelizovat jiz existujici zdrojaky (napr. BSD, GNU apod. utility).

Jednoduse receno je to vhodne pouze pro nove aplikace a obeznamene vyvojare v C, coz jsou dva IMHO zasadni predpoklady, ktere splni naprosto minimalni mnozina vyvojaru .

Kazdopadne preji co nejvice zabavy az ti to dorazi za par mesicu domu! Napis pak nejaky blogpost co a jak to (ne)umi.

[w4rr10r]

Potřebujeme víc Lispu.

[pc2005]

Jo některý GNU nástroje by paralelizovat bylo dobrý, ale zase se říká: "nešahej na to, co funguje". Osobně používám vědomě jen make -jX. To s tím malým paralelismem je ale imho způsobeno tím, že je prostě malý počet jader. I já jsem měl donedávna jen jednojádro a aby měl někdo doma třeba desítky jader, to je takřka nereálné (už jen proto, že koupitelná x86 jich tolik zatím nemá). Tohle chce imho ta Parallella změnit (a tedy naučit paralelně programovat). Každopádně mě jde hlavně o ty ARMy v Zynqu .

Blog napíšu (pokud to teda dorazí, doufám, že jsem nezmotal tu bankovní platbu).

Jinak paralelizace v současné době neparalelních aplikací by měla fungovat. Koneckonců přesně to dělá superskalarita v P5+ jádrech.

[dumblob]

No, dvou a vicejaderne procesory v uzivatelskych stanicich mame jiz dost dlouho na to, aby vsechny nove aplikace byly psane paralelne. Coz se nedeje, a proto bych nevidel chybu v nedostupnosti HW.

Kazdopadne superskalarita je pouzitelna u rekneme az ctyrnasobnych vypocetnich jednotkach, ale urcite ne v pripade 64, kde bys routovanim jednotlivych instrukci (nebo pouze jejich casti) znacne ztratil na frekvenci (casto by se cekalo NOPama na mnoho nedokoncenych instrukci a nebo jejich casti) a cela rychlost vypoctu by sla do kytek.

Tam se fakt bude muset predem alespon zhruba naplanovat na kterem z tech 64 jader co pobezi (a nebo nejjednoduseji: proste to prenechat na planovaci v OS tim, ze si pustim vice vlaken nebo dokonce procesu).

[pc2005]

Mnohovláknové aplikace se na 2-8 jádrech píšou dost blbě a stejně to je prakticky časově multiplexovaná záležitost. To kdyby člověk měl třeba 1000 jader (nebo aspoň stovky = víc jader než má procesů a vláken), takby to začalo být zajímavý. Ale určitě ne na SMP.

Ta superskalarita byl příklad, že to jde, dokonce procesorem (tedy, že i v obyčejným programu je tuna paralelizovatelného kódu).

No podle toho obrázku to vypadá, že linux poběží na těch dvou ARMech v Zynqu a to Epiphany pole bude výpočetní koprocesor, asi jako výpočty na GPU, takže tam úlohy OS asi nepojedou, ale třeba bitcoiny by těžit šly.

[Člověk z Horní Dolní]

Funkcionálně programovat jde i v Cčku...

[Člověk z Horní Dolní]

Pardon, tohle měla být odpověď na http://www.abclinuxu.cz/blog/GardenOfEdenConfiguration/2012/10/superpocitac-parallella/diskuse#6

[w4rr10r]

Je to asi jako škrábat se na koulích přes záda.

[Člověk z Horní Dolní]

Pravda, ale ten Lisp paralelní programování taky nějak zvlášť neulehčí. Zaprvé nemá pure funkce (nějaká varianta Lispu teoreticky možná jo, ale...) a zadruhé, paralelní funkcionální algoritmy jdou pohodlně naprogramovat prakticky ve všech jazycích, které mají lambda funkce.

[w4rr10r]

Líp se ladí.

[Člověk z Horní Dolní]

Podle mých zkušeností ne...