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.
Zdravím,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.
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
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 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.
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.
A ještě k té záměně JVM.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.
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.
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á.Zkusme si shrnou pár základních faktů: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.
- 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 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.
Zkusme si shrnou pár základních faktů: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.
- 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ší.
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 polotovaremHaskell 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
Haskell jde nějak zjednodušit?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 zaujalAle 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ší
"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...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.
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...Jo, myslel jsem třeba přes síť. Erlang se mi začíná líbitTyjo, 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).
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).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.
g Jo, myslel jsem třeba přes síť. Erlang se mi začíná líbitKdyž 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.
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ášť.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é.
Já měl taky na mysli případ, kdy je hodně procesů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).
[...] 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.
Pokud v nějakém jazyce musím explicitně vybírat GC, aby mi program fungoval, tak je něco hodně špatně.ale stejně bych čekal, že GC si s tím poradí lépeJste si jistý, že to souvisí s GC? Nebylo by pak řešením použít jiný GC?
Root.cz (www.root.cz), informace nejen ze světa Linuxu. ISSN 1212-8309
Copyright © 1998 – 2023 Internet Info, s.r.o. Všechna práva vyhrazena. Powered by Linux.