Co zpomaluje Javu? A co překlad do nativního kódu?

[gll]

Jen nejsou tak dobré. Plno skriptovacích věcí běží všude, ale kdo by chtěl dělat v jazycích na malé skriptíky. Plus jsou obvykle brutálně pomalé.

Java je ale z takych jazykov najrychlejsia.

c se dá zkompilovat všude.

[Reklama]

[linuxtardis]

Jen nejsou tak dobré. Plno skriptovacích věcí běží všude, ale kdo by chtěl dělat v jazycích na malé skriptíky. Plus jsou obvykle brutálně pomalé.

Mám to chápat tak, že např. GitHub a GitLab napsaly samé lopaty?

[javaman ((]

Asi ano, ale to jsou dost jednoduché softy, které nic moc neumí, takže třeba to nejsou lopaty. Webové věci jsou celkově dost jednoduché a back-end z toho nepoznám.

[gll]

K tomu prepisovani "lepsiho" softu do Javy, ona vyhoda bude, ze to potom spustite vsude, kde se spusti Java. Nejste zavisli na nejakych binarkach pro konkretni architekturu.

Treba v JavaScriptu je to podobne. Nektere baliky z npm si s sebou tahaji ruzne obludnosti v Ruby, Pythonu nebo C (klidne na vsech zaroven) a jsou s tim neustale problemy. Pokud to funguje, tak to muze byt rychlejsi, ale pokud to nefunguje, tak je to celkem peklo - dohledavani na cem vsem to zavisi, ze to nefunguje s touhle verzi Pythonu (2 vs 3) a ze se tomu musi manualne nekde predat cesta, ze se nekde nestahly predkompilovane binarky pro mou architekturu a OS, ze mi chybi nejaka knihovna. Proste tohle u cisteho JS reseni neni, tomu date "npm install" a konec. Vse je rychle stazene, nic se nemusi prekladat nebo dotahovat odjinud, funguje to vsude, kde jede nodejs.

Původní téma této diskuze bylo proč je Java pomalá. Uvedl jsem ty příklady pro srovnání rychlosti. Chápu, že implementace v Javě může mít své výhody.

[kimec]

Queue.py je stejný ve všech implementacích.

https://github.com/python/cpython/blob/master/Lib/queue.py

https://github.com/aljosa/pypy/blob/master/lib-python/2.7/Queue.py

To je v poriadku. Ja som reagoval na tvrdenie "Zrovna Javisté často reimplementují existující software v Javě" nasledovnymi argumentami:

• PyPy vobec nie je dobry priklad pre nastoleny argument nakolko neobstoji voci odkazovanym faktom. Je to tak isto reimplementacia Pythonu a navyse mladsia ako Jython. Argument je preto mozne obratit: Preco niekto potreboval pisat PyPy, ked uz existoval CPython a Jython...
• Co sa Jythonu konkretne tyka, je to port runtime-u na JVM. Pythonovske moduly z Python Standard Library funguju bezozmeny, co priamo hovori o miere kompatibility runtime-u. Inymi slovami, tuto cast Pythonu Javisti nereimplementovali, lebo to nebolo nutne.

Pokud ten modul použijete, tak se přeloží do java bytekódu. Provádění toho bytekódu je řádově pomalejší než pypy.

Iste, asi ste prehliadli video, ktore som linkoval na prvej strane aj s casovym odkazom na presne miesto, kde Jim Baker porovnava vysledky pystone benchmarku Jython vs. CPython vs. PyPy... Odporucam davat pozor na argumenty, s ktorymi test spusta Jim vo videu versus argumenty, s ktorymi sa test spusta na pybenchmarks.org vid tu https://pybenchmarks.org/u64q/benchmark.php?test=pystone&lang=jython&data=u64q#log

[Reklama]

[kolemjdoucí]

Co zpomaluje Javu?

To fluidum, co je mezi židlí a klávesnicí.

A co preklad do nativniho kodu?

To má opačný efekt snad.

[balki]

Jen nejsou tak dobré. Plno skriptovacích věcí běží všude, ale kdo by chtěl dělat v jazycích na malé skriptíky. Plus jsou obvykle brutálně pomalé.

Java je ale z takych jazykov najrychlejsia.

c se dá zkompilovat všude.

To by som netvrdil.  Staci skusit zobrat projekt z linuxu a bezo zmien ho skompilovat trebars pod cygwin. Clovek z toho zosedivie.

[gll]

Queue.py je stejný ve všech implementacích.

https://github.com/python/cpython/blob/master/Lib/queue.py

https://github.com/aljosa/pypy/blob/master/lib-python/2.7/Queue.py

To je v poriadku. Ja som reagoval na tvrdenie "Zrovna Javisté často reimplementují existující software v Javě" nasledovnymi argumentami:

• PyPy vobec nie je dobry priklad pre nastoleny argument nakolko neobstoji voci odkazovanym faktom. Je to tak isto reimplementacia Pythonu a navyse mladsia ako Jython. Argument je preto mozne obratit: Preco niekto potreboval pisat PyPy, ked uz existoval CPython a Jython...
• Co sa Jythonu konkretne tyka, je to port runtime-u na JVM. Pythonovske moduly z Python Standard Library funguju bezozmeny, co priamo hovori o miere kompatibility runtime-u. Inymi slovami, tuto cast Pythonu Javisti nereimplementovali, lebo to nebolo nutne.

Pokud ten modul použijete, tak se přeloží do java bytekódu. Provádění toho bytekódu je řádově pomalejší než pypy.

Iste, asi ste prehliadli video, ktore som linkoval na prvej strane aj s casovym odkazom na presne miesto, kde Jim Baker porovnava vysledky pystone benchmarku Jython vs. CPython vs. PyPy... Odporucam davat pozor na argumenty, s ktorymi test spusta Jim vo videu versus argumenty, s ktorymi sa test spusta na pybenchmarks.org vid tu https://pybenchmarks.org/u64q/benchmark.php?test=pystone&lang=jython&data=u64q#log

Podle toho videa je PyPy řádově rychlejší. Jython je na druhou stranu kompatibilější s CPythonem (podporuje C extensions). Srovnávat rychlost s CPythonem nedává moc smysl. CPython je čistě interpretovaný a nepoužívá JIT. Vyniká v jiných parametrech. Například v rychlosti startu a paměťové náročnosti.

[kimec]

Psal jsem o konkrétním případě, kdy kód napsaný inteligentně pracuje s mnoha objekty alokovanými na zásobníku, což Java neumožňuje, pročež je řádově pomalejší. Už se to tu řešilo několikrát, kdysi dávno i s kódem, kterýžto byl důkazem, a naposledy tu jeden z mála inteligentních účastníků tohoto fóra s nekonečnou trpělivostí vysvětloval těm méně chápavým, proč tomu tak je (už nevím, jestli M.Prýmek nebo O.S.Nekola, ale to je fuk).

Vy ste asi mysleli tento prispevok. https://forum.root.cz/index.php?topic=13854.msg179201#msg179201

[...] V Javě NEJDE zaručit, že se alokátor bude chovat inkrementálně a objekty bude umísťovat za sebe. Defaultně se o to snaží, ale ne vždy to lze. Problém je to hlavně při fragmentaci haldy, pak si alokátor bude vytvářet objekty tam, kde je zrovna místo. Nelze to rozumně ovlivnit. Heap compaction nic moc neřeší, protože je to drahé.

Ale jasne, ze to ide aj v Jave, ved som to linkoval vyssie http://mechanical-sympathy.blogspot.sk/2012/10/compact-off-heap-structurestuples-in.html .
Je to blog samotneho Thomsona, na ktoreho odkazuje aj Ondra Satai Nekola v tom vlakne... Takze to islo to uz 4 roky pred tou septembrovou diskusiou, LOL...

[zboj]

Psal jsem o konkrétním případě, kdy kód napsaný inteligentně pracuje s mnoha objekty alokovanými na zásobníku, což Java neumožňuje, pročež je řádově pomalejší. Už se to tu řešilo několikrát, kdysi dávno i s kódem, kterýžto byl důkazem, a naposledy tu jeden z mála inteligentních účastníků tohoto fóra s nekonečnou trpělivostí vysvětloval těm méně chápavým, proč tomu tak je (už nevím, jestli M.Prýmek nebo O.S.Nekola, ale to je fuk).

Vy ste asi mysleli tento prispevok. https://forum.root.cz/index.php?topic=13854.msg179201#msg179201

[...] V Javě NEJDE zaručit, že se alokátor bude chovat inkrementálně a objekty bude umísťovat za sebe. Defaultně se o to snaží, ale ne vždy to lze. Problém je to hlavně při fragmentaci haldy, pak si alokátor bude vytvářet objekty tam, kde je zrovna místo. Nelze to rozumně ovlivnit. Heap compaction nic moc neřeší, protože je to drahé.

Ale jasne, ze to ide aj v Jave, ved som to linkoval vyssie http://mechanical-sympathy.blogspot.sk/2012/10/compact-off-heap-structurestuples-in.html .
Je to blog samotneho Thomsona, na ktoreho odkazuje aj Ondra Satai Nekola v tom vlakne... Takze to islo to uz 4 roky pred tou septembrovou diskusiou, LOL...

Ten blog přesně potvrzuje, co tu psal O.S.Nekola a tuším že R.Miček.

[gll]

Jen nejsou tak dobré. Plno skriptovacích věcí běží všude, ale kdo by chtěl dělat v jazycích na malé skriptíky. Plus jsou obvykle brutálně pomalé.

Java je ale z takych jazykov najrychlejsia.

c se dá zkompilovat všude.

To by som netvrdil.  Staci skusit zobrat projekt z linuxu a bezo zmien ho skompilovat trebars pod cygwin. Clovek z toho zosedivie.

Pokud v Javě používáte nativní knihovny nebo kód specifický pro platformu, dopadnete stejně. Jediná výhoda Javy je, že můžete distribuovat software bez zdrojových kódů.

[balki]

Jen nejsou tak dobré. Plno skriptovacích věcí běží všude, ale kdo by chtěl dělat v jazycích na malé skriptíky. Plus jsou obvykle brutálně pomalé.

Java je ale z takych jazykov najrychlejsia.

c se dá zkompilovat všude.

To by som netvrdil.  Staci skusit zobrat projekt z linuxu a bezo zmien ho skompilovat trebars pod cygwin. Clovek z toho zosedivie.

Pokud v Javě používáte nativní knihovny nebo kód specifický pro platformu, dopadnete stejně. Jediná výhoda Javy je, že můžete distribuovat software bez zdrojových kódů.

Pokud ...  V Jave to byva skor vynimka, kdezto v C je to pravidlo. Vacsinou, ak je Java vyvojar aplikacie prasa a pouziva nejaku platformovo zavislu kniznicu, byva tak jedna v celom projekte. Kdezto programy zlozitejsie nez hello world v C sa zavislostami na platforme hemzia. Pri lenivom programatorovi to skonci pribalenim emulacie posix-u, alebo windows api do projektu. Pri menej lenivom programatorovi sialenymi ifdefmi.

[kimec]

Psal jsem o konkrétním případě, kdy kód napsaný inteligentně pracuje s mnoha objekty alokovanými na zásobníku, což Java neumožňuje, pročež je řádově pomalejší. Už se to tu řešilo několikrát, kdysi dávno i s kódem, kterýžto byl důkazem, a naposledy tu jeden z mála inteligentních účastníků tohoto fóra s nekonečnou trpělivostí vysvětloval těm méně chápavým, proč tomu tak je (už nevím, jestli M.Prýmek nebo O.S.Nekola, ale to je fuk).

Vy ste asi mysleli tento prispevok. https://forum.root.cz/index.php?topic=13854.msg179201#msg179201

[...] V Javě NEJDE zaručit, že se alokátor bude chovat inkrementálně a objekty bude umísťovat za sebe. Defaultně se o to snaží, ale ne vždy to lze. Problém je to hlavně při fragmentaci haldy, pak si alokátor bude vytvářet objekty tam, kde je zrovna místo. Nelze to rozumně ovlivnit. Heap compaction nic moc neřeší, protože je to drahé.

Ale jasne, ze to ide aj v Jave, ved som to linkoval vyssie http://mechanical-sympathy.blogspot.sk/2012/10/compact-off-heap-structurestuples-in.html .
Je to blog samotneho Thomsona, na ktoreho odkazuje aj Ondra Satai Nekola v tom vlakne... Takze to islo to uz 4 roky pred tou septembrovou diskusiou, LOL...

Ten blog přesně potvrzuje, co tu psal O.S.Nekola a tuším že R.Miček.

Ach, chapem, ja som predpokladal, ze vas argument je, ze to Java neumoznuje. A moj protiargument bol, ze to umoznuje, za cenu, ze si musite alokovat blok pamate mimo heap cez Unsafe, inymi slovami presne to iste, co je v predmetnom algoritme napisane v C. Predpokladam, ze toto je ten algoritmus
https://forum.root.cz/index.php?topic=13854.msg179103#msg179103 . Cize cele to bolo o tom, ze si allocujete jeden suvisli blok pamate, teda pocet * velkost structov Point. Ja to chapem tak, ze presne to sa da urobit a presne to je predmetom toho blogu. C-cko ziadnu typesafety nema, takze porovnavat Javovsky ArrayList/array referenci nema zmysel. Porovnavat suvisli blok alokovanej pamate z Javy cez Unsafe a struct Point *points = malloc(ARR_LEN * sizeof(struct Point)) sa moze? Spravne to chapem?

[zboj]

Jen nejsou tak dobré. Plno skriptovacích věcí běží všude, ale kdo by chtěl dělat v jazycích na malé skriptíky. Plus jsou obvykle brutálně pomalé.

Java je ale z takych jazykov najrychlejsia.

c se dá zkompilovat všude.

To by som netvrdil.  Staci skusit zobrat projekt z linuxu a bezo zmien ho skompilovat trebars pod cygwin. Clovek z toho zosedivie.

Pokud v Javě používáte nativní knihovny nebo kód specifický pro platformu, dopadnete stejně. Jediná výhoda Javy je, že můžete distribuovat software bez zdrojových kódů.

Pokud ...  V Jave to byva skor vynimka, kdezto v C je to pravidlo. Vacsinou, ak je Java vyvojar aplikacie prasa a pouziva nejaku platformovo zavislu kniznicu, byva tak jedna v celom projekte. Kdezto programy zlozitejsie nez hello world v C sa zavislostami na platforme hemzia. Pri lenivom programatorovi to skonci pribalenim emulacie posix-u, alebo windows api do projektu. Pri menej lenivom programatorovi sialenymi ifdefmi.

Co když potřebuju třeba GPGPU? Jinak s C jsem nikdy problémy neměl, ale ono to je o zkušenostech, žádný učený z nebe nespadl a psát dobrý kód se člověk učí s časem (nicméně při dodržení POSIXu a nějakého toho BSD API by neměl být problém).

[zboj]

Psal jsem o konkrétním případě, kdy kód napsaný inteligentně pracuje s mnoha objekty alokovanými na zásobníku, což Java neumožňuje, pročež je řádově pomalejší. Už se to tu řešilo několikrát, kdysi dávno i s kódem, kterýžto byl důkazem, a naposledy tu jeden z mála inteligentních účastníků tohoto fóra s nekonečnou trpělivostí vysvětloval těm méně chápavým, proč tomu tak je (už nevím, jestli M.Prýmek nebo O.S.Nekola, ale to je fuk).

Vy ste asi mysleli tento prispevok. https://forum.root.cz/index.php?topic=13854.msg179201#msg179201

[...] V Javě NEJDE zaručit, že se alokátor bude chovat inkrementálně a objekty bude umísťovat za sebe. Defaultně se o to snaží, ale ne vždy to lze. Problém je to hlavně při fragmentaci haldy, pak si alokátor bude vytvářet objekty tam, kde je zrovna místo. Nelze to rozumně ovlivnit. Heap compaction nic moc neřeší, protože je to drahé.

Ale jasne, ze to ide aj v Jave, ved som to linkoval vyssie http://mechanical-sympathy.blogspot.sk/2012/10/compact-off-heap-structurestuples-in.html .
Je to blog samotneho Thomsona, na ktoreho odkazuje aj Ondra Satai Nekola v tom vlakne... Takze to islo to uz 4 roky pred tou septembrovou diskusiou, LOL...

Ten blog přesně potvrzuje, co tu psal O.S.Nekola a tuším že R.Miček.

Ach, chapem, ja som predpokladal, ze vas argument je, ze to Java neumoznuje. A moj protiargument bol, ze to umoznuje, za cenu, ze si musite alokovat blok pamate mimo heap cez Unsafe, inymi slovami presne to iste, co je v predmetnom algoritme napisane v C. Predpokladam, ze toto je ten algoritmus
https://forum.root.cz/index.php?topic=13854.msg179103#msg179103 . Cize cele to bolo o tom, ze si allocujete jeden suvisli blok pamate, teda pocet * velkost structov Point. Ja to chapem tak, ze presne to sa da urobit a presne to je predmetom toho blogu. C-cko ziadnu typesafety nema, takze porovnavat Javovsky ArrayList/array referenci nema zmysel. Porovnavat suvisli blok alokovanej pamate z Javy cez Unsafe a struct Point *points = malloc(ARR_LEN * sizeof(struct Point)) sa moze? Spravne to chapem?

Ne, to není ten algoritmus, a nešlo o souvislou alokaci, ale o použití objektů alokovaných na zásobníku v kolekcích, což v Javě nejde ani s použitím unsafe, jež se tu taky řešilo a místní Java bumboys ho nazvali prasárnou. Jinak univerzálně přenositelný kód - pokud někomu nevoní POSIX - lze psát v Go včetně jednoduché kroskompilace.