Rychlost Haskell vs. C++

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Rychlost Haskell vs. C++
« Odpověď #60 kdy: 25. 08. 2018, 01:36:40 »
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.)
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.
Z titulu svého zaměření tě můžu ubezpečit, že věci, které dokáže vyplodit 80procent vývojářů... by tě chytl infarkt.


Kiwi

Re:Rychlost Haskell vs. C++
« Odpověď #61 kdy: 25. 08. 2018, 09:52:52 »
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.)
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.
Z titulu svého zaměření tě můžu ubezpečit, že věci, které dokáže vyplodit 80procent vývojářů... by tě chytl infarkt.
To rozhodně.  :D Ale mám obavy, že co není v hlavě, to kompilátor nespraví, ale u imperativních jazyků vynásobí, u funkcionálních spíš umocní. Proto ten současný funkcionální hype nesdílím, protože mám obavy, že jakmile by se to paradigma rozšířilo více do praxe, tak budeš mezi prvními, koho pak s tím infarktem doopravdy povezou.  ;)

Bacsa

Re:Rychlost Haskell vs. C++
« Odpověď #62 kdy: 25. 08. 2018, 11:56:14 »
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.)
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.
Z titulu svého zaměření tě můžu ubezpečit, že věci, které dokáže vyplodit 80procent vývojářů... by tě chytl infarkt.
Proto ten současný funkcionální hype nesdílím, protože mám obavy, že jakmile by se to paradigma rozšířilo více do praxe, tak budeš mezi prvními, koho pak s tím infarktem doopravdy povezou.  ;)
Takže Haskell v korporátu nehrozí?  :D

Re:Rychlost Haskell vs. C++
« Odpověď #63 kdy: 25. 08. 2018, 11:57:29 »
... ale překlad Haskell -> JS ...
Jakože javashit?
Aháááá.

Bacsa

Re:Rychlost Haskell vs. C++
« Odpověď #64 kdy: 25. 08. 2018, 12:46:52 »
No pěkně.
Także co se mi bude psát lépe, gui (pro něco) v c++, nebo v haskellu?
příchod WebAssembly by tuhle část mohl (a to nejen pro haskell, ale i pro další jazyky) výrazně posunout vpřed.
WebAssembly je hodně zajímavá věc, ale než se to rozšíří...


BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Rychlost Haskell vs. C++
« Odpověď #65 kdy: 25. 08. 2018, 19:51:21 »
Ale mám obavy, že co není v hlavě, to kompilátor nespraví, ale u imperativních jazyků vynásobí, u funkcionálních spíš umocní. Proto ten současný funkcionální hype nesdílím, protože mám obavy, že jakmile by se to paradigma rozšířilo více do praxe, tak budeš mezi prvními, koho pak s tím infarktem doopravdy povezou.  ;)

Mě se to nezdá.

Základním problémem imperativního programování je OOP. Vyžaduje příliš velký skill, aby se dal psát dobře. U FP skutečnost, že všechno je funkce, která nejde moc rozkošatit, tak to IMHO hodně sváže ruce kreativitě některých vývojářů.

Teda, moje úvaha je taková, že u FP jde vždycky špatný kód wrapnout, a postupně odlifrovat do zapomění. Zatímco u OOP se ty špagety někdy opravdu těško rozmotávají.

Re:Rychlost Haskell vs. C++
« Odpověď #66 kdy: 25. 08. 2018, 21:40:27 »
Ale mám obavy, že co není v hlavě, to kompilátor nespraví, ale u imperativních jazyků vynásobí, u funkcionálních spíš umocní. Proto ten současný funkcionální hype nesdílím, protože mám obavy, že jakmile by se to paradigma rozšířilo více do praxe, tak budeš mezi prvními, koho pak s tím infarktem doopravdy povezou.  ;)

Mě se to nezdá.

Základním problémem imperativního programování je OOP. Vyžaduje příliš velký skill, aby se dal psát dobře. U FP skutečnost, že všechno je funkce, která nejde moc rozkošatit, tak to IMHO hodně sváže ruce kreativitě některých vývojářů.

Teda, moje úvaha je taková, že u FP jde vždycky špatný kód wrapnout, a postupně odlifrovat do zapomění. Zatímco u OOP se ty špagety někdy opravdu těško rozmotávají.

Mě se to nezdá.

Základním problémem OOP programování je imperativnost.


BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Re:Rychlost Haskell vs. C++
« Odpověď #67 kdy: 25. 08. 2018, 22:53:56 »
Základním problémem OOP programování je imperativnost.
Jo.

Bacsa

Re:Rychlost Haskell vs. C++
« Odpověď #68 kdy: 25. 08. 2018, 23:09:55 »
Základním problémem OOP programování je imperativnost.
Jo.
To si pak člověk nevybere, každé paradigma má problematické aspekty.

lopata

Re:Rychlost Haskell vs. C++
« Odpověď #69 kdy: 26. 08. 2018, 04:59:53 »
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?
Není to dobře, protože to rozbíjí základní koncepty jazyka. Něco ke čtení:
https://www.orchid.inf.tu-dresden.de/gdp/reports/p76-voigtlaender.pdf
https://stackoverflow.com/questions/12617664/a-simple-example-showing-that-io-doesnt-satisfy-the-monad-laws/12620418#12620418
https://wiki.haskell.org/Performance/Strictness#Evaluating_expressions_strictly
Warning: Using any kind of strictness annotations as above can have unexpected impact on program semantics, in particular when certain optimizations are performed by the compiler. See correctness of short cut fusion.

Haskell si tak nějak neumí vybrat, co chce být. Jestli akademický jazyk, který má ukázat, jak se to má dělat správně, nebo jazyk, který bude i pro mainstreamované použití. Chtěli jít i tou druhou cestou, potřebovali vylepšit výkon, tak začali tu akademickou část prasit. Ve výsledku není Haskell ani jedno a výkon taky nic moc.

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é?
Všechno co jsi vyjmenoval umí ošetřit i jiné jazyky. Třeba Rust s výkonem řádově jinde než Haskell.

Hele, že tys v haskellu ještě nic pořádně nenapsal, nejde ti to, tak jsi se rozhodl, že to "prostě nejde"?
S Haskellem jsem si v rámci výzkumu soukromě hrál a nepřesvědčil mě, na větší projekt bych ho nepoužil. Můžeš si klidně myslet, že mi to v Haskellu nejde, je mi to jedno. Důvodů, proč mě Haskell nepřesvědčil, je víc, výkon je až někde hodně vzadu.

C-like jazyky nejsou vhodné do produkce kvůli tomu, že to používá pointry,
Ale to je dávno známá věc, že C-like jazyky nejsou vhodné pro produkci. K používání C v produkci už je dnes jen pár legitimních důvodu: omezené zdroje (RAM, CPU) nebo požadavky na co nejvyšší výkon. V jiném případě se prakticky vždy vyplatí sáhnout po něčem jiném než C.

lopata

Re:Rychlost Haskell vs. C++
« Odpověď #70 kdy: 26. 08. 2018, 05:09:48 »
Naprosto. Až budeme mít geniální strictness analýzu a optimalizátory, tak to nebude potřeba.
Až budeme mít růžové slony schopné psát dokonalý kód v assembleru, nebou žádné optimalizátory potřeba.

Ale podobné "prasárny" z jiných jazyků - unboxed values v Javě (int, double, float, short...).
Máš v tom trochu hokej, prasárna je spíš boxování.

Používání objektů na stacku v C++
Tady ses úplně odkopal, objekty na stacku jsou skvělá věc. Jiné jazyky včetně Haskellu se taky snaží co nejvíc objektů alokovat na stacku, používají na to escape analysis (která samozřejmě není dokonalá), v C++ si můžeš explicitně zvolit, jestli objekt vytvoříč na stacku nebo na heapu.

, 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...
Je potřeba podívat se na věci v historickém konceptu. Pointery vznikly kdysi dávno ještě před C, v podstatě už na úrovni strojového kódu. Ví se, že pointery a poiterová aritmetika jsou nebezpečná věc. Většina jazyků se s tím snaží v průběhu času něco dělat a situaci zlepšovat (reference, smart pointery...). V Rustu na raw pointer mimo unsafe kód nenarazíš, v C++ byla docela přelomová verze C++11. Od C++11 raw pointery prakticky nemusíš používat. Vývoj jde tak nějak správnou cestou dopředu. Haskell do dělá opačně, na začátku to udělali správně (lazy evaluation i když s vyšším overheadem), ale pak si řekli: "Je sice moc hezké, ale moc pomalé, trochu to doprasíme. Doděláme strict evaluation.".

andy

Re:Rychlost Haskell vs. C++
« Odpověď #71 kdy: 26. 08. 2018, 09:43:26 »
Naprosto. Až budeme mít geniální strictness analýzu a optimalizátory, tak to nebude potřeba.
Až budeme mít růžové slony schopné psát dokonalý kód v assembleru, nebou žádné optimalizátory potřeba.
Přesně. A do té doby je docela rozumné mít možnost vysvětlit kompilátoru JAK chceš daný kód vykonávat. What's the problem?

Citace
Ale podobné "prasárny" z jiných jazyků - unboxed values v Javě (int, double, float, short...).
Máš v tom trochu hokej, prasárna je spíš boxování.
Aha... jasně. Tak si zkus udělat Nějaké generikum s unboxovaným číslem. Nejde to. Proč? Protože unboxované čísla tam máme z toho důvodu, protože jinak by to bylo tragicky pomalý. Tak trochu to likviduje čistotu jazyka...ale co se dá dělat....
Citace
Používání objektů na stacku v C++
Tady ses úplně odkopal, objekty na stacku jsou skvělá věc. Jiné jazyky včetně Haskellu se taky snaží co nejvíc objektů alokovat na stacku, používají na to escape analysis (která samozřejmě není dokonalá), v C++ si můžeš explicitně zvolit, jestli objekt vytvoříč na stacku nebo na heapu.
Ale ten problém je, že to já jako uživatel musím vůbec řešit. Ty si stěžuješ, že haskellu musíš říct, jestli má použít foldl nebo foldl', a třeba v C++ tohle musíš pořád řešit taky - kde použít smart pointry, různý to opičárny v operátorech, aby se odkazovalo, kde se odkazovat má, nekopírovalo, kde se nekopírovat nemá... a najednou říct překladači, že má použít strict je problém? Máš psa a chceš ho bít?
Citace
, 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...
Je potřeba podívat se na věci v historickém konceptu. Pointery vznikly kdysi dávno ještě před C, v podstatě už na úrovni strojového kódu. Ví se, že pointery a poiterová aritmetika jsou nebezpečná věc. Většina jazyků se s tím snaží v průběhu času něco dělat a situaci zlepšovat (reference, smart pointery...). V Rustu na raw pointer mimo unsafe kód nenarazíš, v C++ byla docela přelomová verze C++11. Od C++11 raw pointery prakticky nemusíš používat. Vývoj jde tak nějak správnou cestou dopředu. Haskell do dělá opačně, na začátku to udělali správně (lazy evaluation i když s vyšším overheadem), ale pak si řekli: "Je sice moc hezké, ale moc pomalé, trochu to doprasíme. Doděláme strict evaluation.".
[/quote]
Je strašně hezké, že máme objekty v Javě, ale je to moc pomalé. Trochu to doprasíme, uděláme unboxed čísla. Je strašně hezké všude dělat kopie v C++, ale trochu to doprasíme, uděláme odkazy..... Ale pokračujme dál: volatile. Různé bariéry v multithreadovaných programech.

Všechny tyhle jazyky ti evidentně umožňují ovlivnit způsob vykonávání kódu - a to jsou založeny na tom, že to, co napíšeš, se v podstatě přesně vykoná. A i tak v tom málu, kde ten kompiler může improvizovat, ti to umožňují. Haskell je založen na úplně jiných principech, kompiler může improvizovat na mnohem vyšší úrovni - a najednou je "špatně", že můžeš ovlivnit způsob vykonávání kódu? Protože haskell má - na rozdíl od ostatních - "čistou filosofii", a lopata řekla, že by to byl hřích porušit?

andy

Re:Rychlost Haskell vs. C++
« Odpověď #72 kdy: 26. 08. 2018, 09:57:21 »
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?
Není to dobře, protože to rozbíjí základní koncepty jazyka. Něco ke čtení:
https://www.orchid.inf.tu-dresden.de/gdp/reports/p76-voigtlaender.pdf
https://stackoverflow.com/questions/12617664/a-simple-example-showing-that-io-doesnt-satisfy-the-monad-laws/12620418#12620418
https://wiki.haskell.org/Performance/Strictness#Evaluating_expressions_strictly

Warning: Using any kind of strictness annotations as above can have unexpected impact on program semantics, in particular when certain optimizations are performed by the compiler. See correctness of short cut fusion.

Haskell si tak nějak neumí vybrat, co chce být. Jestli akademický jazyk, který má ukázat, jak se to má dělat správně, nebo jazyk, který bude i pro mainstreamované použití. Chtěli jít i tou druhou cestou, potřebovali vylepšit výkon, tak začali tu akademickou část prasit. Ve výsledku není Haskell ani jedno a výkon taky nic moc.

Někde je nějaký paper o tom, jak všechno tohle, co linkuješ je akademicky pravda a v praxi irelevantní (teď si fakt nemůžu vzpomenout jak se jmenoval). Konkrétně u "fusion" jde o to, že program, který by jinak spadnul, překvapivě funguje. Což je fakt děsný problém.

Ono by fakt asi bylo lepší, kdyby ta seq nebyl, čímž pádem by foldl nešlo reálně vyhodnotit - ale bylo by to filosoficky čisté a pak bysto rozhodně začal používat??

Nebo kdyby to naopak bylo celé strict, takže bys u spousty knihoven měl 2 verze toho samého, jednou pro strict a jednou pro lazy variantu? (viz knihovny u purescriptu) To by byla taky evidentně výhra...? Nebo jak si to představuješ?

Citace
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é?
Všechno co jsi vyjmenoval umí ošetřit i jiné jazyky. Třeba Rust s výkonem řádově jinde než Haskell.
A výkon je faaakt ta nejdůležitější věc, kteoru si vybírám v jazyce....  Toho psa brzo ubiješ...

Citace
Hele, že tys v haskellu ještě nic pořádně nenapsal, nejde ti to, tak jsi se rozhodl, že to "prostě nejde"?
S Haskellem jsem si v rámci výzkumu soukromě hrál a nepřesvědčil mě, na větší projekt bych ho nepoužil. Můžeš si klidně myslet, že mi to v Haskellu nejde, je mi to jedno. Důvodů, proč mě Haskell nepřesvědčil, je víc, výkon je až někde hodně vzadu.
No vždyť jo, celou dobu tady píšeš, že ti na haskellu vadí, že není filosoficky čistý, nikoliv výkon. Tak právě píšu, že to je dost uhozený důvod jazyk nepoužít...

Citace
C-like jazyky nejsou vhodné do produkce kvůli tomu, že to používá pointry,
Ale to je dávno známá věc, že C-like jazyky nejsou vhodné pro produkci. K používání C v produkci už je dnes jen pár legitimních důvodu: omezené zdroje (RAM, CPU) nebo požadavky na co nejvyšší výkon. V jiném případě se prakticky vždy vyplatí sáhnout po něčem jiném než C.
No vidíš a dlouhou dobu se v produkci používaly.... Co třeba Java s nullpointerexception? Taky se dlouho používala - a používá. Prostě ty kompilery a jazyky nejsou dokonalé...ale fakt, že Haskell není filosoficky čistý je prostě důvod ten jazyk nepoužít.

lopata

Re:Rychlost Haskell vs. C++
« Odpověď #73 kdy: 26. 08. 2018, 10:42:43 »
Andy, pořád jsi nepochopil, jaká je strict vyhodnocení v Haskellu prasárna. Nevadí, zkusím to znovu. Změnit způsob vykonávání kódu a změnit sémantiku existujícího kódu jsou totiž dost rozdílné věci. Když píšeš třídu v C++, nemusíš přemýšlet o tom, jestli bude vytvořená na heapu nebo na stacku, bude fungovat v obou případech. Neexistuje žádné pragma stack ani pragma heap, které by měnilo sémantiku kódu ve třídě, podle toho, jestli je vytvořená na stacku nebo heapu. Pragma strict v Haskellu to ale dělá, kód který funguje bez pragma strict nemusí fungovat s ním a naopak. Úlpně to mení sémantiku kódu, nikoliv takové detaily, kde leží data, jestli na stacku nebo na heapu.

borekz

  • ****
  • 492
    • Zobrazit profil
    • E-mail
Re:Rychlost Haskell vs. C++
« Odpověď #74 kdy: 26. 08. 2018, 13:19:46 »
No vidíš a dlouhou dobu se v produkci používaly.... Co třeba Java s nullpointerexception? Taky se dlouho používala - a používá.
Co je nebezpečného na tom, že Java předvídatelně vyhodí výjimku při dereferencování null pointeru ? C umí akorát SIGSEGV při přístupu na určitý rozsah adres a asi právě proto adresový prostor nezačíná na nule, ale o několik megabytů výše. V případě hodně dlouhého pole začínajícího na nule se to odchytit nemusí. Problém pointerů a v C ale jinde. Snadno se poškodí nesouvisející paměť, v horším případě zásobník a chyba se nemusí projevit ihned na místě chyby v kódu, ale může se projevit se zpožděním naprosto nepředvídatelně a tudíž neodhalitelně.