• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
    • přihlásit
    registrace
    ztracené heslo?
    XCHAOSBenchmarky programovacích jazyků, knihoven a toolkitů
    AUREL
    AUREL --- ---
    1 odpověď+1
    Myslim si ze tady to se bude hodit:
    The Computer Language Benchmarks Game - Wikipedia
    https://en.wikipedia.org/wiki/The_Computer_Language_Benchmarks_Game
    https://benchmarksgame-team.pages.debian.net/benchmarksgame/index.html
    RUTHAN
    RUTHAN --- ---
    WOODMAKER: Ty Python je jeste daleko pomalejsi nez Java, takze vsechno je zlepseni.. Jinak to spusteni Javy - jak mate nastavenou JVM (min, max mem a tak), to muze mit vliv.
    WOODMAKER
    WOODMAKER --- ---
    JANFROG: zatim to je ten posledni problem. Ale diky za tipy.
    JANFROG
    JANFROG --- ---
    1 odpověď
    WOODMAKER: > Ale spousteni netrva 2 sekundy, ale pul minuty
    A co pouzivate za VM, hotspot? Muzes zkusit J9, pokud vas ta pul minuta stve, startup time se da zredukovat pouzitim AOT).
    WOODMAKER
    WOODMAKER --- ---
    2 odpovědi+1
    My v praci prepisujeme sw z Pythonu do Javy/springu pri snaze o zachovani logiky. Nedelame to kvuli zvyseni vykonu.
    Zatim je ta Java casto rychlejsi, kdyz uz pracuje. Ale spousteni netrva 2 sekundy, ale pul minuty. Taky je ted velkym zdrzovadlem logovani behem zpracovavani dat. To zvyseni rychlosti jde videt hlavne na uz hotove komponente/docker containeru, kterej zere data ze zdroje a hazi je do Kafky. Na druhe strane kafky je neco, co se stara o zpracovani dat a zapis do Influxdb, to je teprve ve vyrobe, ale obecne se zda, ze knihovny v Jave jsou optimalizovanejsi, nez ty pythonovy.
    XCHAOS
    XCHAOS --- ---
    MARASAN: tak koukám od benchmarků jsme rychle postoupili k optimalizacím a to rovnou k optimalizacím skrz paralelizovatelnost :-) ok, to je fakt už "vyšší dívčí", tam asi hraje roli podíl toho, kolik je fakt počítání (takže se použije více threadů v procesoru) a kolik třeba přístupy do paměti (kde je úzke hrdlo sběrnice)
    MARASAN
    MARASAN --- ---
    nebude to hned, az to zmerim, dam vysledky.
    MARASAN
    MARASAN --- ---
    1 odpověď
    MARASAN: v RUSTu to mam uplne bez paralelizace.
    MARASAN
    MARASAN --- ---
    1 odpověď+1
    XCHAOS: ja hodne pracuju s datama v XML, takze bych udelal neco, co veme gz fajl, 1 XML dokument na radku - ruzny druhy - a tech radku je par milionu na soubor. To bych promeril a muzu to srovnat i s implementaci, kterou mam v RUSTu.
    XCHAOS
    XCHAOS --- ---
    1 odpověď
    MARASAN: ano, no tak benchmarky masivně paralelizovatelných algoritmů, to je teprve kapitola sama pro sebe. tenhle klub je zatím podle mě někde na úrovni toho, aby si lidi dokázali srovnat aspoň třeba algoritmu na fibonacciho čísla (ne, že by jim byl dobrej k něčemu jinýmu, než k prolezení písemky někde na gymplu) v bashi vs. v PHP v céčku... ale pokud to tu přeskočí na vyšší level, tak jedině dobře!
    MARASAN
    MARASAN --- ---
    1 odpověď+1
    XCHAOS: otazka je, jestli to mam masivne paralelizovat, coz je snadny a pouzivam to hodne, anebo se to projevi v sekvencnim zpracovani.
    XCHAOS
    XCHAOS --- ---
    1 odpověď
    MARASAN: no tak právě proto je potřeba prohnat nějaký vzorový benchmarkový kód oběma variantami a výsledky postnout sem :-)
    MARASAN
    MARASAN --- ---
    1 odpověď
    DEFILA: tu praci by mel dodat prave JIT.
    DEFILA
    DEFILA --- ---
    1 odpověď
    MARASAN: bez práce?:)
    MARASAN
    MARASAN --- ---
    1 odpověď
    Erlang 24 prave prichazi s JITem, RabbitMQ slibuje bez prace az 30% narust propustnosti. Mohl bych protestovat nejaky ulohy mezi verzema.
    RUTHAN
    RUTHAN --- ---
    -1
    Uz se "tesim", jak tu nejaky fanatik bude rikat, ze se v Jave, pythonu da psat stejne rychle jako v C. Ano je mozny, extreme narocne tyhle smilaky optimalizovat, ale zadny velka rychla velka vec v tom asi neexistuje, jen nejaky optimalizovany steky.. Byt jsem teda videl nejaky release notes novy verze Javy a byla tam moznost pouzit ASM, ale to predpokladam, driv snad pres nejaky wrappery slo taky..

    Urcite existuje neco lepsiho a meli bychom to postupne datav na nastenku, protoze se to relativne spatne hleda, ale pro zacatek:
    Programming Languages Benchmarks
    https://attractivechaos.github.io/plb/
    https://github.com/kostya/benchmarks
    http://hildstrom.com/projects/langcomp/index.html
    https://thenewstack.io/which-programming-languages-use-the-least-electricity/
    XCHAOS
    XCHAOS --- ---
    +1
    K čemu je myšlený tenhle klub: je pro šílence, kteří si dají tu práci napsat nějaký složitější algoritmus ve více různých programovacích jazycích/prostředích, a pak srovnávají, jak na jinak stejné platformě se stejnými daty běží dlouho. Založeno jako nový klub, aby to nezaclánělo jinde.
    TORI
    TORI --- ---
    Vítejte a ať se vám tu líbí.

    Můžete pozvat své přátele.
    Kliknutím sem můžete změnit nastavení reklam