abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 13:22 | Nová verze

Vyšla nová verze 3.1.15 softwaru ISPConfig, který slouží pro poloautomatickou konfiguraci hostingového serveru přes webové rozhraní. Největší novinkou je podpora antispamového systému Rspamd, který by měl poskytnout lepší výkon a snížit komplexitu systému sjednocením celého antispamového řešení do jednoho démona. K dispozici je také manuál na přechod ze stávajícího antispamového systému Amavis + SpamAssassin.

Harvie.CZ | Komentářů: 0
dnes 09:00 | Komunita

Richard Stallman, zakladatel hnutí svobodného softwaru, projektu GNU a Free Software Foundation (FSF), rezignoval na funkci prezidenta FSF i člena její správní rady. Rada začne okamžitě hledat nového prezidenta. Další informace budou zveřejněny na stránkách FSF.

Ladislav Hagara | Komentářů: 153
dnes 05:55 | Komunita

Vývojáři linuxové distribuce CentOS oznámili, že nová stabilní major verze 8 této distribuce bude vydána příští týden 24. září. Red Hat Enterprise Linux 8, ze kterého CentOS 8 vychází, byl vydán v květnu. Dle aktualizovaného plánu je CentOS 8 již téměř připraven. Práce na vlastním vydání byly ale přerušeny, poněvadž se vývojáři soustředí na vydání CentOSu 7.7 vycházejícího z Red Hat Enterprise Linuxu 7.7.

Ladislav Hagara | Komentářů: 5
dnes 04:44 | Nová verze

Byla vydána nová verze 6.3.0 správce digitálních fotografií a videí digiKam (digiKam Software Collection, Wikipedie). Přehled novinek i s náhledy v oficiálním oznámení. Vývojáři zdůrazňují plugin GMic-Qt. Nový digiKam je ke stažení také jako balíček ve formátu AppImage. Stačí jej stáhnout, nastavit právo ke spuštění a spustit.

Ladislav Hagara | Komentářů: 0
včera 15:55 | Zajímavý projekt

Evropská kosmická agentura (ESA) s nadací Raspberry Pi vyhlásily další ročník soutěže pro studenty s názvem European Astro Pi Challenge o co nejzajímavější využití počítačů Astro Pi, tj. Raspberry Pi s rozšířením Sense HAT, na Mezinárodní vesmírné stanici (ISS). Pro inspiraci vítězné projekty z 2018/2019.

Ladislav Hagara | Komentářů: 2
včera 12:00 | IT novinky

Společnost PINE Microsystems oznámila, že vedle miniaturních jednodeskových počítačů ROCKPro64, ROCK64, PINE H64 nebo PINE A64, notebooků Pinebook a Pinebook Pro, tabletu PineTab, chytrého mobilního telefonu PinePhone nebo IP kamery CUBE, vyvíjí také chytré hodinky PineTime. Jejich cena by měla být 25 dolarů.

Ladislav Hagara | Komentářů: 28
včera 05:55 | Nová verze

Po 10 týdnech vývoje od vydání Linuxu 5.2 oznámil Linus Torvalds vydání Linuxu 5.3 (LKML). Přehled nových vlastností a vylepšení na stránce Linux Kernel Newbies. Nově je například povolen síťový rozsah 0.0.0.0/8. Kódové jméno Linuxu 5.3 zůstává Bobtail Squid.

Ladislav Hagara | Komentářů: 2
včera 04:44 | Komunita

Mozilla nabídne firmám placenou podporu Firefoxu. Cena by se měla pohybovat okolo 10 dolarů za podporovanou instalaci.

Ladislav Hagara | Komentářů: 29
13.9. 22:00 | Nová verze

Po roce a čtvrt od vydání verze 12.0 byla vydána verze 13.0 zvukového serveru PulseAudio. Přehled novinek v poznámkách k vydání. Zmínit lze například podporu Dolby TrueHD a DTS-HD Master Audia.

Ladislav Hagara | Komentářů: 2
13.9. 16:33 | Zajímavý projekt

Blockchainový projekt Tezos nedávno prošel procesem hard-forku a zrodil se nový projekt Dune Network. Držitelé XTZ tokenů si již bezpečně mohou vyzvednout své DUN tokeny a delegovat je na nějakou z veřejných Dune baker služeb jako je třeba Dune Whale.

Mark Stopka | Komentářů: 9
Kdy jste naposledy viděli počítač s připojeným běžícím CRT monitorem?
 (21%)
 (3%)
 (11%)
 (34%)
 (29%)
 (2%)
Celkem 146 hlasů
 Komentářů: 15, poslední 15.9. 16:45
Rozcestník

Programovací jazyk pro 256 jádrový procesor

20.8. 12:02 | Přečteno: 2726× | Výběrový blog | poslední úprava: 20.8. 13:03

V poslední době se tady dost debatuje o různých aspektech různých jazyků, proto využiju tuto příležitost pro další téma. Na trhu se začínají objevovat 64 core / 128 thread CPU a nebude dlouho trvat a zcela běžně budou dostupné 256 core / thread CPU. Do pár let to máme na stole. A nastává otázka, jak pro tyto cpu programovat.

Přístupů k multiprocesingu je celá řada. Nejjednodušší a nejtradičnější způsob je programovat malé singlethread programy, které lze snadno řetězit. Klasický UNIX přístup, na kterém není nic špatného. Pro použití těchto programů existuje celá řada "lepidel" jako xargs nebo parallel pro spuštění jednoho programu nad hromadou souborů. Nebo použití pipe. Pomocí jednoduchých skriptů můžeme oba přístupy snadno kombinovat, pokud to charakter dat a jejich zpracování dovolí.

Co se týče podpory multiprocesing (nebo multithreading, budu to volně zaměňovat) přímo v programovacích jazycích, tady je situace horší. Ano, v klasickém C máme fork() s tím, že si všechno (výměnu dat mezi procesy, zámky apod musíme pohlídat sami). Některé jazyky (Python) jsou vyloženě singlethread. Ne, že by nešlo programovat ve více vláknech, ale v základu všechno dost komplikuje GIL (global interpreter lock). Existují snadno použitelné knihovny, které to různými způsoby obcházejí (Multiprocessing). V Golangu máme gorutiny a kanály. V Rustu máme threads a message passing. Ale je tohle opravdu způsob, jak snadno napsat program pro 256 jader?

O co mi jde a tak trochu zopakuju jeden ne moc povedený dotaz, který jsem měl nedávno pod nějakým blogem. Proč neexistuje jazyk, který by multiprocesing řešit sám bez zásahu programátora? Když uvedu příklad z pythonu, tak v pythonu máme list comprehension, což je udělátko, které na vstupní seznam aplikuje nějakou fci a výstupem je opět seznam:
output = [f(item) for item in input]
Problém je, že jak celý vstupní, tak celý výstupní seznam se musí vejít do paměti. Tenhle problém se řeší pomocí generátorů a od toho máme generator comprehension:
output = (f(item) for item in input)
Pokud máte pocit, že to až na použité závorky vypadá úplně stejně, je to tak. Drtivou většinu list comprehension lze přepsat na generator comprehension a všechno bude fungovat. Výhodou generátorů je to, že jsou lazy, že další prvek vygenerují až je potřeba, na rozdíl od listu, který je kompletní. To znamená, že pomocí generátorů můžeme generovat nekonečné seznamy a taky můžeme jako prvky používat objemná data (já to takto používám pro obrázky, jejichž celkový objem je výrazně větší než dostupná paměť a přes to s nimi můžu pracovat jako s jedním seznamem).

Zpět k tématu. Python poskytuje snadno použitelnou knihovnu (Multiprocessing.Pool) pro zpracování dat ve více procesech. Použití triviální:
output = Pool().map(f, input)
Toto nám vyrobí seznam stejně jako list comprehension, ale využije k tomu automaticky všechny dostupné procesory. Což je moc fajn, pokud se nám vstupní a výstupní data vlezou do paměti. Je to rychlé, snadné na použití a efektivní.

Bohužel neexistuje nic jako Pool generátor. Tj že by pro výrobu další prvků používat více procesů, ale nevygeneroval by celý výstupní seznam naráz. Držel by si několik předzpracovaných prvků k okamžitému výdeji. Ano, toto si lze napsat pomocí jiných prostředků a mít tak frontu požadavků ke zpracování a ty zpracovávat paralelně (což ve skutečnosti mám, ale nepovažuju to za řešení ale spíš jako workaround). Co by se mi líbilo by byl automaticky paralelní generator comprehension.

Nebo ještě lépe, jazyk, který od programátora vůbec nevyžaduje hint ve stylu "tady bude další thread" (tak jako třeba Golang i Rust vyžadují o C ani nemluvě). Prostě jazyk, který by sám dokázal generovat nezávislé úlohy a jejich závislosti, tak jak se třeba píšou pravidla pro Make (popis, jak vyrobit nějakou část dat a popis závislostí jednotlivých podúloh), dával si je do fronty a toto exekuoval na všech dostupných procesorech.

Je něco takového na obzoru? Vím, že existují speciální jazyky jako ERlang, ale v těch jsem nikdy nic "pořádného" napsaného neviděl. Ano, používá se s výhodou tam, kde je potřeba řídit komunikaci many to many (tj ejabberd nebo rabbitmq) a ty nic nepočítají a erlang se tam používá spíš jen pro výměnu zpráv mezi jednotlivými interními thready (kterých mohou být snadno miliony) a nikoliv pro paralelní výpočet čehokoliv.        

Hodnocení: 100 %

        špatnédobré        

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

20.8. 12:09 _
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
julia
Heron avatar 20.8. 12:51 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Mrknu. Nějaké příklady programů?
20.8. 12:36 /dev/null
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Pokial nebudu dostatocne rychle storage zariadenia (XXX GB/s aj pri sekvencnom a nahodnom pristupe a pri malych suboroch) budu nam velke pocty jadier nafigu (maximalne budeme operacie vykonavat v malej RAM)
20.8. 12:40 kuprexit | blog: bflmpsvz
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
je spousta úloh, kdy si člověk s ram vystačí
Heron avatar 20.8. 12:49 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
To samozřejmě závisí na typu úlohy. CPU bound úlohy jsou mnohem pomalejší, než úložiště. Když jsem si otestoval dvě asi nejčastější mnou prováděné úlohy z oblasti zpracování médií, tak jedna má rychlost cca 400kB/s per jádro, to znamená že na mém úložišti by hravě vytížila cca 850 jader (jasně, je otázka, zda by se to vešlo do paměti a zda by na přenos stačila sběrnice). A druhá je ještě pomalejší.
20.8. 12:55 luky
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
V C muzete pouzit OpenMP. Perl6 umi paralelismus out of the box - ctete https://docs.perl6.org/language/concurrency
⧠ A = 0 avatar 20.8. 13:01 ⧠ A = 0 | skóre: 8 | blog: Technokratovo_zrcadlo | Helsinki
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Když uvedu příklad z pythonu, tak v pythonu máme list comprehension, což je udělátko, které na vstupní seznam aplikuje nějakou fci a výstupem je opět seznam:
output = (f(item) for item in input)
Problém je, že jak celý vstupní, tak celý výstupní seznam se musí vejít do paměti. Tenhle problém se řeší pomocí generátorů a od toho máme generator comprehension:
output = [f(item) for item in input]
Nemáš to naopak?
Nevolte zmrdy.
Heron avatar 20.8. 13:05 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Jasně, opraveno, dík. Tj tak, když to po sobě 3x přepisuju a přehazuju pořadí odstavců.
20.8. 13:17 Cal | skóre: 6 | blog: CalBlog
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Pro nekoho prekvapujici odpoved je Java:
LongStream
                .range(1000000L, 1000000000000000000L)
                .parallel()
                .filter(num -> isMersennePrime(num))
                .findFirst();
Kod hleda prvni Mersennovo prvocislo nad 1 milion. Streamy jsou lazy, takze .range() postupne krmi retezec ostatnich metod, coz zaruci, ze se cely proces for nalezeni prvniho hned zastavi.

Volani .parallel() automaticky distribuuje praci do thread poolu, ktery ma pocet threadu stejny jako pocet jader. Single thread varianta je uplne stejna, jen vynechame to .parallel(). Duvod proc tohle musi byt explicitni je, ze koordinace threadu atp. ma znacny overhead a vyplati se jen od urciteho mnozstvi prace (coz musi usoudit programator).

Tohle reseni neni idealni, momentalne proto ze vsechny takove paralelni streamy pouzivaji stejny thread pool, ale ukazuje to jednu moznou cestu.
20.8. 13:19 /dev/null
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
A bude 256 jadier na Javu stačiť súdruhovia ?
Heron avatar 20.8. 13:23 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
To se teda Java od dob 5, kdy jsem ji opustil, dost změnila. Tohle je nějaké funkcionální rozšíření?
20.8. 13:38 Cal | skóre: 6 | blog: CalBlog
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Lambda funkce a streamy (vcetne paralellnich) umi Java od verze 8 (2014).
20.8. 14:58 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
To samé v Rustu s knihovnou rayon.:

    let result = (1000000u64 .. 1000000000000000000u64)
        .into_par_iter()
        .find_first(|num| is_mersenne_prime(*num));

příp. podobný kód se dá napsat v C++ s TBB.
22.8. 18:19 Rezervní Polská Kotace
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
+1
20.8. 14:00 Michal
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
C♯ plinq viz https://docs.microsoft.com/en-us/dotnet/standard/parallel-programming/introduction-to-plinq

Ja se ale obavam, ze to stejne resi pouze situace, kdy zpracovani tech jednotlivych prvku seznamu neovlivni zadny sdileny stav jinak to pri 256 threadech zabijou zamky. Smula je, ze az na nejake trivialni skolni priklady nejaky ten stav menit obvykle chces.

20.8. 14:27 /dev/random
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Neda sa cez QEMU nasimulovat 256/512/XXX CPU a ich spravanie ?
Josef Kufner avatar 20.8. 19:50 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Na málovláknovém CPU se to emuluje blbě a vždy to bude mít k realitě daleko.
Hello world ! Segmentation fault (core dumped)
20.8. 14:44 Cal | skóre: 6 | blog: CalBlog
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Smula je, ze az na nejake trivialni skolni priklady nejaky ten stav menit obvykle chces.
To si uplne nemyslim, ze vsechny ty nabusene hadoop clustery se pouzivaji jen na skolni priklady :-)
21.8. 11:25 Xerces
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
To ne. Ty tam jsou kvůli té Javě. :-)
20.8. 15:26 goldenfish | skóre: 38 | blog: aqarium | Praha
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
zdravim,

jak tady psal uzivatel Cal, tak specielne pro mne knihovny na Javu jsou a uz hodne davno.

Ac nemam rad lambda vyrazy, tak jsem je zacal diky paraelizaci vice respektovat.

Asi bych se nebranil nejakym anotacim, ktere by nejak rozdelovaly kod (fork, join) operace a byla by tam pak nejaka paraelizace automaticky. Treba na urovni for, while cyklu..... Asi se spatne vyjadruji.

Prozatim si vystacim s nejakymi Runnable, Thready a podobne. Ono ty paraelizace nedelate tak casto.

Po nejakych zkusenostech s 8, 16, 32 jadry, pripadne *2 thready mam spise obavy o toto:

- napisete krasnou ulohu, ktera perfektne vypocet paraelizuje. Skoncite na cteni nebo jeste lepe na zapisu do databaze/uloziste = zapis na disk. Lehce to zlepsite RAM-diskem, ale to neni moc reseni. Neco se da resit tak, ze ctete nebo zapisujete pouze jeden soubor v jeden cas.

- propustnost pameti. Kdo ma 32-core od AMD a neni to EPYC, tak vi o cem je rec.

- antiviry. Klidne 25% vykonu jde do haje.

- hodne bych se zamyslel nad tim, kolik uloh je mozne paraelizovat pro treba 15 a vice jader ?? Ono uz toho tolik neni a dostavame se k specializovanym aplikacim.

gf
Heron avatar 20.8. 16:01 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
jak tady psal uzivatel Cal, tak specielne pro mne knihovny na Javu jsou a uz hodne davno
Takže tu budoucnosti vidíte (množné číslo) jen v nových knihovnách? Jazyk ani paradigma podle vás není potřeba?
Ac nemam rad lambda vyrazy, tak jsem je zacal diky paraelizaci vice respektovat.
Mě funkcionální programování postihlo jen během studia a to setkání bylo takové zvláštní. Jednak se říkalo, že je to velmi snadno paralelizovatelné, protože funkce nemají žádné vedlejší efekty (což skutečně nemají) ale žádný interpret (tehdy scheme) nikdy nebyl multithreading. Já proti funkcionálnímu paradigmatu nic nemám, ale chtěl bych někdy vidět všechny jeho výhody v plné palbě včetně toho masivního paralelismu. Lamba funkce se v nefunc jazycích používají spíše jen jako syntaxe pro anonymní funkce. (Typicky, chcete předat něco filteru nebo mapu a nechcete dělat pojmenovanou fci, tak to napíšete jako lambdu.)
Asi bych se nebranil nejakym anotacim, ktere by nejak rozdelovaly kod (fork, join) operace a byla by tam pak nejaka paraelizace automaticky. Treba na urovni for, while cyklu..... Asi se spatne vyjadruji.
Jo, tomu rozumím a to jsem navrhoval už v předchozí diskusi. Mít v první fázi alespoň možnost udělat hint "tohle můžeš paralelizovat". V druhé fázi už by to měl jazyk poznat sám.
propustnost pameti. Kdo ma 32-core od AMD a neni to EPYC, tak vi o cem je rec
Jo. Možná dojde k tomu, že ryzen zůstane optimalizován spíš pro hry a epyc pro servery a workstation. Ty 32 core ryzeny jsou takové zvláštní.

hodne bych se zamyslel nad tim, kolik uloh je mozne paraelizovat pro treba 15 a vice jader ?? Ono uz toho tolik neni a dostavame se k specializovanym aplikacim
Proto si myslím, že musí dojít ke změně paradigmatu. Dneska se afaik až na nějaké speciality stále programuje tak, že se přímo určuje kde se to má forknout a co v tom vlákně má běžet. Tj se ručně alokuje určitá činnost do určitého vlákna. Proto jsem uvedl ty příklady, kde to prog vůbec neřeší.
20.8. 16:14 goldenfish | skóre: 38 | blog: aqarium | Praha
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Takže tu budoucnosti vidíte (množné číslo) jen v nových knihovnách? Jazyk ani paradigma podle vás není potřeba?

Kdyz jsme se bavili s Milou Ponkracem, tak rekl jednu peknou vec a to, ze paraelizaci bude casem sam resit kompilator.

Jak je to realizovatelne nevim. Zda se mi to jako nejlepsi reseni.

Co se tyce paralizace, tak zde hodne zavisi na architekture daneho programu. Kdysi jsem zacal psat jedno vetsi GUI formou tasku a nejakych zasilanych udalosti. Neverim moc tomu, ze takto zacnou programatori pracovat.

Paradigma se ujme za hodne let. Ze by prisel novy programovaci jazyk a rozsiril se masove, tak tomu moc neverim.
Heron avatar 20.8. 16:22 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Kdyz jsme se bavili s Milou Ponkracem, tak rekl jednu peknou vec a to, ze paraelizaci bude casem sam resit kompilator
Ano, to jsem poprvé slyšel možná taky už před dvaceti lety. Osobně bych na to příliš nesázel.
21.8. 05:43 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Řešení paralelizace kompilátorem je jediné možné skutečné řešení. Takové řešení byly a jsou, jen nikoli v mainstreamových jazycích.

Je to vlastně paradoxní situace. Hardware a elektronika jede raketově dopředu. Software: operační systémy a programovací jazyky proti tomu téměř stagnují. Rozevírají se čím dál více nůžky mezi neustále rostoucími možnostmi hw a slabými možnostmi dnešních programovacích jazyků.

Je jenom otázkou času, kdy to vynutí kvalitativní změnu programovacích jazyků.

***

Mimochodem, máme tu unix, který je myšlenkově a principiálně postaven na situaci před 50 lety. Máme tu programovací jazyky postavené na hw situaci několik desetiletí nazpátek: C/C++, Java, atd.

Asi byste prskali, kdyby jste měli počítač postavený na hw a protokolech 50 let starých. Nejspíše byste rozmlátili takový počítač o zeď.

Hw udělal obrovský skok dopředu, sw jen zlomečkový proti hw. Nízký pokrok v sw a programovacích jazycích je možný jen proto, že hw šel výkonově tak nahoru, že pokryje i neefektivitu programovacích jazyků a programátorů.

***

Maximálně efektivně dokáže u rozsáhlého systému paralelizovat pouze kompilátor. Programovací jazyky, které to umějí už existovaly, a jsou. A jednoho času se rozšíří i mezi mainstream.
Heron avatar 21.8. 08:29 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Řešení paralelizace kompilátorem je jediné možné skutečné řešení. Takové řešení byly a jsou, jen nikoli v mainstreamových jazycích.
Si fakt nejsem jist, zda je kompilátor to správné místo. Podpora ze strany jazyka tam být musí, ale podle mě by se na tohle mnohem víc hodil JIT a nějaké běhové prostředí. A spolupráce s OS.
Hardware a elektronika jede raketově dopředu.
Opravdu? Tenhle pocit fakt nemám. Frekvence CPU už hodně dlouho neroste. Rychlost výpočtů se řeší jinými způsoby. Jedno jádro dostává více ALU ke stejné sadě registrů, takže může vykonávat více nezávislých instrukcí současně. Totéž s FPU. Většina instrukcí už je ale 1T a nelze donekonečna měnit jejich pořadí. Proto se do CPU přidávají akcelerátory na všechno. Když už ani to nepomáhá, tak se udělá "inteligentní" cache (což potom vede k bezpečnostním problémům viz všechny problémy Intelu za poslední roky). Fakticky jedinou možností jak zrychlovat výkon CPU je vícejadernost. Jenže to opravdu za raketový pokrok nepovažuju.

Nehledě na naprostou nesmyslnost držení zpětné kompatibility až někam k ATčku. Tím máme v CPU módy, které tam nemají co dělat a přinášejí další bezpečnostní problémy.

Já očekávám koncepční změnu v tom, že místo CPU (central) bude DPU (distributed). Tj ze místo toho, aby se veškeré výpočty dělaly na jednom místě, tak např paměť dostane vlastní jednoduchý procesor, který bude umět dělat základní tranformace dat (přičti vzor, odečti vzor, xor apod) přímo na modulu, místo toho, aby se, jako dnes, každá stránka paměti posílala do CPU a zpět jen k vůli triviální transformaci. Totéž disk. Disk by mohl více spolupracovat s FS a místo neustálého posílání bloků tak a zpět by disk uměl sám udělat základní blokové operace (nebo proudové).
Josef Kufner avatar 21.8. 11:16 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
[…] např paměť dostane vlastní jednoduchý procesor […]
Ten už tam je. Jmenuje se řadič DMA. I když tedy těch transformací umí jen pár.
Hello world ! Segmentation fault (core dumped)
21.8. 11:31 Xerces
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
doplním ... kvantové počítače v nedohlednu :-D
Heron avatar 21.8. 12:09 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Na kvantové počítače nevěřím. Z toho nikdy nebude obecně použitelný procesor (v dnešním slova smyslu), max to bude akcelerátor pro vybrané přesně definované úlohy.

To spíš IMO dřív přijde použitelná spintronika, kdy hodnota bitu nebude zaznamenána pomocí náboje jako dnes, ale pomocí projekce spinu jednotlivých nábojů (schválně nechci říkat elektronů). A některé dílčí operace půjdou dělat pomocí manipulace spinů podobně jako existuje fotonika s manipulací polarizace.
21.8. 13:15 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
To je ovšem jen váš subjektivní a ničím než vašimi dojmy podložený názor.
21.8. 17:16 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Jen pro objasnění: Spintronika se už dávno používá. Kvantový počítač často také patří do spintroniky.
Heron avatar 21.8. 17:32 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
No to je otázka, kde se položí ta hranice. Svým způsobem je každý počítač kvantový, protože bez znalostí kvantové mechaniky by nevznikl ani první tranzistor. Přechody v polovodičích jsou kvantový jev.

Spintronika, stejně jako fotonika, využívá dalších kvantových vlastností přenášených částic. To ale neznamená, že se jedná o kvantové počítání. Kvantové počítání se většinou bere jako využití entanglovaných stavů a jejich superpozice apod. Ano, ty stavy mohou být klidně spiny. Ale to čistě ze spintroniky ještě nedělá kvantové počítání.

AFAIK čistý kvantový počítač dodnes nemáme. Máme stroje, jejichž výrobce moc chce na ně dát nálepku kvantový a čím víc qbitů, tím víc Adidas. A ty o něco málo skutečnější počítače jsou založené na několika málo provázaných mikrovlných squidech.
21.8. 19:17 Gilhad | skóre: 20 | blog: gilhadoviny
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
bez znalostí kvantové mechaniky by nevznikl ani první tranzistor nevim a mozna se pletu, ale nejak mi z mladi utkvelo v pameti, ze nekdo si hral s hrotovyma diodama, a kdyz dal dva hroty dost blizko k sobe, tak se mu to zaclo chovat "divne" a ovlivnovaly se navzajem, tak si s tim zacal hrat vic. A pochopeni, jak presne a proc presne prislo az po objeveni toho jevu, nikoli ze by ten jev byl nejdriv kvantove vypocitan a teprve pak se cilene provedla prvni demonstrace.

Cili, ze to byl objev typu, kdy newtonovi spadlo jabko na hlavu a on se nasledne zamyslel a prisel s teorii gravitace, nikoli objev typu, ze Mendelejev vymyslel tabulku, mel tam dirry, tak je pojmenoval treba eka-silicium a popsal, jak by se chovaly, kdyby byly a az pozdeji nekdo extrahoval germanium a zjistil ze tomu fakt odpovida ...

Ale rad se necham presvedcit, jak to bylo doopravdy :)
Heron avatar 21.8. 19:43 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
s hrotovyma diodama
Jenže ani dioda by bez kvantovky nevznikla. Je pravda, že jistý pan Schottky (ano, ten, po kterém je pojmenován jeden z druhů polovodičových diod) (a doufám, že si to jméno nepletu s jiným známým) na to přišel intuicí, ale obecně jiné druhy diod vznikly aplikací kvantové mechaniky a materiálové fyziky.

Taky je zajímavé, že hned na počátku vznikly oba hlavní druhy tranzistoru (řízený polem a bipolární). Tuším, že nejdřív to vypadalo na velký úspěch pro FET, ale velice rychle převzal štafetu BJT až opět došlo na FET (mluvím zejména o použití pro výpočetní techniku).
Cili, ze to byl objev typu, kdy newtonovi spadlo jabko na hlavu
Tohle je pohádka. Newtonova gravitace nevznikla jednou událostí někde v sadu, i před Newtonem se zkoumal pohyb a hledal se pro to matematický aparát. A v podstatě to šlo přidáváním dalších derivací (i když to tak ti lidé nenazývali). Nejprve (tisíc let před letopočtem) se někteří lidé domnívali, že každý předmět má svoji určenou polohu do které se prostě dopraví (nějak). Potom si někdo všiml, že se ale předměty přece jen pohybují a snažil se najít popis pro ten pohyb. První derivace dráhy je rychlost. A tuším že už někdo před Newtonem do toho strčil další derivaci, tedy zrychlení. A Newton to potom uhladil a uvědomil si, že by takto šlo popisovat i pohyb planet. Tehdy byly už velmi dobře měřené dráhy planet, byla známa Keplerovská elipsa a Newton to z toho prostě odvodil.

Takže, práce jak na kostele, vymyslel si k tomu matematický aparát, který posunul jak matematiku, tak fyziku, ale rozhodně to nevymyslel celé sám na zelené louce. Každý objev stojí na objevech předchozích a kdyby to nevymyslel on, tak to vymyslel někdo jinej (třeba takovou speciální relativitu ve skutečnosti ještě přes Einsteinem napsal Poincaré a určitě i Lorentz, ale teprve šutr tomu dal správnou fyzikální interpretaci a našel správný invariant (rychlost světla)).

Fakt to nejsou samostatně stojící jednotky. Bohužel, výuka ve školách má tendenci spíše vypichovat osobnosti a nikoliv metody, jak se k nějakému objevu došlo.
Heron avatar 21.8. 19:53 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Jinak na matfyzu probíhá každoročně vynikající cyklus přednášek Fyzika jako dobrodružství poznání a Filozofické problémy fyziky, je to připravené pro širokou veřejnost ale určitě to není vůbec banální, ba naopak. Start třeba zde. Bohužel, na tomto kanále LLion nemá na toto playlisty, takže se to tam válí mezi mnoha dalšími tématy (zejména Sisyfos a Pátečníci, obé samozřejmě doporučuju). Ale tyhle cykly jdou de facto od pazourků až po kvantovou teorii pole.
Bystroushaak avatar 21.8. 21:00 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Jenže ani dioda by bez kvantovky nevznikla. Je pravda, že jistý pan Schottky (ano, ten, po kterém je pojmenován jeden z druhů polovodičových diod) (a doufám, že si to jméno nepletu s jiným známým) na to přišel intuicí, ale obecně jiné druhy diod vznikly aplikací kvantové mechaniky a materiálové fyziky.
Elektronkové diody se používaly před tím a podle wikipedie byl ten objev asymetického toku proudu detekován Ferdinandem Braunem v roce 1874.
Heron avatar 21.8. 21:20 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Elektronkové diody
Jistě, nikdo netvrdí, že ne. Řeč byla o polovodičích.
objev asymetického toku

No a co tím chceš říct? Ano, polovodivost některých materiálů byla známá i před tím, stejně jako třeba i závislost na osvětlení. Ale cíleně to vyrobit a vědět proč a jak je zcela jiná disciplína. Stejně jako magnetismus byl znám a využíván hodně dlouho před Ampérem a Maxwellem, kteří tomu dali tu první správnou interpretaci.
22.8. 00:28 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
že hned na počátku vznikly oba hlavní druhy tranzistoru

Nám to na škole říkali tak, že FET byl teoreticky známý před BJT, ale protože nešlo vyrobit dost čistý křemík bez vad mřížky, tak první reálná součástka vznikla až po BJT... První funkční teda - FET se zabudovaným kanálem, který nejde vypnout, je dost k ničemu.
Quando omni flunkus moritati
25.8. 12:53 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Podle wikipedie: patent na FET 1925, 1947-1948 patent na BJT a první vyrobená součástka (první zkusili FET a nefungovalo jim to), první FET 1959. Takže to nevypadá, že by hned na počátku vznikly oba hlavní druhy...
Quando omni flunkus moritati
Josef Kufner avatar 21.8. 21:55 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Legendy praví, že když se tehdy snažili vyrobit polovodičový tranzistor, tak zkoušeli různé materiály a pořád to nechtělo fungovat. Až najednou, jedno dne to fungovalo a nevěděli proč. Následně zjistili, že jeden kolega při výrobě svačil, vzorek kontaminoval a funkční tranzistor byl na světě.
Hello world ! Segmentation fault (core dumped)
Heron avatar 21.8. 22:09 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Já jsem slyšel legendu, že to polili vodou. Nebo že to bylo špatně vysušené. :-)
21.8. 13:28 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Opravdu? Tenhle pocit fakt nemám. Frekvence CPU už hodně dlouho neroste. Rychlost výpočtů se řeší jinými způsoby. Jedno jádro dostává více ALU ke stejné sadě registrů, takže může vykonávat více nezávislých instrukcí současně. Totéž s FPU. Většina instrukcí už je ale 1T a nelze donekonečna měnit jejich pořadí. Proto se do CPU přidávají akcelerátory na všechno. Když už ani to nepomáhá, tak se udělá "inteligentní" cache (což potom vede k bezpečnostním problémům viz všechny problémy Intelu za poslední roky). Fakticky jedinou možností jak zrychlovat výkon CPU je vícejadernost. Jenže to opravdu za raketový pokrok nepovažuju.
Za prvé já mluvil o elektronice a hw, ne pouze o procesoru.

Za druhé frekvence ani zdaleka není jediné co byste měl sledovat, když hodnotíte pokrok.

Za třetí procesory udělaly snad úplně všechno, co je možné k maximálnímu single thread výkonu. Další zvyšování single thread výkonu půjde jen po troškách. Výrazné zvýšení výkonu už je možné jen paralelizací. Jenže na to dnešní programátoři a programovací jazyky nejsou jaksi připraveni moc dobře.

---
Nehledě na naprostou nesmyslnost držení zpětné kompatibility až někam k ATčku. Tím máme v CPU módy, které tam nemají co dělat a přinášejí další bezpečnostní problémy.
O tom přesně mluvím. Současné operační systémy (zejména unix), současné mainstreamové programovací jazyky a současný PC standard - vyžadují aby hw emuloval mnoho věcí, které jsou zbytečné.

---
Já očekávám koncepční změnu v tom, že místo CPU (central) bude DPU (distributed). Tj ze místo toho, aby se veškeré výpočty dělaly na jednom místě, tak např paměť dostane vlastní jednoduchý procesor, který bude umět dělat základní tranformace dat (přičti vzor, odečti vzor, xor apod) přímo na modulu, místo toho, aby se, jako dnes, každá stránka paměti posílala do CPU a zpět jen k vůli triviální transformaci.
To už tu v minulosti bylo a neosvědčilo se to. Například Amiga se až neskutečně podobala tomu, co očekáváte.

Dále to naráží na to, že se sw firmy i programátoři zvysoka vykašlou na to psát pro různé architektury různé verze programů. Zde chybí hlavně ten programovací jazyk, který by tu paralelizaci podporoval. Bez toho se celý hw/sw nepohne dál, a bude to celé viset na single thread výkonu.

---
Totéž disk. Disk by mohl více spolupracovat s FS a místo neustálého posílání bloků tak a zpět by disk uměl sám udělat základní blokové operace (nebo proudové).
Jenomže mu vadí třeba unix. Unix, který disk považuje za blokové zařízení, a file system chce řešit nezávisle na ovladači blokového zařízení. V tomto asi nejvíce překáží nedomyšlenost unixu.
xkucf03 avatar 23.8. 13:16 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Jenomže mu vadí třeba unix. Unix, který disk považuje za blokové zařízení, a file system chce řešit nezávisle na ovladači blokového zařízení. V tomto asi nejvíce překáží nedomyšlenost unixu.

Ona je to zároveň silná vlastnost, protože díky těmto abstrakcím je možné vyměňovat a kombinovat různé vrstvy nezávisle na sobě, aniž by autoři těchto vrstev museli vědět, co bude pod nimi a nad nimi v době použití. Jestli si uživatel ty vrstvy nakombinuje vhodně nebo nevhodně, to už je na něm. Ale ten návrh právě dost promyšlený a flexibilní je.

Jasně, že když se vše zadrátuje napevno a na přímo propojí, tak se tím ušetří nějaký výkon, ale má to zase jiné nevýhody.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
Josef Kufner avatar 23.8. 13:38 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
A zrovna v tomto případě na "nedomyšlenost" vůbec ničemu nevadí, neboť to, že drivery k blokovému zařízení a nad ním umístěným file systémem běží na dedikovaném CPU, které má přímé fyzické napojení na to blokové zařízení, bude fungovat úplně v pohodě a ona jednoduchá půl století stará abstrakce je stále platná a funkční. Jediné co, tak scheduler musí vědět, že to CPU je specializované a má tam běžet to, co tam má běžet, protože pak nebude muset šoupat spoustu dat sem a tam.
Hello world ! Segmentation fault (core dumped)
xkucf03 avatar 23.8. 13:03 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Si fakt nejsem jist, zda je kompilátor to správné místo. Podpora ze strany jazyka tam být musí, ale podle mě by se na tohle mnohem víc hodil JIT a nějaké běhové prostředí.

To hledání té optimální cesty může být dost náročné a bude vyžadovat dostatečný vzorek dat. Může se to dít v rámci JITu, ale tu pracně nalezenou optimální cestu pak nechceš při ukončení programu zahodit. Takže by tam měla být možnost si ten stav uložit a příště ho už jen načíst. Ve výsledku to pak bude vypadat tak, že program nakrmíš vzorovými daty a necháš ho zahřívat – tomu se pak dá říkat „kompilace“ nebo to poběží těsně po klasické kompilaci v rámci vydání nové verze softwaru.

V podstatě to navazuje na myšlenku PGO (Profile-guided optimization), které je třeba v GraalVM.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
20.8. 16:18 goldenfish | skóre: 38 | blog: aqarium | Praha
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Jeste pridam jednu vec, na kterou nas svet neni moc pripraveny.

OK, zacneme delat v nejakych vetsich aplikacich paraelizace. Pak si muzete posilat zpravy napric aplikaci a servery.

Vypada to krasne. Ale pak zacinate resit nejake pridelovani zdroju. Prozatim CPU. Nekde se Vam zacnou kupit zpravy - treba na WebLogicu. A zpracovani zprav generuje nejake dalsi zpravy.

To, ze v jedne casti aplikace udelate paraelni zpracovani, tak v druhe casti muze dojit k nejakemu kolapsu.

A ted je otazka jak to resit a jakymi prostredky (aplikacne, sprava front,nejaka sprava zdroju webserveru, monitoring).
xkucf03 avatar 23.8. 13:18 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Reaktivní programování
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
20.8. 23:17 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
ale žádný interpret (tehdy scheme) nikdy nebyl multithreading.

Jak to ze nebyl? A co Schemik?!!! ;-] Asi to zkusim trochu oprasit a podivam se, jak to pojede na soudobem zeleze. ;-]
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
Heron avatar 21.8. 08:03 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Jenže já jsem u Vychodila studoval v roce 2002, tohle je z 2009 :-D
20.8. 15:51 dumblob | skóre: 10 | blog: dumblog
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Vzhledem k tomu, že se této oblasti věnuji již přes 10 let poměrně intenzivně, hodím sem mini přehled, který považuji za relevantní.

stará garda

  • prakticky všechny data-flow jazyky (ty mají paralelismus/konkurenci "zadarmo" inherentně),
  • velká část funkcionálních a logických jazyků,
  • Erlang (Erlang je IMHO s velkým odstupem nejrozšířenější jazyk mající "first class" podporu pro paralelismus včetně např. migrace běžící verze distribuovaného systému na verzi novou a to za plného provozu a při plném vytížení bez jakéhokoliv výpadku)

nová garda

Jinak drtivá většina přístupů a jazyků implementuje explicitní paralelismus, tedy více práce pro programátora a méně čitelný kód. Ale např. ParaSail a DawnCC a později snad i Red jsou zástupci implicitního paralelismu, což je dle mého budoucnost.

Jinak ještě malá hračka Spry pro Smalltalkisty (ano, myslím mj. i na Tebe Bystroushaaku :-)). Spry je aktuálně neparalelní, avšak s nenulovým potenciálem pro implicitní paralelismus trochu inspirovaný např. Dask pro Python.

Nějaké myšlenky jsou např. v https://github.com/daokoder/dao/issues/524#issuecomment-497068976 a https://github.com/daokoder/dao/issues/524#issuecomment-500064368.
Refundace za Windows 7 od Lenovo obchodníka - soud rozhodl, že je zákazník v právu!
Heron avatar 20.8. 16:04 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
To je matroš, díky.
Bystroushaak avatar 21.8. 16:00 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Jinak ještě malá hračka Spry pro Smalltalkisty (ano, myslím mj. i na Tebe Bystroushaaku :-))
Cool :) Spry jsem kdysi viděl, ale nějak mi na dlouho zmizelo z obzoru. Když si to tak teď čtu, tak se to hodně blíží tomu na co cílím s tinySelfem.
21.8. 17:30 dumblob | skóre: 10 | blog: dumblog
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Tak hlavní myšlenkou Spry (stejně jako Rebolu/Redu) je "neustálé hraní si s evaluací nad živým AST" (tohle jde dobře pouze u homoikonicitních jazyků) - tedy podpora různých "úrovní" evaluace (od "maker" přes různé úrovně "lazy/deferred/on-demand" evaluace až po "přímou okamžitou evaluaci". Viz. Spry Evaluation a Spry Words. Spry sice trochu napodobuje syntaxi Smalltalku a bere si nějaké implementační myšlenky, ale já v architektuře Spry vnímám hlavně Rebol/Red.

Umí tohle "provádění výpočtu neustálým hraním si s evaluací AST" i tinySelf (nedíval jsem se do zdrojáku ani nečetl dokumentaci, ale tinySelf nevypadá homoikonicitně, a tak očekávám spíše horší podporu pro "hraní si s AST")?
Refundace za Windows 7 od Lenovo obchodníka - soud rozhodl, že je zákazník v právu!
Bystroushaak avatar 21.8. 18:28 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Umí tohle "provádění výpočtu neustálým hraním si s evaluací AST" i tinySelf (nedíval jsem se do zdrojáku ani nečetl dokumentaci, ale tinySelf nevypadá homoikonicitně, a tak očekávám spíše horší podporu pro "hraní si s AST")?
V tinySelfu si momentálně s AST hrát moc nemůžeš, ale už jsem se nad tím zamýšlel a časem nejspíš zkusím nějaké experimenty. Jde si hrát s reprezentací objektů v paměti skrz mirrory, což tuhle vlastnost z malé části nahrazuje (můžeš měnit sloty a parenty a objekty, ale nemůžeš zatím měnit kód). Homoikonicita tam není, ale opět, rád bych se časem dostal na úroveň, kdy tam pro ní bude částečná podpora. Rebol mě částečně inspiroval v té myšlence "jazyka pro data", kde určitě jedna z vlastností, které chci je mít možnost vyplivnout objekty reprezentující nějakou informaci zpět do zdrojáku, který poté bude přenositelný na další počítače.

Celkově, tinySelf se pomalu blíží teprve prvnímu beta vydání a momentálně spíš odlaďuji bugy a přidávám podporu základních věcí do stdlibu, než že bych se věnoval složitějším věcem.
20.8. 17:22 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Asi je mým údělem být za skeptika, ale obávám se, že nějaký specializovaný jazyk, který vývojáře odstíní od úskalí paralelizace, bude prakticky použitelný jen pro velmi specifické úlohy, kde spolu jednotlivé thready téměř nekolidují a potřeba synchronizace je minimální. Když vidím, jaké šílenosti je občas nutné provádět v linuxovém síťovém stacku, aby fungoval rozumně i s větším počtem procesorů (přičemž větší nezřídka znamená už něco kolem šedesáti), nemyslím, že to půjde obecně nechat jen na překladači.
20.8. 17:34 Cal | skóre: 6 | blog: CalBlog
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Na kompilator to taky nevidim, ale urcita nadeje by mohla byt v runtime, ktery by dynamicky sledoval chovani aplikace a podle toho paralelizoval podle potreby. Hotspot v JRE dela ruzne runtime optimizace. Nebo mozna neco jako GCC PGO, ale tam by to bylo asi vic omezene.
20.8. 17:41 dumblob | skóre: 10 | blog: dumblog
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
V runtime to dělá např. ten Python Dask - a dělá to dost dobře (samozřejmě v rámci možností Pythonu - ty principy by ale pravděpodobně šly použít i na nějaké síťování v kernelu pro větší pakety či větší bloky).
Refundace za Windows 7 od Lenovo obchodníka - soud rozhodl, že je zákazník v právu!
20.8. 21:07 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Ironií osudu je, že kompilátor jazyka, který podporuje paralelizaci - má obrovské množství informací pro optimalizaci paralelizace. Snadno uvidí závislosti, může třeba odebrat synchronizaci a zámky mezi thready nebo částmi kódu, kde k žádnému konfliktu nedochází, může změnit obrovské množství věcí. Jako runtime už toho uděláte jen minimum.

Ale znovu, musí to být jazyk primárně paralelní - což není žádný z běžných mainstreamových jazyků.
20.8. 21:32 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor

Obávám se, že každý mluvíme o něčem jiném. Neměl jsem na mysli rozdělování na samostatné jednotky, které lze spustit paralelně, tam jazyk a překladač určitě mohou odvést hodně práce, ale v tom problém není. Pokud ty thready potřebují přistupovat ke společným datům, pak se už u desítek procesorů snadno dostaneme do situace, kdy je režie klasického zamykání neúnosně velká, takže obvyklé metody, které bez problémů zvládaly 4-8 threadů, prostě neškálují. Před pár lety jsem třeba dělal microbenchmark IPv6 routing lookupu v jádře 3.12 a už při ~60 paralelních threadech byl výsledek některých testů horší než kdyby ty dotazy byly serializované.

Opravdu dost těžko si dokážu představit, že by jazyk a překladač byly schopny řešit, kde není problém se spinlockem nebo atomickým counterem, kde se dá použít RCU, kde třeba per-CPU datové struktury a kdy je to prostě potřeba celé navrhnout od základu jinak. Spíš bych řekl, že prostor pro "paralelní jazyky" bude spíš tam, kde je na jedné misce vah cena za vývojáře a na druhé cena za hardware a elektřinu, ne tam, kde je potřeba jít s výkonem opravdu "na krev".

20.8. 22:01 Cal | skóre: 6 | blog: CalBlog
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Jo, no, ja tak nejak podvedome tyhle pripady vyrazuju, protoze uz mam dlouho zafixovane ze "shared mutable state" proste neskaluje a moc si nedokazu predstavit, ze by nekdy mohla bez nejakeho paradigm shiftu ve fyzice (i kvantova nelokalita je omezena rychlosti svetla).

IMHO jsou dve cesty - 1) transformovat reseni tak, aby SMS nevyzadovala (funguje jen nekdy) nebo 2) zmenit business requirements tak, aby reseni SMS nevyzadovala (kdyz se chce, tak jde vzdycky)
21.8. 00:35 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Znovu: Jazyky s podporou paralelizace existovaly, pár si jich pamatuji. Rozhodně bych šel do paralelizace tisíckrát raději s takovým jazykem, než s nějakým C/C++, Javou. Pythonem, apod.

Právě tam, kde je potřeba jít s výkonem na krev bych tisíckrát raději uvítal jazyk s podporou paralelismu. Pokud má kompilátor a linker jazyka k dispozici informace o paralelismu, může optimalizovat řádově lépe než programátor - a hlavně to dělá bezchybně.

Proč by jazyk a překladač nebyly schopny řešit mnoho problémů při paralelismu za programátora? Vždyť takové jazyky existovaly.

Dnešní programátor přemýšlí o threadech a jádrech v zásadě z pozice vnějších knihoven (ála pthread) a služeb operačního systému. Chápu, že pak je těžké si představit, co dokáže dobrý programovací jazyk, který má trochu vyšší podporu paralelismu než jen volání funkcí knihoven.
21.8. 05:11 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Jeden o koze, druhý o voze, … no nic.
21.8. 05:48 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Zřejmě byste si měl přečíst, co jste sám napsal.
21.8. 07:30 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Pan Kubeček má pravdu. Vy tu řešíte „mikrooptimalizace“ v jednom bodu časoprostoru, což díky principu lokality má svoje opodstatnění a je opravdu škoda, že současné překladače, když už máme procesory o deseti jádrech, to nedělají. Jenže je třeba podívat se dále, kdy režie soupeření procesoru o sdílené zdroje (cache, sběrnice, paměť) celou paralelizaci paralyzuje. Zastánci funkcionálních přístupů to neradi slyší, ale programy spouštíme, abychom měnili stav. Tedy problém není kód, ale data. Zcela konkrétně je to rozdíl mezi architekturou SMP a NUMA. Opět díky principu lokality dává smysl rozdělit prostředky (paměti, CPU) na menší části a hierarchicky je propojit. Abychom hierarchií nepopřeli paralelismus a ponechali si potenciál k růstu, tak nejvyšší úroveň hierarchie je řešena „peer-to-peer“ směrováním obvykle v čtyřrozměrné síti (počet rozměrů vychází z nutnosti někudy vést sběrnice a všechno to uchladit). Podobný princip najdeme jak ve větším měřítku (superpočítače), tak v menším (FPGA). Samozřejmě nic není zadarmo a tak výpočetní výpočetní výkon měníme za zpoždění v přístupu k datům. Tyto změny hardwaru vyžadují změny v softwaru. Přístup „čím víc jader, tím vyšší výkon“ lineárně nefungují. Tady ale lepší překladače nepomůžou. Tady jde o samotné algoritmy, které programu implementují. Tedy programátor se musí zamyslet a architekturu softwaru a výběr datových struktur a algoritmů tomu přizpůsobit.
21.8. 11:41 Xerces
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Tenhle problém v podstatě řeší některé databáze s dynamickou optimalizací plánovače dotazů, kdy pro stejný dotaz nad jinak velkými daty podle informací z indexů a například aktuální zátěží CPU jader zvolí jiné JOIN algoritmy, jestli dobře chápu o čem se tady hovoří.
21.8. 13:14 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Pan Kubeček nemá pravdu.

Upřímně řečeno, je to několik dní, co jsem zrušil můj závazek nepsal na abclinuxu.cz. A už přemýšlím, že to byla chyba. Hned na začátku jsem utrpěl setkání s kovaným přesvědčeným marxistou Davidem Kolibáčem, který měl tendenci házet do debat odkazy na jeden (neo)merxistický článek za druhým - a chtěl abych je snad bral vážně.

Teď zase pan Kubeček i pan petr_p si domýšlejí, co jsem chtěl napsal - a neumějí číst.

Myslím, že moje představa, že diskuse na abclinuxu.cz bude technická, a bude za něco stát, byl asi krutý omyl.

Já nejsem zastánce funkcionálních přístupů. Když mluvím o jazycích podporujících paralelizaci, nemám na mysli funcionální přístup.

Programátor se samozřejmě musí zamyslet. Ale můj názor je, že programovací jazyky musí v paralelizaci odvést maximum práce. A znovu: Takové jazyky existovaly a existují. Tím popírají celý váš příspěvek. Existují pro každou vámi zmíněnou architekturu.
21.8. 14:43 PetebLazar
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Jsou určité případy kdy paralelizace (či dokonce již pouhá computerizace) úlohy se ukazuje jako jasně nevhodné řešení. ;-)
21.8. 16:22 Miloslav Ponkrác
Rozbalit Rozbalit vše IBM computerizovala různé úlohy
Existují i reálně realizované příklady: Například firma IBM dodala své počítací stroje nacistům, aby mohli Němci rychleji likvidovat Židy a provádět holokaust Židů. Ta vytetovaná čísla u vězňů z nacistických koncentráků je id z databáze IBM. Dá se s černým humorem říci, že každý vězeň z nacistického koncentráku je chodící reklama na firmu IBM.
21.8. 16:52 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Jednoznačně to byla chyba, pravděpodobně vám blbě vyšla konjunkce smrku a borovice. Doporučuju vám ten závazek obnovit, čím dřív, tím líp.
Quando omni flunkus moritati
21.8. 21:58 johnyK
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
:-)

ale na druhou stranu se mohl pan Kubecek mirnit, stary je na to dost :-)
23.8. 11:16 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Upřímně řečeno, je to několik dní, co jsem zrušil můj závazek nepsal na abclinuxu.cz. A už přemýšlím, že to byla chyba.
Tak ještě než odejdeš, tak bys možná mohl konečně odpovědět v té vedlejší diskusi, které že platformy nemají uint16_t . Čekám už nějakou dobu, že se dozvím třeba něco novýho / zajímavýho o platformních specifikách C/C++.
xkucf03 avatar 23.8. 13:42 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Jazyky s podporou paralelizace existovaly, pár si jich pamatuji. Rozhodně bych šel do paralelizace tisíckrát raději s takovým jazykem, než s nějakým C/C++, Javou. Pythonem, apod. Právě tam, kde je potřeba jít s výkonem na krev bych tisíckrát raději uvítal jazyk s podporou paralelismu. Pokud má kompilátor a linker jazyka k dispozici informace o paralelismu, může optimalizovat řádově lépe než programátor - a hlavně to dělá bezchybně.

Výkon ale není jediné kritérium kvality a jediný cíl. V jednom programu můžou být části, kde je výkon důležitý, a části, kde na něm prakticky vůbec nezáleží a kde jsou důležité jiné věci. A teď je otázka, jak se k tomu postavit a který jazyk zvolit nebo zda ten program rozdělit na části a psát každou v jiném jazyce.

Pokud má kompilátor a linker jazyka k dispozici informace o paralelismu

Zrovna tyhle informace lze kompilátoru dodat i třeba anotacemi, makry nebo obalením do nějaké OOP abstrakce nebo funkce. Takže si myslím, že k tomu, aby programátor sdělil kompilátoru takové informace, nový jazyk není nutný.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
20.8. 18:59 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Moderní jazyky jdou cestou být co nejblbější, a vše dohánět knihovnami. Takové jazyky samozřejmě při paralelizaci pomohou jen velmi málo (tam patří i ten Python, Java a další).

Aby byl jazyk dobrý pro paralelizaci, je třeba ho takový od začátku navrhnout.

Není důvod, proč by programovací jazyk nemohl převzít všechnu nebo skoro všechnu zátěž na řešení paralelizace. Ale drtivá většina programovacích jazyků je navržena jako jednothreadová (C, C++, Java, Python, Ruby, atd.).

Takže souhlasím s tím, že jazyk primárně syntaxí i jinak navržený jako jednothreadový s drobnými dodatky pro mulithreading - není schopen vývojáře příliš odstínit od zátěže řešení paralelizace.

Je vlastně s podivem, že třeba i ta provařená Ada pomáhala a pomáhá s paralelizací mnohem více než drtivá většina dnešních jazyků.

Mimochodem, toto znáte: https://chapel-lang.org/
20.8. 19:15 Radovan
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
20.8. 18:12 Gilhad | skóre: 20 | blog: gilhadoviny
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
No a samozřejmě paralelizace pomůže i při samotném programování, nejen při překladech (změněná hlavička může být použita v desítkách souborů a jdou překládat nezávisle), ale hlavně v testování, kdy by testy mohly taky běžet paralelně a jen na konci to setřídit na ty, co prošly a ty co ne. Pokud by testy proběhly 30x,100x... rychleji, byl by menší opruz je spouštět - daly by se spouštět po každé drobné změně, nejen na větš celky - celkově by se vyplatily mnohem víc a tím by mohly pokrývat víc kódu lépe a vést ke kvalitnějším programům stejně jako k jejich rychlejšímu ladění/psaní
20.8. 23:12 R
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Na paralelnu kompilaciu a testy davno funguje "make -j cislo".
21.8. 01:50 Gilhad | skóre: 20 | blog: gilhadoviny
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Jasne, znam a pouzivam a pri instalaci v Gentoo jde navic pouzit i --jobs=x a --load-average=x a vesele to preklada a instaluje i vic baliku paralelne.

Jen jsem chtel poukazat i na jinou oblast, kde 256 core a paralizace prinese vyrazne vyhody oproti soucasnym procesorum (ten rozdil je velice zrejmy i mezi 1jadro/1thread a 4/4 s make -j a mezi --jobs=20 kdy vytizim nejen procesor, ale i IO a diky pameti se pak procesor nezastavi a neceka)

A rozvoj jazyku pouzivajicich masivnejsi paralelizmus IMHO prispeje i k rozvoji instrumentu tezicich z tehoz a vetsi vyuziti - proste se zase posune paradigma - v soucasnosti se skutecne hodne veci odehrava principialne jako singlethreadovych, i kdyz diky multitaskingu jich bezi nekolik naraz - 256core procesory by mohly prinest zmenu, kdy to nebude, ze se hafo singletheadu rychle strida na jednom procesoru (no dobre, s berlickama na 2, 4, 8), ale ze skutecne vic veci zacne byt tak nejak automaticky paralelizovanych (i kdyby se nasledne mely rychle stridat na jednom jadru).

Ono ostatne uz soucasne procesory zacinaji ukazovat, ze stavajici pristup ma sva omezeni a neskaluje dost dobre a tak se snad zase neco pohne :)

(co jsem tak zahlednul, tak vetsine her dojde dech uz pri 8 vlaknech, nebo i driv a vic jader uz efektivne nepomaha - a jelikoz to ted dost tlaci herni prumysl, tak bude muset na vicevlaknove zpracovani zareagovat a nasledne asi strhne s sebou i zbytek - stejne jako lepsi grafarny prinesly potrebu lepsich grafaren a nasledne i vypocty v nich, nejen zobrazovani - CGA, EGA, VGA jen pridavaly barvy a pixely, ale pak prisla i fyzika, 3D operace, mapovani povrchu na dratene kostry, svetelne odrazy atd atd ... a nasledne CUDA, bitcoinmining ....)
21.8. 05:15 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
kdy vytizim nejen procesor, ale i IO

Pokud chcete opravdu využít CPU, překládejte na tmpfs.

21.8. 07:57 Gilhad | skóre: 20 | blog: gilhadoviny
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
To bych potreboval jeste vic RAM, ten I/O peek je jen ze zacatku, pak uz to vazne prevazne na CPU. (az na uzka hrdla, kde se vsechno sejde v jednom bode, protoze zbytek zavisi jen na nem a pak se to zase rozebehne do sire). Az budu stavet dalsi pocitac (coz bude desktop nebo tower), tak to bude vypadat zase trochu jinak, ale ted pouzivam prevazne NB a potrebuju hodne disku a kdyz jsem ho kupoval, tak SSD byly jeste neunosne drahe. Ty I/O peeky jsou hlavne u pocatecniho cteni zdrojaku a rozbalovani archivu.

(ale s tim tmpfs jeste zkusim, jak by se to zmenilo - spousta mezivysledku se opravdu nemusi na disk skutecne ulozit - a pak zase smazat)
Heron avatar 21.8. 08:48 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
ale ze skutecne vic veci zacne byt tak nejak automaticky paralelizovanych (i kdyby se nasledne mely rychle stridat na jednom jadru)
V tohle doufám prakticky taky těch 20 let, od chvíle, kdy jsem se poprvé dostal k více procesorovému PC. Přesně jak píšeš, i multithread program na jednom single core cpu může být výhodou. Jenže tohle jde o dost pomaleji, než bych před těmi 20 lety čekal a spíše slyšíme výmluvy, proč to nejde a nikdy nepůjde - viz třeba situace kolem herních API. Tak dlouho jsme slyšeli, že hry nikdy nebudou multithread, až přišlo AMD Mantle a ukázalo, že to jde levou zadní.
jelikoz to ted dost tlaci herni prumysl
Je potřeba si uvědomit, že to tlačí jen díky aktuálnímu HW herních konzolí. Dokud měl prim Intel a konzole byly různé, tak to "nešlo" (viz předchozí odstavec). Ani DX neumělo moc multithreading. Potom přišlo AMD se svým Mantle a následně obě NextGen herní konsole měly AMD APU osmijádro a najednou to šlo. Tedy, kdyby tehdy někdo přišel s herní konzolí postavené na zázračném jednojádru, tak se obávám, že dodnes budeme mít hraní na PC totálně v zajetí málojaderných cpu s vysokým výkonem na jedno jádro.
21.8. 09:16 Gilhad | skóre: 20 | blog: gilhadoviny
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
No a ted ma AMD Threadripper a osmijadro je prekonane (OK, uz neni top a zanedlouho bude stezi mainstream), takze je sance ze se to zase nekam posune, protoze kdyz uz si kazdy hrac muze dovolit 24/48 procesor, a se stavajicim zvedajicim se rozlisenim i nejnovejsi grafarny stezi stihaji na nejvyssi detaily vsechny pi....ny, takze tady jde cekat v relativne kratke dobe jeste dalsi posun a rozliseni monitoru roste i v pricetnych cenach ...

... tak tu je HW, ktery je potreba vytizit a to zada reseni a asi bude potreba zase skalovat vys a co se jeste dalo nejak priohnout ze 2 therdu pro 8, to pro 48 uz asi priohnout nebude stacit (nemluve o tom, ze to urcite neni posledni slovo, kdyz se ted do CPU uz cpe vic chipu, tak jich tam pujde snadno nacpat jeste vic, protoze omezeni plochou kremiku a vyteznosti timto pristupem pada, zatimco vyssi frekvence uz dost narazeji na fyziku. Takze misto par MHz navic se prida par chipu navic a pocet jader naroste jeste nasobne a aspon uvnitr CPU uz to bude spis to DPU - stejne jako sveho casu vyrostl uvnitr CPU dalsi pocitac, misto nativniho zpracovani instrukci).

Takze za par let to asi zase "najednou pujde" :)

(Nemluve o tom, ze kdyz se z (blackbox zobrazovacu) VGA staly samostatne graficke akceleratory a pak zacly byt misto grafiky pouzivane pro vypocty, tak by me neprekvapilo ani kdyby casem z toho CPU vyhreznul distribuovany pocitac ven a zacal byt pouzivany i na teto urovni, nikoli jen jako blackbox CPU)
21.8. 13:38 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Je tu hw, který je potřeba vytížit. Ale to je věcí architektury operačních systémů, a věcí programovacích jazyků především.

Jednoho dne už to prostě takto dál nepůjde. Hw vychází maximálně vstříc, ale to jde jen od - do, protože architektury dnešních operačních systémů a dnešní programovací jazyky jsou tím limitem.

Hw by mohl najednou udělat mnohem větší skok, kdyby mohl počítat s tím, že mu sw vyjde naproti. Bohužel s tímto počítat výrobci hw nemohou, naopak velice mnoho křemíku padne na to, aby hw emuloval to, co koncepčně 50 let staré operační systémy a programovací jazyky čekají od hw.

Úzké hrdlo už je minimálně 10 let na operačních systémech a programovacích jazycích. Jednoho dne se to změní.
20.8. 21:10 Pavel Křivánek | skóre: 28 | blog: Kvičet nezávaznou konverzaci
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor

256 jader je zrovna takové divné číslo. Na manuální řízení je to moc a na pořádnou paralelizaci zase málo. Osobně si myslím, že bude převládat hybridní přístup a žádný jazyk tento problém univerzálně nevyřeší. Moc nevěřím tomu, že funkcionální a logické jazyky z masivní paralelizace dokáží skutečně těžit, ač k tomu mají teoreticky dostatečné předpoklady. V osmdesátých letech se věřilo, že Prolog je pro to jako stvořený, ale v praxi se ukázalo tak velké množství problémů, že i dnes aby člověk pohledal jeho paralelní implementaci.

A protože nakonec i 256 jader je málo, budete potřebovat mnoho takových strojů, což zase znamená nutnost je pokud možno transparentně řídit, spravovat, rozdělovat mezi ně zdroje a úlohy. Navíc je úloh, které si vyžadují paralelizaci, tolik různých druhů s odlišnými nároky, že ještě dlouho tohle kompilátory uspokojivě automaticky řešit nebudou.

Osobně jsem zkoušel třeba hloupočké experimenty se 128 samostatnými smalltalkovskými image, kde byla každá s každou propojena (takže přes 8 tisíc obousměrných spojení), přičemž díky proxy objektům a zasílání zpráv není z pohledu jazyka prakticky žádný rozdíl v programování takového systému oproti běžným programům. Ale přístup k návrhu programů pro takový systém je samozřejmě značně odlišný. Dokáži si představit i lepší podporu od jazyka. Třeba reference jako first-class objekty.

Tetris teaches that your successes disappear as soon as they happen, while your mistakes pile up until they kill you.
21.8. 00:28 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Prolog je jazyk, který řeší problémy vnitřně hrubou silou. Proto zklamal.

Funkcionální jazyky takovou paralelizaci v minulosti skutečně zvládly. Viz třeba paralelní LISP mašiny.

Mimochodem, i na dnešních 4jádrovém procesoru uděláte občas i desítky paralelních operací najednou. S pomocí SIMD instrukcí a dalšího.

Dnešní běžné jazyky jsou prostě hloupé. Jsou dělány primárně jako jednothreadové. Dříve byla řada jazyků, které s podporou paralelizace přímo v jazyce počítaly. Hodně to ušetřilo práci, kompilátor pak hodně optimalizoval a celá paralelizace byla o dost rychlejší, byť u paralelních aplikací je třeba trochu jinak přemýšlet.

20.8. 23:37 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
V minulosti jsem se tomu docela intenzivne venoval a trochu jsem ztratil iluze ve svetle zitrky.

Tech problemu, proc paralelismu nesplnil/neplni ocekavani, je rada.

Jednim z nejvetsich nepratel je Amdahluv zakon. A jelikoz rada uloh obsahuje nejake neparalelizovatelne casti (hodne casto I/O) ta mez, kdy ma jeste smysl pridavat nova jadra muze byt hodne nizko.

Dalsi problem je, ze ne kazda uloha jde dobre paralelizovat. Coz hodne zabiji i pristup, jak jsme zvykli o programech uvazovat. Udelej neco, pak udelej neco, jestlize neco, udelej neco. Psat program tak, aby sel automaticky paralelizovat vyzaduje uplne jiny mindset a pristup k programu. Je potreba nebat se vytvaret kopie dat, netrapit se tim, ze program provede vic operaci nez musi, atd.

(Jak spravne identifikovals) List comprehension, streamy v Jave, PLinq, map/reduce, Apache Spark a dalsi nejspis nastinuji vhodnou cestu, kudy se muze paralelizace vydat. Jsou to vlastne instance jednoho reseni, kdy mas (relativne) omezeny jazyk, kterym muzes deklarativne popsat, co se s daty ma stat.
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.
Heron avatar 21.8. 09:01 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
A jelikoz rada uloh obsahuje nejake neparalelizovatelne casti (hodne casto I/O) ta mez, kdy ma jeste smysl pridavat nova jadra muze byt hodne nizko.
To ano, ale tohle nejsou případy všech úloh.
Coz hodne zabiji i pristup, jak jsme zvykli o programech uvazovat. Udelej neco, pak udelej neco, jestlize neco, udelej neco. Psat program tak, aby sel automaticky paralelizovat vyzaduje uplne jiny mindset a pristup k programu.
Ano. A nejen v programování je někdy potřeba změnit mindset. A je to strašně těžké a přináší to spíš zklamání.
Jsou to vlastne instance jednoho reseni, kdy mas (relativne) omezeny jazyk, kterym muzes deklarativne popsat, co se s daty ma stat.
Přesně tak. Neříkat jak se to má udělat, ale co se má udělat. Ne že by to mohlo fungovat všude, ale budoucnost právě vidím v tom, že ve vysokoúrovňových jazycích přestaneme psát jak to má dělat krok za krokem, ale budeme popisovat výsledek. Ať si to udělá jak chce.

A jak píšeš, já vím, že Python není nejdokonalejší jazyk na světě, ale první setkání s list / generátor comprehension si budu pamatovat hodně dlouho. To, co se dřív psalo min na 4 řádky (s ifem na 6), je tady na jeden. Elegantně vyjádřené všechno podstatné (vstupem je iterable, výstupem je iterable, je tam jasná transformace prvků a je tam volitelný filter v podobě if).
21.8. 09:05 PetebLazar
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
U neparalelizovatelných(či hůře s jádry škálujích) algoritmů tu někdy zbývá možnost úlohu granularizovat. Vstupní data úlohy rozdělit na menší části, ty svěřit samostatný úlohám a výsledky z nich pak spojit.

Například z multimediálního souboru se svěří části stopáže jednotlivým instancím encodérů a jejich výsledky se spojí do jednoho souboru. Asi pro každý procesor/cache/mem_bandwith/IO by šlo prakticky stanovit míru této granularizace, kdy je dosaženo max. výkonu.

ad IO) Díky SSD/NVMe s jejich nízkými latencemi a vysokými sekvenčními rychlostmi lze dnes provádět úlohy v minulosti prakticky neproveditelné (například takto granulovaný encoding uncompressed video formátu).

Také růst velikosti cache/core snad v budoucnosti přispěje k rozšíření palety komplexnějších úloh, které je možné efektivně (z hlediska provádění) paralelizovat.
21.8. 06:45 pb.
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Paralelismus se dostává rychle i do klasických jazyků, sám pracuji v C++.

Jednak je to OpenMP, například:
#pragma omp parallel for schedule(static)
for (int i=0; i<size; i++) {
 ....
}
V kódu uvedeném výše se provede smyčka paralelně. Samozřejmě to znamená, že kód musí být nezávislý. Největší radost je ladit přístupy do cache - musí se pamatovat už při návrhu datových struktur na to, aby program z různých vláken nesahal do společných prostor. Klasickému programování shora dolů je tento přístup nejbližší.

V C++17 se mi pak líbí stl přístup, například:
std::for_each(begin, end, [](DataItem& data) {
    data.q4 = data.d * data.dt;
    data.a = data.v + data.w1 * data.q1 - data.w2 * data.q2 + data.w3 * data.q3 + data.w4 * data.q4;
    });
Podobně se dají programovat paralelní výpočty v Qt. Proti stl je ale výběr algoritmů chudší a na kontejnerech mi chybí úplně.

V každém případě není problémem malá podpora ze strany jazyků - určitě ne u C++, větší potíž je vývojář.
21.8. 16:30 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Vývojář ale řeší věci, které by u solidního jazyka s podporou paralelizace řešit nemusel. Jasně, že se dá paralelizace NĚJAK řešit i na mainstreamových (ideově single thread) aplikacích. Třeba s pomocí OpenMP nebo s pomocí toho, co dodává STL - ale pořád je to málo.

Sám jsem psal mnoho multithreadových programů různými způsoby. Jako z nouze ctnost se to vždy nějak zařídit dá z jakéhokoli jazyka.

Problém ovšem není vývojář, ten je nucen pouze nějak obcházet současný stav jazyků, u kterých je paralelizace jen nekonzistentní nalepovák. S lepšími jazyky, které paralelizaci vedou od prvního návrhu jazyka - ten vývojář u drtivé většiny paralelních problémů nemusí většinu věcí vůbec řešit.

Multithreadové programování je náročné: Jazyky na to nejsou připraveny. Pokud si vše děláte ručně, je velice snadné udělat chybu a nedomyslet to. A nedá se to ani rozumně debugovat, protože při debugování jsou jiné podmínky.
21.8. 18:31 pb.
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
...mnoho multithreadových programů různými způsoby...

Je něco jiného psát ve více/mnoha vláknech a něco jiného dělat paralelní výpočet.

Python v původním příspěvku a C++ jsou v možnostech zcela rovnocenné:
output = [funkce(item) for item in input]
odpovídá
std::for_each(begin, end, funkce);
Jen zápis v Pythonu může být omezený neexistencí lambda funkcí, ale to se dá udělat v pohodě jinak.

Jazyky jsou na paralelizaci připravené lépe, než programátoři. Školívám C++ (a rozhodně ne začátečníky) a žasnu, že se mi na kurzech sejde jen velmi málo lidí, kteří aspoň slyšeli o přístupu map-filter-reduce. Když se naučíte tímto způsobem myslet, tak třeba to zmiňované C++ vám z vašeho kódu velmi ochotně splácá paralelní aplikaci. Bobužel, strukturované, serializované algoritmy máme všichni velmi kvalitně vypálené do hlavy, do budoucích programátorů se tlačí už od mateřské školy. Je obtížné si osvojit jiné přístupy.
Heron avatar 21.8. 22:08 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Jen zápis v Pythonu může být omezený neexistencí lambda funkcí, ale to se dá udělat v pohodě jinak.
Python má lambdy taky.
Školívám C++ (a rozhodně ne začátečníky) a žasnu, že se mi na kurzech sejde jen velmi málo lidí, kteří aspoň slyšeli o přístupu map-filter-reduce.
No tohle asi postihuje každý obor. Já sice nejsem programátor (ani nechci být, jsem admin a sem tam, bohužel a s největším odporem, něco napsat musím) a žasnu taky. Což o to, jedna věc je žasnout nad tím, že někdo něco neví, druhá věc je ho to naučit. (Na pohovorech mě ani tak nezajímá to, co člověk umí teď, ale co bude umět za měsíc.) Bohužel se najdou lidé, jejichž neochota přijímat nové myšlenky je skutečně obdivuhodná. Naposledy dneska jsem někoho klepl přes prsty (za poslední rok snad po desáté), když použil v aktuálním linuxu příkaz route (se divím, že tam ještě vůbec je, tedy ten příkaz ;-)).

V jednom analyzátoru logů jsem použil map-filter koncept a potom jsem to chtěl někomu předat a vůbec to nepochopil. No nic.
C++ vám z vašeho kódu velmi ochotně splácá paralelní aplikaci
A to automaticky nějakou volbou kompilátoru nebo viz výše, třeba přes #pragma?
21.8. 22:46 pb.
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Python má lambdy taky.
Má konstrukci, kterou nazývá "lambda". Nejsem žádný velký odborník na Python, takže se můžu lehce mýlit. Nikdy jsem ale nedokázal v Pythonu napsat lambda funkci (ne jeden pouhý výraz, který se může v Python lambdě objevit) s případnými dalšími vnořenými lambda funkcemi. V C++ to naprostá samozřejmost.
Školívám C++ (a rozhodně ne začátečníky) a žasnu, že se mi na kurzech sejde jen velmi málo lidí, kteří aspoň slyšeli o přístupu map-filter-reduce.
Bavíme se v kontextu paralelního zpracování. Map-filter-reduce jsou základní používané postupy v paralelním zpracování a nad čím žasnu, je, jak málo lidí o těchto postupech ví. Strukturované programování, objektové programování a další metodiky jsou známé a nedělají vývojářům problémy. Paralelní postupy už tak zažité nejsou. Není to, že bych žasnul, že ti lidi jsou blbí, protože něco neví. Žasnu nad tím, že paralelní postupy jsou tak málo rozšířené a mezi lidem vývojářským prakticky neznámé. To je ten důvod, proč tvrdím, že slabým místem paralelního programování jsou vývojáři. Oni ti lidi, co si u mě školení zaplatí, tam nakonec jdou proto, aby se něco naučili - patří (snad) mezi ty aktivnější. Nějaké základy paralelního zpracování si ode mě odnesou a snad i zapamatují a později dokážou použít. Nevím.
C++ vám z vašeho kódu velmi ochotně splácá paralelní aplikaci
Je to součástí C++17. Používám GCC, tam asi dosud není podpora úplná (nevím, jak GCC 8.3). Ale dá se použít jmenný prostor __gnu_parallel místo std, funguje to velmi podobně. Je jen potřeba přilinkovat OpenMP.

Bystroushaak avatar 21.8. 23:07 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Má konstrukci, kterou nazývá "lambda". Nejsem žádný velký odborník na Python, takže se můžu lehce mýlit. Nikdy jsem ale nedokázal v Pythonu napsat lambda funkci (ne jeden pouhý výraz, který se může v Python lambdě objevit) s případnými dalšími vnořenými lambda funkcemi. V C++ to naprostá samozřejmost.
To jde, ale je to trochu zběsilé*. Co nejde je použít v lambdě return, nebo bloky. Důvod je, že bývalý benevolentní diktátor je prostě neměl rád: Language Design Is Not Just Solving Puzzles.

*:
>>> (lambda x: (lambda y: y)(x))(1)
1
Heron avatar 22.8. 10:19 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
benevolentní diktátor
A s ním lze jen souhlasit. Jazyk je trochu víc, než jen prostředek pro řešení problémů. Pokud někdo chce komplexní lambda kalkul, ať se mrkne třeba na Haskell.
22.8. 10:19 pb.
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Paralelní algoritmy jsou implementované od verze GCC 9.1. Netuším, kde jsem vzal 8.3, na počítači mám 9.2. Prostě už na mě bylo příliš pozdě. Těch nepřesností jsem uvedl více, syntax algoritmů se trochu liší - je tam navíc parametr, který říká, jak se má algoritmus provádět. Ale to asi není úplně podstatné.
22.8. 10:50 Kate | skóre: 9
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
V pythonu lze použít i output = map(funkce, input) jen je potřeba od pythonu 3 počítat s lazy evaluation, map vrací místo listu iterátor.

Lambda se dá samozřejmě použít.

Filter používám docela pravidelně, reduce se mi hodí méně často, ale functools ho zná.
Bystroushaak avatar 22.8. 11:09 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Filter používám docela pravidelně, reduce se mi hodí méně často, ale functools ho zná.
Proč používáš filter místo list comprehensions / generator expressions?
22.8. 11:49 Kate | skóre: 9
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Dobrá otázka a neumím na ni odpovědět. Zvyk? Možná mi to prostě pro ten účel přijde podvědomě výstižnější. Při pohledu na filter je hned jasné, že s ním chci filtrovat nějaký iterable a nechci s jeho obsahem dělat nic víc.

Je mi jasné, že comprehension je víc pythonic a BDFL chtěl z Pythonu odstranit i map, ale i tam mi přijde třeba pro konverzi obsahu listu map(int, list) úhlednější a stručnější než (int(i) for i in list))
Bystroushaak avatar 22.8. 12:23 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Já jsem to tak měl kdysi taky, všude jsem používal map/filter. Časem jsem začal komponovat složitější transformace a zjistil jsem, že se mi generator expressions hodí víc, nehledě na to že může kombinovat map i filter dohromady. Taky ti to šetří nutnost používat lambdy a podle všeho by to mělo být i rychlejší.
22.8. 12:30 Kate | skóre: 9
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
To rozhodně, jakmile je potřeba složitější transformace, nebo kombinovat map + filter, okamžitě přecházím na generator expression :)
21.8. 12:47 OldFrog {Ondra Nemecek} | skóre: 31 | blog: Žabákův notes | Praha
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
IMHO se paralelizace docela rozšiřuje:
  • GPU výpočty
  • optimalizátory v SQL databázích
  • parelelní renderování v prohlížečích
  • průnik lambd, workerů a agentních systémů do mainstreamových jazyků
  • mikroservices a cloudy co se týče infrastruktury
  • ...
Optimalizace kompilátorem má i svoje omezení, protože kompilátor neví, jak dlouho která operace bude při běhu trvat takže nedokáže vhodně balancovat úlohy vůči jádrům - čili podle mě musí být podpora i v runtime.

Jak už někdo řekl, paralelizace pro 256 jader vyžaduje mnohem víc než jen paralelizaci, je potřeba dostatečná propustnost celého systému a bude se to hodit jen pro určité typy úloh.

Určitě je co vylepšovat, na druhou stranu mi to přijde trochu jako akademické řešení neexistujícího problému. Resp. to téma je už delší dobu docela prozkoumané (procesory se spoustou jader tu byly už dávno), akorát se z toho teď stává mainstreamové téma. A jelikož mainstream a business geniální myšlenky vždy pošlape, zdeformuje a rozmělní, nečekám nic moc ani od této situace - spíš jen pozvolný progress v mezích zákona.
-- OldFrog
21.8. 13:41 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Kompilátor dokáže optimalizovat velice mnoho. Protože kompilátor+linker má o celém programu mnohem více informací než kdokoli jiný. Cílem kompilátoru je zoptimalizovat co se dá - včetně paralelizace - na úrovni, které je schopen.

A na dobré plánování toho zbytku je tu operační systém.
21.8. 14:56 PetebLazar
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Kdo ve Vámi zmiňovaném modelu má rozhodnout o tom na kolika vláknech má taková konkrétní paralelní úloha běžet, aby například snížené cache-hit-ratio při velkém počtu současných vláken nesnížilo celkovou efektivitu (výkon) provádění v rámci dané platformy(HW)?
21.8. 16:15 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Všechny strany co jsou ve hře o tom spolurozhodují.
21.8. 17:24 PetebLazar
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
To mne také napadlo, s otázkou zda je vůbec reálné aby taková rozhodnutí byla reálně vědomá, konsenzuální a vedoucí k optimálnímu výkonu.

Například výše nepřímo zmiňovaný Threadripper 2990WX vykazoval v Indigo benchmarku výrazně nižší výkon pod Windows než v Linuxu. Obvyklý podezřelý, pouze quad-channel RAM, se ukázal býti nevinným (octa-channel EPYC tím trpěl také), jako nejpravděpodobnější pachatel byl označen plánovač ve Windows, který přepínal core mezi thready podle dlouholetého dogma (všechna jádra si jsou si prakticky rovna) což moc neplatilo v případě multi-die(multi L3 cache) architektury. Procesor sice navenek vykazoval plné vytížení, ale patrně významně jalovou režií.

Problém vícevrstvého řešení je jak zajistit optimální dílčí funkci ve prospěch celku. Vetšina vrstev má povědomí pouze o sobě a možná sousedech a rozhodnutí v její(jejich) prospěch se může ukázat kontraproduktivní ve vzdálenějších vrstvách. Schopnost přijmout lokálně nepříznivé řešení s celkovým pozitivním dopadem může kvalifikovaně provést jen někdo(něco) disponujícími komplexními informacemi, schopnostmi a vůlí rozhodnout.
21.8. 17:50 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Když míříte na maximální rychlost, jdou všechny dobré zásady softwarového vývoje, do zadele. Když vám vadí, že možnosti hw využijete jen na 99,99 % a ne na 100 %, pak je třeba prasit, a pojmout to zcela jinak. To platilo, platí a platit bude.

Když budete dodržovat zásady správného sw inženýrství, tak vás to třeba 1 % výkonu bude stát.

Bystroushaak avatar 21.8. 18:30 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Když budete dodržovat zásady správného sw inženýrství, tak vás to třeba 1 % výkonu bude stát.
Je ovšem dobré se taky zamyslet nad tím, jestli cena úprav a dalšího rozšiřování software potom nebude větší než cena za 1% výkonu navíc.
21.8. 18:32 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
A stejně tak i nad tím, jestli to opravdu bude jedno procento nebo jestli si to číslo pan Ponkrác vycucal z prstu.
xkucf03 avatar 23.8. 17:27 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
+1
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
xkucf03 avatar 23.8. 17:24 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor

Když program operačnímu systému nasype třeba tisíc1 vláken, tak se je operační systém bude snažit spravedlivě střídat (s ohledem na jejich prioritu), aby se na každé dostalo. Nebo je tu způsob, jak může proces operačnímu systému říct: „tady máš 1000 vláken, ale kdyby se ti to nehodilo, tak jich spusť třeba jen 200 a zbytek ukonči“? To AFAIK nejde a program by musel nějak adaptivně přisypávat další vlákna a průběžně měřit, jak efektivně pracují, jak je vytížený HW a zda má smysl přidávat další. Ostatní programy můžou ale dělat totéž a pokud se nebudou mezi sebou koordinovat, tak ten HW můžou přetížit nebo to minimálně povede na neoptimální výsledek.

Částečně by to šlo řešit tak, že by si proces spustil více vláken s odlišnými prioritami a zjišťoval, jak často na které vyjde řada a podle toho upravoval počet vláken a rozhazoval mezi ně úkoly. Kolik vláken spustit s normální prioritou a kolik s nižší, ale nejde odvodit ze zdrojového kódu – tam je potřeba zohlednit, jaké všechny procesy na daném počítači běží a jaké jsou mezi nimi vztahy a priority. Když např. zpomalení jednoho procesu způsobí, že jiný proces nebude mít co dělat, je potřeba to při optimalizaci zohlednit. Stejně tak i zahlcení (viz #143).

[1] resp. on to nemusí být jeden program, ale třeba si každý proces bude myslet, že je dobrý nápad pustit tolik vláken, kolik má daný počítač jader, akorát neví o tom, že stejný nápad měly i jiné procesy běžící na témže stroji

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
23.8. 17:58 PetebLazar
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Nejde asi jen o prioritu v přidělování "strojového času", ale i dalších zdrojů (např. cache). V rámci core jedno datově hladové vlákno může zhoršit cache-hit ratio ostatním vláknům (snížit jejich výkonnost). Mám pocit, že Zen 2 zavádí nové instrukce na management mem_bandwith/cache, primárně snad mířené na virtualizaci. Aby bylo možné pro VM garantovat spravedlivé penzum i těchto zdrojů. Pokud jsem to tedy z prezentace pobral správně.
21.8. 12:57 Messa
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Bohužel neexistuje nic jako Pool generátor.
Co pool.imap()?
Heron avatar 21.8. 14:23 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Z dokumentace nejsem moc moudrej. Pro 2.7 se tam píše, že je to totéž jako itertools.imap, což vytvoří generátor podle nejkratšího vstupního iterable. Ok, tak máme generátor, ale nikde se nepíše, jestli se ty prvky generují v jiných procesech a kdy.

Ve 3.7 je pro jistotu jen napsáno A lazier version of map() bez dalšího vysvětlení.

Když se dívám do kódu, tak tam nějaký pokus o asynchronní frontu v imap() je, ale taky je tam doc:
'''
Equivalent of `map()` -- can be MUCH slower than `Pool.map()`.
'''
což nenadchne.
Bystroushaak avatar 21.8. 14:27 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Některé jazyky (Python) jsou vyloženě singlethread. Ne, že by nešlo programovat ve více vláknech, ale v základu všechno dost komplikuje GIL (global interpreter lock).
Tady si pleteš Python jako jazyk a Python jako interpreter. Konkrétně tohle je omezení CPythonu. Existuje například verze Pypy s STM, která tohle omezení nemá.
Existují snadno použitelné knihovny, které to různými způsoby obcházejí (Multiprocessing).
Knihovna multiprocessing to neobchází, ta prostě jen pouští víc procesů.
Nebo ještě lépe, jazyk, který od programátora vůbec nevyžaduje hint ve stylu "tady bude další thread"
Neuměl tohle Common lisp?
21.8. 16:05 Miloslav Ponkrác
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Tady si pleteš Python jako jazyk a Python jako interpreter. Konkrétně tohle je omezení CPythonu. Existuje například verze Pypy s STM, která tohle omezení nemá.
Programovací jazyk, který dobře podporuje paralelismus, je třeba navrhnout už s touto myšlenkou. Ne to tam dolepit.

Bystroushaak avatar 21.8. 17:49 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Jo, whatever. Tady jde spíš o to že CPython díky GILu není schopen thready skutečně efektivně využít, kdežto Pypy s STM je používá vcelku v pohodě. Ani jedno z toho není řešení paralelismu.
21.8. 18:46 mimi.vx | skóre: 37 | blog: Mimi.VX | Praha
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor

hmm,  odbornik promluvil.

USE="-gnome -kde";turris
Bystroushaak avatar 21.8. 21:02 Bystroushaak | skóre: 35 | blog: Bystroushaakův blog | Praha
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Co prosím?
22.8. 03:39 _
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
neboj myslel to ironycky
21.8. 14:59 goldenfish | skóre: 38 | blog: aqarium | Praha
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Příloha:
Mozna by to chtelo, aby nekdo koupil alespon 12-16 jadro a podelil se tady o zazitky, jak jsou aplikace optimalizovany na beh s opravdu vice jadry. Me tady asi moc lidi neuveri, protoze goldenfish.

V obrazkove priloze mate maven build (-T 1C) mensiho projektu s 300k SLOC radky v Jave - asi 30 vterin buildu tam je. Do toho zobrazeni monitoru CPU neni uplne bezchybne. Tech 64 kousku celkove tam neni. Jinak mi paraelne bezi na masine vice veci, co zerou pamet. Samotny build bere asi tak 1/3 pameti.

gf

21.8. 17:18 debian+
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
A aku ma spotrebu?
21.8. 20:43 goldenfish | skóre: 38 | blog: aqarium | Praha
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
zdravim,

na spotrebu se tady pta nekdo uz vicekrat. Ale OK.

Neco jsem cetl, ze male zatizeni 70W, plny vykon 250W. Toto se da dohledat na netu (AMD 2990WX). Zdroj mam asi 750W a grafika nic moc mimo skvelyho obrazu.

Vetsinou resim nejake spicky do 1 minuty, kdyz uz plny vykon na vsechna jadra. Pripadne 5-20 minut.

Priznam se, ze moc spotrebu neresim. Mozna je to rocne 2-4 tisice navic. Protoze moje sazby mi to zaplati velmi rychle. Zanedbatelna castka.

Jo v mistnosti dovedu zvednout teplotu o 1 stupen behem 1-2 hodin provozu. Pod plnym vykonem masina trochu hreje - vodni chlazeni.

Pro me je dulezity ohledne vsech komponent HW:

- mit build 1M codebase za 1.5 minuty a ne za 55 minut.

- mit testy celeho projektu hotovy behem 5-10 minut a ne za 2.5 hodiny.

- nacist do InteliJ IDEA projekt za 5-7s a ne za 10 minut.

- nacist vubec 1GB logu behem 15s - to je treba 1 minuta behu aplikace. A neresit, ze dosla pamet. Identifikovat chybu, stacktrace, thread, najit komunikaci webservices.

- nastartovat webserver za 50s a ne za 7 minut.

- vecer nemit bolesti oci.

- kdyz si spustim najednou nebo i samostatne par aplikaci, tak mohu jeste v klidu pracovat.

gf
22.8. 12:07 debian+
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Dik za pridanu hodnotu k mojej otazke.

Napis to ako blog. Nie je bezne, ze clovek ma taku nadupanu masinu a s nou priamu skusenost.
22.8. 14:58 goldenfish | skóre: 38 | blog: aqarium | Praha
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Psano hodne s nadsazkou:

Kdyz to vezmu hodne drsne ironicky, tak by o techto pocitacich mohly psat ty uspesne webove eziny a uspesni blogeri a diskuteri.....

Mozna budete prekvapeni, ale je bezne, ze redakci pujci welkoobchod s pocitaci sestavu zdarma.

Pisi radeji do prispevku nez do blogu, kdyz mam naladu a cas. Ono se pak dovite, ze machrujete s nabusenou workstation.

Ono v jedne zemi na zapad od Slovenska se pry lidi maji tak spatne, ze musi resit spotrebu elektriny. Mohou si koupit jen lepsi klavesnici a chlazeni=tichy pocitac.

Vykon v teto zemi nikdo neresi. Pry je to tak drahe, ze zakoupeni lepsiho PC (staci 12-16 core) zruinuje totalne rozpocet jednotlivce, ne-li rodiny. Platy v IT se pohybuji v takove nizke vysi, ze se poridite jen hypoteku, 2 auta, gril za 10 koliku a 3 rocne dovolenou. Porad nevidim lidi s tlacitkovymi telefony, kdyz se mame tak spatne.

Takze tak radio Jerevan....

gf
xxx avatar 22.8. 15:01 xxx | skóre: 42 | blog: Na Kafíčko
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Pockej az ti zavedou emisni povolnky podle poctu a frekvence jader. Treba to ale bude porad levnejsi nez topit uhlim.
Please rise for the Futurama theme song.
22.8. 16:02 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Všechno je to otázka priorit. Já třeba mám tlačítkový telefon (osm let starý) a Ryzen 2700X (ten má sice jen 8 jader, ale začínám uvažovat o 3900X, ten už by se do vašeho rozmezí vešel). Někdo si za 5KKč pořídí klávesnici, někdo raději (druhých) 32 GB paměti. A někdo radši pojede na (lepší) dovolenou. To, že má někdo priority jiné než já, neznamená, že je má špatně zvolené.
23.8. 10:52 goldenfish | skóre: 38 | blog: aqarium | Praha
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Trochu to uvedu na pravou miru:

Dovedu pochopit, ze si __nekdo__ nekoupi to, ci ono. No treba ty 16 jadrove stroje.

Mam ale z ceskych e-zinu, youtube a linuxovych portalu (clanky, diskuze) pocit, ze si to nekoupi __nikdo__ . Az na asi 3 pripady(2xabicko, youtube).

Kdyz jsem kupoval 128GB RAM, tak na mne koukali v centru Prahy v jednom vetsim e-shopu, jak na zazrak. Toto pry nikdo neobjednava.

Proto taky hledam zajmove veci spise v cizine.

No a to je nejake divne. Proste tady chybi pionyri, co maji novy HW a jsou trochu na technologicke spici. 16-jadro uz tedy neni zrovna technologicka novinka.

To, co popisuju je spise znak technologickeho zastaravani. Dobre muzeme si jej omluvit. To jde. Ale neni to dobry znak libovolne technologicke komunity.

gf
Heron avatar 23.8. 11:12 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Hele, mě tady lidé taky v roce 2008 považovali za snoba s tehdy čtyřjádrem a 8GB RAM. A dodnes po mě někteří lidé chtějí podání vysvětlení, proč mám tolik disků. Z toho bych si nic nedělal.
Dovedu pochopit, ze si __nekdo__ nekoupi to, ci ono. No treba ty 16 jadrove stroje.
Ono je to taky otázka KDY. Tohle jde ve vlnách. Já si Ryzen (8/16) koupil okamžitě jak byl dostupný. Před tím nic takového dostupného nebylo a byl to velký skok. Ale dneska je to vlastně obyč a pokud si dneska někdo bude kupovat highend cpu, tak poskočí někam na tvou úroveň 16/32 nebo 32/64. Tedy je to taky otázka času.
Kdyz jsem kupoval 128GB RAM
Tady je to pro mě otázka taky trochu morální. Od roku 2013 jsem měl 32GB RAM a v roce 2017 jsem chtěl pro Ryzen minimálně 64GB a nejlépe to naplnit na maximum, co umí základní deska. Jenže ty ceny od roku 2013 dost vzrostly (podle mě uměle) a za 32GB jsem v 2017 zaplatil víc než v roce 2013. A na tohle nejsem ochoten přistupovat v žádném oboru a u žádného výrobku.
To, co popisuju je spise znak technologickeho zastaravani. Dobre muzeme si jej omluvit. To jde. Ale neni to dobry znak libovolne technologicke komunity.
Ano, tohle mě taky překvapuje. Na IT portálech bych čekal trochu větší afinitu k HW a tak trochu bych očekával, že každý toho máme doma víc a že kolem toho nebudou otázky typu proč a na co apod.
23.8. 12:52 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Jenže ty ceny od roku 2013 dost vzrostly (podle mě uměle) a za 32GB jsem v 2017 zaplatil víc než v roce 2013.

Tohle jsem taky zaznamenal, v roce 2012 jsem kupoval 32 GB (4x8, DDR3) za něco kolem 3500 Kč včetně DPH, na podzim 2018 mne stálo 32 GB (2x16, DDR4) víc než dvojnásobek. Ale co jsem teď koukal na ceny, zdá se, že už to konečně zase spadlo, 2x16 GB začínají pod 4000 Kč s DPH.

23.8. 13:06 goldenfish | skóre: 38 | blog: aqarium | Praha
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
\\add ceny HW a pameti

Kdyz si spocitam kolik stoji HW a kolik si uctuji a mohu uctovat, tak do 20 tisic se to bez problemu ztrati. Zakaznici plati a jestli mam dokoupit dalsi disk nebo pamet, tak to neresim. Pro me je naopak vyhoda vykonny HW, pokud neco prolamujuju hrobou silou.

Pres casem byly pameti drahe oproti dnesku. To asi souhlas. I tak jsem do toho sel.

64GB RAM - 16.000,-Kc, 128GB RAM - 21.000,-. 32GB, co jsem mel radeji nepocitam.

Doma se mi valid 64GB RAM a nejak neni cas a nalada resit prodej za 2 tisice vyvolavaci cena nebo kolik do aukce.

Primarne jsem resil, zda se mi to zaplati za nejaky cas nebo ne. OK, tech 128GB byla dlouhodobejsi investice.
23.8. 14:09 PetebLazar
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Myslím, že řada lidí je stále v zajetí požadavku na single-thread výkon a vysoké frekvence (asi trauma z doby P4). Při paralelních úlohách, nebo paralelizovatelných úlohách ovšem spíše rozhoduje hodnota n_core * takt (samozřejmě o mem bandwith/latencích a IO nemluvě).

Řekl bych, že částečně za to může nízká infomovanost. Například 12-core 2920X stojí v současnosti 10kKč+ a MB X399 s 10Gbps podobně. Na platformě Ryzen 3000/X570 to vystačí tak na levnější 8-mi jádro a MB disponujícím 10 Gbit LAN.

Každopádně se zlepšeným IPC, zvětšenou cache a možná i trochou taktů navíc je tu šance, že Threadripper 3000 ztratí ty zbytky "bad rep", kterou možná získal svým ne zcela přesvědčivým výkonem ve hrách. To, že byl vůbec ve hrách testován je věcí druhou, je to asi důsledek neexistujících WorkStation medií a komunity.

Souhlas s orientací na zahraniční zdroje. Když se malý počet prodaných kusů (desítky-stovky v ČR) podělí počtem např. modelů MB, je o konkrétní (non)success stories v rodném jazyce logicky nouze.
23.8. 14:17 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Tak Threadripper a vůbec Zen obecně má hlavně bad rep kvůli špatné podpoře v Linuxu. Měli by zlepšit předevšim tohle, pak se můžeme nějak bavit... Oproti tomu nějaký perf ve hrách je mi osobně u zadku.
23.8. 14:32 goldenfish | skóre: 38 | blog: aqarium | Praha
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Muzete nejake rozvest tuto informaci ?

Mam tyto zkusenosti:

Ze nesla merit hned po vydani teplota, tak to OK.

Ale zrovna podpora Ryzen a Threadripper byla pripravena dopredu a kdyz jsem vymenil procesor (1800X,1950X,2990WX) na Debian stable, tak jsem mohl hned po bootu pracovat. V BIOSU jsem akorat zapinal virtualizaci - default je vypla.

Ryzen 1800X mel problem s pady velkych kompilaci C/C++. To OK, pokud jste si hned po vydani koupil novy CPU. Normalni smrtelnik to nepoznal.

23.8. 14:33 goldenfish | skóre: 38 | blog: aqarium | Praha
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
OK=mate pravdu.
23.8. 14:41 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Např. toto nebo toto.
23.8. 19:25 debian+
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Ryzen 1800X mel problem s pady velkych kompilaci C/C++.
Prve padali na Linuxe (Linux sa snazil regularne vyzmykat na maximum hardver, co je dostupne systemu). AMD to pekne riesilo, vymenou procesora za novsi - za dalsi z vyrovnej linky, kde hardverovu chybu v procesore sposobujucu to).
23.8. 15:05 PetebLazar
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Pokud bych měl jako spokojený (v září cca dvouletý uživatel Threadrippperu 1950X v Linuxu, Win10 typicky jen přes KVM/QEMU) zmínit výhradu, pak to byla počáteční nefunkčnost PCI passthrough u první generace Tr. V řádu jednotek měsíců jeden z uživatelů napsal "dirty patch" řešící problém, ale nestanovující příčinu. Tu odhlalil a opravil až Geof/gniff (tvůrce mj. Looking Glass) a ve formě "ugly patch". Okolo té doby již i AMD přiznalo problém, ale řešení se dočkal snad až z jara v některé z dalších AGESA. Na jejich obranu je možné asi zmínit, že u jejich GK snad tento případ ze zvláštních důvodů nenastával.

Na druhou stranu nemohu nevzpomenout na revizi C1 Intel CPU XEON Sandy Bridge-E, kde byla mikrokodem neopravitelná chyba v implementaci VT-d a tuto feature bylo nutné vypnout. Zajímavé je, že se ani nenamáhali tuto skutečnost zohlednit v DB Intel ARK, podle níž procesor touto schopností disponoval a to dlouhé měsíce před vydáním revize C2, kde již byla chyba napravena.
23.8. 19:19 debian+
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Mozna budete prekvapeni, ale je bezne, ze redakci pujci welkoobchod s pocitaci sestavu zdarma.
Uz ani nie, lebo uz sa zvykne pod/v clanku uvadzat, kto a ako spozoroval clanok.

Ale nikde co sledujem, som nevidel recenziu na ten clanok. V CZ alebo SK (Alebo ja na nejake take stranky s tym obsahom zrejme nechodim :D). Predsa, pre min 80% beznych ludi to nateraz nie je atraktivne, cena alebo vykon. Takze tvoj pohlad a skusenosti by nam ukazali, tym co to teraz nemame, co nas caka o X rokov.
24.8. 13:23 goldenfish | skóre: 38 | blog: aqarium | Praha
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
No a v cem je problem, ze dole v clanku bude sponzor ? To je tak nejak normalni protisluzba. To asi vite.

Me je tak nejak jasny, ze jakmile prijde cesky clovek na eshop s HW, tak okamzite mentalne prepne do rezimu cena/vykon nebo maximalni sleva a jsme tam kde jsme byli.

Posledni dobou me spise zacina bavit delat ty revoluce sam na spravnych mistech, nez o tom nekde psat. Ted jsem koukal po cizine dost po placeni mobilem a hodinkama. Taky se zacinam ucit, jak z toho i neco mit. Penize, slava, zkusenosti a tak.

Mozna by jste se divil, jaky prehled ziskate za 1100,-Kc/rok pri cteni Hospodarskych novin.

Az tady trolove, vysiraci, ekologove, sociologove, skudlilove a dalsi budou mit mensi prava, nez lidi se zkusenostma, tak mozna. Zatim je to naopak.

gf
24.8. 12:32 David
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Priznam se, ze moc spotrebu neresim. Mozna je to rocne 2-4 tisice navic. Protoze moje sazby mi to zaplati velmi rychle. Zanedbatelna castka.
Nová studie nazvaná Měření ekologické stopy bohatých. Nadměrná spotřeba, ekologická dezorganizace, zelený zločin a spravedlnost, kterou provedli badatelé Michael J. Lynch, Michael A. Long, Paul B. Stretesky a Kimberley L. Barrett, zkoumá, jak chování bohatých lidí ovlivňuje změnu klimatu. Studie tvrdí, že když má člověk mnohem větší množství peněz, než potřebuje k životu, „stává se pro něj nadměrná spotřeba či nakupování nemovitostí statusovým symbolem, který musí být pravidelně obnovován, což vede k ještě větší spotřebě“. To vede velmi bohaté lidi k výstavbě obrovských domů, k nakupování luxusních jachet, aut nebo soukromých letadel. K tomu, aby se vyvážil jejich ekologický dopad, by bylo potřeba nesmírné množství zmíněných „zelených“ baterií Powerwall.
24.8. 13:12 goldenfish | skóre: 38 | blog: aqarium | Praha
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Asi nejaka nova tajna forma komunikace... copy-paste z a2larm.cz .

21.8. 19:08 pb.
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Pěkné ;-)

Já zase podobně ždímám výkon z grafických karet (někdo se tu ptal na spotřebu? ~800W v zátěži). Převážně na tom jedou statistické výpočty v TensorFlow.

Když už vzpomínám TensorFlow - to je pěkná ukázka toho, jak programátoři nejsou připravení na paralelizaci. Pro "zapisovatele algoritmů" je TensorFlow zcela neuchopitelné - zapomeňte na cykly či jiné řídící struktury. TensorFlow je více o zvládnutí matematického aparátu, který je za tím. Normální programátor myslí úplně jinak. Výkonné části programu nakonec mohou mít jen pár desítek řádků a dokáží efektivně zaměstnat veškerá výpočetní jádra.

21.8. 20:18 PetebLazar
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Basecalling 10GB sekvenovaných dat Threadripper 1950X (300min?), 1080Ti(12min) při prakticky srovnatelné průběžné spotřebě (160W versus 220W). Na druhou stranu GTX 1660Ti (120min). Chápu, že daný program je laděný na Pascal generaci (GTX 10x0), ale přesto mě rozdíl GPGPU výkonu zmíněných GK (10:1) docela překvapil. Jsou úlohy, které řešit pomocí CPU je dnes "hřích".
21.8. 21:57 pb.
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Zaměstnávám Radeon VII a tam je u některých úloh poměr výkonu GPU:CPU až 15:1 (procesor Ryzen 1800X). Většinou ale ten poměr není tak veliký. Záleží samozřejmě na typu úlohy, vyjímečně může být CPU rychlejší. Vega64 má výkon zhruba srovnatelný s Radeon VII, ale občas se do té karty nevlezu s pamětí (8GB Vega64 vs 16GB Radeon VII).
Heron avatar 21.8. 22:18 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Já zaměstnávám Radeon RX480(8GB) a Ryzen 1700 a výkon v Blenderu je naprosto srovnatelný :-D Asi je čas na upgrade, začínám pošilhávat po 3950X i když je ještě čas počkat na threadrippery nové generace.
Heron avatar 21.8. 22:21 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Blenderu

V Cycles. V EEVEE je to těžce ve prospěch GPU.
22.8. 00:07 PetebLazar
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Doporučuji upřednostnit HEDT, už jen kvůli PCIe linkám a quad-channel je to úplně něco jiného. Čímž tedy nechci naznačit, že mi při 60 linkách nějaké přebývají. ;-)
21.8. 20:47 goldenfish | skóre: 38 | blog: aqarium | Praha
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Moc hezke.

Do neuronovych siti planuju jit zacatkem roku, tak jsem hodne zvedavej. Take pocitam s vypocty pres grafickou kartu a ne pres CPU.
24.8. 12:30 David
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Roztomilé.

Jak se angažuješ v zastavení těžby a spalování uhlí?
21.8. 17:18 debian+
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Mas zalusk na toto?
21.8. 17:23 /dev/urandom
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
a videl si spotrebu ?
21.8. 17:46 aaaaaaaaaaaaaaaaaaaaaaaaaaaa
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
na 256 jadrovy procesor sa najlepšie hodí Turbo Pascal 7.0 alebo 7.1 snáď - ale musí mať ošetrenu CRT knihovnu...
Max avatar 21.8. 18:15 Max | skóre: 67 | blog: Max_Devaine
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Když ten 256 jádrový procesor nebude běžet na vyšší frekvenci než 200MHz, tak netřeba patchovat :).
Zdar Max
Měl jsem sen ... :(
21.8. 19:25 /dev/urandom
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
dobre pamatas :D +1
21.8. 20:22 PetebLazar
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
S tím IPC pokrokem od dob Pentia Pro bych to bez aplikace patche bych to pro jistotu podtaktoval na 100MHz. ;-)
22.8. 00:31 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Co se na ní patchovalo? Něco tam dělali prázdným cyklem a pak dělili rozdílem času, což vedlo na dělení nulou?
Quando omni flunkus moritati
22.8. 01:11 Gilhad | skóre: 20 | blog: gilhadoviny
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Jo, kalibrovali rychlost a na moc rychlych pocitacich se to spocetlo moc rychle a pak deleni nulou a pad. Napriklad ve Wizardry 6 (aspon myslim) kdyz clovek narazil na majestatne krouzici netopyry (na libovolnem slabsim pocitaci stale stejne rychle), tak na rychlejsim pak vypadali, jako kdyz nekdo zapne mixer :)
Josef Kufner avatar 22.8. 11:09 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Další potíž s čekacími smyčkami je, že když CPU usoudí, že je nějaké vytížené a zvedne kmitočet, tak je kalibrace v háji a čekací smyčky čekají špatně. Vypínání CPU frequency scaling bývalo v návodech docela častou radou.
Hello world ! Segmentation fault (core dumped)
21.8. 18:45 mimi.vx | skóre: 37 | blog: Mimi.VX | Praha
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor

Herone .. Jazyku ktere jsou implicintne concurrentni a parallelni existuje celkem nepreberne mnozstvi. Uz mimo jine proto ze mnohojadrove systemy tu mame skoro vice nez 50 let. Jen ted se dostavaji do beznych PC ..-> https://en.wikipedia.org/wiki/List_of_concurrent_and_parallel_programming_languages

USE="-gnome -kde";turris
22.8. 12:34 pc2005 | skóre: 38 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Na současné architektuře mě přijde paralelizace dost těžkopádná. Ono přimět cizí procesor aby začal pracovat na mém vláknu bude hypotetický plně paralelizující jazyk dost limitovat. Z hlediska architektury by to chtělo nějakou instrukci, co by dělala přímo "fork", takže by se daly paralelizovat i velmi malé úseky kódu.
22.8. 15:02 OldFrog {Ondra Nemecek} | skóre: 31 | blog: Žabákův notes | Praha
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Můžete to víc rozvést? Co jsou pro Vás „malé kousky kódy“? IMHO instrukce paralelizuje přímo CPU a kompilátor, větší kousky kódu pak prostředky jazyka (např. různé executor services spustí tasky na poolu x vláken, zpracování streamů pomocí filter-map-reduce, může běžet paralelně, sql pracuje už na v některých databázích paralelně automaticky), o jak velké části kódu si většinou volí programátor.
-- OldFrog
23.8. 15:18 pc2005 | skóre: 38 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
o jak velké části kódu si většinou volí programátor.
To právě Heron nechce. On chce (jestli jsem pochopil blog správně), aby kompilátor byl schopný paralelizovat libovolný dumb (sériový, triviální) algoritmus. A to podle mě nejde udělat tak, aby se úloha přeložila na volání kernelu pro spuštění dalších threadů (a zároveň to mohlo paralelizovat třeba jednu for smyčku).

Paralelizace pomocí CPU je velmi omezená na buď SIMD, což neumožňuje počítat naprosto nesouvisející data, nebo na plnění prázdných ALU slotů blízkým kódem bez závislostí.

To co jsem měl na mysli by bylo něco jako realtime FPGA syntéza, kde by se před for smyčkou prostě jen syntetizovalo 10 nových ALU a po skončení smyčky by se zase dealokovaly zpátky do poolu volných prostředků. V případě potřeby něčeho jako další vlákno (v měřítkách existujících vláken) by se prostě ten procesor nechal běžet déle.

Moje instrukce fork by pak fungovala asi jako podmíněný skok, jen s tím rozdílem, že by zárověň skočila i neskočila :-D, chovalo by se to vlastně jako nedeterministický automat (omezený hardwarem samozřejmě).
Heron avatar 23.8. 15:27 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
To právě Heron nechce. On chce (jestli jsem pochopil blog správně), aby kompilátor byl schopný paralelizovat libovolný dumb (sériový, triviální) algoritmus. A to podle mě nejde udělat tak, aby se úloha přeložila na volání kernelu pro spuštění dalších threadů (a zároveň to mohlo paralelizovat třeba jednu for smyčku).
+1
To co jsem měl na mysli by bylo něco jako realtime FPGA syntéza, kde by se před for smyčkou prostě jen syntetizovalo 10 nových ALU a po skončení smyčky by se zase dealokovaly zpátky do poolu volných prostředků.

No to by byla úplná bomba.

O použití FPGA pro ad hoc akcelerátory kde čeho jsem tady taky kdysi snil. Program by si pro svou specifickou činnost vyrobil akcelerátor na prvním volném FPGA a potom to opět zrušil. Je pravdou, že toto postupem doby alespoň částečně na sebe vzaly GPU a kde co si přes OpenCL něco nechá spočítat na GPU.
23.8. 15:36 PetebLazar
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
OpenCL snad není omezeno jen na GPU/CPU, tento standard snad míří i na FPGA?
Heron avatar 23.8. 15:42 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Jo, ale v kompech těch volně použitelných FPGA mnoho není. Na rozdíl od GPU.

Dělají se vůbec nějaké veřejnosti dostupné FPGA PCIE desky, které by šly použít v PC? Co jsem viděl na YT, tak to byly jen desky vlastní výroby od HW nadšenců k jejich specializovaným činnostem.
23.8. 16:26 PetebLazar
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
23.8. 16:41 PetebLazar
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Asi existují i dostupnější, výkonově(funkčně) méně schopné. https://www.enterpoint.co.uk/shop/home/11-raggedston2.html

Pokud by cílem bylo OpenCL, pak je nejspíš v GPU výkon (mem bandwith?) dostupnější.
24.8. 04:39 pc2005 | skóre: 38 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Volně použitelné ne. A čipy co jsou cenově dostupné (spartan-6) jsou všude bez PCIe verze (řada T, ty bez T měly nejspíš defekt v PCIe části, jinak jsou identický), nehledě na to, že spartany jsou pomalý. Ještě možná Zynq, ale všechny karty s lepšíma generacema mají už čtyřcifernou cenu.
xkucf03 avatar 23.8. 12:27 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Na trhu se začínají objevovat 64 core / 128 thread CPU a nebude dlouho trvat a zcela běžně budou dostupné 256 core / thread CPU. Do pár let to máme na stole. A nastává otázka, jak pro tyto cpu programovat.

Tohle mi přijde jako poněkud zvláštní směr uvažování. Podle mého by se k tomu mělo přistupovat spíš z druhé strany: mám nějaký problém, požadavky, potřebu → hledám vhodný hardware. A ne naopak, že si koupím 256jádrový procesor a pak teprve začnu vymýšlet, k čemu a jak ho použiji.

Ty požadavky se v čase mění, např. jsou dnes centralizované weby, které obsluhují obrovské množství návštěvníků – v takovém případě dává smysl si pořídit server se spoustou procesorů/jader/vláken a tahle úloha se dá krásně paralelizovat (a to celkem primitivním způsobem, prostě jen vytvoříš patřičný počet procesů a mezi ně pak rozhazuješ požadavky resp. zpracováváš v nich události).

Další změna je třeba rostoucí rozlišení u videí, fotek nebo zvukových záznamů a jejich rostoucí počet. Pokud je počet souborů vyšší než počet jader, lze to paralelizovat opět naprosto primitivním způsobem (třeba tím xargs nebo parallel) a není potřeba měnit algoritmus. Pokud chceš jeden soubor zpracovat rychle ve více vláknech, změna algoritmu je potřeba, ale díky vyššímu rozlišení to jde i relativně jednoduše rozsekáním na menší části, které se pak zase poskládají dohromady.

Toto nám vyrobí seznam stejně jako list comprehension, ale využije k tomu automaticky všechny dostupné procesory.

Ona ta všudypřítomná automatická paralelizace sice vypadá lákavě, ale často to smysl nemá nebo to může být i kontraproduktivní. Představ si, že máš jeden server, který obsluhuje velký počet uživatelů. Díky tomu, že jich je víc než jader, jsou schopní naplno vytížit CPU a tím využít hardware efektivně. Přitom se každý požadavek může vyřizovat sekvenčně, v jednom vlákně (v rámci toho požadavku můžeš klidně iterovat ve for cyklu přes nějaký seznam). Pokud to v rámci jednoho požadavku začneš paralelizovat, zvýší se počet úloh, který byl ale už před tím vyšší než počet jader, takže tím vlastně nemáš co získat, a akorát to bude čekat na plánovač, který rozhazuje úlohy mezi jádra procesoru – a jeho režie může způsobit i pokles výkonu. Pokud bys tam měl nevytížená jádra (kvůli čekání na I/O) tak by to smysl mělo (nicméně to obvykle nenastává, protože když máš velký počet klientů, začneš během čekání u jednoho obsluhovat požadavek někoho jiného).

Největšího efektu podle mého stejně dosáhneš tam, kde jsi schopný to paralelizovat vědomě/explicitně. Na nějakou magii, která ti libovolnou úlohu automaticky zoptimalizuje na pozadí, bych moc nespoléhal – ve chvíli, kdy to bude dostupné a spolehlivé, asi není důvod to nepoužít a nějaká procenta výkonu ti to přidá, ale žádné zázraky a skokové zlepšení bych od toho nečekal.

Když se dívám na to, jak se dneska vrší jedna vrstva na druhou, jak si např. lidi pouští mnoho instancí webového prohlížeče a dalších komponent i pro triviální aplikace, jak roste komplexita… tak vidím ty rezervy úplně někde jinde, než v nějakých automatických optimalizacích. Když některé vrstvy/komponenty proškrtáš, tak ušetříš mnohem víc, než když je tam necháš a budeš je (sebelépe) optimalizovat.

Takže tu budoucnosti vidíte (množné číslo) jen v nových knihovnách? Jazyk ani paradigma podle vás není potřeba? (#19)

Podpora paralelizace na úrovni syntaxe jazyka může přidat nějaké pohodlí, ale podle mého se dobrý jazyk pozná spíš tak, že je dostatečně pružný na to, aby takovéto vylepšení (a nemusí jít jen o paralelizaci) umožnil zavést formou knihovny (a třeba anotací nebo jiného již existujícího jazykového prostředku) a bylo to ve výsledku srovnatelně pohodlné, aniž by se musela měnit syntaxe jazyka nebo specifikace běhového prostředí.

Časem se třeba dočkáme nějaké umělé inteligence, která zanalyzuje tvoji úlohu a vymyslí za tebe, které části lze paralelizovat a kde je potřeba na sebe čekat a synchronizovat se… a tahle optimalizace se bude dít v době kompilace nebo dynamicky za běhu. To by zásadní změna paradigmatu a vůbec způsobu vývoje softwaru byla. Ale tady bych čekal, že na vstupu bude spíš nějaký deklarativní popis toho, co má být cílem výpočtu, než imperativní předpis, co se má dělat. Zajímavé by bylo automatické rozložení algoritmu napříč více počítači (ne jen více procesory jednoho počítače). Potřeboval bys dost vzorových vstupních dat a popis požadovaného výsledku, kterým by se to testovalo – a kompilátor (o dost jiný než dnešní kompilátory) by pak pouštěl různé simulace a hledal nejefektivnější cestu, jak dosáhnout správného výsledku.

Mě funkcionální programování postihlo jen během studia a to setkání bylo takové zvláštní. Jednak se říkalo, že je to velmi snadno paralelizovatelné, protože funkce nemají žádné vedlejší efekty (což skutečně nemají) ale žádný interpret (tehdy scheme) nikdy nebyl multithreading. Já proti funkcionálnímu paradigmatu nic nemám, ale chtěl bych někdy vidět všechny jeho výhody v plné palbě včetně toho masivního paralelismu.

Ano, to se tak říká, ale přijde mi, že ty reálné přínosy nás trochu míjejí a že spousta lidí do toho vkládá větší naděje, než to může přinést – asi podobně, jako když bylo na vrcholu módní vlny OOP a lidi čekali zázraky od něj.

Lamba funkce se v nefunc jazycích používají spíše jen jako syntaxe pro anonymní funkce. (Typicky, chcete předat něco filteru nebo mapu a nechcete dělat pojmenovanou fci, tak to napíšete jako lambdu.)

Z praktického hlediska považuji za vítěze multiparadigmatické jazyky, které umožňují kombinovat více přístupů, podle toho, co se na kterou část programu hodí. Typicky to pak vede na nějakou objektovou (nebo v jednodušším případě procedurální) kostru programu a uvnitř nějaké funkcionální a deklarativní prvky. Sice to není tak akademicky čité jako např. výhradně funkcionální jazyk, ale z praktického hlediska je to užitečnější.

Proto si myslím, že musí dojít ke změně paradigmatu. Dneska se afaik až na nějaké speciality stále programuje tak, že se přímo určuje kde se to má forknout a co v tom vlákně má běžet. Tj se ručně alokuje určitá činnost do určitého vlákna. Proto jsem uvedl ty příklady, kde to prog vůbec neřeší.

A o jaké konkrétní programy ti jde? Co se týče desktopu nebo pracovní stanice a uživatelských aplikací určených pro toho člověka, který u počítače sedí, tak tam mi to přijde jako zbytečná otázka, protože výkon současného HW je pro potřeby jednoho člověka brutálně předimenzovaný a pokud se systém jeví jako pomalý, tak je to spíš špatně odvedená práce autorů softwaru – tzn. je to řešitelné v rámci stávajícího paradigmatu, jen stačí dodržovat doporučení a nedělat základní chyby, nekašlat úplně na všechno, co se učí i v prvním semestru SW inženýrství. Pokud jde o zpracování velkého množství dat nebo zpracování požadavků velkého počtu uživatelů na sdíleném stroji (serveru), tak bývají jednoduše paralelizovatelné úlohy, protože tam na první pohled vidíš, co může běžet vedle sebe, je na sobě nezávislé, a co na sebe musí čekat a synchronizovat se.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
Heron avatar 23.8. 13:34 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Tohle mi přijde jako poněkud zvláštní směr uvažování. Podle mého by se k tomu mělo přistupovat spíš z druhé strany: mám nějaký problém, požadavky, potřebu → hledám vhodný hardware. A ne naopak, že si koupím 256jádrový procesor a pak teprve začnu vymýšlet, k čemu a jak ho použiji.
Hlavním důvodem tohoto blogu a taky toho, proč jsem po 8 letech něco napsal na ABCLinuxu, byla především diskuse a ta se velmi povedla a díky všem za ni.

Jinak to cos popsal není můj směr uvažování. Já mám dat, že bych tím mohl vytížit i 4096 jádro. Nebo procesorů na síti. Což ve skutečností provozuju (ne to 4096core ale distribuované počítání).
Další změna je třeba rostoucí rozlišení u videí, fotek nebo zvukových záznamů a jejich rostoucí počet. Pokud je počet souborů vyšší než počet jader, lze to paralelizovat opět naprosto primitivním způsobem (třeba tím xargs nebo parallel) a není potřeba měnit algoritmus. Pokud chceš jeden soubor zpracovat rychle ve více vláknech, změna algoritmu je potřeba, ale díky vyššímu rozlišení to jde i relativně jednoduše rozsekáním na menší části, které se pak zase poskládají dohromady.
Přesně tak.
Představ si, že máš jeden server, který obsluhuje velký počet uživatelů. Díky tomu, že jich je víc než jader, jsou schopní naplno vytížit CPU a tím využít hardware efektivně.
To je zase podle mě chybný pohled na věc. Podle mě bych se vůbec neměl řídit tím, kolik uživatelů naplní potenciál cpu na serveru, ale měl bych to psát tak, aby to po přehození na vyšší počet cpu mohl využít. Dám příklad z FreeBSD. Ve FreeBSD se na celkem dost systémových úkonů používá Make a ty Makefile obsahují velký počet celkem triviálních úkolů. Když jsem to přestěhovat z dvoujádra na osmijádro, tak při zachování celé instalace svižnost systému vzrostla určitě více než 4x. Tj ten OS má dost úkolů, které může distribuovat mezi procesory. A nemyslím si, že by ty Makefile měly být psány s ohledem na nějaký počet cpu. Prostě pokud se dá udělat malý úkol, měl by zůstat malý bez ohledu na to, že jich tam celkově budou desetitisíce.

Kdyby ti uživatelé psali svoje programy tak jak navrhuješ, tak by přestěhování na výrazně vyšší počet cpu nemělo takový efekt. Proto si myslím, že je vhodnější to psát paralelizovatelně bez ohledu na skutečný počet aktuálně dostupných procesorů.
Když se dívám na to, jak se dneska vrší jedna vrstva na druhou, jak si např. lidi pouští mnoho instancí webového prohlížeče a dalších komponent i pro triviální aplikace, jak roste komplexita… tak vidím ty rezervy úplně někde jinde, než v nějakých automatických optimalizacích. Když některé vrstvy/komponenty proškrtáš, tak ušetříš mnohem víc, než když je tam necháš a budeš je (sebelépe) optimalizovat.
Na tom se shodneme.
A o jaké konkrétní programy ti jde?
V tom konkrétním tebou vypíchnutém odstavci o žádné. Jde mi jen o vyjádření myšlenky, že místo explicitního psaní "tady bude vlánko a bude dělat to a to" se to stane jaksi samo implicitně bez zásahu proga.
Co se týče desktopu nebo pracovní stanice a uživatelských aplikací určených pro toho člověka, který u počítače sedí, tak tam mi to přijde jako zbytečná otázka, protože výkon současného HW je pro potřeby jednoho člověka brutálně předimenzovaný a pokud se systém jeví jako pomalý, tak je to spíš špatně odvedená práce autorů softwaru – tzn. je to řešitelné v rámci stávajícího paradigmatu, jen stačí dodržovat doporučení a nedělat základní chyby, nekašlat úplně na všechno, co se učí i v prvním semestru SW inženýrství.
Mě se brutálně předimenzovaný tedy nezdá a jako příklad uvedu to, co jsem psal v minulosti už několikrát. Tak triviální věc jako prohlížeč obrázků. Dekódovat jeden obrázek dnešních rozlišení rozhodně není z hlediska lidského vnímání hned. Proto by mi přišlo logické, kdyby prohlížeče obrázků na pozadí v dalších vláknech / procesech načítaly a do paměti dekódovaly další obrázky v adresáři. Tj spustím prohlížeč nad složkou kde jsou tisíce obrázků, prohlížeč zjistí, že mám 16jádro, a v dalších threadech začne načítat dalších 16 obrázků, protože lze očekávat, že na ně za chvíli dojde řada pro zobrazení. Na to mi tady někdo minule napsal "ale to by se ti roztočil ventilátor"... Takže ano, částečně souhlasím s tím, že je to špatná práce sw inženýra, ale když takhle blbě se dneska píše skoro všechno.
xkucf03 avatar 23.8. 14:37 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Kdyby ti uživatelé psali svoje programy tak jak navrhuješ, tak by přestěhování na výrazně vyšší počet cpu nemělo takový efekt. Proto si myslím, že je vhodnější to psát paralelizovatelně bez ohledu na skutečný počet aktuálně dostupných procesorů.

Já to nenavrhuji – je to vlastně současný stav a tím návrhem na změnu je naopak to, že použijeme jiný jazyk, který to nějak zázračně implicitně paralelizuje. Pokud tahle změna bude zadarmo a nebude mít žádné negativní dopady ani režii, tak není důvod do toho nejít.

Pokud ten přechod ale nějaké negativní dopady a režii má, tak je na místě se ptát, co mi to přinese a co mi to vezme a porovnávat si to. A co jsem se právě snažil říct tím:

Představ si, že máš jeden server, který obsluhuje velký počet uživatelů. Díky tomu, že jich je víc než jader, jsou schopní naplno vytížit CPU a tím využít hardware efektivně.

je fakt, že paralelizace má přínos jen v případě, že ta nevytížená jádra máš. Pokud je nemáš (protože řešených úloh ve frontě je tolik, že čekají, až na ně volné jádro vyjde), tak ta dodatečná paralelizace má nulový pozitivní efekt, ale ty nevýhody a režie zůstávají. Takže ve chvíli, kdy se tvůj počítač fláká a ty jen klikáš v GUI, tak by se ti např. mohla zlepšit odezva uživatelského rozhraní. Ale ve chvíli, kdy svoje procesory vytěžuješ kódováním videa, kompilací nebo třeba na serveru obsluhuješ tolik příchozích požadavků, že dosáhneš zátěže CPU, kterou sis naplánoval1, tak ti ta dodatečná paralelizace už nic nepřinese.

Hello world příklad, jak ti implicitní paralelizace zrychlí program, tedy bude na nevytíženém systému vypadat úžasně, ale na vytíženém se tento efekt vytrácí. Tím nechci říct, že to nemá smysl vůbec – ale že to platí jen za specifických podmínek a obecně to nebude takový zázrak, jak si od toho asi hodně lidí slibuje.

Pak taky záleží na tom, zda se snažíš minimalizovat a) čas zpracování úlohy nebo b) spotřebu elektřiny na zpracování dané úlohy. Pokud bys měl nulovou režii uspávání a zapínání jader CPU a měl volná jádra, tak ti to umožní zkrátit čas zpracování úlohy. Pokud tě ale zajímá víc poměr výkon/spotřeba, tak na té paralelizaci vlastně nezáleží, protože více zapnutých jader (CPU nebo dokonce serverů, pokud jde o větší úlohy a vyplatí se kvůli nim zapínat další servery) znamená i větší spotřebu. Na sdílené pronajímané infrastruktuře pak neplatíš přímo za elektřinu ale za ty využité zdroje – a jestli využíváš jeden zdroj delší dobu nebo více zdrojů paralelně kratší dobu, ti asi nic moc neušetří.

Jakási mikrooptimalizace by mohla spočívat v tom, že by ses vždy podíval, kolik máš aktuálně zapnutých jader a podle toho se rozmyslel, zda úlohu pustíš přesně v tolik vláknech, nebo zda nějaká vypneš a pustíš to v menším počtu vláken, nebo naopak další zapneš a pustíš to více paralelně. Režie takového rozhodování ale může hravě převýšit užitek a navíc to musíš koordinovat napříč všemi programy běžícími v daném systému tzn. není to řešitelné v rámci jednoho procesu a programovacího jazyka. Jinak by ti ta jádra, o kterých si myslíš, že jsou volná, mezi tím obsadil jiný program.

[1] nechceš, aby servery běžely naprázdno (mimo špičku je třeba automaticky vypnínáš), ale na druhou stranu zase nechceš mít 100 % vytížení CPU a chceš si tam nechat nějakou rezervu

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
Heron avatar 23.8. 14:58 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
je fakt, že paralelizace má přínos jen v případě, že ta nevytížená jádra máš. Pokud je nemáš (protože řešených úloh ve frontě je tolik, že čekají, až na ně volné jádro vyjde), tak ta dodatečná paralelizace má nulový pozitivní efekt, ale ty nevýhody a režie zůstávají. Takže ve chvíli, kdy se tvůj počítač fláká a ty jen klikáš v GUI, tak by se ti např. mohla zlepšit odezva uživatelského rozhraní.
To není zcela pravda, protože paralelizace pomáhá i na single cpu. Ne každá úloha je pořád cpu bound, taky někdy načítá data z disku a komunikuje třeba po síti. Takže je výhodou mít víc procesů i v případě málojaderného cpu.
Ale ve chvíli, kdy svoje procesory vytěžuješ kódováním videa, kompilací nebo třeba na serveru obsluhuješ tolik příchozích požadavků, že dosáhneš zátěže CPU, kterou sis naplánoval1, tak ti ta dodatečná paralelizace už nic nepřinese.
Přijde mi, že se trochu zapomíná na prioritu procesů. Já běžně kóduju video a u toho dělám další činnost a nebo třeba hraju hry. A viz výše, žádný proces, ani to kódování videa, kompilace nebo hraní her nevytěžuje cpu vždy na max, takže se tam prostřídají úlohy s nižší prioritou. Takže průměrné vytížení CPU se dlouhodobě může blížit 100% a tohoto vytížení je dosaženo mnoha různými úlohami (aktuálně mám na pozadí kódování videa a vůbec nijak mě to neomezuje v dalších činnostech a zcela běžně mám ještě na pozadí pauznutou nějakou hru, kterou si ve volné chvíli vytáhnu na monitor).
Hello world příklad, jak ti implicitní paralelizace zrychlí program, tedy bude na nevytíženém systému vypadat úžasně, ale na vytíženém se tento efekt vytrácí. Tím nechci říct, že to nemá smysl vůbec – ale že to platí jen za specifických podmínek a obecně to nebude takový zázrak, jak si od toho asi hodně lidí slibuje.
Viz výše, odpovědí jsou priority procesů.
a) čas zpracování úlohy nebo b) spotřebu elektřiny na zpracování dané úlohy
Spotřeba elektřiny bude v obou případech teoreticky stejná, protože na tu úlohu je potřeba stejného počtu elementárních výpočtů, které vyžadují svou energii. Ve skutečnosti ale spotřeba elektřiny v prvním případě (tj rychlejšího zpracování) je nižší, protože v kompu jsou "režijní" komponenty, které žerou proud tak jako tak. Tj nápad snížit rychlost výpočtu aby se snížila energie nedává žádný smysl. Pochopitelně příkon je nižší. Ale energie je příkon krát čas. (Nebo jsem možná i vzhledem k dalším odstavcům jen nepochopil, co tím vlastně chceš říct.)
xkucf03 avatar 25.8. 10:13 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor

Ne každá úloha je pořád cpu bound, taky někdy načítá data z disku a komunikuje třeba po síti. Takže je výhodou mít víc procesů i v případě málojaderného cpu.

Pokud úloha čeká na I/O, tak nevytěžuje jádro tzn. nevytížená jádra můžeš mít, i když máš víc spuštěných úloh než jader. Pointa byla v tom, že v určitém bodě se to saturuje a další paralelizace už nemá smysl nebo je dokonce kontraproduktivní. Ano, nastává to typicky ve chvíli, kdy je počet běžících úloh mírně vyšší než počet jader – ve chvíli, kdy je jen stejný, tak to ještě saturované není, kvůli tomu čekání na I/O, ale ten bod zlomu nepochybně existuje.

Ostatně dobrým příkladem jsou HTTP servery. Jednu dobu se pro každé příchozí spojení spouštělo jedno vlákno/proces, ale pak se přišlo na to, že na hodně navštěvovaných serverech není taková paralelizace optimální a je lepší pustit menší počet vláken/procesů a úlohy v nich odbavovat vlastně více sekvenčně. A pokud na tom stroji běží i jiné služby jako třeba databáze, nějaké fronty nebo další servery, tak nakonec o počtu vláken přidělených jednotlivým službám ručně rozhoduje administrátor a neděje se to nějak samo, že by za tebe optimální konfiguraci vymyslel jazyk nebo jeho kompilátor. Pokud by se to mělo automatizovat, tak to vyžaduje minimálně účast plánovače OS.

Stejné je to s RAM – tam bys taky mohl říct, ať si každý program vezme, kolik chce, a udělat velký swap a ať se mezi sebou nějak poperou a OS rozhodne o tom, co skončí ve swapu a co ve fyzické RAM. Ale to taky není optimální řešení a pravděpodobně tam budeš jednotlivým komponentám (databáze, aplikační server atd.) chtít alespoň naznačit, kolik paměti si která může vzít.

Totéž v případě úložišť – asi tam budeš mít nějaké rychlé SSD/NVME disky, pak nějaké pomalejší a pak nějaké úplně nejpomalejší kdesi na síti. A taky budeš chtít nějak inteligentně rozhodnout o tom, kolik kapacit v které kategorii si může která služba vzít. Kdybys to rozhodnutí nechal na těch službách/programech, tak si každý vezme co nejvíc toho co nejrychlejšího úložiště, ale z pohledu celého systému to optimální (nebo vůbec proveditelné) nebude.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
Heron avatar 25.8. 10:38 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
mírně vyšší než počet jader
Přičemž v praxi to mírně může být klidně 10x.
Ostatně dobrým příkladem jsou HTTP servery. Jednu dobu se pro každé příchozí spojení spouštělo jedno vlákno/proces, ale pak se přišlo na to, že na hodně navštěvovaných serverech není taková paralelizace optimální a je lepší pustit menší počet vláken/procesů a úlohy v nich odbavovat vlastně více sekvenčně.
Tady se míchají dvě věci. Dodnes se u webů, které skutečně něco dělají, používá proces per client a není na tom nic špatného.

U webů, které "jen" posílají drobný statický obsah se tento přístup neosvědčil a přešlo se na event model. V praxi to vypadá tak, že na drobný statický obsah se používá event base webserver a zbytek se předává na těžkotonážní proces per client (to už nemusí být vyloženě plnohodnotný webserver ale třeba FCGI proces skriptovacích jazyků).
A pokud na tom stroji běží i jiné služby jako třeba databáze, nějaké fronty nebo další servery, tak nakonec o počtu vláken přidělených jednotlivým službám ručně rozhoduje administrátor a neděje se to nějak samo, že by za tebe optimální konfiguraci vymyslel jazyk nebo jeho kompilátor. Pokud by se to mělo automatizovat, tak to vyžaduje minimálně účast plánovače OS.
Viz níže. Tohle považuju za předčasnou optimalizaci a v praxi se to moc neřeší.
Stejné je to s RAM – tam bys taky mohl říct, ať si každý program vezme, kolik chce, a udělat velký swap a ať se mezi sebou nějak poperou a OS rozhodne o tom, co skončí ve swapu a co ve fyzické RAM. Ale to taky není optimální řešení a pravděpodobně tam budeš jednotlivým komponentám (databáze, aplikační server atd.) chtít alespoň naznačit, kolik paměti si která může vzít.
Swap se nepoužívá. Na serveru už rozhodně ne. K tomu dalšímu, je pochopitelně otázka, co je to za konkrétní program. Ano, některé programy si myslí, že zvládnou práci lépe než např. iocache v OS, ale tak ty si dáme na blacklist. Normální programy používají výhod OS a neřeší co nemusí a vezmou si jen tolik paměti, kolik potřebují. Ano jistě, některé potřebují hint. Taky je otázkou, zda je vhodné mixovat jednotlivé programy na jednom stroji (za předpokladu, že to chceš takhle brutálně optimalizovat). Už jen tato skutečnosti by ti měla naznačit, že bys to možná měl rozdělit na různé stroje.
Totéž v případě úložišť – asi tam budeš mít nějaké rychlé SSD/NVME disky, pak nějaké pomalejší a pak nějaké úplně nejpomalejší kdesi na síti. A taky budeš chtít nějak inteligentně rozhodnout o tom, kolik kapacit v které kategorii si může která služba vzít. Kdybys to rozhodnutí nechal na těch službách/programech, tak si každý vezme co nejvíc toho co nejrychlejšího úložiště, ale z pohledu celého systému to optimální (nebo vůbec proveditelné) nebude.
Tohle je na samostatnou debatu. V prvním přiblížení říkám ano, každý proces má právo přistupovat ke storage stejně jako kterýkoliv jiný. Někde jsi tady obhajoval abstrakci rozdělení do vrstev, tak tady to máš na stříbrném podnose. Proces vidí jen VFS. ;-)

A jakožto člověk, co se dlouhodobě zabývá FS a storage systémy to pochopitelně vnímám trochu komplikovaněji a předchozí odstavec svým způsobem nemám rád. Ale na vysvětlení toho proč by to chtělo mnohem víc prostoru. Souvisí to totiž s návrhem celého systému, který na tom chceme provozovat. A ten, kdo to navrhuje by měl na straně jedné znát data, co se mají ukládat a požadavky na to ukládání kladené a na straně druhé znát specifika jednotlivých storage systémů. Třeba jednou někoho takového potkám a nebudu to musel suplovat. ;-) (Konec osobního traumatu :-D). Ale jasně, tohle se opět týká brutálně optimalizovaných systémů, kde se řeší každý kB/s. V praxi je levnější koupit nové pole. Prostě je to tak, i když s tím často nesouhlasím.
Heron avatar 25.8. 11:16 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Příloha:
Přičemž v praxi to mírně může být klidně 10x.

Abych to ilustroval, v příloze je rychlý test z POVRay na Ryzenu 1700 (8 core / 16 thr). Jedná se o čistě CPU bound úlohu (raytracing, pravda, v této scéně je i trocha radiozity) a těžko říct, jak moc je POVRay optimalizovaný (tato verze 3.7 je první s podporou multithreadingu) a přes to mu nedělá 80 vláken problém. Rozdíl mezi optimem na 16 vláknech a 80 vlákny je jen 6.4%.

Takže se opravdu netřeba bát programů, které si automaticky naspawnují počet procesů podle počtu cpu.
xkucf03 avatar 25.8. 12:45 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor

Tohle jsou dost dobré výsledky1 a nad 6,4% rozdílem2 bych asi mávl rukou a neřešil ho.

[1] nevím, jak moc typické – jinde ta režie s více vlákny a rozdělením úlohy na malé kousky může být vyšší
[2] nebo někomu může stát za to, řešit i takhle malý rozdíl tzn. když bude mít na systému s 16 jádry pět služeb, nebude chtít spustit všechny s 16 vlákny a mít celkem 80 paralelně běžících vláken

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
xkucf03 avatar 25.8. 12:38 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Přičemž v praxi to mírně může být klidně 10x.

Teoreticky to může být libovolné číslo v závislosti na charakteru I/O operací a úložiště. Tím spíš nelze říct, ať si program vytvoří tolik vláken, kolik máme jader. Nakonec se používá nějaká kombinace alchymie, intuice a zkušenosti, kde si vymyslíš, jaké bude třeba Xmake -j X.

Tohle považuju za předčasnou optimalizaci a v praxi se to moc neřeší.

Já to v praxi taky moc neřeším – pokud programy dobře fungují s výchozím nastavením vláken (a třeba limitů RAM nebo adresářů, kam co ukládat), tak do toho taky nevrtám a jsem spokojený. Ono to nějak funguje a ty potenciální úspory, které by optimalizace přinesla, jsou menší, než práce navíc. Takže ano, často by šlo o předčasnou optimalizaci.

Nicméně je to takový „dřevorubecký“ přístup ve stylu pustíme X vláken na Y-jádrovém procesoru a plánovač už si s tím poradí. I tento přístup funguje relativně dobře. Ale měl jsem pocit, že tahle diskuse je nikoli o nějakém „good enough“ řešení, ale o hledání něčeho lepšího, promyšlenějšího – a to je daleko složitější a je potřeba řešit ty různé věci, o kterých tu píšu. A nebo si říct, že nám za to tahle optimalizace nestojí – to je taky racionální úvaha.

Normální programy používají výhod OS a neřeší co nemusí a vezmou si jen tolik paměti, kolik potřebují.

Jednu úlohu lze obvykle řešit různými způsoby a některé budou více náročné na RAM, některé na CPU a jiné třeba na úložiště a síť. Tím, že programu naznačíš, kolik si kterých zdrojů může vzít, mu dáváš šanci ten algoritmus vhodně parametrizovat nebo zvolit jiný algoritmus vhodnější pro dané podmínky.

Taky je otázkou, zda je vhodné mixovat jednotlivé programy na jednom stroji (za předpokladu, že to chceš takhle brutálně optimalizovat). Už jen tato skutečnosti by ti měla naznačit, že bys to možná měl rozdělit na různé stroje.

Dneska jsou ty různé stroje typicky VM běžící na jednom fyzickém stroji, kde v lepším případě má každá virtuálka přidělená nějaká fixní jádra, v horším případě se perou navzájem o fyzická jádra. V tom druhém případě je to oddělení celkem na nic, protože se stejně budou navzájem ovlivňovat. V tom prvním je to pak podobné, jako kdybys to pustil na jednom stroji a jednotlivým službám přidělil nějaký počet vláken.

Jak jsem tu někde psal, mohlo by pomoci, kdyby si služba pustila třeba X vláken s normální prioritou a Y s nižší (tak aby celkový počet byl optimální pro případ, že na tom systému nic jiného neběží) a takových služeb by ti tam běželo několik (jednotlivá X bys volil tak, aby rozdělení kapacit mezi jednotlivé služby bylo spravedlivé resp. tak, jak potřebuješ pro plynulý chod celého systému) a plánovač by věděl, že ta vlákna s nižší prioritou má pouštět jen ve chvíli, kdy má volná jádra. A program by se pak měl umět vypořádat se situací, kdy vlákno s normální prioritou doběhne výrazně dřív než vlákno s nižší tzn. měl by umět přehodit nedokončenou práci z jednoho vlákna na jiné – nebo by to mohl udělat plánovač (když bude vědět, která vlákna patří k sobě, a že když to prioritnější doběhne, má dostat prioritu to další ze stejné skupiny). Nicméně pokud si myslíš, že režie přepínání vláken/procesů je dostatečně nízká, tak to je zbytečná mikrooptimalizace.

V prvním přiblížení říkám ano, každý proces má právo přistupovat ke storage stejně jako kterýkoliv jiný. Někde jsi tady obhajoval abstrakci rozdělení do vrstev, tak tady to máš na stříbrném podnose. Proces vidí jen VFS.

To není nic proti ničemu. Mít společnou abstrakci a pracovat s úložišti jednotným způsobem je dobré. Ale ty můžeš říct programu, ať si dá primární data do jednoho adresáře, dočasné soubory do druhého a logy do třetího atd. a tím to vyladit, aniž by program věděl, které úložiště je rychlé a které pomalé nebo co jsou lokální disky a co síťové.

A ten, kdo to navrhuje by měl na straně jedné znát data, co se mají ukládat a požadavky na to ukládání kladené a na straně druhé znát specifika jednotlivých storage systémů.

Stejně tak lze přistupovat k těm vláknům a snažit se nějak vymyslet, v kolika vláknech by měl běžet aplikační server, v kolika databáze, jaké by jednotlivé procesy měly mít priority atd.

V praxi je levnější koupit nové pole. Prostě je to tak, i když s tím často nesouhlasím.

Analogicky lze říct, že pustíme všechny programy s třeba dvojnásobným počtem vláken, než máme jader, a nějak to dopadne. Je to asi o tom, jak moc si s tím člověk chce hrát a ladit to.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
Heron avatar 25.8. 13:04 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Nicméně je to takový „dřevorubecký“ přístup ve stylu pustíme X vláken na Y-jádrovém procesoru a plánovač už si s tím poradí. I tento přístup funguje relativně dobře.
Viz graf, který jsem tady přikládal. On ten dřevorubecký přístup má opodstatnění tam, kde je systém velmi necitlivý na změnu parametrů. Tj změníš počet vláken na libovolné číslo od 16 do 80 (a jistě by to pokračovalo i dál) a ono se nic nestane (kde ono nic je v tomto problému 6%). Takovou úlohu nemá cenu optimalizovat a má smysl přejít na jiné parametry, které jsou na změnu daleko citlivější (třeba změna nastavení renderingu přinese stovky procent).

Ale měl jsem pocit, že tahle diskuse je nikoli o nějakém „good enough“ řešení, ale o hledání něčeho lepšího, promyšlenějšího – a to je daleko složitější a je potřeba řešit ty různé věci, o kterých tu píšu.
To je velmi dobrá poznámka a je vidět, že tady v diskusi každý přistupujeme ze svého pohledu a každý ten problém vidíme jinak. Proto jsem ani nereagoval na Michala Kubečka (kterého si samozřejmě velmi vážím), protože o jeho doméně, tedy jaderný vývoj síťového stacku nevím vůbec nic a stojí vlastně na přesně opačné straně toho, co běžně řeším já, tedy paralelizace zpracování velkých balíků dat.
Jednu úlohu lze obvykle řešit různými způsoby a některé budou více náročné na RAM, některé na CPU a jiné třeba na úložiště a síť. Tím, že programu naznačíš, kolik si kterých zdrojů může vzít, mu dáváš šanci ten algoritmus vhodně parametrizovat nebo zvolit jiný algoritmus vhodnější pro dané podmínky.
To jistě.
Dneska jsou ty různé stroje typicky VM běžící na jednom fyzickém stroji, kde v lepším případě má každá virtuálka přidělená nějaká fixní jádra, v horším případě se perou navzájem o fyzická jádra. V tom druhém případě je to oddělení celkem na nic, protože se stejně budou navzájem ovlivňovat. V tom prvním je to pak podobné, jako kdybys to pustil na jednom stroji a jednotlivým službám přidělil nějaký počet vláken.
Ano, to je znak dnešní doby. Místo, aby se virtuální prostředí využilo tam, kde to má smysl a vysokou přidanou hodnotu, tak se používá všude a ještě se nad tím staví různé vzdušné zámky. Trochu se zapomíná na to, že existuje taky fyzické železo a některé úlohy lze provozovat s výhodou rovnou tam.
To není nic proti ničemu. Mít společnou abstrakci a pracovat s úložišti jednotným způsobem je dobré. Ale ty můžeš říct programu, ať si dá primární data do jednoho adresáře, dočasné soubory do druhého a logy do třetího atd. a tím to vyladit, aniž by program věděl, které úložiště je rychlé a které pomalé nebo co jsou lokální disky a co síťové.
Tak já myslím, že každý, kdo mě trochu zná a ví, jaké články jsem v průběhu let napsal, tak pochopil, že to bylo myšleno spíš ironicky.
Stejně tak lze přistupovat k těm vláknům a snažit se nějak vymyslet, v kolika vláknech by měl běžet aplikační server, v kolika databáze, jaké by jednotlivé procesy měly mít priority atd.
Jenže, a omlouvám se, že se k tomu stále vracím, tahle optimalizace pracuje v těžce necitlivé oblasti. Prostě to nemá smysl řešit. Zatímco v případně dnešního storage se stále ještě vyplatí optimalizovat až na úroveň každé jednotlivé tabulky a umístění indexu na různé storage, tak u počtu vláken tohle příliš nefunguje. (Teď mě určitě někdo rozseká nějakým hororovým příběhem o tom jak plánování na NUMA nodech těžce selhalo. )
25.8. 13:38 PetebLazar
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Cca 20 let stará příručka Mistrovství v Oracle 7 prakticky začíná: Vezměte 7 HDD na (system, table, index, temp, rollback tablespacy, na logfiles, archivy logfile). Někdy mám pocit, že většina tu první kapitolu přeskočila.

25.8. 11:22 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Ostatně dobrým příkladem jsou HTTP servery. Jednu dobu se pro každé příchozí spojení spouštělo jedno vlákno/proces, ale pak se přišlo na to, že na hodně navštěvovaných serverech není taková paralelizace optimální a je lepší pustit menší počet vláken/procesů a úlohy v nich odbavovat vlastně více sekvenčně.
To není pravda. Tam nešlo o to, že vlákna/procesy by byly "moc paralelizace", ale o to, že vlákna/procesy mají moc velký overhead. HTTP server typicky odbavuje paralelně, akorát se ten paralelismus řeší na jiný úrovni (v rámci nějakého event loopu s použitím např. epollu, kqueue apod.). To, že v jedný chvíli odbavuje ten server jen nějakej subset spojení/tasků nezmanená, že to je sekvenční - když si vytvoříš hromadu procesů/vláken, tak se v jedný chvíli taky provádí jen tolik, kolik zvládnou najednou CPU.

Koneckonců, z tohoto důvodu je úspěšný např. jazyk Go.
xkucf03 avatar 25.8. 13:09 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Tam nešlo o to, že vlákna/procesy by byly "moc paralelizace", ale o to, že vlákna/procesy mají moc velký overhead.

O tom právě celou dobu mluvím, že ta paralelní vlákna/procesy mají nějakou nenulovou režii.

To, že v jedný chvíli odbavuje ten server jen nějakej subset spojení/tasků nezmanená, že to je sekvenční - když si vytvoříš hromadu procesů/vláken, tak se v jedný chvíli taky provádí jen tolik, kolik zvládnou najednou CPU.

Odebíráš z fronty události (sekvenčně) a rozhazuješ je mezi dostupná vlákna/procesy (které pak běží paralelně). Když ti třeba nějaké náročné úlohy vyžerou tři vlákna ze čtyř a ucpe se to, tak ten zbytek událostí se bude zpracovávat už čistě sekvenčně v tom jednom zbylém vlákně.

Ano, je to sekvenční i paralelní zároveň. Ale ve srovnání s přístupem, kdy pro každý požadavek spustíme nové vlákno/proces, asi můžeme říct, že tento přístup jen více sekvenční a méně paralelní.

Koneckonců, z tohoto důvodu je úspěšný např. jazyk Go.

Já pořád nevím, jestli je objektivně úspěšný nebo jen módní. Když si čtu, jak si někteří lidé pochvalují Go nebo Clojure atd. a srovnávají ho s Javou, tak tam nelze přehlédnout fakt, že ti lidé najednou programují úplně jiným stylem, než programovali v Javě (nebo v jiném jazyce, se kterým to srovnávají). Kdyby ale stejný styl uplatnili i v té Javě (což lze, jen na to nebyli zvyklí), tak by výsledek byl stejný. Tato srovnání mi tedy přijdou dost neobjektivní, protože když člověk při příležitosti změny jazyka změnil zrovna i přístup k programování, tak to neříká celkem nic.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
25.8. 15:06 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Odebíráš z fronty události (sekvenčně) a rozhazuješ je mezi dostupná vlákna/procesy (které pak běží paralelně).
Úplně to samé ale přece platí pro scheduller vláken/procesů (rozhazuje mezi CPU/jádra/hw thready).
Ano, je to sekvenční i paralelní zároveň. Ale ve srovnání s přístupem, kdy pro každý požadavek spustíme nové vlákno/proces, asi můžeme říct, že tento přístup jen více sekvenční a méně paralelní.
Ne, to nemůžeme. To se ti právě snažím říct, že to je úplně stejně paralelní. Akorát ten scheduling těch tasků nedělá OS, ale nějaká userspace implementace nad primitivy OS. Z hlediska paralelismu to vyjde nastejno.

Vlastně je to naopak více paralelní v tom smyslu, že těch tasků můžeš díky tomu nízkému overheadu vytvořit mnohem (řádově) více než threadů/procesů.
Já pořád nevím, jestli je objektivně úspěšný nebo jen módní. Když si čtu, jak si někteří lidé pochvalují Go nebo Clojure atd. a srovnávají ho s Javou, tak tam nelze přehlédnout fakt, že ti lidé najednou programují úplně jiným stylem, než programovali v Javě (nebo v jiném jazyce, se kterým to srovnávají). Kdyby ale stejný styl uplatnili i v té Javě (což lze, jen na to nebyli zvyklí), tak by výsledek byl stejný. Tato srovnání mi tedy přijdou dost neobjektivní, protože když člověk při příležitosti změny jazyka změnil zrovna i přístup k programování, tak to neříká celkem nic.
Změna jazyka většinou znamená i změnu stylu, to mi nepřijde překvapivý. Java má v porovnání s Go tu smůlu, že Go ji poráží její vlastní dřívější PR strategií (tj. hlavně "jednoduchost"/"snadnost" daná nízkou úrovní abstrakce), ale zároveň není zatíženo OOP módou a může taky být efektivnější (hodnotové typy, kompilace do nativního kódu). IMO Java to bude mít proti Go dost těžké, zejména jestli teď konečně dostane generika ...
xkucf03 avatar 25.8. 16:19 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
25.8. 23:54 oryctolagus | skóre: 29 | blog:
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
TL;DR Java doufá, že ji spasí GraalVM. Osobně jsem si na něj zatim moc neudělal názor.

Ze zvědavosti: Jakej je rozdíl mezi OSS a Enterprise edicí?
xkucf03 avatar 26.8. 00:06 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše GraalVM

AFAIK jen výkonnostní – v té EE jsou nějaké optimalizace navíc, které chce Oracle prodávat velkým firmám typu Twitter a financovat z toho vývoj celého GraalVM.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
23.8. 15:30 PetebLazar
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Z mého pohledu rozlišuji zda je dosaženo zvýšení pohodlí, či docíleno jiné funkčnosti. Na praktickém příkladu: zkrácení renderingu webových stránek o pozorovatelný rozdíl je myslím zvýšením pohodlí (kvantitativní změna). Proti tomu docílit díky vhodné paralelizaci (CPU/GPU) při zpracování vstupních multimediálních dat toho, že je možné výsledek sledovat v reálném čase je o již změně funkčnosti (kvalitativní změna) umožňující např. úpravu workflow. Ten kdo ve svém řešení nabízí novou "kvalitu" pak má nepopiratelnou konkurenční výhodu.
Josef Kufner avatar 23.8. 13:50 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Podpora paralelizace na úrovni syntaxe jazyka může přidat nějaké pohodlí, ale podle mého se dobrý jazyk pozná spíš tak, že je dostatečně pružný na to, aby takovéto vylepšení (a nemusí jít jen o paralelizaci) umožnil zavést formou knihovny (a třeba anotací nebo jiného již existujícího jazykového prostředku) a bylo to ve výsledku srovnatelně pohodlné, aniž by se musela měnit syntaxe jazyka nebo specifikace běhového prostředí.
Docela hezký příklad je zavedení await/async v Javascriptu. V podstatě celá ta věc je jen syntaktický cukr nad promises. Tedy zavedla se knihovna, která řešila nepohodlí. Knihovna se standardizovala a následně se ke knihovně dodělal syntaktický cukřík, aby se to používalo ještě pohodlněji.

V případě paralelních výpočtů by to asi mohlo být podobné. Jen je potřeba, aby ten jazyk měl připravené to správné podhoubí ze kterého takové funkce mohou vyrůst. Například Rust se v tomto směru tváří docela nadějně právě díky tomu, jak pracuje s kontextem proměnných.
Hello world ! Segmentation fault (core dumped)
xxx avatar 23.8. 14:54 xxx | skóre: 42 | blog: Na Kafíčko
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Problem jazyka, ktery by mel sam umet resit paralelni vypocty vidim v tom ze u:

for (i = 0; i < len(a); i++) { sum += a[i]; }

mu nebude stacit resit datove zavislosti a podle nich jen tak rozhazovat instrukce na jednotliva jadra, ale ze smycku musi nejdriv prevest na paralelni soucet, a pak teprve rozhodit na jednotliva jadra.

Coz znamena existenci prekladace vesticiho z kristalove koule, nebo neceho jako x = sum(a, i, +) coz uz klade naroky na znalosti programatora.
Please rise for the Futurama theme song.
Heron avatar 23.8. 15:12 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Tak by takovou smyčku prostě neparalelizoval. Cílem není paralelizovat všechno za každou cenu, ale to, co jde.

On i ten Pool.map() vyžaduje, aby ta funkce neměla vedlejší efekty, tedy aby neměnila sdílený stav.

Tj místo:
for item in input:
    output.append(funkce(item))
nebo ekvivalentu:
output = [f(item) for item in input]
by automaticky použil pool.map(funkce, input) a to všude tam, kde by mohlo dokázat, že funkce() nemá vedlejší efekty (což ví, protože na to stejně umí upozornit u toho map()) a taky tam, kde vykonávání funkce bude trvat delší než malou dobu (proto tady vidím potenciál pro běhové prostředí víc než pro kompilátor).

xxx avatar 23.8. 18:27 xxx | skóre: 42 | blog: Na Kafíčko
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Coz mj. znamena ze musi vedet, ze u append nezalezi na poradi. (Operace + je komutativni.) Coz netusim, jestli tade z nejakeho duvodu z neceho neplyne. TO muze byt dalsi problem pro automaticke rozhodovani.
Please rise for the Futurama theme song.
xkucf03 avatar 23.8. 18:34 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor

Tohle by šlo řešit nějakými anotacemi nad příslušnou metodou – jen deklaruješ určité vlastnosti a kompilátor/VM na základě toho pak může optimalizovat.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
23.8. 15:33 pc2005 | skóre: 38 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Nestačilo by jen ten sum analyzovat do stromu:
     O    - final sum (0123)
    / \   - a[3]
   O      - sum_012
  / \     - a[2]
 O        - sum_01
/ \       - a[0], a[1]
A pak na základě pravidel komutativity a HW schopností přenosu a[0] a a[1] v jednom burstu ten strom vyvážit:
     O    - final sum (0123)
    / \   
   O   O   
  / \ / \   
a jednotlivé (nezávislé) branche pustit na různých ALU?

(samozřejmě ta databáze pravidel by byla velká jako kráva :-D )
xxx avatar 23.8. 15:49 xxx | skóre: 42 | blog: Na Kafíčko
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Stacilo. Ted to jen mit univerzalne pro vsechny seriove algoritmy. ;-)
Please rise for the Futurama theme song.
24.8. 04:42 pc2005 | skóre: 38 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Všechny ne, jenom ty, na které jsme omezeni schopnostmi hardware (dneska třeba SSE, AVX) a pak třeba i jen ty, který jsou nejčastější v instrukčním mixu.
xkucf03 avatar 23.8. 16:22 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor

Ono jsou tu dva úkoly: 1) umět paralelizovat úlohu a 2) rozhodnout, kdy má paralelizace smysl.

IMHO nelze předpokládat, že paralelizace má smysl vždy, kdy ji umíme provést – protože do paměti těch jader je potřeba rozkopírovat určitá data dané úlohy a při střídání úloh tato data prohazovat. A pak může nastat situace, že na počítači s dvou-jádrovým procesorem, kde řešíš dvě úlohy je lepší je pustit jedno-vláknově, každou na jednom dedikovaném jádře, než je pustit dvou-vláknově a mít celkově čtyři vlákna, která se střídají na dvou-jádrovém procesoru. (to je jen zjednodušený příklad, ty počty by byly vyšší) A pro takové rozhodnutí je potřeba mít přehled o všech úlohách běžících na daném počítači, o jejich CPU, IO a paměťové náročnosti (to vyžaduje nějaké předchozí profilování a nelze to vyvodit jen ze zdrojového kódu), prioritách a o zpracovávaných datech, která čekají na zpracování. Asi by to vyžadovalo nějaké nové rozhraní mezi programem a OS nebo dokonce mezi OS a CPU…

Třeba to jednou dospěje do fáze jako assembler vs. C, kde se dneska ve většině případů nevyplatí psát ručně assembler, protože kompilátor C nebo vyššího jazyka vygeneruje lepší strojový kód. Prostor pro zlepšení kompilátorů a běhových prostředí tady určitě je, jen nevím, jestli je k tomu nutné mít i nový jazyk – přijde mi, že to je ortogonální. Jazyk je jen způsob, jak programátor počítači řekne, co chce – a jak si to počítač zoptimalizuje a provede, to už je na něm. U těch stávajících jazyků resp. jejich kompilátorů a běhových prostředí neustále přibývají optimalizace a běh se zrychluje, aniž by bylo nutné měnit syntaxi jazyka. Tady je výhodou deklarativní zápis, který se optimalizuje snáze, ale i u ten imperativní kód lze analyzovat a odvodit z něj předpoklady, na kterých se dá při té optimalizaci stavět.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
24.8. 06:41 pc2005 | skóre: 38 | blog: GardenOfEdenConfiguration | liberec
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
protože do paměti těch jader je potřeba rozkopírovat určitá data dané úlohy a při střídání úloh tato data prohazovat.
V daném příkladě s forem bude kompilátor vědět která data bude mít které "vlákno" a už dostane předem ty správné adresy apod.
A pak může nastat situace, že na počítači s dvou-jádrovým procesorem, kde řešíš dvě úlohy je lepší je pustit jedno-vláknově, každou na jednom dedikovaném jádře, než je pustit dvou-vláknově a mít celkově čtyři vlákna, která se střídají na dvou-jádrovém procesoru.
V případě mnou navrhované architektury by byl takovej overhead minimální. Vlastně co jsem se koukal, tak třeba MT DSP u MIPSu umí něco co je hodně blízko. Přes konfigurační registr TCRestart si nastavíš adresu jakou začne thread vykonávat a po dokončení rutiny se může třeba i sám zastavit přes stejnej mechanismus. Samozřejmě by bylo potřeba tenhle mechanismus vylepšit (a odstranit spectre útoky :-D). Podobně bude kompilátor vědět jak dlouho ten for bude trvat, takže může vzniknout instrukce podobná prefetchi, která bude říkat procesoru kolik taktů bude rutina trvat. A ohledně nevýhodné paralelizace: tak i když bude ten strom rozřezán na paralelní podstromy nezávislého kódu, tak je jedno zda se zpracují sériově nebo paralelně (stejně jako HT omezuje paralelizmus ALU slotů pro jedno vlákno).

Jinak čekání na IO není takový problém, to by prostě bylo sched_yield().
Asi by to vyžadovalo nějaké nové rozhraní mezi programem a OS nebo dokonce mezi OS a CPU…
Jj jsem právě navrhoval kompletně nové CPU, které bere paralelizmus už od základu.
jen nevím, jestli je k tomu nutné mít i nový jazyk
Jo kompilátory mají velké rezervy, ale i dneska pomůže vyšší paralelizaci jazyk, co má tu podporu i v základu.
23.8. 22:05 dumblob | skóre: 10 | blog: dumblog
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Protože se tady množí komentáře, že (určitě/možná/pravděpodobně/...) stačí použít či rozšířit stávající jazyky (při zachování zpětné kompatibility), tak uvedu jeden příklad za všechny, který to dle mého dost jasně vyvrací:

C is not a low-level language


(je tam i popsáno, proč různé formy paralelismu nejsou v C možné či jsou nespolehlivé či alespoň příliš komplikované na implementaci - obdobné problémy má většina rozšířených neparalelních jazyků, které nejsou čistě funkcionální ani logické ani dataflow)
Refundace za Windows 7 od Lenovo obchodníka - soud rozhodl, že je zákazník v právu!
25.8. 07:56 JS1 | skóre: 2 | blog: intuition_pump
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Driv se mi pristup map-reduce nebo Sparku hodne libil, ale dneska mam jiny nazor.

Hlavni potiz asi bude, ze paralelizace proste neni modularni. Kdyz napiseme paralelni program A, a paralelni program B, a program C, ktery vola mnohokrat A i B, pak optimalni paralelizace C muze byt napriklad jen v tom, pouzit sekvencni verzi A a sekvencni verzi B, a ty provadet paralelne. Jak tu psal uz Michal Kubecek, skalovat na vic nez desitky procesoru vyzaduje jinou architekturu.

Takze kazdy program, ktery chceme paralelizovat, je samostatny ukol. A je treba se podivat, ktera data muzeme v ramci celeho programu rozdelit tak, aby se jejich zpracovani dalo provadet paralelne. Coz je asi nejlepsi pristup k paralelizaci, co znam; takove "neparalelizuj predcasne". (Map-reduce a spol. to porusuji a vysledky co do vykonu jsou spis tristni.)

Takze IMHO, dokud nebude mit prekladac alespon hrubou predstavu, jak velke objemy dat v ktere casti programu protekaji, nebude mit dost informaci na to, provadet automaticky nejake paralelizace. Neznam jazyk, ktery by nejakou takovou informaci vyuzival.
Lidstvo má již jen 11 let, aby odvrátilo nejhorší důsledky klimatické katastrofy. Podpořte hnutí Limity jsme my!
xkucf03 avatar 25.8. 09:44 xkucf03 | skóre: 48 | blog: xkucf03
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor

Celkově souhlasím (viz také #152#165). Jen k tomu:

Map-reduce a spol. to porusuji a vysledky co do vykonu jsou spis tristni.

Přijde mi, že tam se tak nějak předpokládá, že úloha, kterou tímto způsobem řešíš, bude ta nejdůležitější, která na daném HW běží. Proto různá dema/příklady vypadají tak skvěle – protože počítač v tu chvíli nic jiného s podobnou prioritou nedělá. Pokud ten předpoklad platí a chceš HW využít třeba na dávkové zpracování velkého množství dat, tak to bude dávat dobré výsledky.

Pokud se tam úloh s podobnou prioritou sejde víc, tak už to nelze paralelizovat stylem „dáme úloze tolik vláken, kolik má procesor jader“, ale je potřeba nějaký inteligentní plánovač, který má přehled o celém systému, všech programech a zpracovávaných datech.

Mám rád, když se lidé přou, znamená to, že vědí, co dělají, a že mají směr. Frantovo.cz, SQL-DK, Relational pipes
Heron avatar 25.8. 10:13 Heron | skóre: 52 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Budu částečně nesouhlasit a částečně souhlasit.

Nejdřív ten nesouhlas. V serverové (natožpak desktopové) praxi jsem se nikdy nesetkal s tím, že by přístup "každý proces si naspawnuje tolik vláken, kolik je cpu" představoval problém. Stačí se podívat na prakticky libovolný graf z testů "vliv počtu vláken na výkon" po překročení počtu fyzických cores se výkon ustálí na nějaké hodnotě a potom je graf více méně plochý. S dalšími vlákny výkon ani nestoupá ani neklesá. A to třeba až do hodnoty 10x počet cpu.

Řešit počet vláken jednotlivých služeb ve skutečnosti považuju za předčasnou optimalizaci, protože většinou je problém s výkonem někde úplně jinde a to i když se jeví jako primární příčina právě počet vláken - i v takovém případě je z mojí praxe problém většinou jinde.

Myšlenka dne otce Fura: neřešte to, pokud si vyloženě nejste jisti, že to je skutečný problém.

Teď ten souhlas. Ano, pokud někdo potřebuje brutální výkon a každé procento procesorového času, tak platí to co píšeš. Jenže v takovém případě se to napíše celé od podlahy jinak a výše zmíněné problémy ani nevzniknou.
25.8. 12:42 deda.jabko | skóre: 23 | blog: blog co se jmenuje "každý den jinak" | za new york city dvakrát doleva a pak už se doptáte
Rozbalit Rozbalit vše Re: Programovací jazyk pro 256 jádrový procesor
Driv se mi pristup map-reduce nebo Sparku hodne libil, ale dneska mam jiny nazor.
Neni to stoprocentni reseni, ale pro docela sirokou skalu uloh to predstavuje adekvatni reseni.
Takze kazdy program, ktery chceme paralelizovat, je samostatny ukol. A je treba se podivat, ktera data muzeme v ramci celeho programu rozdelit tak, aby se jejich zpracovani dalo provadet paralelne.
Souhlasim, ze klicove je prave znat data.
takove "neparalelizuj predcasne". (Map-reduce a spol. to porusuji a vysledky co do vykonu jsou spis tristni.)
Map/Reduce (a spol.) je v zasade jen princip, jak zapsat algoritmus pomoci transformaci, ktere maji tu vlastnost, ze je lze soucasne i dobre paralelizovat. Napr. u jednoho programu mam, ze pro mala data se pouzije standardni implementace funkci map a reduce, pro vetsi data uz se to posila frameworku postavenem na vlaknech.
takove "neparalelizuj predcasne"
To mas tezke. Pro radu uloh je napr. nejefektivnejsi reseni iterativni (resp. sekvecni pruchod), pro paralelni zpracovani jsou zase vyhodne napr. stromove rekurzivni algoritmy. Takze si muzes vybrat. Bud naprogramujes ulohu iterativne a bude to v jednom vlaknu a pro mala data efektivni, nebo to naprogramujes napr. stromove rekurzivne a uloha bude snadno paralelizovatelna, ale pro mala data bude neefektivni (ve srovnani s iterativnim algoritmem). Takze se najednou dopustis predcasne paralelizace. ..
Asi před rokem se dostali hackeři na servry Debianu a ukradli jim zdrojové kódy.

Založit nové vláknoNahoru

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.