Příspěvky

2341

Studium a uplatnění / Re:Kniha Objektové programování od Čady

« kdy: 29. 05. 2017, 16:34:46 »

Nevim, jestli spamovat vlakno o necem uplne jinem, ale kdyz uz jste s tim zacali... A koneckoncu je to mistni kolorit, tak snad v poho 

Pochopení FP do hloubky vyžaduje detailní znalost teorie kategorií. [...] Ovšem ne každý to potřebuje, takže se není o čem hádat.

To tvrzeni mi prijde vylozene zhoubne. Protoze uplne zbytecne od FP odrazuje lidi, kteri ho ani nezkusili, popr. ty, kdo ho zkusili a po prvnim zamotani se rychle skoncili, utvrdi v tom, ze udelali dobre. A pritom je dost zavadejici, kdyz uz nechci rict vylozene nepravdive.

V "pragmatickych" FP jazycich, kde jsou povolene side effects (vychazejici ze Standard ML nebo Lispu), je TK vicemene uplne nadbytecna. V pure jazycich typu Haskell se muze hodit na to, ze se na ty konstrukce v jazyce muzu podivat z obecnejsiho pohledu, z jineho uhlu, pochopit, proc je to udelane tak, jak je to udelane. Muze mi to dodat nejaky nadhled apod., ale k praktickemu, skutecnemu, programovani to neni potreba vubec. Uplne bohate staci se naucit to, co v tom jazyce je: ze Functor je typeclass s nejakymi funkcemi a ma splnovat nejake axiomy. Proc, to mi muze byt z praktickeho hlediska uplne putna. Pro nekoho je zabava to zjistit a rozsirit si obzory, ale potreba to neni.

Tak zbytecne nestras lidi!

P.S. pokud by nekdo jo chtel, urcite by pomoci TK slo popsat i OOP - a tvrzeni "k programovani v OOP musite znat TK" by se pak ukazalo ve sve nahote

2342

Vývoj / Re:Přepsání serveru v Javě

« kdy: 25. 05. 2017, 19:20:21 »

No nic, jdu na pláž, přeju hodně sil v boji s duševním polotovarem

Abysme si rozuměli, mně se Elm moc líbí a používám ho rád. Protože nejsem haskellista, tak mi absence typeclasses zas tak moc nevadí, prostě se občas duplikuje kód, ale zas je aspoň jednodušší a není "přeabstrahováno", což mně u Haskellu občas trochu vadí (pokud to člověk nemá všechno v hlavě, musí sestoupit postupně několik vrstev abstrakce, aby zjistil, co ten kód vlastně dělá).

Akorát Elm není pro člověka, který aspoň trochu zná Haskell, moc zajímavý z hlediska studia. Zajímavý je jenom podívat se, co zjedodušili a jaké to má pro webový vývoj důsledky. Jinak tam myslím není nic moc, co by nebylo v Haskellu.

2343

Vývoj / Re:Přepsání serveru v Javě

« kdy: 25. 05. 2017, 18:21:05 »

Haskell jde nějak zjednodušit?     

Jo. Elm nemá typeclasses. Takže nemá ani obecné monády. Pro každý typ je potřeba monádu napsat zvlášť - např. http://package.elm-lang.org/packages/elm-lang/core/5.1.1/Json-Decode#andThen

2344

Vývoj / Re:Přepsání serveru v Javě

« kdy: 25. 05. 2017, 18:17:02 »

O vyhlazení špiček právě jde.

Řekl kdo? Třeba o ně vůbec nejde.

bavíme se o na sobě nezávislých úlohách.

A?

Jo, kouknu, aspoň zběžně, i když ve frontě mám asi milion dalších věcí, třeba Rust nebo Elm - a času je málo...

Rust ti schvaluju, ze seriálu Pavla Tišnovského mě taky zaujal Ale Elixir si dej před Elm. Elm je jenom takový "zjednodušený Haskell pro web" - oproti Haskellu tam nic moc novýho nevykoukáš, Elixir, resp OTP je daleko zajímavější

2345

Vývoj / Re:Přepsání serveru v Javě

« kdy: 25. 05. 2017, 17:40:53 »

Jo, myslel jsem třeba přes síť. Erlang se mi začíná líbit

Tyjo, to's mě dost překvapil, že ho neznáš ani z rychlíku. Určitě na něj koukni, je to extrémně zajímavá věc, minimálně pro studijní účely.

Víc než plain Erlang bych teda doporučil Elixir - je modernější, má zepár modernějších featur (třeba homoikonická, volitelně hygienická makra) a opravuje drobné chybky Erlangu (např. fakt úplně všechno je výraz, to v Erlangu neplatí). Zároveň je s Erlangem plně kompatibilní (asi tak jako Scala s Javou).

2346

Vývoj / Re:Přepsání serveru v Javě

« kdy: 25. 05. 2017, 17:31:18 »

fronta omezí množství dat zpracovávané současně.

O-M-G!

Tak samozřejmě. Pokud mám 50 req/s a pro každý musím načíst několik MB, tak se můžu dostat do úzkých. Ale to nemá žádné řešení. Pool ani fronta to nijak nevyřeší, maximálně můžou trochu vyhladit špičky.

To rozhodně. A právě proto mezi sebou erlangovské procesy komunikují zprávami, které se ukládají do - tramtadadáááá - fronty

2347

Vývoj / Re:Přepsání serveru v Javě

« kdy: 25. 05. 2017, 17:28:43 »

Když už jsme u toho "zahazování" - v jazycích majících nativně CSP lze napsat optimální load balancer na dva řádky. Erlang neznám, nevím, jestli má posílání zpráv v rámci IPC, ale nejspíš by to šlo stejně snadno jako v Go.

Nevím, co přesně myslíš "posílání zpráv v IPC". Erlangovské procesy komunikují jenom pomocí zpráv, popř. DB. Navíc mechanismus posílání zpráv v rámci jednoho erlangovského VM nebo víc (třeba přes síť) je stejný, takže je to plně transparentní, dobře se to horizontálně škáluje.

Asi největší rozdíl oproti Go (který znám teda málo...) je v tom, že vybírání zpráv z mailboxu je v Erlangu selektivní - tj. můžu si pomocí patternmatchingu třeba vybrat zprávy, který chci zpracovat přednostně. U Go bych asi (?) musel použít separátní channely, což je míň pohodlný a komplikuje to kód.

2348

Vývoj / Re:Přepsání serveru v Javě

« kdy: 25. 05. 2017, 17:22:35 »

Když jsou to části, které nepoužívám, může mi být úplně jedno, že jsou tam nějaké chyby.

Opsáci to vidí jinak. Stomegové updaty jednou měsíčně, opravující nikdo neví co, miluje každý

Pokud je to děsivý moloch, tak to nepoužívejte.

Nepoužívám

Já jsem také psal o nejzazší krizové možnosti. Jenže když už k takové situaci dojde, je pořád lepší, když server zvládne obsloužit aspoň nějaké požadavky, než když je plně zaměstnán sám sebou a neodvede vůbec žádnou reálnou práci.

To rozhodně. A právě proto mezi sebou erlangovské procesy komunikují zprávami, které se ukládají do - tramtadadáááá - fronty

Ten proces pracuje s nějakými daty. Ta mohou být velká.

Zatímco když se použije fronta, tak budou malá?!

2349

Vývoj / Re:Přepsání serveru v Javě

« kdy: 25. 05. 2017, 16:41:31 »

Rozdíl je v paměťové náročnosti.

Jak už tady zaznělo, jeden Erlangovský proces zabírá řádově 300 slov. Kde je jaká paměťová náročnost?!

Výhoda je i v oddělení náročných úloh od ostatních.

Což samozřejmě můžu (a měl bych) udělat i u procesů.

Fronty úloh se používají i v Erlangu/Elixiru

Ano - tam, kde k tomu je explicitní důvod. Což je docela málo kdy, protože právě co se v jiných prostředích řeší frontami, dá se často v Erlangu řešit procesy.

To ale platí skoro o všech knihovnách a nástrojích – i s Erlangem nebo i s glibc dostanete spoustu balastu, který váš program nevyužije.

Ano, ale tu funkcionalitu, o které se bavíme, mám v Erlangu přímo v runtimu.

Ale vadí to něčemu? Tohle budete řešit maximálně u mikrokontrolerů s omezenou pamětí, a to je evidentně jiný typ úloh, než jaký se tu řeší.

Vadí to v případě, že ten balast se například musí natahovat při startu, že v něm bývají chyby, že je to děsivý moloch, který nikdo neví, jak funguje atd. atd.

Chce a fronty to právě řeší.

Lidi nechtějí požadavky zahazovat. Lidi chtějí mít tak výkonné systémy, aby dokázaly všechny požadavky zpracovat - a mít i nějakou rezervu, popř. autoscaling. Zahazování by měla být nejzazší krizová možnost, není to něco, čím by kdokoli chtěl řešit problém.

To nebude ipso facto schedulerem, ale tím, že tam je kooperativní rozvrhování. Stejně optimálně by to fungovalo v jakémkoliv jazyce nebo prostředí od Go přes GCD po - blahé paměti - WebObjects.

Jasně, já jsem jenom chtěl říct, že v Erlangu typicky bývá hodně malých procesů a ty pak scheduler rozhazuje po dostupných vláknech. Hodně malých procesů má větší pravděpodobnost vlákna vytížit rovnoměrně, čistě statisticky. V jazycích, kde mám obvykle procesů míň, to nebude tak dobře fungovat (ale v principu je to to samý, o to se nehádám).

2350

Vývoj / Re:Přepsání serveru v Javě

« kdy: 25. 05. 2017, 15:23:52 »

To samé platí i při použití vhodných frameworků nebo knihoven.

Jo, může být. Akorát frameworky a knihovny (obzvlášť "enterprise" v Javě) vždycky hrozí dalším bobtnáním a hromadou balastu, kterou člověk nevyužije...

Pokud každý Erlangovský proces načte do paměti několika-megabyteový soubor, tak vám dojde paměť úplně stejně jako v Javě.

Tak samozřejmě. Pokud mám 50 req/s a pro každý musím načíst několik MB, tak se můžu dostat do úzkých. Ale to nemá žádné řešení. Pool ani fronta to nijak nevyřeší, maximálně můžou trochu vyhladit špičky.

Erlangovské procesy se opravdu hodí jen k udržování socketového spojení, kdy většinu času nic nedělají. Pro náročnější operace potřebujete frontu a omezení počtu souběžných operací.

A čím se jako principielně ta fronta od těch erlangovských procesů liší?! Tím, že můžu stanovit horní limit počtu obsloužených requestů? To většinou pochopitelně nikdo nechce.

Jo, je rozdíl mezi rychlým jazykem (C,C++,Java,Rust apod) a pomalým Erlangem, ale nevidím rozdíl mezi procesy a frontami (kromě toho, že fronty musím pracně obhospodařovávat).

2351

Vývoj / Re:Přepsání serveru v Javě

« kdy: 25. 05. 2017, 13:30:27 »

Pokud ty procesy přistupují k nějakým omezeným prostředkům, nebo žerou hodně paměti, tak jich chcete mít jen omezený počet.

Ano - a přesně proto, pokud se týče CPU, spouští Erlangovský scheduler tolik OS-vláken, kolik je jader Není to závislé na počtu (erlangovských) procesů.

Pokud je problém s pamětí nebo GC, tak ten u Erlangu taky s velkou pravděpodobností nebude, protože v Erlangu je GC lehčí než v Javě.

Pokud je problém s DB, tak se i v Erlangu musí použít pool, tam nijak nepomůže.

Jedině pokud by aplikace dělala nějaké intenzivní výpočty, tak by byl Erlang vyloženě nevhodná volba.

Podstatné bylo to „pokud ta vlákna skutečně něco dělají“. Pokud je ten server přetížený tím, že má moc práce,

...tak nepomůže nic než optimalizovat kód nebo povýšit hw, protože Java je slušně výkonná a přepsáním do jiného jazyka se moc nezíská.

nepomůže to, že budete práci jiným způsobem přerozdělovat.  Tam je řešením jedině řadit požadavky do fronty [...]

Netvrdil jsem, že pomůže přerozdělení, ale že v Erlangu člověk může dál psát tím pohodlným způsobem, že každý request řeší v samostatném "vláknu" (erlangovském procesu) a scheduler za něj rozprostření po dostupných CPU vyřeší (pro dobře napsaný kód velmi optimálně) sám. Čili má člověk optimalitu poolu zadarmo, aniž by nějaký pool, fronty, zamykání atd. musel řešit.

2352

Vývoj / Re:Přepsání serveru v Javě

« kdy: 25. 05. 2017, 12:05:36 »

Jestli ta vlákna skutečně něco dělají, tak Erlang ani Node.js nepomohou. Výpočetně náročné úlohy musíte zpracovávat v nějakém poolu s omezeným počtem vláken.

Pokud je hlavní problém v tom, že se pro každý req spouští samostatné vlákno (a zároveň se OP chce zbavit Javy), tak by Erlang rozhodně pomohl. Dál v něm může každý req zpracovávat ve vlastním procesu a přitom se mu to krásně bude samo škálovat přes všechna dostupná jádra - žádný pool tam není potřeba, bude to fungovat samo, zabezpečí to erlangovský scheduler.

2353

Vývoj / Re:Callbacky vs. korutiny v C

« kdy: 23. 05. 2017, 10:55:40 »

NIL je vhodná i pro AVR a neumí round-robin preemption vláken stejné priority (tj. sledování spotřebovaného time slicu a přepnutí při zjištění jeho vypršení). Umí preemption vláken různých priorit. Tj. když se probudí vlákno vyšší priority interruptem od časovače nebo periférie, uloží stav stávajícího vlákna a přepne na jiné s vyšší prioritou. Samozřejmě se musí hlídat paměť. NIL neumí dynamicky vytvářená vlákna.

Aha, tak to je lepsi, nez jsem myslel - omezeni jsou tam porad velky, ale na AVR je to super vysledek.

Diky moc za doplneni a linky!

2354

Vývoj / Re:Callbacky vs. korutiny v C

« kdy: 23. 05. 2017, 10:30:51 »

Co konkrétně je potřeba v MCU pro správu "vláken", jaká se používají v tenkých "OS" typu FreeRTOS či ChibiOS? Běží to i na AVR v arduinu http://www.chibios.org/dokuwiki/doku.php?id=chibios:product:nil:features

Pro složitější projekty se tenká vrstva takového "OS" hodí.

Myslim, ze je potreba odlisit vlakna a tasky (abysme vedeli, o cem se vlastne bavime). Neznam vnitrnosti ChibiOSu pro AVR, ale mam podezreni, ze bude fungovat jenom na principu casovace - tj. zadam si, ze za dve sekundy chci spustit nejaky task a on se mi za dve sekundy spusti, pokud v tu dobu nebezi jiny task.

Docela pochybuju o tom, ze by se na AVR dal udelat "plnotucny" hard realtime system s preempci, ale mozna se mylim.

2355

Bazar / Re:Koupím PowerMac G5 (2x CPU)

« kdy: 22. 05. 2017, 22:37:19 »

Když už jsme u těch sběratelských artiklů, mám tu jednu HP Visualize B2000 workstation a k tomu druhou desku. Má to PA-RISC 2.0 procesor a grafiku…

Spíš něco od SGI by bylo zajímavý - Tezro, O2, Fuel...