Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - zboj

Stran: 1 ... 13 14 [15] 16 17 ... 101
211
Studium a uplatnění / Re:ČVUT OI vs MFF
« kdy: 27. 05. 2017, 10:39:48 »
Zdravím,
Rozhodujem sa medzi vysokou školou a ako posledné rozhodnutie mi ostáva OI a MFF. Vedeli by ste mi niekto prosim tieto dve školy porovnat? Zaujímam sa o CS.
Ďakujem
Má to být více o teorii nebo praxi? Na MFF je ze začátku hodně vyšší matematiky a celkově tam je dost teorie. Na druhou stranu teorie je základ, praxi člověk získá za běhu, když chce.

212
Vývoj / Re:Přepsání serveru v Javě
« kdy: 26. 05. 2017, 18:21:33 »
Pokud je čas a chuť to přepsat do něčeho jiného a nebude vadit že to má někdo jiný udržovat, tak by byl hřích to nevyužít.
V tomto případě je Go nejlepší volba, protože je to jazyk (resp. "platforma") přesně pro tento účel.

Něco jiného je někde ve firmě, kde se řeší věci jako náklady nebo zastupitelnost. Tam pak platí, že by se mělo zjistit co je přesně špatně a podle toho pokračovat.
V Go to bude z obecných jazyků nejsnadnější. Kdo má chuť experimentovat, může ještě zkusit GCD, když už je verze v C.

213
Vývoj / Re:Přepsání serveru v Javě
« kdy: 26. 05. 2017, 10:03:27 »
A ještě k té záměně JVM.
Už podle slov autora vlákna není zjevně problém ve verzi JVM, ale spíš v architektuře aplikace. Pokud na server chodí vyšší desítky požadavků za vteřinu, přičemž každý požadavek = jeden thread, pro zlepšení bude s největší pravděpodobností potřeba přepsat i tu Java aplikaci. Samozřejmě to může drhnout na mnoha místech, nikde se nezmiňuje charakter těch požadavků (sběr dat => zápis nebo spíš čtení).
Takže pokud by se to přepisovalo tak jako tak, je otázka jestli zůstat u Javy velice aktuální, zvláště pak v případě nutnosti učit se třeba nějaký framework.
Než řešit výběr JVM, GC a nevím co ještě, to je fakt lepší to přepsat do něčeho moderního.

214
Vývoj / Re:Přepsání serveru v Javě
« kdy: 25. 05. 2017, 20:39:53 »
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á.

215
Vývoj / Re:Přepsání serveru v Javě
« kdy: 25. 05. 2017, 18:42:12 »
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.

216
Vývoj / Re:Přepsání serveru v Javě
« kdy: 25. 05. 2017, 18:25:33 »
Haskell jde nějak zjednodušit?  ???  :-\  :o
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 ;)

217
Vývoj / Re:Přepsání serveru v Javě
« kdy: 25. 05. 2017, 18:19:27 »
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?  ???  :-\  :o

218
Vývoj / Re:Přepsání serveru v Javě
« kdy: 25. 05. 2017, 18:17:32 »
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...

219
Vývoj / Re:Přepsání serveru v Javě
« kdy: 25. 05. 2017, 17:49:47 »
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...

220
Vývoj / Re:Přepsání serveru v Javě
« kdy: 25. 05. 2017, 17:44:22 »
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).

221
Vývoj / Re:Přepsání serveru v Javě
« kdy: 25. 05. 2017, 17:36:57 »
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 :)

222
Vývoj / Re:Přepsání serveru v Javě
« kdy: 25. 05. 2017, 16:58:16 »
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ášť.

223
Vývoj / Re:Přepsání serveru v Javě
« kdy: 25. 05. 2017, 16:56:47 »
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.

224
Vývoj / Re:Přepsání serveru v Javě
« kdy: 25. 05. 2017, 16:28:20 »
[...] 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.

225
Vývoj / Re:Přepsání serveru v Javě
« kdy: 25. 05. 2017, 16:24:39 »
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ě.

Stran: 1 ... 13 14 [15] 16 17 ... 101