Má Haskell budoucnost?

čumil

Re:Má Haskell budoucnost?
« Odpověď #210 kdy: 16. 05. 2016, 11:00:05 »
To není nic divnýho, u algoritmicky jednoduchých problémů, kde máš vytuněné řešení v C, bude každý vysokoúrovňový jazyk vždycky pomalejší. Protože prostě C má blíž k hardware, takže na těhle problémech moc není jak ho porazit.
Na tom není celkem co tunit, ten algoritmus je asi na 3 řádky. Ano je to algoritmicky jednoduché, ale když Haskell nedrží krok ani v jednoduchých čistě matematických nemutable algoritmech, proč bych měl věřit tomu, že to bude v něčem vysokoúrovňovém lepší? Jednoduché algoritmy jsou pomalé, ale složité budou rychlé? Nemyslím si to.
S vyšší abstrakcí jde ruku v ruce nižší rychlost. FP je v některých případech ultimate win (parser combinator atp.) a někdy zas ultimate lose. BTW FP je schopno implicitního paralelismu programů, takže hej, se správným runtime na stroji s hodně jadry bude FP jazyk rychlej jak fretka. V jiném jazyku by ses pekloval s thready zatimco FP program by už běžel.


gamer

Re:Má Haskell budoucnost?
« Odpověď #211 kdy: 16. 05. 2016, 11:04:15 »
No tím "vytuněný" jsem myslel, že ten C kód se přeloží do nějakého optimálního strojáku. Tak je asi zřejmé, že nějaký "optimálnější než optimální" stroják asi těžko můžeš z jakéhokoliv jazyka dostat.
Však Haskell se taky překládá do nativního strojáku, kde je rozdíl?

Nikdo tě nenutí si to myslet. Když tě Haskell neoslovuje a nevěříš mu, tak ho nepoužívej, co na tom chceš řešit? :)
Nechci řešit nic, mně se Haskell celkem zalíbil, trochu jsem si s ním hrál, ale přitom přišlo celkem rozčarování. Výkon nic moc, občas mi to spadlo na velkých datech na stack overflow (když se Haskellu nepovedla nějaká tail recursion optimization). Jasně, je to moje chyba, měl jsem kód napsat líp, aby to Haskell správně pochopil a nespadl na stak overflow, ale takové chyby mě po pravdě děsí, v testu se to nemusí projevit a v produkci na velkých datech začne padat. Neviním z toho Haskell, aby bylo jasno, jednom ho prostě neumím dost dobře používat :).

gamer

Re:Má Haskell budoucnost?
« Odpověď #212 kdy: 16. 05. 2016, 11:09:31 »
S vyšší abstrakcí jde ruku v ruce nižší rychlost. FP je v některých případech ultimate win (parser combinator atp.) a někdy zas ultimate lose. BTW FP je schopno implicitního paralelismu programů, takže hej, se správným runtime na stroji s hodně jadry bude FP jazyk rychlej jak fretka. V jiném jazyku by ses pekloval s thready zatimco FP program by už běžel.
Nějaký praktický příklad, kdy bude FP jazyk rychlý jako fretka? Teorie je to hezká, ale nějaké praktické srovnání? Tyhle abstraktní výroky nemám rád. Jo až se nějaký hypotetický algoritmus pustí v FP na stoji v více jádry, to bude hukot... No asi bude... Co se na to dá říct?

Re:Má Haskell budoucnost?
« Odpověď #213 kdy: 16. 05. 2016, 11:11:51 »
Však Haskell se taky překládá do nativního strojáku, kde je rozdíl?
Rozdíl je v tom, že u Céčka je skoro přímá korespondence mezi zdrojákem a strojákem.

Výkon nic moc
Hrubý výkon sám o sobě je v dnešní době celkem podružná věc. Vždyť stejně dneska všechno jede na virtualizaci, ve které je ještě docker a komponenty spolu komunikují po TCP z jednoho kontejneru do druhého ;)

Pokud někde nutně potřebuješ výkon i za cenu dražšího vývoje a horší udržovatelnosti, tak prostě použiješ céčko.

občas mi to spadlo na velkých datech na stack overflow (když se Haskellu nepovedla nějaká tail recursion optimization).
Haskell v praxi nepoužívám, takže si nejsem jistý, ale tohle mi přijde hodně divný. Tail rekurze by se imho měla poznat vždycky. Problém bývá spíš v tom, že ten program je špatně napsaný, takže tam ta tail rekurze prostě není (je tam rekurze jinde než na konci).

Jasně, je to moje chyba, měl jsem kód napsat líp, aby to Haskell správně pochopil
Nejde o to, že by to nepochopil, ale o to, že ne-koncová rekurze se prostě optimalizovat nedá a na zásobník se ukládat musí.

Re:Má Haskell budoucnost?
« Odpověď #214 kdy: 16. 05. 2016, 11:13:47 »
Nějaký praktický příklad, kdy bude FP jazyk rychlý jako fretka? Teorie je to hezká, ale nějaké praktické srovnání? Tyhle abstraktní výroky nemám rád. Jo až se nějaký hypotetický algoritmus pustí v FP na stoji v více jádry, to bude hukot... No asi bude... Co se na to dá říct?
Co se na to dá říct? Že to je stejně obecné tvrzení jako "zkusil jsem to a bylo to pomalý". Pokud tě to opravdu zajímá, tak si prostě najdi nějaké testy. Nevím jak pro Haskell, ale pro Erlang by ti mělo stačit napsat do Googlu "erlang linear scalability test" a můžeš číst až do smrti :)


andy

Re:Má Haskell budoucnost?
« Odpověď #215 kdy: 16. 05. 2016, 11:18:55 »
To není nic divnýho, u algoritmicky jednoduchých problémů, kde máš vytuněné řešení v C, bude každý vysokoúrovňový jazyk vždycky pomalejší. Protože prostě C má blíž k hardware, takže na těhle problémech moc není jak ho porazit.
Na tom není celkem co tunit, ten algoritmus je asi na 3 řádky. Ano je to algoritmicky jednoduché, ale když Haskell nedrží krok ani v jednoduchých čistě matematických nemutable algoritmech, proč bych měl věřit tomu, že to bude v něčem vysokoúrovňovém lepší? Jednoduché algoritmy jsou pomalé, ale složité budou rychlé? Nemyslím si to.
Jasně - chápu, že si to jedno kolečko v převodovce doma v dílně uděláš líp, než ti to vyplivne továrna. A teď se zkus zamyslet nad tím, kdo dokáže postavit lepší auto.


gamer

Re:Má Haskell budoucnost?
« Odpověď #217 kdy: 16. 05. 2016, 11:23:21 »
Hrubý výkon sám o sobě je v dnešní době celkem podružná věc. Vždyť stejně dneska všechno jede na virtualizaci, ve které je ještě docker a komponenty spolu komunikují po TCP z jednoho kontejneru do druhého ;)

Pokud někde nutně potřebuješ výkon i za cenu dražšího vývoje a horší udržovatelnosti, tak prostě použiješ céčko.
To není o C(++) versus Haskell, ale spíš cokoliv mainstreamového imperativního versus něco funkcionálního. Mně osobně to z hlediska nákladů na vývoj a udržovatelnost zatím vychází lépe pro imperativní jazyk. Na funkcionální jazyk neseženu lidi a když je seženu, tak budou dražší. Se zaučením bude taky problém, přijde mi, že funkcionální jazyky mají hodně plochou křivku učení.

gamer

Re:Má Haskell budoucnost?
« Odpověď #218 kdy: 16. 05. 2016, 11:27:35 »
Jasně - chápu, že si to jedno kolečko v převodovce doma v dílně uděláš líp, než ti to vyplivne továrna. A teď se zkus zamyslet nad tím, kdo dokáže postavit lepší auto.
Troufám si tvrdit, že C++ nebo Java nabízí minimálně stejně dobrou míru abstrakce jako Haskell a fungují jak pro jedno kolečko v převodovce, tak pro celé auto.

Re:Má Haskell budoucnost?
« Odpověď #219 kdy: 16. 05. 2016, 11:28:19 »
To není o C(++) versus Haskell, ale spíš cokoliv mainstreamového imperativního versus něco funkcionálního. Mně osobně to z hlediska nákladů na vývoj a udržovatelnost zatím vychází lépe pro imperativní jazyk. Na funkcionální jazyk neseženu lidi a když je seženu, tak budou dražší. Se zaučením bude taky problém, přijde mi, že funkcionální jazyky mají hodně plochou křivku učení.
To se spíš mýlíš. Nebo respektive jde o to, co chceš dělat. Opět: najdeš na webu různé success stories, kde CTO malé firmy práskl do stolu, zavedl FP a pochvaluje si to. Samozřejmě pokud seš mamutí firma s tisíci programátorů, kteří pro tebe nejsou nic než spotřební zboží, tak tam by to asi těžko fungovalo.

Zajímavá oblast, na které to je vidět, jsou třeba distribuované databáze. Každý rok se vyrojí minimálně jeden startup, který má relativně během chvilky napsaný v Erlangu nějaký DB engine s hodně zajímavými vlastnostmi. Oproti tomu rychlost vývoje klasických RDBMS se počítá spíš na eony ;)

Re:Má Haskell budoucnost?
« Odpověď #220 kdy: 16. 05. 2016, 11:31:31 »
Troufám si tvrdit, že C++ nebo Java nabízí minimálně stejně dobrou míru abstrakce jako Haskell

Tak urcite.

andy

Re:Má Haskell budoucnost?
« Odpověď #221 kdy: 16. 05. 2016, 11:52:05 »
Jasně - chápu, že si to jedno kolečko v převodovce doma v dílně uděláš líp, než ti to vyplivne továrna. A teď se zkus zamyslet nad tím, kdo dokáže postavit lepší auto.
Troufám si tvrdit, že C++ nebo Java nabízí minimálně stejně dobrou míru abstrakce jako Haskell a fungují jak pro jedno kolečko v převodovce, tak pro celé auto.
Hmm... dobře. Tak teď já. Máš obrovský JSON soubor. Je to pole, vyskytují se v něm 2 typy záznamů. Třeba něco typu
Kód: [Vybrat]
{ "name": ..., "score":...} a { "organization": .., "score" ..  }.
Chceš vypsat součet score, organizační skóre chceš násobit deseti. Tak v haskellu by to vypadalo cca takhle (z hlavy):
Kód: [Vybrat]
let parser = "name" .: string *> score .: integer
                <|> (*10) <$> "organization" .: "string" *> "score" .: integer)
res <- readFile =$= parseIncremental parser =$= CL.fold (+) 0
Jak to zvládneš v C++?

gamer

Re:Má Haskell budoucnost?
« Odpověď #222 kdy: 16. 05. 2016, 12:54:27 »
Hmm... dobře. Tak teď já. Máš obrovský JSON soubor. Je to pole, vyskytují se v něm 2 typy záznamů. Třeba něco typu
Kód: [Vybrat]
{ "name": ..., "score":...} a { "organization": .., "score" ..  }.
Chceš vypsat součet score, organizační skóre chceš násobit deseti. Tak v haskellu by to vypadalo cca takhle (z hlavy):
Kód: [Vybrat]
let parser = "name" .: string *> score .: integer
                <|> (*10) <$> "organization" .: "string" *> "score" .: integer)
res <- readFile =$= parseIncremental parser =$= CL.fold (+) 0
Jak to zvládneš v C++?

Tohle je elegantní, uznávám, v C++ by to tak hezký nebylo. Ale je to taky dost speciální případ, funguje to jen díky tomu, že JSON je context-free jazyk. Pokud bys chtěl parsovat něco složitějšího, nebo kontrolovat validitu toho JSON souboru, tak stejně skončíš u nějakého obecnějšího parseru pro konkrétní formát dat.

andy

Re:Má Haskell budoucnost?
« Odpověď #223 kdy: 16. 05. 2016, 13:20:16 »
¨Tohle je elegantní, uznávám, v C++ by to tak hezký nebylo. Ale je to taky dost speciální případ, funguje to jen díky tomu, že JSON je context-free jazyk. Pokud bys chtěl parsovat něco složitějšího, nebo kontrolovat validitu toho JSON souboru, tak stejně skončíš u nějakého obecnějšího parseru pro konkrétní formát dat.
Normální parser by vypadal třeba takhle:
Kód: [Vybrat]
data Item = Person { name :: Text, score :: Int} | Organization { name :: Text, score :: Int }
instance FromJSON Item where
  parseJSON = withObject "Item" $ \obj -> parsePerson obj <|> parseOrg obj
     where
       parsePerson o = Person <$> o .: "name" <*> o .: "score"
       parseOrg o = Organization <$> o .: "organization" <*> o .: "score"
No a tohle klidně můžeme vložit i do toho streaming parseru, takže máme třeba:
Kód: [Vybrat]
getScore User{score} = score
getScore Organization{score} = 10 * score
res <- runConduit $ readFile ... =$= parseIncremental (arrayOf value) =$= CL.map getScore =$= CL.fold (+) 0
A tohle je parser pro konkrétní formát dat. Ta FromJSON část je "monadická", tzn. je možné tam napsat jakoukoliv logiku. A tohle není speciální případ. Takhle to funguje ve většině haskellu. Dva často uváděné příklady - quickcheck a stm. Představ si, že chceš např. otestovat, jestli ti decode (encode x) je totéž. Např. pro výše uvedenou strukturu Item. To se hodí v momentě, kdy to dekódování nemáš generované automaticky. Tak takhle se to dělá v haskellu:
Kód: [Vybrat]
instance Arbitrary Item where
   arbitrary = oneOf [ Person <$> arbitrary <*> arbitrary, Organization <$> arbitrary <*> arbitrary ]

enc_check :: (FromJSON a, ToJSON a, Eq a) => a -> Bool
enc_check = decode (encode a) == Just a

spec = do
  describe "JSON structures" $ do
      prop "Item" (jsonCheck :: enc_check -> Bool)
A test je hotový.

No a STM - software transactional memory - psal jsi někdy multithreadované aplikace? Tak třeba následující kód je úplně OK v multithreadovaném programu:
Kód: [Vybrat]
prevedPenize zdroj cil obnos =
   atomically $ do
      zustatek <- readTVar zdroj
      if | zustatek >= obnos -> return False
         | otherwise -> do
            modifyTVar zdroj (subtract obnos)
            modifyTVar cil (+ obnos)
            return True
Tenhle kód je perfektně thread-safe. Žádné zámky, nic. Výkonnost? Ano, není to tak super-rychlé, jako kdybys to řešil v C++ se zámkama, ale pořád je to velmi slušně rychlé.

A tohle je jen nástin věcí, které lze s abstrakcema v haskellu udělat. To není žádný "speciální příklad", takhle vypadá normální kód a ty abstrakce se tam využívají. Hodně.

noef

  • *****
  • 897
    • Zobrazit profil
    • E-mail
Re:Má Haskell budoucnost?
« Odpověď #224 kdy: 16. 05. 2016, 13:53:31 »
Buď to bylo v Haskellu čitelné, ale oproti C(++) řádově pomalejší, nebo to bylo pomalejší jen asi 2x, ale naprosto nečitelné.
To není nic divnýho, u algoritmicky jednoduchých problémů, kde máš vytuněné řešení v C, bude každý vysokoúrovňový jazyk vždycky pomalejší. Protože prostě C má blíž k hardware, takže na těhle problémech moc není jak ho porazit.

Problémy ze skutečného světa ale nebývají algoritmicky jednoduché a na reálný výkon mají vliv jiné věci než hrubá rychlost výpočtu.

I v těchto umělých příkladech má ale Haskell výkonově blízko k Javě, což mi přijde dost dobrej výsledek na to, jak daleko je ten jazyk od hardware (sémanticky) - viz http://benchmarksgame.alioth.debian.org/u64q/haskell.html

Srovnavat takto vysokourovnovy jazyk s C(++) neni opravdu fer. S Javou/C#/PHP/Pythonem nebo Ruby by to bylo ferovejsi. Fakt jsem netusil, ze Haskell je na tom tak dobre s rychlosti - neminim to ironicky, navic kdyz si vezmem, ze JVM ma za sebou urcite ladeni vykonu zaplacene obrovskymi korporacemi.

...C++ nebo Java nabízí minimálně stejně dobrou míru abstrakce jako Haskell...

o_O