Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: fullstack 22. 03. 2017, 15:29:23
-
Zdravím, znám rozdíl mezi synchronním a neblokujícím IO. Nedávno jsem se dostal k projektu v Go, kde je celý kód napsán synchronně, ale architekt tvrdí, že celá aplikace používá NIO (a testy výkonu tomu víceméně odpovídají). Je tu nějaký odborník, který by mi mohl vysvětlit, jak toho v Go dosáhli při použití sekvenčního kódu? Zběžně jsem prošel dokumentaci ke Go, ale na nic konkrétního jsem nenarazil.
-
asi že každá ta "sekvence" je ve vlastním vlákně (https://en.wikipedia.org/wiki/Go_(programming_language)#Concurrency)
-
asi že každá ta "sekvence" je ve vlastním vlákně (https://en.wikipedia.org/wiki/Go_(programming_language)#Concurrency)
To by nebylo NIO, ale debilní implementace se samostatným vláknem na požadavek. V Go se obecně používá multiplex (NIO), i když je k dispozici jen jedno vlákno (na jednojádrovém procesoru nepoběží nikdy víc než jedna goroutina).
-
Zdravím, znám rozdíl mezi synchronním a neblokujícím IO. Nedávno jsem se dostal k projektu v Go, kde je celý kód napsán synchronně, ale architekt tvrdí, že celá aplikace používá NIO (a testy výkonu tomu víceméně odpovídají). Je tu nějaký odborník, který by mi mohl vysvětlit, jak toho v Go dosáhli při použití sekvenčního kódu? Zběžně jsem prošel dokumentaci ke Go, ale na nic konkrétního jsem nenarazil.
Je to triviální, Go má vlastní scheduler. Na vstupu do funkce se přepíná kontext mezi goroutinami, a pokud by se nějaká zablokovala na IO, tak se prostě nespustí. Jakmile kqueue nebo epoll nebo IOCP (podle OS) dodá aktivní file descriptor, Go goroutinu spustí a výpočet vesele pokračuje. Go má své ABI, které dělá přepnutí kontextu levným (všechny registry na zásobníku), a překladač při volání funkce vkládá kód pro scheduler, takže v rámci normálního kódu funguje kooperativní přepínání velmi dobře, není problém mít milion goroutin (C1M). Použití callbacků bude sice stále efektivnější vzhledem k využití paměti (kqueue v C s bloky bude úspornější), ale v praxi - ruku na srdce - kdo řeší milion souběžných requestů (navíc 1M vyžaduje jen 4GB RAM, neboť Go automaticky smršťuje zásobník podle potřeby).
-
asi že každá ta "sekvence" je ve vlastním vlákně (https://en.wikipedia.org/wiki/Go_(programming_language)#Concurrency)
To by nebylo NIO, ale debilní implementace se samostatným vláknem na požadavek. V Go se obecně používá multiplex (NIO), i když je k dispozici jen jedno vlákno (na jednojádrovém procesoru nepoběží nikdy víc než jedna goroutina).
Nevím, jestli jsem tu odpověď dobře pochopil (první část si podle mne odporuje se závorkou), ale na jednojádrovém stroji samozřejmě může běžet mnoho (klidně tisíce) gorutin. Go multiplexuje gorutiny do dostupného množství jader (lze omezit).
Spouštění gorutin pro příchozí požadavky je skryto ve standardní knihovně, která spouští gorutinu pro každé příchozí spojení. Ukázka v knihovně http třeba zde:
https://golang.org/src/net/http/server.go (https://golang.org/src/net/http/server.go), poslední řádek funkce Serve (2668). Každá io operace pak přeplánuje gorutiny (kooperativní multitasking, podobně jako v node.js, ale pro více vláken a bez potřeby callbacků).
Takže pokud je potřeba, aby něco běželo souběžně, spustíte to jakogo func(...) {...} a kód píšete normálně synchronně. V hlavním threadu pak musíte zajistit synchronizaci výsledku.
-
Zdravím, znám rozdíl mezi synchronním a neblokujícím IO. Nedávno jsem se dostal k projektu v Go, kde je celý kód napsán synchronně, ale architekt tvrdí, že celá aplikace používá NIO (a testy výkonu tomu víceméně odpovídají). Je tu nějaký odborník, který by mi mohl vysvětlit, jak toho v Go dosáhli při použití sekvenčního kódu? Zběžně jsem prošel dokumentaci ke Go, ale na nic konkrétního jsem nenarazil.
V Go som sice nenapisal ani ciarku, ale vysvetlenie je velmi jednoduche. Aj ked sa zda, ze kod je synchronny, predpokladam, ze vsetky zdanlivo blokujuce I/O operacie sa deju v tele gorutin. Gorutiny maju vlastny stack. Ked gorutina robi zdanlivo blokujuce volanie, skutocne tazke vlakno, na ktorom je v tom case spustena/namultiplexovana skoci v tom momente do schedulovacej casti go runtime-u a ako prve zafreezuje stack (a registre) gorutiny tak, aby ju bolo mozne spustit od tohto bodu opat, t.j. ked budu pre nu ready data, ktore by bola byvala nacitala/zapisala. Uvolnene vlakno pozrie stavy otvorenych NIO deskriptorov a ak pribudli nejake data pre nejaku inu z predoslych gorutin, tieto data pripravi a dotycnu gorutinu spusti (da jej data na stack a zacne vykonavat telo gorutiny) od bodu kedy bola zafreezovana aj s datami. Vtip je v tom, ze tazke vlakno by nemohlo robit freeze/unfreeze stackov gorutin keby samo robilo blokujuce volania cez OS, lebo by ho blokol OS scheduler. Z toho vyplyvaju najmenej tieto body: takato forma schedulovania sa technicky bez NIO ani robit neda, go runtime ma vlastny workstealing scheduler, ktory v podstate simuluje spravanie akehosi lahkeho OS schedulera, ale iba pre gorutiny. Pokial go scheduler ma co robit, drzi tazke vlakna zaneprazdnene(resp. vlakna sa sami drzia zaneprazdnene a ked nenajdu inu robotu [gorutinu, ktoru treba vykonat, lebo jej dotiekly data] u seba, idu nejaku ukradnut od inych tazkych vlakien, z ktorych scheduler pozostava).
http://blog.nindalf.com/how-goroutines-work/
Ludia to nazyvaju kooperativny multitasking preto, ze gorutiny neprerusuje casovac, ale zdanlivo blokujuca I/O operacia, kedy sa gorutina dobrovolne zastavi, resp. tazke vlakno, ktore ju vyoknava zafreezuje jej stack a registre. Avsak od programatora je tato logika schovana za fasadou gorutinoveho zdanlivo blokujuceho API, takze sa zda, ze kod je synchronny-blokujuci. Z clanku hore ale vyplyva, ze aj go ma istu notaciu preemptivnosti a ze dokaze gorutinu pozastavit-zafreezovat pri najblizsiom vstupe do funkcie, keby velmi zatazovala procesor.
-
Nevím, jestli jsem tu odpověď dobře pochopil (první část si podle mne odporuje se závorkou), ale na jednojádrovém stroji samozřejmě může běžet mnoho (klidně tisíce) gorutin. Go multiplexuje gorutiny do dostupného množství jader (lze omezit).
Zboj asi myslel, že nepoběží víc goroutin souběžně. V jednu chvíli poběží vždycky jenom jedna a budou se přepínat. Záleží, jestli se na to dívám z hlediska programátora (běží jich tisíce) nebo hw (běží jenom jedna).
-
ty vole, vy ceski vypatlanci neviete pouzivat ani GO. fuj hanba
-
ty vole, vy ceski vypatlanci neviete pouzivat ani GO. fuj hanba
Ty budeš tiež nejaká maďarská sračka z čečenska keď przníš náš jazyk čechizmami ako "ty vole".
-
ty vole, vy ceski vypatlanci neviete pouzivat ani GO. fuj hanba
Ty budeš tiež nejaká maďarská sračka z čečenska keď przníš náš jazyk čechizmami ako "ty vole".
Proto dělník, který staví politický svazek s buržoazií "svého" národa nad bezpodmínečnou jednotu s proletáři všech národů, jedná proti svým zájmům, proti zájmům socialismu a zájmům demokracie.
Lenin, V.I.: Teze o národnostní otázce
-
Zboj asi myslel, že nepoběží víc goroutin souběžně. V jednu chvíli poběží vždycky jenom jedna a budou se přepínat. Záleží, jestli se na to dívám z hlediska programátora (běží jich tisíce) nebo hw (běží jenom jedna).
Mysleli ste asi paralelne. Gorutiny bezia subezne aj na jednom CPU.
Cesky preklad soubezne https://translate.google.sk/?bav=on.2,or.&bvm=bv.150475504,d.d2s&biw=1920&bih=966&um=1&ie=UTF-8&client=tw-ob#auto/cs/concurrent
when people hear the word concurrency they often think of parallelism, a related but quite distinct concept. In programming, concurrency is the composition of independently executing processes, while parallelism is the simultaneous execution of (possibly related) computations.
-
Cesky preklad soubezne https://translate.google.sk/?bav=on.2,or.&bvm=bv.150475504,d.d2s&biw=1920&bih=966&um=1&ie=UTF-8&client=tw-ob#auto/cs/concurrent
No je tam překlad "souběžný = concurrent, parallel", takže podle toho bych se asi neorientoval ;)
V češtině asi není na tohle tak ustálené názvosloví jako v angličtině. Wikipedia to taky používá:
Paralelní výpočty (anglicky parallel computing) je v informatice označení pro výpočty, které jsou řešeny souběžně („paralelně“).
"Souběh" v češtině znamená, že se něco stane zaráz, v jeden okamžik.
Asi není nutný slovíčkařit. Prostě v jednom konkrétním okamžiku může logicky na jednojádrovém procesoru běžet jenom jedna konkrétní gorutina (není to paralelní) i když je nad tím abstrakce, která programátorovi vytváří iluzi nezávislého běhu (je to konkurentní).
-
Zboj asi myslel, že nepoběží víc goroutin souběžně. V jednu chvíli poběží vždycky jenom jedna a budou se přepínat. Záleží, jestli se na to dívám z hlediska programátora (běží jich tisíce) nebo hw (běží jenom jedna).
Mysleli ste asi paralelne. Gorutiny bezia subezne aj na jednom CPU.
Cesky preklad soubezne https://translate.google.sk/?bav=on.2,or.&bvm=bv.150475504,d.d2s&biw=1920&bih=966&um=1&ie=UTF-8&client=tw-ob#auto/cs/concurrent
when people hear the word concurrency they often think of parallelism, a related but quite distinct concept. In programming, concurrency is the composition of independently executing processes, while parallelism is the simultaneous execution of (possibly related) computations.
souběžně=paralelně (celkem logicky odvoditelné v tomto případě)
-
Zboj asi myslel, že nepoběží víc goroutin souběžně. V jednu chvíli poběží vždycky jenom jedna a budou se přepínat. Záleží, jestli se na to dívám z hlediska programátora (běží jich tisíce) nebo hw (běží jenom jedna).
Mysleli ste asi paralelne. Gorutiny bezia subezne aj na jednom CPU.
Cesky preklad soubezne https://translate.google.sk/?bav=on.2,or.&bvm=bv.150475504,d.d2s&biw=1920&bih=966&um=1&ie=UTF-8&client=tw-ob#auto/cs/concurrent
when people hear the word concurrency they often think of parallelism, a related but quite distinct concept. In programming, concurrency is the composition of independently executing processes, while parallelism is the simultaneous execution of (possibly related) computations.
souběžně=paralelně (celkem logicky odvoditelné v tomto případě)
Inymi slovami: zvyrazneny text nic nevysvetlil, kedze cesky vyraz soubezne nedokaze vyjadrit rozdiel vyznamu medzi concurrent a parallel a bez logickeho odvodenia na zaklade nasledujucej vety, je vyznam vety so zvyraznenym slovom soubezne nejednoznacny a matuci. Naco bol vyraz zvyrazneny v prvom rade?
Asi není nutný slovíčkařit.
A prave s tymto nesuhlasim, pretoze Rob Pike sa vo svojom prihovore o Go venuje tejto teme dost zasadne a vysvetli rozdiel medzi concurrent a parallel bezozvysku. Ak to robi on pri vysvetlovani ako Go funguje, zrejme to povazuje za zasadnu informaciu k pochopeniu ako Go funguje.
Pre vas je to mozno slovickarenie a inemu to pomoze pri pochopeni.
-
A prave s tymto nesuhlasim, pretoze Rob Pike sa vo svojom prihovore o Go venuje tejto teme dost zasadne a vysvetli rozdiel medzi concurrent a parallel bezozvysku. Ak to robi on pri vysvetlovani ako Go funguje, zrejme to povazuje za zasadnu informaciu k pochopeniu ako Go funguje.
Pre vas je to mozno slovickarenie a inemu to pomoze pri pochopeni.
Slovíčkaření to je, pokud se hádá o terminologii, která prostě v češtině (AFAIK) není úplně striktně ustálená a proto je potřeba ji doplnit vysvětlením. Anebo použít anglicizmy "konkurentní" a "paralelní".
Není potřeba z toho dělat vědu, ani to není potřeba nijak zvlášť vysvětlovat - stačí jeden obrázek http://stackoverflow.com/a/1898024.
-
Taky bych z toho nedělal vědu, s českým názvoslovím je už historicky mnoho problémů, reálně se ustálilo jen pár nejběžnějších pojmů, v mnoha případech různí autoři používají stejná slova pro různé významy a proto dávám přednost anglickému názvosloví.
Ten obrázek je moc pěkný, taková blbůstka, ale perfektně ilustruje podstatu.
-
Prostě v jednom konkrétním okamžiku může logicky na jednojádrovém procesoru běžet jenom jedna konkrétní gorutina (není to paralelní) i když je nad tím abstrakce, která programátorovi vytváří iluzi nezávislého běhu (je to konkurentní).
Čistě teoreticky by i na jednojádrovém procesoru mohly běžet dvě gorutiny najednou. Jedna by něco počítala pomocí CPU, druhá by tahala data pomocí DMA :-)
-
Čistě teoreticky by i na jednojádrovém procesoru mohly běžet dvě gorutiny najednou. Jedna by něco počítala pomocí CPU, druhá by tahala data pomocí DMA :-)
V tom případě je ovšem ta druhá pozastavená a čeká na interrupt ;)