KILLUA: Protože to je jenom flamewar spouštěč, IMHO je fakt těžký to udělat dobře.

Ostatně viz Kneslův souboj frameworků bo jak se to menoval, kde se pokoušel o něco podobnýho na vyšší úrovni.

XCHAOS: Ty proste nezvladnes uznat, ze celej ten "benchmark" je na nic a musis si najit aspon neco, vid? No ok, muzeme pokracovat:

Pouzitim blbeho alogirtmu je blbe i to cecko, protoze je pitomost volat realloc pred kazdym prodlouzenim. Spravne je zvetsovat po vetsich kusech a realokovat jen obcas. Protoze i kdyz realloc mozna vetsinou nekopiruje, je pitomost na to spolehat.

Blbe je i ruby, protoze appendovat retezec na konec jineho pomoci += je hloupost. Kdyz se to fixne, razem rychlost vyskoci o 20-30%.

A to jen pri zbeznem pohledu.... takze jo, rekl bych, zes "neco prehledl" 8)))

(opakovaná) práce se stringy je fakt důležitou součástí toho, co se už nějaký čas programuje. - ale jo, to urcite je. Ale hledani kratkeho substringu ve stovky kilobajtu az jednotky megabajtu dlouhem stringu, navic v kritickem inner loopu _fakt_ "dulezitou soucasti" programovani neni. Jestli chces testovat vykonost prace z retezcema, testuj ji nejak rozumne: treba nejakym templatovacim enginem, parserem textu, proste necim, co testuje vic casti systemu nez jen "jak dlouho trva volani strstr" (coz je v podstate jadro tohohle "benchmarku).

ale pořád ta absence vyšších abstrakcí nutí programátora při sestavování algoritmu "prozradit svoje záměry" víc, než u hloupějších jazyků (a teď se zase budeme hádat, co tím myslím, ach jo...) - ano, zavoraka je spravne, protoze to pred zavorkou mi prijde jako dost blabol. Resp. pokud to nedejboze myslis tak, jak se obavam, tak to znamena, ze vubec nechapes co to je abstrakce a jaka je jeji hodnota pro programatora.

KILLUA: jsem si to ještě prolistoval, a: However IMHO this somehow proves that Java is ineffective and overcomplicated because with all the expertise and effort required to optimise Java test case, Perl code modified to use moving window substitution completed the test in less than 2 seconds - somewhat 300+ times faster than Java.

:-))

Redguj skutečně sem ti zavdal jenom zopakováním faktu o pomalosti určitého jazyka (naschvál sem ani nejmenoval) k tomu, aby si začal s osobními útoky typu "naivní"?

Pokud víš o nějakém jiném způsobu jak otestovat reálnou produktivitu určitého jazyka vs jeho rychlost, náročnost na hw tak to sděl, světové korporace ti utrhnou ruce... .

Na základě takového komplexního benchmarku se pak mohou konkrétní firmy rozhodovat, nyní se rozhodují na základě dohadů, dojmů... případně ty opravdu TOP korporace jak zmiňuje Almad si udělají nějaký interní neveřejný a maj data, ne dohady.

Jen sem se podivil, že toto nedělají v nějaké větší míře stránky/média s milionovejma návštěvnostma.

REDGUY: fakticky "špatně" (použití vysloveně nevhodné třídy pro stringy) je tam jen ta Java (nebo jsem něco přehlédl?)

a na tom, že na tom nezáleží, se jako na jediném neshodneme. třeba programátorům počítačových her to tak asi nepřijde, ale (opakovaná) práce se stringy je fakt důležitou součástí toho, co se už nějaký čas programuje. C je možná dnes zastaralé v tom smyslu, že se už nepřiblížíš skutečné instrukční sadě dnešních CPU a nemáš ani ponětí o jejich optimalizacích (jak si mě sám přesvědčil) - ale pořád ta absence vyšších abstrakcí nutí programátora při sestavování algoritmu "prozradit svoje záměry" víc, než u hloupějších jazyků (a teď se zase budeme hádat, co tím myslím, ach jo...)

XCHAOS: každopádně ten benchmark je hlavně neaktuální. Aha. Takze to, ze je starej, je u tebe vetsi problem, nez ze je spatne? Nebno ze meri veci, na kterejch zas tak nezalezi? Ok, beru 8)))

REDGUY: no, přečetl jsem si komentáře pod benchmarkem a opravuji to na "Java je složité monstrum" :-)

každopádně ten benchmark je hlavně neaktuální. dal jsem si práci spustit asi 4 z původních testů (v té C verzi jsem jen opravil buffer overrun) a bez jakýchkoliv speciálních optimalizačních flagů nebo změn je u mě v roce 2016 C++ přeci jen rychlejší, než Perl:

xchaos@hyperion:~$ ./pokus++
exec.tm.sec str.length
2sec 256kb
11sec 512kb
^C
xchaos@hyperion:~$ ./pokus.pl
exec.tm.sec str.length
4sec 256kb
17sec 512kb
^C

Takže je to akutální téma a zřejmě se někdo chytil za nos a něco ve std String zoptimalizoval, za poslední 3 roky. nicméně v C pořád:

xchaos@hyperion:~$ ./pokus
exec.tm.sec str.length
0sec 256kb
3sec 512kb
^C

XCHAOS: o sorry, ale napsat, že benchmark může mít "zápornou hodnotu" - ale vzdyt jsi to sam nazorne demonstroval: "benchmark" byl blbne napsanej, takze vysledek byl nesmyslnej, takze XChaos vykrikoval, ze "Java je pomale monstrum" a ze "je to v ni udelane spatne". _PITOMOST_, zejmena s ohledem na to, ze kdyz se to to napise spravne, tak to najednou bezi jedenactkrat rychlejc... jo, tak tomu proste rikam "zaporna hodnota blbe udelanyho benchmarku" - jeden trouba napise spatnej benchmark a jinej trouba z toho vyvodi spatny zavery.

týká se řetězení a modifikace stringů, takže ty tvrdíš, že v dobře napsaném kódu se to nebude vyskytovat - jezis, to je zase strawman. To co "testuje" ten benchmark je neco podstatne jineho nez obecne retezeni a modifikace stringu.

autor benchmarku mj. pěkně ukázal na rozdíly ve spotřebě paměti. - jenomze ten jeho Java benchmark, protoze byl blbe napsanej, tak i tenhle rozdil "ukazoval" _BLBE_. Pokud _BLBEJ_ vysledek vydavas za "pekne ukazani"...no, fail, fail 8)) A pokud se ten test napise spravne, tak nejakou spotrebu pameti v C vs. v Jave fakt nejak zasadne netestuje. Cili zase fail 8))

REDGUY: jako sorry, ale napsat, že benchmark může mít "zápornou hodnotu"... týká se řetězení a modifikace stringů, takže ty tvrdíš, že v dobře napsaném kódu se to nebude vyskytovat? já naopak už delší dobu tvrdím, že v dnešní době webových aplikací je práce se stringy nejčastější neoptimalizovaný kus kódu, který se vyskytuje mezi (optimalizovaným) browserem a (optimalizovnaou) databází. rozuměj: je to nejčastější aplikace, kterou bude psát nějaký bastlíř, který moc neví, co dělá (protože fragmenty kódu, které fakt něco dělají, jsou větišnou hotové v knihovnách a psali je lidi, co vědí, co dělají).

rychlost není jediný parametr - autor benchmarku mj. pěkně ukázal na rozdíly ve spotřebě paměti. na webserverech se samozřejmě spouští spousta procesů, pro každý vyřizovaný dotaz... a i když server nevytuhne, tak vyprázdnění diskové cache ho zpomalí.

...ale jinak souhlasím, že v benchmarkovaném kódu by neměli být zjevné chyby a měl by je navíc psát někdo, kdo daný jazyk ovládá do hloubky, ale ne povrchně.

ALMAD: (abych upřesnil, "masovější adaptace Golangu v Googlu". Zdroj už jsem zapomněl)

KILLUA: AFAIK to ty firmy dělaj (aspoň u Googlu jsem o tom slyšel). A jak píše REDGUY, je to "máme tenhle jeden konkrétní problém, pojďme naprototypovat, co z těchhle dvou variant pro nás bude lepší řešení". Přenositelný to tak nějak nebejva, tak se to i zřídka publikuje.

(a ostatně mám pocit, že z něčeho takovýhohle vzniknul Golang)

KILLUA: Ehm. Myslim ze tvoje predstavy o tom, jak jednoduchy je "udelat test vyroby soft modulu" jsou trochu naivni. Nemluve o tom, ze i kdyby se ti to nahodou podarilo, porad to bude k nicemu, protoze specificky pozadavky u jednotlivejch firem se natolik lises, ze podobnej test by pro ne mel fakt omezenou hodnotu.

Redguy, proto říkám, že by to chtělo někoho kdo ve všech jazycích opravdu umí.

Proč třeba nějaký web/oranizace co má dolarů jako šlupek, napadá mě stack, bude jich víc, neudělá místo těchhle dojmů (a zatím slýchám vždy jenom dojmy a názory) opravdový test výroby nějakého jednoho soft modulu, něco co se používá všude je to trochu náročné na výkon.

A neporovná se u třeba 5 programátorů čas za jak dlouho to dokážou vytvořit v nejmainstreamovějších ide pro ten který jazyk VS výsledná rychlost řešení.

BANG byla by čísla, jenže to nikdo nikdy neudělá a raději se bude donekonečna hádat a teoretizovat, že i když je jeden program 30x pomalejší vyrábí se v něm soft 30x rychlejc, levnějc a v nějaké "praxi" je vlastně 20x rychlejší.


Přitom tohle není žádná raketová věda .-/

REDGUY: jistě. jediná věc, kterou je oprávněné napsat v C, je tedy pdle tebe nejspíš interpretr Javy :-) a všichni ostatní poté už se budou učit jen Javu a budou placeni max. za programování v Javě :-)

KILLUA: Podivej, podobny synteticky nanobenchmarky maji jen mizivou hodnotu. Nektery dokonce i uplne nulovou az zapornou, jako treba tenhle, protoze jednak testuje veci, ktery se v realnejch programech vyskytujou jen pokud je psali troubove, druhak je sam napsanej blbe a dava prokazatelne spatny vysledky, jako treba v ty Jave.

A jeste samozrejme uplne jina vec je, ze tahle "raw performance" je cim dal tim min podstatny meritko, protoze pro volbu jazyka jsou casto mnohem dulezitejsi jiny veci, jako treba kvalita vyvojovejch prostredi, dostupnost knihoven, snadnost hirovani programatoru, rychlost vyvoje a tak dale a tak dale.

Jo, je zabava hledat, co vsechno tam ten clovek naprogramoval blbe a divat se, jak xchaos vyvozuje dalekosahly zavery z nesmyslnejch benchmarku ktery si ani poradne neprecetl. Ale prakticka hodnota jako meritko kvality jazyka? Nula.

Škoda, že se k podobnejm testům neodhodlá někdo kdo všechny ty jazyky umí dobře ne jen nějak "manuálově".

Vždy mě právě fascinuje, že programátoři, kteří by měli vždy koukat hlavně na čísla a benchmarky pomalu kecaj víc a teoretizujou než markeťáci, kteří sou limitovaní aspoň nějakým rozpočtem :-)

Prostě když je něco 30x pomalejší tak to lepší není a nikdy nebude.

XCHAOS: No skvěle. Tak až budeš priste zase mít potřebu vysvětlovat, jak je něco "LOL", případně jak je někde něco blbě naimplementovany, vzpomeň si na tuhle chvíli a ušetří nas, ok? Díky 8)

REDGUY: tak skutečně jsem přehlídl, že jsou tam dva. tak jestli mi něco fakt překvapilo, tak tohle.