Node.js a multiplexed IO obecně

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Node.js a multiplexed IO obecně
« Odpověď #15 kdy: 22. 04. 2017, 22:21:33 »
Má nějakou zvláštní výhodu node.js? Chápu princip epoll (a podobných technologií na jiných OS), ale není mi jasné, proč do toho pletou JS. Proč nepoužít C, C++ nebo třeba Rust či jiný podobný nativně kompilovaný jazyk? Ono i v Javě už jsou lambda výrazy a Java má oproti JS řadu výhod.

Javascript a Node.js jsou od začátku postavené nad jedním defaultním event-loopem. Všechny knihovny provádějící IO to dělají neblokujícím způsobem za použití toho jednoho event-loopu. Ve vámi uváděných jazycím můžete používat jen knihovny kompatibilní s daným event loopem nebo si vypomáhat použitím vláken.

Dnes Javascript obsahuje i jazykové konstrukce usnadňující tento typ konkurentního programování. Vámi uváděné jazyky nemají obdobu async await.

Nepomáhá si ten JS runtime náhodou v případě async IO operací taky vláknama na úrovni OS? Vždyť podpora async IO na Linuxu je poměrně pochybná. Takže mi to přijde jen jako přesun pacienta na plicní, navíc s penalizací vyplývající z používání mimořádně úchylného jazyka.
NIO nemá s vlákny nic společného a upřímně, OS vlákna by byla kontraproduktivní overkill.

Jenže diskové IO na Linuxu nikdy non-blocking není, takže pokud mě trápí neresponzivita během zápisu fakt velkého souboru, musím si to do smyčky naplánovat po nějakých malých blocích, nebo pustit vlákno. U socketů to samozřejmě neplatí a tam je totální nesmysl to řešit jinak než epollem.
100% souhlas ohledně souborů, bavím se výhradně o síťové komunikaci.
« Poslední změna: 22. 04. 2017, 22:24:08 od zboj »


hu

Re:Node.js a multiplexed IO obecně
« Odpověď #16 kdy: 22. 04. 2017, 22:26:51 »
Jenže diskové IO na Linuxu nikdy non-blocking není, takže pokud mě trápí neresponzivita během zápisu fakt velkého souboru, musím si to do smyčky naplánovat po nějakých malých blocích, nebo pustit vlákno. U socketů to samozřejmě neplatí a tam je totální nesmysl to řešit jinak než epollem.
100% souhlas se soubory, bavím se výhradně o síťové komunikaci.

OK, tam je to fakt v C na jednu obrazovku, jak říkáš. A pokud už člověk používá nějaký C nebo C++ framework, ještě jsem nenarazil na to, že by neměl podporu pro poll, epoll, select nad deskriptorem. Ostatně třeba V4L2 se používá taky s (e)pollem a bylo naprosto bez problémů ho připojit jednou proxy třídou do Qt aplikace.

Já jenom nevím, proč se zbytečně izolovat od low level implementace už na úrovni jazyka, když to můžu udělat stejně dobře knihovnou a v případě nouze se můžu povrtat i níž.

Mimochodem, za coroutines v C bych vraždil. Kolikrát člověk nepotřebuje paralelismus, jen víc kontextů, zejména na bare-metal hw.

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Node.js a multiplexed IO obecně
« Odpověď #17 kdy: 22. 04. 2017, 22:33:13 »
Jenže diskové IO na Linuxu nikdy non-blocking není, takže pokud mě trápí neresponzivita během zápisu fakt velkého souboru, musím si to do smyčky naplánovat po nějakých malých blocích, nebo pustit vlákno. U socketů to samozřejmě neplatí a tam je totální nesmysl to řešit jinak než epollem.
100% souhlas se soubory, bavím se výhradně o síťové komunikaci.

OK, tam je to fakt v C na jednu obrazovku, jak říkáš. A pokud už člověk používá nějaký C nebo C++ framework, ještě jsem nenarazil na to, že by neměl podporu pro poll, epoll, select nad deskriptorem. Ostatně třeba V4L2 se používá taky s (e)pollem a bylo naprosto bez problémů ho připojit jednou proxy třídou do Qt aplikace.

Já jenom nevím, proč se zbytečně izolovat od low level implementace už na úrovni jazyka, když to můžu udělat stejně dobře knihovnou a v případě nouze se můžu povrtat i níž.

Mimochodem, za coroutines v C bych vraždil. Kolikrát člověk nepotřebuje paralelismus, jen víc kontextů, zejména na bare-metal hw.
V C se mi osvědčily bloky ve spojení s kqueue nebo epoll. Jinak předpokládám, že v normálním případě člověk použije něco jako libevent nebo libev nebo libuv.

gll

Re:Node.js a multiplexed IO obecně
« Odpověď #18 kdy: 22. 04. 2017, 22:41:31 »
1. Go má thread pool, node.js ne (v původní koncepci).
2. Goroutiny nejsou preemptivní, naopak jsou kooperativní. Nevyjadřuj se k něčemu, o čem nic nevíš, případně si zjisti, co znamená preemptivní.

1. - o tom opravdu nic nevím.

2. - Ok ne úplně preemptivní. Provádění goroutiny může být přerušeno při volání libovolné funkce. V JS coroutinách se musí zavolat explicitní await.

goroutina != coroutina

http://stackoverflow.com/questions/18058164/is-a-go-goroutine-a-coroutine

čumil

Re:Node.js a multiplexed IO obecně
« Odpověď #19 kdy: 22. 04. 2017, 22:43:40 »
Má nějakou zvláštní výhodu node.js? Chápu princip epoll (a podobných technologií na jiných OS), ale není mi jasné, proč do toho pletou JS. Proč nepoužít C, C++ nebo třeba Rust či jiný podobný nativně kompilovaný jazyk? Ono i v Javě už jsou lambda výrazy a Java má oproti JS řadu výhod.

Javascript a Node.js jsou od začátku postavené nad jedním defaultním event-loopem. Všechny knihovny provádějící IO to dělají neblokujícím způsobem za použití toho jednoho event-loopu. Ve vámi uváděných jazycím můžete používat jen knihovny kompatibilní s daným event loopem nebo si vypomáhat použitím vláken.

Dnes Javascript obsahuje i jazykové konstrukce usnadňující tento typ konkurentního programování. Vámi uváděné jazyky nemají obdobu async await.

Nepomáhá si ten JS runtime náhodou v případě async IO operací taky vláknama na úrovni OS? Vždyť podpora async IO na Linuxu je poměrně pochybná. Takže mi to přijde jen jako přesun pacienta na plicní, navíc s penalizací vyplývající z používání mimořádně úchylného jazyka.
A proč je uchylný :) ?

JS je unikat.
Neříkám že je nejlepší, ale plno věcí je tam na úplne jinem levelu nez maji ostatni jazyky.
Namatkou first class async support.
Reactivity ve skoro kazdem novem frameworku.
Prototype oop ...

Na js obvykle hazi spinu lidi ktery to delaj jen proto ze spinit js je free a kuul a vubec strasne in.


Šebestová

Re:Node.js a multiplexed IO obecně
« Odpověď #20 kdy: 22. 04. 2017, 22:43:58 »
1. Go má thread pool, node.js ne (v původní koncepci).
2. Goroutiny nejsou preemptivní, naopak jsou kooperativní. Nevyjadřuj se k něčemu, o čem nic nevíš, případně si zjisti, co znamená preemptivní.

1. - o tom opravdu nic nevím.

2. - Ok ne úplně preemptivní. Provádění goroutiny může být přerušeno při volání libovolné funkce. V JS coroutinách se musí zavolat explicitní await.

goroutina != coroutina

http://stackoverflow.com/questions/18058164/is-a-go-goroutine-a-coroutine
Používáš preemptivní ve významu kooperativní, což je pravý opak.

gll

Re:Node.js a multiplexed IO obecně
« Odpověď #21 kdy: 22. 04. 2017, 22:50:53 »
1. Go má thread pool, node.js ne (v původní koncepci).
2. Goroutiny nejsou preemptivní, naopak jsou kooperativní. Nevyjadřuj se k něčemu, o čem nic nevíš, případně si zjisti, co znamená preemptivní.

1. - o tom opravdu nic nevím.

2. - Ok ne úplně preemptivní. Provádění goroutiny může být přerušeno při volání libovolné funkce. V JS coroutinách se musí zavolat explicitní await.

goroutina != coroutina

http://stackoverflow.com/questions/18058164/is-a-go-goroutine-a-coroutine
Používáš preemptivní ve významu kooperativní, což je pravý opak.

preemptivní používám ve významu nekooperativní. V Go přepíná kontext runtime bez toho, abyste mu to explicitně museli říct. Kooperativní jsou právě coroutiny v js, pythonu nebo c#. Zboj používá to slovo špatně.

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Node.js a multiplexed IO obecně
« Odpověď #22 kdy: 22. 04. 2017, 22:57:55 »
1. Go má thread pool, node.js ne (v původní koncepci).
2. Goroutiny nejsou preemptivní, naopak jsou kooperativní. Nevyjadřuj se k něčemu, o čem nic nevíš, případně si zjisti, co znamená preemptivní.

1. - o tom opravdu nic nevím.

2. - Ok ne úplně preemptivní. Provádění goroutiny může být přerušeno při volání libovolné funkce. V JS coroutinách se musí zavolat explicitní await.

goroutina != coroutina

http://stackoverflow.com/questions/18058164/is-a-go-goroutine-a-coroutine
Používáš preemptivní ve významu kooperativní, což je pravý opak.

preemptivní používám ve významu nekooperativní. V Go přepíná kontext runtime bez toho, abyste mu to explicitně museli říct. Kooperativní jsou právě coroutiny v js, pythonu nebo c#. Zboj používá to slovo špatně.
Tak si počti: http://blog.nindalf.com/how-goroutines-work/
Buď neznáš Go, nebo význam slova kooperativní. Sorry jako, ale preferuji diskusi s někým, kdo má aspoň základní znalosti. V Go jde scheduler vyšachovat, což znamená kooperativnost. (Doufám, že Babiš nemá na "sorry jako" copyright...).

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Node.js a multiplexed IO obecně
« Odpověď #23 kdy: 22. 04. 2017, 23:03:23 »
1. Go má thread pool, node.js ne (v původní koncepci).
2. Goroutiny nejsou preemptivní, naopak jsou kooperativní. Nevyjadřuj se k něčemu, o čem nic nevíš, případně si zjisti, co znamená preemptivní.

1. - o tom opravdu nic nevím.

2. - Ok ne úplně preemptivní. Provádění goroutiny může být přerušeno při volání libovolné funkce. V JS coroutinách se musí zavolat explicitní await.

goroutina != coroutina

http://stackoverflow.com/questions/18058164/is-a-go-goroutine-a-coroutine
Používáš preemptivní ve významu kooperativní, což je pravý opak.

preemptivní používám ve významu nekooperativní. V Go přepíná kontext runtime bez toho, abyste mu to explicitně museli říct. Kooperativní jsou právě coroutiny v js, pythonu nebo c#. Zboj používá to slovo špatně.
Viz ještě https://news.ycombinator.com/item?id=4704898, a pokud teď neuznáš svůj přešlap, tak jsi do skonání světa lopata.

gll

Re:Node.js a multiplexed IO obecně
« Odpověď #24 kdy: 23. 04. 2017, 00:14:00 »
Kód: [Vybrat]
package main

import "fmt"
import "runtime"
import "sync"

var wg sync.WaitGroup

func cpuIntensive(p int) {
cycles := 100000000
for i := 1; i <= cycles; i++ {
if i == cycles/2 {
fmt.Printf("%d running\n", p)
}
}
fmt.Printf("%d done\n", p)
wg.Done()
}

func main() {
runtime.GOMAXPROCS(1)
wg.Add(4)
go cpuIntensive(1)
go cpuIntensive(2)
go cpuIntensive(3)
go cpuIntensive(4)
wg.Wait()
}

žádná explicitní kooperativnost tam není.

vypíše:

Kód: [Vybrat]
4 running
1 running
2 running
3 running
4 done
1 done
2 done
3 done

kdyby Go bylo nepreemptivní, tak bych dostal:

Kód: [Vybrat]
1 running
1 done
2 running
2 done
3 running
3 done
4 running
4 done

andy

Re:Node.js a multiplexed IO obecně
« Odpověď #25 kdy: 23. 04. 2017, 00:51:41 »
Kód: [Vybrat]
package main

...
No..preemptivní typicky znamená, že to scheduler přeruší bez ohledu na to, co to dělá. Když vyhodíš ten printf z prostředka, tak to vypíše co? Kooperativní znamená, že to scheduler může přerušit na přesně definovaných místech. Dřív to bývalo explicitní volání yield(), v dnešních jazycích to bývá třeba při volání funkcí, při alokaci paměti apod.. Na týhle úrovni je to (až na nějaké extrémní případy) v praxi v podstatě jedno. Ale jestli to CPU intenzivní smyčku bez volání funkcí není schopno přerušit, tak to preemptivní není.

Citace
Dnes Javascript obsahuje i jazykové konstrukce usnadňující tento typ konkurentního programování. Vámi uváděné jazyky nemají obdobu async await.
A k čemu by mi to mělo být dobré? Celý async await je jenom kvůli tomu, že ten blbý JS není schopen dělat non-blocking IO jinak než přes callbacky... navíc to ani neni pořádně composable.

gll

Re:Node.js a multiplexed IO obecně
« Odpověď #26 kdy: 23. 04. 2017, 01:35:43 »
Citace
Dnes Javascript obsahuje i jazykové konstrukce usnadňující tento typ konkurentního programování. Vámi uváděné jazyky nemají obdobu async await.
A k čemu by mi to mělo být dobré? Celý async await je jenom kvůli tomu, že ten blbý JS není schopen dělat non-blocking IO jinak než přes callbacky... navíc to ani neni pořádně composable.

await je právě náhrada callbacků. Jak funguje non-blocking IO v Javě nebo C++ v jednom vlákně bez callbacků? Co umí Java navíc oproti C#, že nepotřebuje await nebo yield?

gll

Re:Node.js a multiplexed IO obecně
« Odpověď #27 kdy: 23. 04. 2017, 01:43:06 »
Kód: [Vybrat]
package main

...
No..preemptivní typicky znamená, že to scheduler přeruší bez ohledu na to, co to dělá. Když vyhodíš ten printf z prostředka, tak to vypíše co? Kooperativní znamená, že to scheduler může přerušit na přesně definovaných místech. Dřív to bývalo explicitní volání yield(), v dnešních jazycích to bývá třeba při volání funkcí, při alokaci paměti apod.. Na týhle úrovni je to (až na nějaké extrémní případy) v praxi v podstatě jedno. Ale jestli to CPU intenzivní smyčku bez volání funkcí není schopno přerušit, tak to preemptivní není.

Výše jsem psal, že se goroutiny přerušují při volání funkcí. Nejen IO funkcí. Přiznávám, použil jsem špatné názvosloví.

gll

Re:Node.js a multiplexed IO obecně
« Odpověď #28 kdy: 23. 04. 2017, 01:56:26 »
Citace
Dnes Javascript obsahuje i jazykové konstrukce usnadňující tento typ konkurentního programování. Vámi uváděné jazyky nemají obdobu async await.
A k čemu by mi to mělo být dobré? Celý async await je jenom kvůli tomu, že ten blbý JS není schopen dělat non-blocking IO jinak než přes callbacky... navíc to ani neni pořádně composable.

await je právě náhrada callbacků. Jak funguje non-blocking IO v Javě nebo C++ v jednom vlákně bez callbacků? Co umí Java navíc oproti C#, že nepotřebuje await nebo yield?

Ok v C++ jdou implementovat coroutiny

http://www.boost.org/doc/libs/1_62_0/libs/coroutine/doc/html/index.html

přiznávám, jsem lopata

andy

Re:Node.js a multiplexed IO obecně
« Odpověď #29 kdy: 23. 04. 2017, 02:58:59 »
await je právě náhrada callbacků. Jak funguje non-blocking IO v Javě nebo C++ v jednom vlákně bez callbacků? Co umí Java navíc oproti C#, že nepotřebuje await nebo yield?
Blbě a nic. Nějaký důvod, proč to JS nemá pořešené stejně jako třeba Go?