Naučení se asynchronnímu programování

Re:Naučení se asynchronnímu programování
« Odpověď #30 kdy: 07. 10. 2019, 17:37:31 »
Právěže to je shodné implementačně, třeba zrovna v C# funguje scheduler úplně stejně.
Nevim, jestli jsme si uplne porozumeli, ale to je jedno, je to prkotina, nechme to byt :)


Idris

  • *****
  • 2 286
    • Zobrazit profil
    • E-mail
Re:Naučení se asynchronnímu programování
« Odpověď #31 kdy: 07. 10. 2019, 17:42:39 »
akorát to teda nijak nesouvisí se smyčkou událostí, jde jen o kooperativní scheduler
Myslel jsem to tak, ze vsechny tyhle srandy ve finale na nejnizsi urovni znamenaji to samy - rozkouskovani linearnio kodu na nejake chunky, kterym se v nejakem loopu postupne prideluje cas behu. Potencialne na vic jadrech/vlaknech, ale to na tom nic nemeni.

(to může napsat jen javascriptař, ten víc vláken nezná, ale o srandajazycích se snad nebavíme :) ).
No tak on to prave nezna ani Python, v tom je cast toho celyho pruseru :)

Ne ne, akorát přidali přepínání korutin i k volání funkcí
To jo, ale to uz bylo davno. Ted jsem koukal, ze Go 1.2.
Jo, ideálně v loopu na úrovni jádra, proto to je vlastně jen obal okolo kqueue, IO ports etc. Těch víc vláken pak funguje na principu GCD, kde se korutiny přidělují vláknům z poolu, aby nedocházelo ke drahému přepínání kontextu. Technicky to je vlastně brilantní, pamatuju časy, kdy jsem psal nad kqueue přímo, to ještě nebylo ani Go, ani GCD, a Java ještě byla novinkou (ovšem bez NIO). Neuvěřitelné, jaké možnosti otevírá jeden syscall.

Re:Naučení se asynchronnímu programování
« Odpověď #32 kdy: 07. 10. 2019, 22:46:14 »
Zrovna jsem psal takovou jednu servisu v Jave ve Springu a rozhodoval jsem se jestli nektere casti kodu neudelt asynchronne pres Futures a nove thready. Ta resena uloha na to byla jako delana. Uz jsem to tak mel napsane a zjistil jsem, ze mi to prinese vice problemu nez uzitku. Nakonec jsem nasel zpusov jak to udelat normalnim sekvencnim kodem s fixne definovanymi worker thready a je to lepsi. A tak je to dycky. Nejhorsi je, kdyz nejaky jazyk, jako je C#, obsahuje 100 ruznych pitchovin featur. Pak vznikne problem typu "Kdyz mas kladivko, tak se vsechno jevi jako hrebik", a mas chut to vsechno pouzivat, ackoliv to akorat zvysuje komplikovanost kodu.

Ja se treba priznam, ze casto i dost vaham nad uzitecnosti Streamu (monady). Mnohokrat mi prijde pouziti Foreahe mnohem praktictejsi a prehlednejsi. Dodnes z pameti nevim, jak ve Streamu napr. udelat Group By nad Mapou a musim cumet do Googlu.

Po tisicateprve, ti lidi co to takhle ten synchronni design v historii pocitacu vymysleli, nebyli debilove nebo idioti.
« Poslední změna: 07. 10. 2019, 22:51:07 od PetrK »

Idris

  • *****
  • 2 286
    • Zobrazit profil
    • E-mail
Re:Naučení se asynchronnímu programování
« Odpověď #33 kdy: 07. 10. 2019, 22:50:31 »
Zrovna jsem psal takovou jednu servisu v Jave ve Springu a rozhodoval jsem se jestli nektere casti kodu neudelt asynchronne pres Futures a nove thready. Ta resena uloha na to byla jako delana. Uz jsem to tak mel napsane a zjistil jsem, ze mi to prinese vice problemu nez uzitku. Nakonec jsem nasel zpusov jak to udelat normalnim sekvencnim kodem s fixne definovanymi worker thready a je to lepsi. A tak je to dycky. Nejhorsi je, kdyz nejaky jazyk, jako je C#, obsahuje 100 ruznych pitchovin featur. Pak vznikne problem typu "Kdyz mas kladivko, tak se vsechno jevi jako hrebik", a mas chut to vsechno pouzivat, ackoliv to akorat zvysuje komplikovanost kodu.

Ja se treba priznam, ze casto i dost vaham nad uzitecnosti Streamu (monady). Mnohokrat mi prijde pouziti Foreahe mnohem praktictejsi a prehlednejsi. Dodnes z pameti nevim, jak ve Streamu napr. udelat Group By nad Mapou a musim cumet do Googlu.

Po tisicateprve, ti lidi co to takhle v historii pocitacu vymysleli, nebyli debilove nebo idioti.
Streamy jsou úlet.

PanVP

Re:Naučení se asynchronnímu programování
« Odpověď #34 kdy: 07. 10. 2019, 22:56:42 »
"Kdyz mas kladivko, tak se vsechno jevi jako hrebik"

+1000 bludišťáků


Re:Naučení se asynchronnímu programování
« Odpověď #35 kdy: 07. 10. 2019, 23:11:40 »
Jo a kdyz uz jsem se tak rozjel, tak bych chtel jeste rict, ze me dost casto sere i ten foreach a radeji bych pouzival obycejny for, kdyz to jde :D

Jak vidite, jsem konzervativni programator.

PanVP

Re:Naučení se asynchronnímu programování
« Odpověď #36 kdy: 07. 10. 2019, 23:12:52 »
vaham nad uzitecnosti Streamu (monady)
Streamy jsou úlet.

https://mikhail.io/2018/07/monads-explained-in-csharp-again/

To vysvětlení je celkem pěkné.
Ovšem, popravdě, když se po roce koukám na svůj kód, tak si říkám, co jsem tím chtěl vlastně říct?
No a nejsem si jistý, jestli zrovna tohle zlepšuje čitelnost zápisu.

gill

  • ****
  • 270
    • Zobrazit profil
    • E-mail
Re:Naučení se asynchronnímu programování
« Odpověď #37 kdy: 08. 10. 2019, 10:17:14 »
vaham nad uzitecnosti Streamu (monady)
Streamy jsou úlet.

https://mikhail.io/2018/07/monads-explained-in-csharp-again/

To vysvětlení je celkem pěkné.
Ovšem, popravdě, když se po roce koukám na svůj kód, tak si říkám, co jsem tím chtěl vlastně říct?
No a nejsem si jistý, jestli zrovna tohle zlepšuje čitelnost zápisu.

v C# pro to není syntax. Jsou jazyky, kde nemusíš psát  .Bind ručně.

kimec

Re:Naučení se asynchronnímu programování
« Odpověď #38 kdy: 08. 10. 2019, 10:33:49 »
Po tisicateprve, ti lidi co to takhle ten synchronni design v historii pocitacu vymysleli, nebyli debilove nebo idioti.
Ano, tento problem je prinajmensom znamy uz od polovice minuleho storocia 1963 Timesharing: A Solution to Computer Bottlenecks. (zvyraznene zamerne).

Ide v podstate iba o dve veci:
  • ergonomia abstrakcie, s ktorou naraba programator
  • efektivita z pohladu vyuzitia procesora

Najprv stacili programy/procesy, potom prisli vlakna, potom prisli callbacky a lahke vlakna. Uz len samotne kontinuacie boli znovuvynajdene niekolko krat od 60tych rokov... Kazde riesnie ma svoje vyhody a nevyhody. Ale v podstate sa zongluje iba s ergonomiou a efektivitou.

Ci riesim dany problem callbackmi, Promismi, event loopom, co mi poskytuje moj OS (BSD, Linux, Windows), ci ma moj languge runtime userspace scheduler, ktory vytazi CPU bez context switchov a pouziva krajsiu abstrakciu v podobe kontinuacie delimitovanej alebo inej, ci za mna kompiler urobi CPS transformaciu alebo nie, problem je stale ten isty... co robit, ked CPU nema co robit, lebo caka na IO.

kimec

Re:Naučení se asynchronnímu programování
« Odpověď #39 kdy: 08. 10. 2019, 10:51:26 »
Po tisicateprve, ti lidi co to takhle ten synchronni design v historii pocitacu vymysleli, nebyli debilove nebo idioti.
Ano, tento problem je prinajmensom znamy uz od polovice minuleho storocia 1963 Timesharing: A Solution to Computer Bottlenecks. (zvyraznene zamerne).

Ide v podstate iba o dve veci:
  • ergonomia abstrakcie, s ktorou naraba programator
  • efektivita z pohladu vyuzitia procesora

Najprv stacili programy/procesy, potom prisli vlakna, potom prisli callbacky a lahke vlakna. Uz len samotne kontinuacie boli znovuvynajdene niekolko krat od 60tych rokov... Kazde riesnie ma svoje vyhody a nevyhody. Ale v podstate sa zongluje iba s ergonomiou a efektivitou.

Ci riesim dany problem callbackmi, Promismi, event loopom, co mi poskytuje moj OS (BSD, Linux, Windows), ci ma moj languge runtime userspace scheduler, ktory vytazi CPU bez context switchov a pouziva krajsiu abstrakciu v podobe kontinuacie delimitovanej alebo inej, ci za mna kompiler urobi CPS transformaciu alebo nie, problem je stale ten isty... co robit, ked CPU nema co robit, lebo caka na IO.

Zmrsene odkazy:

https://www.youtube.com/watch?v=Q07PhW5sCEk

https://homepages.inf.ed.ac.uk/wadler/papers/papers-we-love/reynolds-discoveries.pdf

Re:Naučení se asynchronnímu programování
« Odpověď #40 kdy: 08. 10. 2019, 10:58:39 »
Ja se treba priznam, ze casto i dost vaham nad uzitecnosti Streamu (monady). Mnohokrat mi prijde pouziti Foreahe mnohem praktictejsi a prehlednejsi. Dodnes z pameti nevim, jak ve Streamu napr. udelat Group By nad Mapou a musim cumet do Googlu.

Co mají Streamy s monádami? Prostě normální funkce vyššího řádu.

A ručně se to copak implementuje snáz? Mapa, group by funkce, funkce na agregaci.. Taky se dívám do dokumentace, když to píšu, ale mnohem častěji to pak čtu. A ta Stream varianta je pro čtení mnohem přehlednější.


Idris

  • *****
  • 2 286
    • Zobrazit profil
    • E-mail
Re:Naučení se asynchronnímu programování
« Odpověď #41 kdy: 08. 10. 2019, 11:54:18 »
Ja se treba priznam, ze casto i dost vaham nad uzitecnosti Streamu (monady). Mnohokrat mi prijde pouziti Foreahe mnohem praktictejsi a prehlednejsi. Dodnes z pameti nevim, jak ve Streamu napr. udelat Group By nad Mapou a musim cumet do Googlu.
Co mají Streamy s monádami? Prostě normální funkce vyššího řádu.
  ::)

Re:Naučení se asynchronnímu programování
« Odpověď #42 kdy: 08. 10. 2019, 12:16:07 »
Ja se treba priznam, ze casto i dost vaham nad uzitecnosti Streamu (monady). Mnohokrat mi prijde pouziti Foreahe mnohem praktictejsi a prehlednejsi. Dodnes z pameti nevim, jak ve Streamu napr. udelat Group By nad Mapou a musim cumet do Googlu.

Co mají Streamy s monádami? Prostě normální funkce vyššího řádu.
Nic moc, krom toho že streamy jsou monády. :D Akorát "bind" je přejmenovaný na "flatMap".

Re:Naučení se asynchronnímu programování
« Odpověď #43 kdy: 08. 10. 2019, 14:42:49 »
Co mají Streamy s monádami? Prostě normální funkce vyššího řádu.
Nic moc, krom toho že streamy jsou monády. :D Akorát "bind" je přejmenovaný na "flatMap".

A to je v kontextu Javy a asynchronního programování důležité proč? Je to pojem z matematické teorie kategorií, který pro běžného programátora není naprosto důležitý. Kdejaká operace splňuje definici grupy nebo monoidu, ale použivá se to tak akorát při formálních důkazech a analýzách algoritmů.

V Pythonu se to samé dělá přes List comprehensions a itertools, v C# pomocí LINQ. V Javě holt syntaxe vyšla jak vyšla. Streamy jsou totiž hlavně užitečnými abstrakcemi nad často se opakujícími operacemi. Nikdo nad nimi matematické důkazy nedělá.

Takže dejte pokoj s monádami, je to v kontextu diskuze nepodstatný a neužitečný detail.



« Poslední změna: 08. 10. 2019, 14:48:55 od Martin Sivák »

Re:Naučení se asynchronnímu programování
« Odpověď #44 kdy: 08. 10. 2019, 16:02:43 »
A to je v kontextu Javy a asynchronního programování důležité proč? Je to pojem z matematické teorie kategorií, který pro běžného programátora není naprosto důležitý. Kdejaká operace splňuje definici grupy nebo monoidu, ale použivá se to tak akorát při formálních důkazech a analýzách algoritmů.
...
Citace
Vy jste se ptal "Co mají Streamy s monádami?" ;)

Běžný programátor to možná _nazývá_ jinak, ale _používá_ to naprosto běžně. Jestli je nějaká operace asociativní je důležité, pokud chci dělat třeba paralelní redukci. Jednotkový prvek mi zjednoduší api a počáteční podmínky. A ejhle, používám monoidy a to jsem k žádnému důkazu ani nečichl.

Máte nějaký problém s tím, že tyhle všudypřítomné struktury budeme nazývat stejně jako v matice?