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++ ...

REDGUY: no to je skutečně blbost, kopírovat do 8 znakového bufferu 8 znaků + ukončující nulu, to sis všiml dobře.

s tou Javou je možné, že to testovali někdy historicky.

HAHAHAHAHAHAHAHAHA.

A je to cim dal tim lepsi.

Jsem si rekl, ze si pro srovnani pustim tu Ceckovou verzi. A dobre jsem udelal, protoze, jak se rika, hilarity ensued 8))

V prvni rade, kod toho cloveka je plnej bugu. Zvlastni zes to nezminil, XChaosi, kdyz jsi psal jak se ti ten test libi, jak pouziva low-level funkce... cim to, zes nezminil pitomosti jako je tahle:

char *str=malloc(8);
strcpy(str,"abcdefgh");

A to je jen jedna z nekolika. Pokud to nekde fungovalo, tak jen nahodou.

Tak jsem to ofixoval, pustil... no, a bezi to DVAKRAT POMALEJC nez ta moje java.

HAHAHAHAHAHAHAHAHA.

Jak jsi to rikal, XChaosi? " zatímco Java a JavaScript jsou v tomhle směru totálně LOL. "? 8))))) No... "LOL" 8)

REDGUY: LOL, jsem idiot, mel jsem tam bugu. Po jejim opraveni je javova verze JEDENACTKRAT rychlejsi nez verze toho trumbery co psal ten clanek.

XCHAOS: samozřejmě obecné povědomí, že Java je pomalé monstrum, ale takovéhle srovnání a tedy i míra toho, jak je to v té Javě asi udělané špatně, stejně zovu překvapí... - ale prdlajs. Jestli neco prekvapi, tak to, ze porad jeste nekdo povazuje podobny nanobenchmarky za uzitecny. Jeste vic prekvapi, ze nekdo povazuje za uzitecny nanobenchmarky, ktery zjevne psal nekdo, kdo treba o ty Jave fakt moc netusi, protoze kdyz jsem ten kod opravil aby pouzival standardni StringBuffer misto String (fix na asi ctyri radky), tak to najednou bezelo trikrat rychlejc a zralo zlomecek pameti. Co ale neprekvapi je, ze XChaos, kterej o Jave vi kulovy, z takovejch nesmyslnejch nanobenchmarku vyvozuje hluboky zavery o tom, jak "je to v ni udelany spatne" 8))))

KOJA: tak mě se to naopak hodně líbí. na práci se stringama je zajímavé to, že většina vyšších jazyků k tomu nabízí spoustu operací, u kterých předstírá, že jsou triviální - ale samozřejmě nejsou.

KOJA: tak každý jazyk přece nabízí nějaké standardní způsoby práce se základními datovými typy/objekty, mezi které stringy zcela nepochybně patří. nepokládat implementaci stringové knihovny ve stdlib za základní feature jazyka je dost odvážné :-)

C++ nedopadlo tak zle - ale je velká otázka, zda nějakou abstrakci nad stringy jde vůbec naprogramovat úplně čistě (asi jde, když ten Perl dopadá tak dobře, jak dopadá).

jejich implementace v C trochu švindluje, protože právě pracuje se stringy jako s mutable a je to právě level, na kterém když se stringy pracují začátečníci, tak spolehlivě vyprodukují děravý kód (což je hlavní příčina všech bezpečnostních děr na bázi buffer overrunů, apod.).

jinak v Pythonu i Perlu používají volání regulární výraz, zatímco v Céčku primitivnější strstr() a pak přímo přepisují string, což třeba zrovna v tom Pythonu s immutable stringy z pricnipu nejde.. takže je to vlastně demonstrace toho, že low-level práce se stringy je rychlejší, než většina vyšších abstrakcí, která musí stále znovu dokola alokovat prostor pro výsledek stringové operace. Samozřejmě je ale otázka, jestli lidi fakt vést k tomu, aby pro modifikace stringů používali memcpy().. jenže když budu chtít mít jistotu, že něco poběží fakt rychle, tak to sám udělám přesně takhle...

Mě se ten test fakt líbí, ne proto, že C "porazilo" C++ (protože ta C implementace je až moc lowlevel a samozřejmě takhle nikdo nechceme programovat každodenní práci se stringy, zvlášť kdo to fakt nějaký čas z nějakého důvodu musel dělat) - ale spíš že C++, Perl, Python i PHP to víceméně dělají nějak "dobře", z hlediska rychlosti i spotřeby paměti, zatímco Java a JavaScript jsou v tomhle směru totálně LOL.

Zajímavé je, jak málo lidí si tohle uvědomuje, existuje samozřejmě obecné povědomí, že Java je pomalé monstrum, ale takovéhle srovnání a tedy i míra toho, jak je to v té Javě asi udělané špatně, stejně zovu překvapí...

Asi embedded systemy.

VITEX: .. zatímco obliba čistého assembleru roste, srsly? :-)

Programovací jazyk C má nejnižší oblíbenost v TIOBE za posledních 15 let - Root.cz
http://www.root.cz/zpravicky/programovaci-jazyk-c-ma-nejnizsi-skore-v-tiobe-za-poslednich-15-let/

XCHAOS: :) Ok