reklama

Node.js a multiplexed IO obecně

Onestone

Node.js a multiplexed IO obecně
« kdy: 22. 04. 2017, 21:14:09 »
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.

reklama


gll

Re:Node.js a multiplexed IO obecně
« Odpověď #1 kdy: 22. 04. 2017, 21:48:41 »
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.

hu

Re:Node.js a multiplexed IO obecně
« Odpověď #2 kdy: 22. 04. 2017, 21:53:13 »
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.

gll

Re:Node.js a multiplexed IO obecně
« Odpověď #3 kdy: 22. 04. 2017, 21:56:13 »
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.

Používá nějaký thread-pool, ale určitě nevytváří nové vlákno pro každou čekající IO operaci.

hu

Re:Node.js a multiplexed IO obecně
« Odpověď #4 kdy: 22. 04. 2017, 21:58:22 »
Používá nějaký thread-pool, ale určitě nevytváří nové vlákno pro každou čekající IO operaci.

To můžu samozřejmě dělat v kompilovaných jazycích taky. A nebo nemusím, záleží na vhodnosti pro danou aplikaci.

reklama


hu

Re:Node.js a multiplexed IO obecně
« Odpověď #5 kdy: 22. 04. 2017, 22:05:50 »
Jako jediná výhoda mě napadá, že teoreticky můžu sdílet nějakou část kódu s frontendem (validace apod.), ale jestli se to tak používá, netuším.

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Node.js a multiplexed IO obecně
« Odpověď #6 kdy: 22. 04. 2017, 22:07:11 »
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.
JS nemá s neblokujícím IO nic společného a na straně serveru to je mor. Kdysi dávno se pro každý požadavek dělal na serveru fork, později se přešlo na vlákna (jež jsou na všech OS poměrně těžkotonážní) a multiplexing je výdobytkem poměrně nedávným (ano, už POSIX měl select a poll, ale teprve kqueue přišlo s efektivní implementací). Kqueue (a analogické implementace) jsou jen syscall do jádra, takže logicky to jde nejsnáze v C, C++ nebo nějakém novějším nativním jazyce (Rust, Swift, Go, take your pick of the languages on offer...) Existují ostatně i NIO implementace pro Javu. JS je v tomto případě jen nepodstatná úchylnost. Koho to zajímá do hloubky, může se podívat na zdrojáky Go, tam můžou na běžném PC koexistovat statisíce korutin, aniž by to stálo přespříliš paměti nebo času CPU. Smyčka událostí je obecný koncept, jeden while, syscall pro file deskriptory a pak zpracování příchozích dat. Žádná magie v tom není a celý slavný node.js se dá v C napsat na jednu obrazovku.

gll

Re:Node.js a multiplexed IO obecně
« Odpověď #7 kdy: 22. 04. 2017, 22:07:16 »
Používá nějaký thread-pool, ale určitě nevytváří nové vlákno pro každou čekající IO operaci.

To můžu samozřejmě dělat v kompilovaných jazycích taky. A nebo nemusím, záleží na vhodnosti pro danou aplikaci.

AFAIK, když použijete nějakou existující knihovnu, provádějící blokující IO, tak to volání musíte spustit ve vlastním vlákně.

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Node.js a multiplexed IO obecně
« Odpověď #8 kdy: 22. 04. 2017, 22:09:02 »
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.

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Node.js a multiplexed IO obecně
« Odpověď #9 kdy: 22. 04. 2017, 22:09:46 »
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.

Používá nějaký thread-pool, ale určitě nevytváří nové vlákno pro každou čekající IO operaci.
Ne, nepoužívá.

Re:Node.js a multiplexed IO obecně
« Odpověď #10 kdy: 22. 04. 2017, 22:11:51 »
Výhodou Node.JS je právě ten JavaScript – můžete psát klientskou i serverovou stranu webové aplikace v jednom jazyce (tzv. izomorfní aplikace), můžete mezi nimi sdílet kód.

gll

Re:Node.js a multiplexed IO obecně
« Odpověď #11 kdy: 22. 04. 2017, 22:16:28 »
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.

Používá nějaký thread-pool, ale určitě nevytváří nové vlákno pro každou čekající IO operaci.
Ne, nepoužívá.

Používá. I Go používá thread pool systémových vláken. Jediný rozdíl je v tom, že Go routiny jsou preemptivní. Což může někdo považovat za výhodu, ale u IO náročných aplikací je to k ničemu.

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Node.js a multiplexed IO obecně
« Odpověď #12 kdy: 22. 04. 2017, 22:17:02 »
P.S. Jakmile začne někdo v souvislosti s node.js mluvit o thread poolu, demonstruje esenciální neznalost node.js a NIO obecně. Účelem NIO je obejít vlákna a klasické implementace běží kompletně v jednom vlákně (například node.js), byť rozumný kód si vytvoří tolik vláken, kolik má procesorů (resp. logických vláken v případě HT). Kqueue (a zkriplený epoll) má výhodu právě v tom, že nevyžaduje vlákna (pomíjím opičárny à la Go, korutiny jsou něco zcela jiného než vlákna).

hu

Re:Node.js a multiplexed IO obecně
« Odpověď #13 kdy: 22. 04. 2017, 22:17:54 »
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.

zboj

  • *****
  • 1 507
    • Zobrazit profil
    • E-mail
Re:Node.js a multiplexed IO obecně
« Odpověď #14 kdy: 22. 04. 2017, 22:19:50 »
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.

Používá nějaký thread-pool, ale určitě nevytváří nové vlákno pro každou čekající IO operaci.
Ne, nepoužívá.

Používá. I Go používá thread pool systémových vláken. Jediný rozdíl je v tom, že Go routiny jsou preemptivní. Což může někdo považovat za výhodu, ale u IO náročných aplikací je to k ničemu.
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í.

 

reklama