Přepsání serveru v Javě

[Mirek Prýmek]

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

Tyjo, to's mě dost překvapil, že ho neznáš ani z rychlíku. Určitě na něj koukni, je to extrémně zajímavá věc, minimálně pro studijní účely.

Víc než plain Erlang bych teda doporučil Elixir - je modernější, má zepár modernějších featur (třeba homoikonická, volitelně hygienická makra) a opravuje drobné chybky Erlangu (např. fakt úplně všechno je výraz, to v Erlangu neplatí). Zároveň je s Erlangem plně kompatibilní (asi tak jako Scala s Javou).

[Reklama]

[gll]

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.

O vyhlazení špiček právě jde. Fronta nebo pool to vyřeší perfektně.

To rozhodně. A právě proto mezi sebou erlangovské procesy komunikují zprávami, které se ukládají do - tramtadadáááá - fronty

bavíme se o na sobě nezávislých úlohách.

[zboj]

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.

Většina objektů žije jen krátce a neescapují, takže nemá smysl dávat je na haldu a pak likvidovat GC. Doporučuji přečíst si něco o správě paměti (a pak třeba pochopíte, proč se v Javě plánuje umožnit alokaci na zásobníku - i když v Javě 9 už ne - a proč to je velký problém Javy, resp. tedy JVM).

[zboj]

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

Tyjo, to's mě dost překvapil, že ho neznáš ani z rychlíku. Určitě na něj koukni, je to extrémně zajímavá věc, minimálně pro studijní účely.

Víc než plain Erlang bych teda doporučil Elixir - je modernější, má zepár modernějších featur (třeba homoikonická, volitelně hygienická makra) a opravuje drobné chybky Erlangu (např. fakt úplně všechno je výraz, to v Erlangu neplatí). Zároveň je s Erlangem plně kompatibilní (asi tak jako Scala s Javou).

Jo, kouknu, aspoň zběžně, i když ve frontě mám asi milion dalších věcí, třeba Rust nebo Elm - a času je málo...

[Filip Jirsák]

Většina objektů žije jen krátce a neescapují, takže nemá smysl dávat je na haldu a pak likvidovat GC.

Což je ale něco úplně jiného, než co jste psal předtím. Jinak ty různé GC v JVM se liší mimo jiné tím, jak zacházejí s objekty, které mají krátkou životnost. Třeba se jednou dočkáte i v JVM GC, který umožní používat i zásobník.

problém Javy, resp. tedy JVM

Možná byste si měl ujasnit rozdíl mezi programovacím jazykem a virtuálním strojem – místo poučování, co by si kdo měl přečíst. Aspoň že jste to dal na dvouapůltý pokus.

[Reklama]

[Mirek Prýmek]

O vyhlazení špiček právě jde.

Řekl kdo? Třeba o ně vůbec nejde.

bavíme se o na sobě nezávislých úlohách.

A?

Jo, kouknu, aspoň zběžně, i když ve frontě mám asi milion dalších věcí, třeba Rust nebo Elm - a času je málo...

Rust ti schvaluju, ze seriálu Pavla Tišnovského mě taky zaujal Ale Elixir si dej před Elm. Elm je jenom takový "zjednodušený Haskell pro web" - oproti Haskellu tam nic moc novýho nevykoukáš, Elixir, resp OTP je daleko zajímavější

[zboj]

Většina objektů žije jen krátce a neescapují, takže nemá smysl dávat je na haldu a pak likvidovat GC.

Což je ale něco úplně jiného, než co jste psal předtím. Jinak ty různé GC v JVM se liší mimo jiné tím, jak zacházejí s objekty, které mají krátkou životnost. Třeba se jednou dočkáte i v JVM GC, který umožní používat i zásobník.

"Hezky" jste přešel, proč si Oracle myslí, že nemožnost explicitně používat zásobník je zásadní problém, pročež plánuje tuto možnost přidat. Až vyjde Java 10, určitě se od všech těch mediocre programmers, jimž je Java určena, dozvíme, jak skvěle se ten jejich jazyk vyvíjí a proč je alokace na zásobníku super. Sekta...

[zboj]

O vyhlazení špiček právě jde.

Řekl kdo? Třeba o ně vůbec nejde.

bavíme se o na sobě nezávislých úlohách.

A?

Jo, kouknu, aspoň zběžně, i když ve frontě mám asi milion dalších věcí, třeba Rust nebo Elm - a času je málo...

Rust ti schvaluju, ze seriálu Pavla Tišnovského mě taky zaujal Ale Elixir si dej před Elm. Elm je jenom takový "zjednodušený Haskell pro web" - oproti Haskellu tam nic moc novýho nevykoukáš, Elixir, resp OTP je daleko zajímavější

Haskell jde nějak zjednodušit?     

[Mirek Prýmek]

Haskell jde nějak zjednodušit?     

Jo. Elm nemá typeclasses. Takže nemá ani obecné monády. Pro každý typ je potřeba monádu napsat zvlášť - např. http://package.elm-lang.org/packages/elm-lang/core/5.1.1/Json-Decode#andThen

[zboj]

Haskell jde nějak zjednodušit?     

Jo. Elm nemá typeclasses. Takže nemá ani obecné monády. Pro každý typ je potřeba monádu napsat zvlášť - např. http://package.elm-lang.org/packages/elm-lang/core/5.1.1/Json-Decode#andThen

Kromě Haskellu neznám typovaný jazyk s obecnými monádami (ani ve Swiftu to nejde), takže to asi přežiju. No nic, jdu na pláž, přeju hodně sil v boji s duševním polotovarem

[.]

Zkusme si shrnou pár základních faktů:
- server běží nad ARM64
- je to velmi jednoduchý server, v podstatě asi dotaz do databáze nebo IPC a serializace/deserializace JSON
- existuje proof of concept v C (ještě nikdy jsem neviděl PoC v low-level jazyce, což opět indikuje relativně jednoduché řešení)
- autor má velkou vůli to přepsat a naučit se něco nového

Nevíme:
- zda DB běží na stejném zařízení

Za dobu, co tady diskutujete bych to s největší pravděpodobností už měl přepsané.

Takže mých 0.005c:
1. Určitě není špatná rada zjistit, kde to drhne. Pokud s tím nemáš zkušenosti, je to výzva naučit se něco nového
2. Určitě není vyloženě špatný nápad to přepsat do něčeho jiného (zvláště pokud je to ARM64). Někteří masochisté sice propagují Javu i na RPi, ale nejlepší nápad to většinou není
3. Z toho co víme (C, Java) si myslím, že nejméně problematické bude Go.
 a) je to velmi jednoduchý jazyk s téměř identickou syntaxí, se znalostí C a Javy lze po přečtení tutoriálu (cca 2h) najít nějaký příklad a začít psát
 b) je určen přesně pro toto použití
 c) má extrémně malé paměťové nároky a je překládán přímo do strojového kódu
 d) má neuvěřitelně jednoduchou křížovou kompilaci, takže lze vyvíjet na vlastním stroji a spouštět a testovat na ARM
 e) jeho GC je optimalizován na latenci, takže žádné stop the world na 2s nehrozí

Osobně to odhaduji, že ačkoliv začátečník, přes víkend to budeš mít hotové. Pokud jsem to odhadl dobře, bude to mít celé do 500 řádků.

Pokud bys potřeboval poradit, dej tady vědět.

Pro ostatní:
Netvrdím, že Go je jediné nebo nejlepší řešení. Jen říkám, že z výše uvedených důvodů je to určitě velmi dobré řešení. A s největší pravděpodobností problémy zmizí "samy" i bez toho profilování. Celkové paměťové nároky budou odhadem 10-20x menší.

[zboj]

Zkusme si shrnou pár základních faktů:
- server běží nad ARM64
- je to velmi jednoduchý server, v podstatě asi dotaz do databáze nebo IPC a serializace/deserializace JSON
- existuje proof of concept v C (ještě nikdy jsem neviděl PoC v low-level jazyce, což opět indikuje relativně jednoduché řešení)
- autor má velkou vůli to přepsat a naučit se něco nového

Nevíme:
- zda DB běží na stejném zařízení

Za dobu, co tady diskutujete bych to s největší pravděpodobností už měl přepsané.

Takže mých 0.005c:
1. Určitě není špatná rada zjistit, kde to drhne. Pokud s tím nemáš zkušenosti, je to výzva naučit se něco nového
2. Určitě není vyloženě špatný nápad to přepsat do něčeho jiného (zvláště pokud je to ARM64). Někteří masochisté sice propagují Javu i na RPi, ale nejlepší nápad to většinou není
3. Z toho co víme (C, Java) si myslím, že nejméně problematické bude Go.
 a) je to velmi jednoduchý jazyk s téměř identickou syntaxí, se znalostí C a Javy lze po přečtení tutoriálu (cca 2h) najít nějaký příklad a začít psát
 b) je určen přesně pro toto použití
 c) má extrémně malé paměťové nároky a je překládán přímo do strojového kódu
 d) má neuvěřitelně jednoduchou křížovou kompilaci, takže lze vyvíjet na vlastním stroji a spouštět a testovat na ARM
 e) jeho GC je optimalizován na latenci, takže žádné stop the world na 2s nehrozí

Osobně to odhaduji, že ačkoliv začátečník, přes víkend to budeš mít hotové. Pokud jsem to odhadl dobře, bude to mít celé do 500 řádků.

Pokud bys potřeboval poradit, dej tady vědět.

Pro ostatní:
Netvrdím, že Go je jediné nebo nejlepší řešení. Jen říkám, že z výše uvedených důvodů je to určitě velmi dobré řešení. A s největší pravděpodobností problémy zmizí "samy" i bez toho profilování. Celkové paměťové nároky budou odhadem 10-20x menší.

ad 2) Na ARM32 je Java nepoužitelná tragédie, na ARM64 to je asi o něco lepší, ale stejně bych se tomu obloukem vyhnul.
ad 3) Rozhodně to bude snazší než to psát v C nad kqueue a GCD. Pokud je problém GC, tak se fakt vyřeší sám.

[Mirek Prýmek]

No nic, jdu na pláž, přeju hodně sil v boji s duševním polotovarem

Abysme si rozuměli, mně se Elm moc líbí a používám ho rád. Protože nejsem haskellista, tak mi absence typeclasses zas tak moc nevadí, prostě se občas duplikuje kód, ale zas je aspoň jednodušší a není "přeabstrahováno", což mně u Haskellu občas trochu vadí (pokud to člověk nemá všechno v hlavě, musí sestoupit postupně několik vrstev abstrakce, aby zjistil, co ten kód vlastně dělá).

Akorát Elm není pro člověka, který aspoň trochu zná Haskell, moc zajímavý z hlediska studia. Zajímavý je jenom podívat se, co zjedodušili a jaké to má pro webový vývoj důsledky. Jinak tam myslím není nic moc, co by nebylo v Haskellu.

[balki]

Zkusme si shrnou pár základních faktů:
- server běží nad ARM64
- je to velmi jednoduchý server, v podstatě asi dotaz do databáze nebo IPC a serializace/deserializace JSON
- existuje proof of concept v C (ještě nikdy jsem neviděl PoC v low-level jazyce, což opět indikuje relativně jednoduché řešení)
- autor má velkou vůli to přepsat a naučit se něco nového

Nevíme:
- zda DB běží na stejném zařízení

Za dobu, co tady diskutujete bych to s největší pravděpodobností už měl přepsané.

Takže mých 0.005c:
1. Určitě není špatná rada zjistit, kde to drhne. Pokud s tím nemáš zkušenosti, je to výzva naučit se něco nového
2. Určitě není vyloženě špatný nápad to přepsat do něčeho jiného (zvláště pokud je to ARM64). Někteří masochisté sice propagují Javu i na RPi, ale nejlepší nápad to většinou není
3. Z toho co víme (C, Java) si myslím, že nejméně problematické bude Go.
 a) je to velmi jednoduchý jazyk s téměř identickou syntaxí, se znalostí C a Javy lze po přečtení tutoriálu (cca 2h) najít nějaký příklad a začít psát
 b) je určen přesně pro toto použití
 c) má extrémně malé paměťové nároky a je překládán přímo do strojového kódu
 d) má neuvěřitelně jednoduchou křížovou kompilaci, takže lze vyvíjet na vlastním stroji a spouštět a testovat na ARM
 e) jeho GC je optimalizován na latenci, takže žádné stop the world na 2s nehrozí

Osobně to odhaduji, že ačkoliv začátečník, přes víkend to budeš mít hotové. Pokud jsem to odhadl dobře, bude to mít celé do 500 řádků.

Pokud bys potřeboval poradit, dej tady vědět.

Pro ostatní:
Netvrdím, že Go je jediné nebo nejlepší řešení. Jen říkám, že z výše uvedených důvodů je to určitě velmi dobré řešení. A s největší pravděpodobností problémy zmizí "samy" i bez toho profilování. Celkové paměťové nároky budou odhadem 10-20x menší.

ad 2) Na ARM32 je Java nepoužitelná tragédie, na ARM64 to je asi o něco lepší, ale stejně bych se tomu obloukem vyhnul.
ad 3) Rozhodně to bude snazší než to psát v C nad kqueue a GCD. Pokud je problém GC, tak se fakt vyřeší sám.

Hlavne by som najprv vyskusal vyhodit openjdk a dat tam javu od oracle. Teda, ako to pytajuci sa este neurobil.  To moze spravit aj 10-nasobny rozdiel.  Na x86 je openjdk s vykonom zhruba zarovno, na ARM to vsak neplati.

[zboj]

Zkusme si shrnou pár základních faktů:
- server běží nad ARM64
- je to velmi jednoduchý server, v podstatě asi dotaz do databáze nebo IPC a serializace/deserializace JSON
- existuje proof of concept v C (ještě nikdy jsem neviděl PoC v low-level jazyce, což opět indikuje relativně jednoduché řešení)
- autor má velkou vůli to přepsat a naučit se něco nového

Nevíme:
- zda DB běží na stejném zařízení

Za dobu, co tady diskutujete bych to s největší pravděpodobností už měl přepsané.

Takže mých 0.005c:
1. Určitě není špatná rada zjistit, kde to drhne. Pokud s tím nemáš zkušenosti, je to výzva naučit se něco nového
2. Určitě není vyloženě špatný nápad to přepsat do něčeho jiného (zvláště pokud je to ARM64). Někteří masochisté sice propagují Javu i na RPi, ale nejlepší nápad to většinou není
3. Z toho co víme (C, Java) si myslím, že nejméně problematické bude Go.
 a) je to velmi jednoduchý jazyk s téměř identickou syntaxí, se znalostí C a Javy lze po přečtení tutoriálu (cca 2h) najít nějaký příklad a začít psát
 b) je určen přesně pro toto použití
 c) má extrémně malé paměťové nároky a je překládán přímo do strojového kódu
 d) má neuvěřitelně jednoduchou křížovou kompilaci, takže lze vyvíjet na vlastním stroji a spouštět a testovat na ARM
 e) jeho GC je optimalizován na latenci, takže žádné stop the world na 2s nehrozí

Osobně to odhaduji, že ačkoliv začátečník, přes víkend to budeš mít hotové. Pokud jsem to odhadl dobře, bude to mít celé do 500 řádků.

Pokud bys potřeboval poradit, dej tady vědět.

Pro ostatní:
Netvrdím, že Go je jediné nebo nejlepší řešení. Jen říkám, že z výše uvedených důvodů je to určitě velmi dobré řešení. A s největší pravděpodobností problémy zmizí "samy" i bez toho profilování. Celkové paměťové nároky budou odhadem 10-20x menší.

ad 2) Na ARM32 je Java nepoužitelná tragédie, na ARM64 to je asi o něco lepší, ale stejně bych se tomu obloukem vyhnul.
ad 3) Rozhodně to bude snazší než to psát v C nad kqueue a GCD. Pokud je problém GC, tak se fakt vyřeší sám.

Hlavne by som najprv vyskusal vyhodit openjdk a dat tam javu od oracle. Teda, ako to pytajuci sa este neurobil.  To moze spravit aj 10-nasobny rozdiel.  Na x86 je openjdk s vykonom zhruba zarovno, na ARM to vsak neplati.

Urobil som to ja. Na ARM32 řádově pomalejší (nepoužitelné) obě. ARM64 oraclí zvládá lépe, ale furt napikaču na rozdíl od amd64. JIT prostě ARM nedává.