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.

REDGUY: JavaScriipt, obávám se, je s tou efektivitou přesně na obráceném konci spektra, než Perl. Každý string tam určitá vzniká nejspíš jako další obecně rozšířitelný meta-objekt (javascript stojí na prototypingu - vznik nových objektů kopírováním z nějaké šablony), což musí nutně mít nějakou reži a ten test to ukazuje.

debata pod benchmarkem rozebírá, kde udělal autor chybu v Javové a C++ verzi (to nepřekvapí, že zrovna tohle si příslušné komunity hlídají, protože Java i C++ jsou velké trhy s dobře placenou programátorskou silou... a náznaky, že ty platformy jsou snad v něčem čemkoliv měřitelném nevhodné, jsou přímé ohrožení pro těžce pracující lid, co musí splácet svoje hypotéky a tak...). zajímavé je, že jsem tam asi nějak přehlídl zuřivou polemiku, že by snad ta javascriptová implementace byla špatně :-)

jedna z věcí, nad kterými jsem ohledně svého dalšího směřování v programování fakt přemýšlel, byla napsat pre-compiler z javascriptu do C (nebo teda případně do bytekódu). javascript totiž má masivní uživatelskou základnu bastlířů... a i když se mi třeba nelíbí, tak vyjít z něj je lepší, než se snažit nějak bastardizovat syntaxi jazyků jako Python či Ruby... (tzn. nebýt vůbec přesně stejný ale tvářit se, že jsem hrozně podobný.. to je nakonec u programovacích jazyků nejhorší zlo...)

(samozřejmě, ty nechápeš můj hlavní úmysl - tedy mít nějakou platformu, která se chová předvídatelně a u které vím, co se uvnitř ní děje, takže tobě se obecně spousta věcí špatně vysvětluje.... což sahá už k tomu, proč jsou "transparentní" Eiffelovka a příhradové železniční mosty celé té éry krásnější, než žižkovská věž či železobeton, ale ty prostě tyhle debaty a to co z nich filosoficky vyplývá nemáš rád a budeš je vždycky rozbíjet...)

"edited 2012-03-22" ... tzn. rozhodně by to celé stálo za přeměření v dnešní době, s dnešními verzemi těch interpreterů, apod. ..

na druhou stranu nesouhlasím s představou, že by na to mohly mít nějaký zásadně větší vliv optimalizace kompileru (no možná na efektivitu toho "realloc", ale stěží na efectivitu std string...). tohle je benchmark srovnávající efektivitu různých implementací stringových operací a jako takový smysl má (i kdyby ten konkrétní byl udělaný špatně).

jinak dal jsem si práci přečíst ty komentáře, a nejvíc nasraný jsou Javisti, pochopitelně :-) problém je, že u nich je k dispozici výběr různých abstrakcí a člověk si musí vybrat tu správnou. na druhou stranu - člověk, který prošel fází programování v C, asi bude jediný pořádně chápat, jaký je mezi těmi různými abstrakcemi rozdíl (pro nově příchozí to bude prostě "zjevený magický trik" - HAHAHA String je pomalý, použijte StringBuilder.... akorát že mezi tím _naučit se_, okoukat od někoho, jak se to dělá, a _chápat_ proč něco nějak je a přijít na to sám je prostě diametrální rozdíl... je fakt, že lidi co některé věci chápou, bývají obtížně zaměstnatelní a říditelní, proto produkční prostředí zřejmě vítá využití mírně cvičených opic, hrajících si s prefabrikovanými vyššími levely abstrakce bez hlubšího pochopení...)

jako vidět výkon interpretovaných jazyků srovnatelný s C++ je celkově pozoruhodné... a hlavně výkon toho Perlu. že má ta interpretace kódu tak malý overhead... C++ by teoreticky mělo mít obrovskou výhodu a dávat výsledek ekvivalentní C (pokud se použije správný nástroj... BTC z C i C++ jde samozřejmě regexpy volat taky, protože jsou POSIX a tedy standardní součást GNU libc... jak jinak by asi ty interpretery, napsané v C, ty regexpy volaly?).

že Perl předhoní C++ kód je protě úlet: vypadá to, že interpreter si může vygenerovat bytekód, který bude jen zanedbatelně pomalejší, než nativní kód (bytekód, tvořený přímo pointery na volané rutiny, tzn. něco jako Just-in-time kompilace?) - a že v tomhle bodě není výhoda nativního binární kódu tak velká. C vede díky tomu, že nutí programátora zcela přesně popsat svůj záměr s jen minimem abstrakce. Ostatní jazyky nabízí superpohodlí, které může a nemusí být implementované úměrně řešemému problému ("dělo na vrabce", aneb když si na krátkou vyjížďku vyjedete s tankem místo na kole... což byl právě příklad té chybné implementace v Javě)

v té debatě pod benchmarkem se ale nejvíc rozčilovali Javisti a strašně jim záleželo na tom ukázat, že nezaostávají za třídou Python/Perl/PHP (přitom ale v Pythonu jsou stringy immutable automaticky, takže stojí za zmínku, že test přesto ustojí). ale mě fakt daleko zajímavější přijde srovnávání C a C++ ...