Rychlost Haskell vs. C++

[lopata]

A když píšeš nějakou aplikaci ve striktním jazyce, používáš jenom svoje moduly, nebo i něco externího? ... Tak to zprofiluješ a zjistíš, že problém je v nějaké externí knihovně. A teď co? Abys ji mohl nějak zrychlit tak ji musíš kompletně nastudovat tak jak tak.

Nemusím ji kompletně nastudovat, protože nemám v plánu do knihovny přidávat "pragma strict". Stačí se zaměřit na problematické pasáže a s nimi něco udělat. Nebo můžu zkusit vypnout/zapnout nějaké optimalizace bez obav, že to rozbije existující kód. Haskell má ten problém, že zavedl optimalizační pragmu, která mění sémantiku kódu na úrovni modulu. Takže když ji chceš použít, musíš nastudovat minimálně ten konkrétní celý modul.

Máš pocit, že většina knihoven ve striktních jazycích je výborně napsaná a tenhle problém tam nehrozí?

Knihovna v Haskellu může být napsána úplně skvěle, ale stejně může být pomalá, protože lazy evaluation overhead. No a co teď s tím? Můžu tam dát pragma strict, nebo nemůžu...?

[Reklama]

[v]

Motáme se pořád v kruhu. Lazy vyhodnocení je hezké, ale má nezanedbatelný overhead. Pokud chci, aby Haskell nebyl lazy, jde to udělat, ale je to narovnávák na ohýbák, lazy kód tím rozbiju.

Už to tu zaznělo. Proč v C striktnost není ohýbák? Když v C použiju lazy techniky, tak se mi nemůže stát, že tím něco rozbiju (dosáhnu nežádoucího chování)?

V C neexistuje žádný přepínač "pragma lazy", existující strict kód v C nijak rozbít nejde. V Haskellu existuje pragma strict, což rozbije spoustu existujícího kódu a to tak, že se sice přeloží, ale spadne to až v runtime. V Haskellu pragma strict existuje jenom z toho důvodu, že se snaží řešit performance problémy lazy evaluation. Proto je to narovnávák na ohýbák: zavedu něco, co mění defaultní chování vyhodnocování, aby to bylo (někdy) rychlejší a přitom rozbiju existující kód.

ne že by to v Cčku nešlo, třeba přeložit každý soubor s jiným nastavením zarovnání dat

To je jenom špané nastavení překladače bez vazby na zdrojový kód. Pragma strict v Haskellu dělá něco mnohem horšího, mění sémantiku existujícího kódu.

tak třeba strict aliasing

[lopata]

tak třeba strict aliasing

Ano to byla docela zásadní změna, nicméně je to definované ve standardu a veškerý nový kód by měl respektovat strict aliasing rules. Překladače implementovaly warningy, pokud nebyly strict aliasing rules dodrženy (nedokázaly to poznat vždy), takže přechod nebyl až tak bolestivý. Navíc kód, který nerespektoval strict aliasing rules, byl vždy považován za prasárnu a často byl také neportabilní, moc se to nevyskytovalo. S pragma strict v Haskellu to nejde úplně srovnávat, protože pragma strict mění fundamentální koncept vyhodnocování výrazů, na kterém je založena spousta existujícího kódu.

[JS]

Knihovna v Haskellu může být napsána úplně skvěle, ale stejně může být pomalá, protože lazy evaluation overhead. No a co teď s tím? Můžu tam dát pragma strict, nebo nemůžu...?

Pragma strict je prilis tezkopadny nastroj na tuhle ulohu. Uz jsem ti prece odkazoval clanky, kde se explicitne popisuje, jak si muzes zavest striktni vyhodnocovani na urovni jednotlivych datovych typu, na urovni jednotlivych predavanych parametru a konecne zcela explicitne primo v kodu pomoci primitivy "seq".

Já nevím, mně to přijde celé ujeté. Haskell přišel s nějakým designových rozhodnotím (lazy evaluation), což má nějaké výhody a nevýhody. Během doby se přišlo na to, že lazy evaluation stojí docela dost výkonu, tak se hledalo, jak z toho ven.

Ujete to asi je.. ale takhle vznikaji vsechny nove vlastnosti programovacich jazyku. Nove abstrakce nikdy nemaji podporu kompilatoru a temer vzdy znamenaji snizeni vykonu, protoze se setri cas programatorum. Ale eventualne se to (pokud je to dobra vec) do kompilatoru nejak prosadi (nekdo to ten kompilator nakonec nauci) a situace se vyrovna.

Pro priklad muze poslouzit i C++. Pokud si dobre vzpominam, jeste koncem 90. let nebyly kompilatory prilis zdatne v efektivni kompilaci C++ vyjimek. Vety ktere pises vys by tak bylo mozne (tehdy) napsat uplne stejne o vyjimkach.

Sorry jako, takhle podle mě nevypadá mainstreamový jazyk vhodný pro produkční nasazení, ve kterém bych se odvážil psát nějakou větší aplikaci.

Omlouvat se nemusis, nikdo te nenuti v nem programovat (aspon doufam ). Tazatel se ptal, proc je to potencialne rychlejsi (nebo proc se to tvrdi) a ja mu odpovedel.

[lopata]

Pragma strict je prilis tezkopadny nastroj na tuhle ulohu. Uz jsem ti prece odkazoval clanky, kde se explicitne popisuje, jak si muzes zavest striktni vyhodnocovani na urovni jednotlivych datovych typu, na urovni jednotlivych predavanych parametru a konecne zcela explicitne primo v kodu pomoci primitivy "seq".

seq a podobné opičárny jsou zase jenom narovnávák na ohýbák a v mnoha případech to nefunguje podle očekávání: https://stackoverflow.com/questions/12617664/a-simple-example-showing-that-io-doesnt-satisfy-the-monad-laws/12620418#12620418. Zavést strict do lazy jazyka prostě asi nejde udělat bez hnusných hacků, bohužel pro Haskell...

Omlouvat se nemusis, nikdo te nenuti v nem programovat (aspon doufam ). Tazatel se ptal, proc je to potencialne rychlejsi (nebo proc se to tvrdi) a ja mu odpovedel.

Tak já mu taky odpovím. Haskell je potenciálně pomalejší, protože má lazy evaluation. Obcházení lazy evaluation zavádí do Haskellu prasárny.

[Reklama]

[Bacsa]

Haskell je potenciálně pomalejší, protože má lazy evaluation

To je jen vaření z vody.

[lopata]

Haskell je potenciálně pomalejší, protože má lazy evaluation

To je jen vaření z vody.

Jistěže není, lazy evaluation má vyšší overhead než strict evaluation, to je známá věc. Proč myslíš, že do Haskellu zavádí všechny ty strict opičárny, které rozbíjí základní koncepty jazyka? Jediný důvod je výkon.

[andy]

No a o tom to celé je. Protože je Haskell lazy, píše se v něm kód, který funguje jen při lazy vyhodnocení a při strict ne. Na to není nic špatného. Jenom je potřeba počítat s tím, že lazy vyhodnocení má z principu vyšší overhead. To se vědělo od začátku. Pak ale někomu začalo vadit, že je Haskell moc pomalý a přemýšlel, jak ho zrychlit. Tak třeba bychom mohli udělat Haskell trochu strict... Co na tom, že rozbijeme existující kód... Mně se Haskell líbí, ale věci jako pragma strict jdou proti jeho designové čistotě a po pravdě moc nechápu, jak někdo z Haskell komunity může takovou věc obhajovat .

Protože se lidi z Haskellu snaží být praktičtí a vzhledem k tomu, že strictness analýza prostě dneska není na úrovni toho, kde bude za 20 let, tak prostě zavedli seq? To je snad dobře, ne?

Chápu důvody vzniku, nepřenesu se ale přes fakt, že to jde proti designu a filozofii jazyka, jen kvůli řešení výkonnostních problémů.

Já tě vůbec nechápu... tady někdo vyrobí jazyk, na kterém se v podstatě testuje spousta nových ideí, které posledních 5 let přejímá spousta dalších mainstream jazyků, zároveň ho udělá tak, že je _použitelný_ na normální produkční programování - sice nemáme geniální strictness analýzu, ale tak když programátor pomůže, tak to bude rozumné - a ty se nemůžeš přenést přes to, že to není "filosoficky čisté"? WTF?

Sorry jako, takhle podle mě nevypadá mainstreamový jazyk vhodný pro produkční nasazení, ve kterém bych se odvážil psát nějakou větší aplikaci

Já bych se osobně dneska neodvážil psát nějakou větší aplikaci v jazycích, které nemají typový systém aspoň na nějaké podúrovni Haskellu. Nullpointer exception? Stack overflow? Padnuté přetypování? Spousta nechycených výjimek, protože jiné způsoby práce s chybami nejsou použitelné?

Hele, že tys v haskellu ještě nic pořádně nenapsal, nejde ti to, tak jsi se rozhodl, že to "prostě nejde"? Protože věc typu "foldl" je něco, na co narazíš, ale asi tak jednou za projekt, a to ještě . Takže jestli kvůli *tomuhle* ti připadá, že to není jazyk vhodný na produkci, tak jsi asi tak na té úrovni, že C-like jazyky nejsou vhodné do produkce kvůli tomu, že to používá pointry, o kterých sis právě něco přečet a přijde ti to hrozný? Někam vrazíš null, pak to dereferencuješ...a ono to spadne! Jak někdo něco takového může používat v produkci... A pak v tom C pár let programuješ, pointry se naučíš, občas ti to spadne, ale dá se s tím v pohodě žít...?

[andy]

Haskell je potenciálně pomalejší, protože má lazy evaluation

To je jen vaření z vody.

Jistěže není, lazy evaluation má vyšší overhead než strict evaluation, to je známá věc. Proč myslíš, že do Haskellu zavádí všechny ty strict opičárny, které rozbíjí základní koncepty jazyka? Jediný důvod je výkon.

Naprosto. Až budeme mít geniální strictness analýzu a optimalizátory, tak to nebude potřeba.

Ale podobné "prasárny" z jiných jazyků - unboxed values v Javě (int, double, float, short...). Používání objektů na stacku v C++, opičárny s dereferencema a příšerný pravidla, aby se zbytečně nealokovaly/nekopírovaly objekty (kdo TOHLE vymyslel...?). Pointer aritmetika v C. Různé bytearray/buffer apod. v pythonu.

Jasně, tohle nejde proti "čistotě filosofie", protože tyhle jazyky žádnou filosofii nemaj...

[BoneFlute]

No a o tom to celé je. Protože je Haskell lazy, píše se v něm kód, který funguje jen při lazy vyhodnocení a při strict ne. Na to není nic špatného. Jenom je potřeba počítat s tím, že lazy vyhodnocení má z principu vyšší overhead. To se vědělo od začátku. Pak ale někomu začalo vadit, že je Haskell moc pomalý a přemýšlel, jak ho zrychlit. Tak třeba bychom mohli udělat Haskell trochu strict... Co na tom, že rozbijeme existující kód... Mně se Haskell líbí, ale věci jako pragma strict jdou proti jeho designové čistotě a po pravdě moc nechápu, jak někdo z Haskell komunity může takovou věc obhajovat . Chápu důvody vzniku, nepřenesu se ale přes fakt, že to jde proti designu a filozofii jazyka, jen kvůli řešení výkonnostních problémů.

Hmm, takže pokud tě chápu dobře, tak tobě nevadí, že je Haskell lazy, či strict ale to, že vůbec má nějaké pragmy? Tak s tím bych se i stotožnil. Do optimalizace kódu by programátor kompilátoru neměl kecat. (Připomíná mi to hinty v Oracle či Postgresu.)

[Kiwi]

Hmm, takže pokud tě chápu dobře, tak tobě nevadí, že je Haskell lazy, či strict ale to, že vůbec má nějaké pragmy? Tak s tím bych se i stotožnil. Do optimalizace kódu by programátor kompilátoru neměl kecat. (Připomíná mi to hinty v Oracle či Postgresu.)

Nechápu, odkud se šíří ty mantry o dokonalosti kompilátorů. Navíc je přebírají a dále šíří lidé, kteří o tom zjevně moc nevědí. Z titulu svého zaměření se na pomezí asm a něčeho lehce vyššího pohybuji, často zkoumám listingy a mohu vás ubezpečit, že i céčkový kompilátor má k dokonalému kódu poměrně daleko. Tím méně bych si dělal iluze u spíše deklarativních jazyků - tam je třeba identifikovat poměrně složité vzorce na vysoké úrovni, což je komplikované. Příkladem nechť je třeba HDL, kde simulaci píšete nějak, ale model pro účely generování zapojení úplně jinak - musíte ten syntezátor doslova dokopat k tomu, co chcete. Jinak sice taky dokáže vygenerovat něco, co něco dělá, ale je to asi tak o řád složitější, pomalejší, náročnější na prostředky. Nevím, jak je tomu dnes, ale jak jsem dával za příklad ten quicksort, který v Haskellu sice vypadá náramně jednoduše, akorát je prakticky k ničemu, protože mu nebude stačit paměť.

[Bacsa]

Hmm, takže pokud tě chápu dobře, tak tobě nevadí, že je Haskell lazy, či strict ale to, že vůbec má nějaké pragmy? Tak s tím bych se i stotožnil. Do optimalizace kódu by programátor kompilátoru neměl kecat. (Připomíná mi to hinty v Oracle či Postgresu.)

Nechápu, odkud se šíří ty mantry o dokonalosti kompilátorů. Navíc je přebírají a dále šíří lidé, kteří o tom zjevně moc nevědí. Z titulu svého zaměření se na pomezí asm a něčeho lehce vyššího pohybuji, často zkoumám listingy a mohu vás ubezpečit, že i céčkový kompilátor má k dokonalému kódu poměrně daleko. Tím méně bych si dělal iluze u spíše deklarativních jazyků - tam je třeba identifikovat poměrně složité vzorce na vysoké úrovni, což je komplikované. Příkladem nechť je třeba HDL, kde simulaci píšete nějak, ale model pro účely generování zapojení úplně jinak - musíte ten syntezátor doslova dokopat k tomu, co chcete. Jinak sice taky dokáže vygenerovat něco, co něco dělá, ale je to asi tak o řád složitější, pomalejší, náročnější na prostředky. Nevím, jak je tomu dnes, ale jak jsem dával za příklad ten quicksort, který v Haskellu sice vypadá náramně jednoduše, akorát je prakticky k ničemu, protože mu nebude stačit paměť.

Nejde vždy jen o překlad, největší vliv na efektivitu mají optimalizované datové struktury. V případě indexovatelného nebo asociativního pole je například funkcionální implementace stejně efektivní jako mutabilní díky optimalizacím uniqref a cow. Třeba ten quicksort tak prakticky běží in situ, i když sémantiku si zachová funkcionální.

[optimizer]

Třeba ten quicksort tak prakticky běží in situ, i když sémantiku si zachová funkcionální.

LOL

[hawran diskuse]

No pěkně.
Także co se mi bude psát lépe, gui (pro něco) v c++, nebo v haskellu?

[andy]

No pěkně.
Także co se mi bude psát lépe, gui (pro něco) v c++, nebo v haskellu?

V Haskellu se teď na GUI docela rozjíždí FRP. Bohužel osobně s tím mám zkušenosti pár let staré (což bylo v podstatě v plenkách), nicméně co jsem četl, tak s tím jsou lidé docela spokojeni. On je spíš problém v těch GUI knihovnách. Daří se to implementovat jako webové UI, ale překlad Haskell -> JS je trochu uhozená záložitost. Očekává se, že příchod WebAssembly by tuhle část mohl (a to nejen pro haskell, ale i pro další jazyky) výrazně posunout vpřed.