Přepsání serveru v Javě

[gll]

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

,,Procesy" v Erlangu jsou velmi lehké, nejsou to skutečné procesy OS – nemyslím, že by byly paměťově nějak náročné.

Nemyslel jsem režii, ale paměť spotřebovanou pro řešení samotné úlohy.

[Reklama]

[zboj]

ale stejně bych čekal, že GC si s tím poradí lépe

Jste si jistý, že to souvisí s GC? Nebylo by pak řešením použít jiný GC?

Pokud v nějakém jazyce musím explicitně vybírat GC, aby mi program fungoval, tak je něco hodně špatně.

[zboj]

[...] 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.

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.

[Mirek Prýmek]

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).

[Filip Jirsák]

Pokud v nějakém jazyce musím explicitně vybírat GC, aby mi program fungoval, tak je něco hodně špatně.

Nevím o jazyku, u kterého byste explicitně vybíral GC. Já jsem psal o JVM, což je běhové prostředí. Také vůbec nebyla řeč o tom, že by program nefungoval. Jenom bylo zmíněno podezření (v diskusi ničím nepodložené), že by GC mohl ovlivňovat výkon aplikace – pak je logické prozkoumat charakteristiku použitého GC a porovnat ji s charakteristikami jiných dostupných GC a případně GC změnit. Na tom, že je v jednom běhovém prostředí dostupných více implementací GC, není nic špatného – každý se chová trochu jinak a hodí se tak pro jiný typ úloh. Například Linux má několik implementací plánovačů procesů, několik implementací plánovačů IO, několik implementací souborových systémů – obecně je to považováno za plus, protože si každý může vybrat, co zrovna on potřebuje, a není odkázán na jedno one size fits all řešení, které bude ve všech případech stejně špatné.

[Reklama]

[gll]

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

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

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

[Filip Jirsák]

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

Pořád nevidím ten rozdíl. Když na to máte funkcionalitu přímo v runtime Erlangu, tak nevadí, že v tom runtime máte také spoustu funkcionalit, které nepoužijete. Ale když tu funkcionalitu máte v knihovně, tak to najednou vadí, že je v té knihovně i něco, co vůbec nepoužijete.

Vadí to v případě, že ten balast se například musí natahovat při startu

To pak nevadí ten balast, ale to, že se natahuje při startu.

že v něm bývají chyby

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

že je to děsivý moloch, který nikdo neví, jak funguje atd. atd.

Pokud je to děsivý moloch, tak to nepoužívejte. A pokud použijete nějakou část, zbytek vás nemusí zajímat. Úplně stejně, jako když to máte implementované v runtime Erlangu.

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.

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.

[zboj]

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).

Já měl taky na mysli případ, kdy je hodně procesů

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.

[zboj]

Pokud v nějakém jazyce musím explicitně vybírat GC, aby mi program fungoval, tak je něco hodně špatně.

Nevím o jazyku, u kterého byste explicitně vybíral GC. Já jsem psal o JVM, což je běhové prostředí. Také vůbec nebyla řeč o tom, že by program nefungoval. Jenom bylo zmíněno podezření (v diskusi ničím nepodložené), že by GC mohl ovlivňovat výkon aplikace – pak je logické prozkoumat charakteristiku použitého GC a porovnat ji s charakteristikami jiných dostupných GC a případně GC změnit. Na tom, že je v jednom běhovém prostředí dostupných více implementací GC, není nic špatného – každý se chová trochu jinak a hodí se tak pro jiný typ úloh. Například Linux má několik implementací plánovačů procesů, několik implementací plánovačů IO, několik implementací souborových systémů – obecně je to považováno za plus, protože si každý může vybrat, co zrovna on potřebuje, a není odkázán na jedno one size fits all řešení, které bude ve všech případech stejně špatné.

Javu jinde než nad JVM nespustím, že? Problém Javy je, že neumožňuje nějakou aspoň pseudotransparentní alokaci dat na zásobníku. Kdyby tomu tak bylo, nemusel by nikdo vyvíjet kvanta různých GC a ladit je pro každou aplikaci zvlášť.

[Mirek Prýmek]

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á?!

[gll]

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

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

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

[Mirek Prýmek]

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.

[Mirek Prýmek]

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

[zboj]

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.

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

[Filip Jirsák]

Javu jinde než nad JVM nespustím, že?

Existovaly nějaké překladače Javy, nevím, v jakém jsou stavu.

Problém Javy je, že neumožňuje nějakou aspoň pseudotransparentní alokaci dat na zásobníku.

Ne, to problém Javy není.

Kdyby tomu tak bylo, nemusel by nikdo vyvíjet kvanta různých GC a ladit je pro každou aplikaci zvlášť.

Kvanta různých GC nikdo nevyvíjí, nikdo je neladí pro každou aplikaci zvlášť, a GC nepoužívá ani zdaleka jenom Java. Vlastně bude jednodušší vyjmenovat jazyky, které běžně GC nepoužívají (ale kam se občas GC dodává jako knihovna) – C, C++, Pascal.