Jazyk Julia pre HPC

18.7. 20:34 | Přečteno: 1173× | Code Snippety | poslední úprava: 19.7. 00:31

Objavil som zaujímavý skriptovací jazyk zo sveta HPC: Julia . Syntax je podobná jazyku LUA (kto programoval v MATLABe, alebo Pythone, tiež sa v ňom nestratí), ale inak je to jazyk z úplne iného súdka: dynamický, strong typed - orientovaný na rýchlosť a efektivitu – používa JIT compiler. V určitých typoch výpočtových úloh dokáže Julia dosiahnuť vyšší výkon než C/C++, pričom je často porovnateľná s Fortranom a Chapelom – najmä pri numerických operáciách a prácou vektormi a maticami, ktoré si vie compiler dobre zoptimalizovať).

No a čím je tento jazyk výnimočný? Je to jeden z mála jazykov obsahujúci skutočný implicitný paralelizmus (podobne ako iný statický HPC jazyk Chapel ktorý sme si spomínali v minulosti), podporuje vykonávanie kódu na CPU aj GPU (GPGPU). Okrem toho podporuje SIMD (počas jednej inštrukcie sa spracováva viacero hodnôt) a distribúciu výpočtov medzi viac počítačov (Grid computing – keď jeden počítač nestačí).

Taktiež má vlastnosti ako broadcasting (v jazyku Chapel sa tomu hovorí „propagácia“), čo znamená, že pracujeme pomocou operátora bodka "." s celým poľom či inou kolekciou (napr. range) ako by to bola jedna hodnota:

arr = [1:5...] # [1, 2, 3, 4, 5]
arr1 = arr .^ 2 
# Operátor "^" je mocnina – keď použijeme operátor ".^", bude to druhá mocnina všetkých položiek poľa.
# Namiesto: `map(a -> a ^ 2, arr)` – platí aj pre iné operátory.
println(arr1) # [1, 4, 9, 16, 25]

Samozrejme, dajú sa použiť aj knižničné funkcie ako map, filter, fold atď., ale broadcasting je rýchlejší, lebo si to JIT kompilátor zoptimalizuje tak, že sa spracováva viac hodnôt naraz (SIMD). Má to aj makrá, takže jazyk sa dá „ohýbať“. Tiež sú tam rôzne druhy cyklov, ktoré sa dajú optimalizovať na rýchlosť.

Julia obsahuje viacrozmerné polia (väčšina moderných jazykov vychádzajúcich z C obsahuje len pole polí, ale nie skutočné viacrozmerné polia. Pokiaľ ste ale niekedy programovali v Basicu, Pascale či Fortrane istotne si viacrozmerné polia pamätáte.

arr = [
    1 2 3
    4 5 6
]
println(arr[2, 1]) # vypíše 4, keďže polia sa indexujú od 1

Jazyk má pár zvláštností, napríklad že polia sa indexujú od 1 a najprv začínajú riadkami (Y), až potom stĺpcami (X) (podobne ako v matematike, naopak ako v mainstreamových jazykoch). Faktom ale je, že práca s jednotkou je prirodzenejšia a hlavne nám to skracuje kód.

Všadeprítomný je multiple dispatch. OOP to nemá – má to len štruktúry, nad ktorými voláme funkcie. Zapúzdrenie sa robí cez moduly, ale tie moc nezapúzdrujú (moduly sa mi v Julii vôbec nepáčia).

Pokiaľ chceme v Julii napísať rýchly backend a k tomu spraviť GUI, môžeme komunikovať napríklad cez HTTP, sockety, gRPC, ale ja som použil ZeroMQ (package ZMQ), ktoré je rýchle ako sockety, ale pritom jednoduché na použitie ako HTTP.

       

Komentáře

[wamba]

Dá se s ní opravdu vyhrát, navíc Julia disponuje výkonnou knihovnou pro matematické programování JuMP, která výrazně usnadňuje formulaci a řešení optimalizačních úloh.

using JuMP
using HiGHS

M = [0 8 2; 1 0 5; 1 4 0;;; 0 4 3; 9 0 4; 3 7 0;;; 0 1 2; 5 0 8; 2 2 0]

model = Model( HiGHS.Optimizer)

x= @variable(model, x[1:3,1:3,1:3] ≥ 0)
@constraint(model, diagonal[i=1:3], sum(x[i,i,1:3]) == 0)
from_c = @constraint(model, sum(x,dims=1) .== sum(M,dims=1))
to_c   = @constraint(model, sum(x,dims=2) .== sum(M,dims=2))
time   = @constraint(model, sum(x,dims=3) .== sum(M,dims=3))
@objective(model, Min, sum(x .^2 ))

optimize!(model)
@show solution_summary(model)

[Miloslav Ponkrác]

Když už jsi zmínil ten Chapel, jak se na něho díváš?

Já jsem kdysi koketoval s jeho předchůdcem, jazykem ZPL, na kterém si vyzkoušeli hlavní koncepty - regiony polí a další. Pak ty chlápky najal Cray, a začali vymýšlet nástupce ZPL - jazyk Chapel.

ZPL: (https://en.wikipedia.org/wiki/Z-level_programming_language)

Mám dojem, že by měli především udělat standard jazyka Chapel. Přestat ten jazyk neustále měnit.

---

Jinak po světě je hodně exotických jazyků, a některé mi pro svou oblast použití nepřipadají úpně pitomé. Třeba jazyk ballerina. (https://ballerina.io/)

[rad]

Faktom ale je, že práca s jednotkou je prirodzenejšia a hlavne nám to skracuje kód.

Jestli je indexování pole od jedničky přirozenější je asi subjektivní, ale o tom, že to zkracuje kód bych dost pochyboval. Implementoval jsem relativně dost algoritmů pro práci s vícerozměrnými poli paralelně v Matlabu a Pythonu a v Matlabu furt někde honím jedničku.

[Miloslav Ponkrác]

Zmiňovaný jazyk Chapel také zvolil, že bude indexovat pole od jedničky. Ale nedávno jim došlo, že je to idiotské, a tak udělali změnu - pole se defaultně indexuje od nuly.

Chapel ale umožňuje explicitně zvolit jakoukoli dolní mez pole.

[...]

Jest-li to nebude tím že -

Fortran - speciál na práci s maticemi - indexuje od 1 a nikdo s tím nemá problém.

C-éčko - speciál na sepsání operačního systému (UNIX) - indexuje od nuly a nikdo s tím nemá problém.

A s trochou rouhání - všechny ty nové jazyky jsou variací na C-éčko.

[Miloslav Ponkrác]

Jestli to nebude tím, že buď se na pole díváte jako na počítačovou datovou strukturu - a pak se volí nula, a nebo jako na matematický tenzor - pak se volí jednička. Poměrně je dobře vidět, jestli autor programu byl spíše programátor nebo matematik.

Jednou kecl jakýsi Dijkstra, že goto by mělo být zakázáno - a programovací jazyky se tím dost řídily. Než někoho napadlo, že když Dijkstra řekne skoč z okna, tak se nemusí poslechnout.

Jednou kecl Dijkstra, že pole by se měla indexovat od nuly - a začalo se to šířit.

Já bych neřekl, že nové jazyky jsou variací na Céčko. Hodně renesance zažívá algolská/pascalská syntaxe, a hodně se objevuje pythonovská syntaxe. Ovšem pokud lovíte pouze ve třech nejznámějších jazycích, pak máte pravdu.

Reálně je pole obdoba podprogramu/funkce. Je to mapování n-tice hodnot na výslednou hodnotu. Funkce to dělá algoritmem, pole to dělá tabulkou hodnot - jinak je to to samé. Sám jsem používal pole jako mapovače hodnot snad miliardkrát.

[plostenka]

Já bych neřekl, že nové jazyky jsou variací na Céčko.

Ale jsou. Bud je to assembler s trochou syntaktickeho cukru (proc asi je "unsafe" v Rustu), nebo n-ta varianta LISPu. Ostatni inovativni pristupy se moc neuchytily, nebo je odval cas (treba Algol, nebo "pictures" v COBOLu a PL/1)...

[Miloslav Ponkrác]

Mohu jen zopakovat to co jsem napsal: Pokud hledáte mezi třemi nejznámějšími programovacími jazyky, pak máte pravdu. Pokud byste dosáhl trochu dále, tak pravdu nemáte.

Problém C/C++ jazyků je, že jsou debilní. Ano, jde v nich napsat vše, ale vždy se drbete pravou rukou za levým uchem. Všechno je neuvěřitelně ukecané, složité, neintuitivní. Například v těch jazycích de facto neexistuje ani pole, jen imitace pole slepovaná z ukazatelové aritmetiky, případně navíc jemně neuměle pozakrytá do šablon. Není tam ani slušná práce s textovými řetězci. Všechno je to jak od parního stroje za krále klacka, kdy máte dojem, že jste ve středověku, a uděláte 100 x víc práce než je nutné.

My starší jsme zvyklí. Postupně jsme si zvykli na fakt, že C je debilní, ale cokoli adoptuje unix se uchytí bez ohleda na to, jak nekvalitní to je. C++ byl pokus udělat z toho lepší jazyk, ale chaotičností a ukecaností Stroustrupa se to moc nepovedlo. Jak šel čas, naše generace se učila postupně C a C++ věci jak přihcázely. Umíme v C/C++.

Ale mladá generace není zatížená ani historií ani předsudky. Nechce, a já ji naprosto chápu, mít s C/C++ nic společného. Vidí ten chaos, vidí neefektivitu vývoje, vidí že ty jazyky programátorovi moc nepomáhají spíše mu překážejí, a chtějí lepší jazyk. Starší generace se pokusila o D, ale ten se logicky neujal. Mladí se pokusili o Rust, což je v podstatě symbol odporu. Můj názor je, že Rust je rozhodně krok dopředu, ale není to seriózní jazyk. Už jen to, že nemá standard ani ve "stabilní" verzi, neustále se mění - tak na něho nelze nic seriózního nakládat.

Musí vymřít generace, která za svůj etalon považuje unix. Protože unix přinesl dobré, ale i velice špatné věci. Jako třeba jazyky C/C++. Dokud tady bude významné procento lidí s názorem, že "co unix dělá, dobře dělá" - bude situace ve známých programovacích jazycích špatná.

[Miloslav Ponkrác]

Mimochodem, významně vylepšené C je zde

[rad]

Chapel ale umožňuje explicitně zvolit jakoukoli dolní mez pole.

To umí i Fortran, ale nijak extrémně užitečné mi to nepřijde. Napadá mě třeba symetrický index kolem nuly (nějaké FFT třeba) nebo snaha sladit zápis matematiky (např. při použití nějakých konkrétních polynomů). Ale spíš je v tom pak akorát bordel. Zas si ale člověk může změnit výchozí spodní mez z jedničky na nulu, takže je to vlastně fajn...

[Miloslav Ponkrác]

Zrovna včera jsem si psal výpis float čísla ve dvojkové až šestnáctkové soustavě. Použil jsem toto pole pro použité konstanty:

array[2..16] -> pár přesných konstant (log2(n), -logn(2));

Nedávno zase normy pro dospělé lidi podle věku:

array[18..120] -> ...

[plostenka]

array[18..120]

Uzasny. Takze ti to rozbijou lidi soudem uznani za zletile, podobne az se nejaka baba dozije 120 (coz s rostouci delkou doziti muze klidne nastat, rekord je neco okolo 115).

[Miloslav Ponkrác]

Chápu vaše myšlení sociálního inženýra, a snahy zbořit jakékoli limity.

Toto byly lékařské tabulky dané věkem a fyziologií vývoje. Tam můžete pořádat demonstrace do alelůjá, ale protože nejste stvořitelem člověka ani ředitelem vesmíru, tak fyziologii člověka nezměníte.

Můžete klidně kojence prohlásit za zletilého třeba mezinárodním soudem, ale pořád pro něho budou platit fyziologické tabulky pro kojence, nikoli pro 18leté.

[plostenka]

Toto byly lékařské tabulky dané věkem a fyziologií vývoje.

Tim spis se priroda nepta na papirove 18+.

[Miloslav Ponkrác]

Nikdo se ještě nikdy 120 let nedožil, pokud se nefixlovalo.

Každopádně protáhnout pole o 10 dalších prvků je to nejmenší. Je to ale k ničemu, protože na takový věk neseženete dostatek lidí, abyste vytvořil normu pro jejich věk. Reálně stejně děláte extrapolaci.

Podstatou ovšem byla demonstrace užitečnosti volby dolní meze polí. Pole pak slouží jako přímé mapování věku (nebo číselné soustavy) na výslednou hodnotu. Takový kód je přehlednější. Mapovací funkci pole dělá kompilátor, a ne idiotsky programátor suplující špatně udělaný jazyk / kompilátor.

[rad]

Takový kód je přehlednější.

To je asi otázka názoru. Hlavně bude záležet na tom kdo a jak ten kód píše. A protože znám své kolegy, mám raději jazyky, které neumožňují být příliš kreativní...

Tu motivaci ale pochopitelně chápu, ale jak píšete víše:

...Je to mapování n-tice hodnot na výslednou hodnotu. Funkce to dělá algoritmem, pole to dělá tabulkou hodnot - jinak je to to samé...

Pro mě je indexování pole jakási low-level operace, pokud potřebuji nestandardní index, volím raději funkci. Ono u možnosti měnit spodní mez nemusíte chtít skončit. Třeba byste rád index, který se neinkrementuje o jedničku, či není lineární, motivace by se asi našla.

Ale nemám pochopitelně nic proti tomu, aby to jazyk podporoval, zejména pokud to jeho uživatelé využívají.

[Miloslav Ponkrác]

V tom, že je potřeba špatným programátorům přistřihnout křídla, máte samozřejmě pravdu. Je třeba se přizpůsobit té které situaci.

***

a) Já pole vnímám jako abstraktní datovou strukturu. Její síla je v tom, že 1) pole lze v dobrém jazyce používat jako zobrazení, 2) pole je vynikající nástroj pro paralelizaci a masivně-paralelní provádění kódu a výpočtů.

b) Indexování jako low-level operace existuje. To je to, čemu se říká pointerová aritmetika. To není de facto pole, ale jen ukazatel na první prvek, a pak se posunujete pomocí offsetů. Není to pole, ale lze v případě nouze skrze pointerovou aritmetiku pole imitovat.

Spravedlivě je třeba říci, že programovací jazyky s plnohodnotnými poli občas řeší, jak dosáhnout ad b). Tedy něco jako pointerové aritmetiky, ale s plnou kontrolou na poli včetně hlídání mezí a hromadný operací s hejnem prvků naráz. Většinou se na to vymýšlí něco jako "řezy polí".

***

Index pole, který neinkrementuje o jedničku, je běžný.

Třeba výše zmíněný jazyk Chapel umožňuje pole, jehož indexy je nějaká sekvence čísel. Třeba pole, které používá za indexy jen sudá čísla.

Řada jazyků umožňuje děravé (sparse) pole. V matematice jsou sparse matice také běžné, je mnoho numerických a jiných algoritmů, které vytvářejí velmi řídké matice / tenzory. To jest samé nuly, a zřidkakde nějaké číslo.

Podle toho, jak je jazyk schopný, může do indexu polí klidně zahrnout i neordinální typy - například pole, jejichž klíčem / indexem je textový řetězec nebo množinu prvků. I když u low level jazyků se taková pole nazývá asociativní nebo zobrazení nebo slovníky.

[rad]

V tom, že je potřeba špatným programátorům přistřihnout křídla, máte samozřejmě pravdu. Je třeba se přizpůsobit té které situaci.

To se bohužel snadněji řekne, než udělá...

Se zbytkem pochopitelně souhlasím snad jen s poznámkou, že řídká pole sice obsahují hromady nul, ale obsahují je, tzn. není to ekvivalentní poli, které ten index nemá vůbec (viz ten příklad sudých indexů). Sice netuším, jak jsou interně implementována, ale nějaký overhead tam bude muset být.

Pokud jde o ta asociativní pole, tak přesně ta jsou podle mého názoru vhodná pro zobrazení/mapování netriviálních indexů. Pole jako taková mají podle mě uplatnění především tam, kde provádíte nějaké náročné operace na větším množství dat, kde – přesně, jak píšete – využijete s výhodou možnosti paralelizace. Alespoň tak to mám já. Pole je hromada dat, kterou je třeba zpracovat a index je více méně podružný, pro data, kde má index nějaký význam používám asociativní datové typy.

[Miloslav Ponkrác]

Implementace běžných, řídkých a asociativních polí je / měla by být věcí kompilátoru programovacího jazyka. Liší se od sebe jen algoritmem mapovací funkce. Jinak jsou to zcela stejná pole hodnot, v paměti mapovaná většinou (nemusí být) jako lineární vektor.

Programovací jazyk má mnohem více prostředků a informací, jak to udělat efektivně - pokud je to dobře navržený programovací jazyk. Bohužel moderní koncepce "programovací jazyk jako vykuchaná slepice bez drůbků, a vše dohánět knihovnami" nemumožňuje nic než low level strojové programování.

Právě schopnost masivní paralelizace polních operací dala vzniknout tzv. array jazykům. Tam ale na mapovací funkci příliš nezáleží, pokud se to udělá dobře. (https://en.wikipedia.org/wiki/Array_programming)

To byl právě důvod vzniku jazyků jako je autorem zmíněný Chapel. Možnost rozdělit pole do regionů, a každý region nechat zpracovávat třeba i na jiném počítače - aniž by se tím musel programátor zabývat a řešit to. Nebo předepsat takovou reprezentaci pole, jaká se pro paralelení výpočty hodila nejvíce. To je gró a podstata, proč vznikl jazyk Chapel.

Nemám co rozporovat z toho co jste napsal. Souhlasíme spolu. Jen zdůrazňuji, že je rozdíl mezi "vektorem hodnot s pointerovou aritmetikou" a plnohodnotným polem.

[Radovan]

Chapel ale umožňuje explicitně zvolit jakoukoli dolní mez pole.

Pascal také, ale lidé se do něj moc nehrnou. To je škoda, odnaučili by se dělat spoustu blbostí

A co se C týče: int array[201]={0}, *teplota=&array[100];

[Miloslav Ponkrác]

Pascal byl stvořen jako učební jazyk. Pro praktické použití mu pár maličkostí schází. Ale jinak to byl geniálně navržený jazyk s mnoha abstraktními datovými strukturami, a programovalo se v něm velice dobře.

Jeho autor, Niklaus Wirth, dokonce vydal verzi Pascalu chodící nad virtuálním strojem. Tedy udělal Pascal snadno široce přenositelný na mnoho různých platforem a operačních systémů. Tím se mu podařilo dosáhnout fenomenálního rozšíření Pascalu. (K dohledání přenositelný P4 Pascal běžící nad p-kódem třeba zde.)

Pro praxi Wirth udělal jazyky Modula-3 (generické programování, objektové programování, thready, výjimky, garbage collector) a Oberon. Oba jazyky jsou také pro systémové programování, a v obou jazycích byly napsány i celé operační systémy. Operační systém Oberon napsaný v programovacím jazyce Oberon měl dokonce velice kvalitní a pěkné GUI (knihovna pro GUI se jmenovala BlueBottle).

Po jazyce Oberon udělal Wirth jeho následníka - Component Pascal. Ten navíc uměl komponenty, což jsou sdílené knihovny objektů a modulů, ale nikoli hloupé DLL nebo SO, ale plnohodnotné objekty s celým rozhraním. Dnes by se řeklo, že jde o object request broker, něco jako CORBA nebo COM/DCOM na Windows. V podstatě se schopností distribuovaného systému schopného běžet na více počítačích v síti a běžících jako jeden program.

[Erlang Developer]

Pascal pro praxi byl Delphi (Object Pascal) ne? Urcitou dobu byl velmi oblibeny pro GUI Windows aplikace...

[Ondřej J]

V Delphi se dokonce vyvíjí dodnes.

A úspěšná česká hra HROT je taky napsána v Pascalu koplet, včetně engine.