Srovnání rychlosti Javy a .NET s C++

Na blogu savara.us se jeho autor pustil do porovnání výkonnosti C++ a jazyků postavených nad virtuálním strojem a jako bonus přidal interpretované PHP a Ruby. K tomuto účelu použil 10 benchmarků. Výsledkem je zjištění, C++ je oproti Javě a .NET o cca 20 % rychlejší a také, že všechny testované jazyky jsou ve verzi pro Linux rychlejší než ve verzi pro Windows Vista. Bohužel není dostupná podrobnější informace o metodice testování ani o použitých strojích.

10.7.2009 10:03 | Kovář David | Zajímavý článek

Komentáře

[Cubic]

Opravdu si myslite, ze tohle zaslouzilo misto mezi zpravickama?

[maros]

Mozno zasa 1.april? Redakcia, spravicku treba malicko upravit:

Java je 5x rychlejsia ako C++. Ale to je nic, lebo Haskell je este 4x rychlejsi.

V tesnom zavese za Javou sa drzi Erlang, Smalltalk a Scheme, nasledovane statickymi jazykmi - podla poradia: Pascal, C++ a C.

Favorizovany Smalltalk prekvapil slabym umiestnenim, ked bol iba 3.5x rychlejsi ako C++.

Zdroj: shootout.alioth.debian.org/u32q/benchmark.php

[Heron]

To se tedy divím, že tato zprávička prošla. Článek s jedním nicneříkajícím obrázkem, bez metodiky a vysvětlení naměřených dat. Zprávička na toto sice upozorňuje, ale čekal bych něco trochu víc.

[cronin]

Z hladiska portalu je to skvela spravicka, nie? Bude flame, bude navstevnost, budu zobrazenia reklam. Pomala Java vs. rychle C++ - co viac si zelat?

[tuxmartin]

Jsou prazniny a tak jsou radi, ze se na webu aspon neco deje.

[Cecek]

Lepší než drátem do oka.

[JaMa]

Zdá se, že metodiku nezveřejnil ani vygooglovaný autor grafu.

 http://www.csharp-architect.com/post/2009/06/17/Reverseblade-publishes-my-performance-stats!.aspx

[Lukáš Zapletal]

Druhá zprávička Davide o dost horší než ta první.

[xkucf03]

Zprávička zní, jako by byla Java bůh ví jak pomalá, ale přitom je na druhém místě hned za C++ a za ní jsou všechny dotnety a síšárpy.

1. C++ GNU (Linux)
2. Java (Linux)
3. VC++ (Windows)
4. C# Mono (Linux)
5. C# .Net (Windows)
6. Java (Windows)
7. C# Mono (Windows)

Nicméně souhlasím s ostatními, že takovýto test bez metodiky a dalších podrobností nemá žádnou váhu. Autorova větička „Tu je pekný graf na prezentáciu“ zní trochu směšně – copak by někdo prezentoval cizí „výzkum“, který není absolutně ničím podložený, může být klidně smyšlený? Já bych tedy před tím plátnem stát nechtěl

[Koroptev]

Je krajne podezrele, ze c# nad monem v linuxu je rychlejsi nez nad .NETem ve Win

[microcz]

me zas pripadne zajimavi ten rozdil rychlosti javy ve win a lin

[Radek]

To je známý problém, o kterém jsem slyšel hodně mluvit, moje zkušenost jej potvrzuje, ale nikdy neviděl žádný benchmark. Docela by mně zajímalo, čím to je...

[peterh]

Su to rovnake VM? Napr. ten test na phoronixe mal pod linuxom server VM a pod vistou client.

 

[dad]

pan Ponkrac ted bloguje na savara.us?

 

[R]

To je sice pekne, ze niekto porovnal vypoctovy vykon, ale o tom to nie je. Je to aj o narocnosti na pamat, rychlosti GUI a rychlosti nabehu. Preto Java vychadza v takychto testoch teoreticky dobre, ale prakticky je kazdy program v Jave brutalne pomaly.

[Radek]

Nemáte k tomu nějaký benchmark? Slyšel jsem totiž, že výhoda Javy na serveru je v malé fragmentaci paměti. Nic přesnějšího však nevím.

[R]

Na serveri nemam s Javou ziadne skusenosti. Len na desktope. Vsetky desktopove programy v Jave, co som skusal, boli nepouzitelne pomale.

[mkoubik]

Vsetky desktopove programy v Jave, co som skusal, boli nepouzitelne pomale.

Kdyby existovalo AWT pro C++, tak to bude taky pomalý.

[JoHnY2]

+1 Na tom bude neco pravdy .

[Milan Jurik]

Jmenuje se to Bugster (bugtracking system), ma to Java GUI a rozhodne nepoznas, ze by to bylo pomale. Nepotrebujes to mit nainstalovane, nastartujes odkudkoliv a nezavisi to na omezenich http protokolu. Naopak treba napsat volumecontrol v Jave je kravina. A pritom oboji pochazi od te same firmy (mimochodem od te, co Javu stvorila).

Jmenuje se to OpenDS, je to LDAP server (takze ne desktopova aplikace, ac ma pekny konfiguracni interface) a je brutalne rychly.

Takze to nebude o jazyce.

[Luk]

jEdit také není vůbec pomalý, ostatně i Netbeans IDE běhá docela rychle (starší verze bývaly rychlejší, ale i šestkové ujdou).

[korotev]

asi mate jina meritka, ja napr. kdysi na (tehdy) novem stroji s AMD K6-2/450MHz videl behat Ofisy 97 na win98; bez ohledu na nekvalitu (az nepouzitelnost) toho OS (coz ovsem pro cokoli od NT neplati), vsechno, co jsem od te doby videl, je pomalejsi

jedit jsem zkousel a krom toho, ze je pomalej, hnusne vypada

[xkucf03]

Co je na něm hnusného?

S rychlostí nabíhání nemám problém – např. nativní Kate nabíhá rychleji, ale jEdit zase načítá řadu pluginů. Rychlost startu stejně není tak důležitá (člověk ho spouští párkrát denně, nebo jednou za několik dní), mnohem důležitější je, co ten program umí – např. přes BeanShell spouštět javový kód nad otevřeným dokumentem a spoustu dalších užitečných věcí.

[xkucf03]

Příloha:

• jedit.png (170305 bytů)

Obrazovka jEditu. Co se ti na ní nelíbí?

[alblaho]

Hnusné písmo bez AA. Ve Windows to vypadalo snesitelně, na Linuxu u mě jEdit nemá šanci, protože ta písmekna vypadají divně (s i bez AA).

[Filip Jirsák]

Písmo i AA si samozřejmě můžete zvolit, taková je ta Java vychytaná. Pravda je, že křišťálová koule tam ještě nefunguje úplně dobře, takže ještě není schopna zareagovat na okamžik, kdy se dělá screenshot pro Alblaha příslušnou úpravou AA tak, že se přizpůsobí Alblahovu monitoru.

[Ladicek]

S tímhle konkrétním obrázkem může být i jednodušší problém: při prohlížení v maximalizovaném okně Firefoxu na 1280x1024 obrazovce ho prohlížeč zmenší na takovou velikost, že člověk na pohled nepozná, že je vůbec zmenšen, ale písmo přitom vypadá strašlivě ohavně

Ale jinak v zásadě souhlasím se zde obvyklými názory na javovské GUI. Jsem javista, ale javovské GUI podle mě pořád stojí více méně za vyližprdel, a dosáhnout s ním solidních výsledků (jEdit, IntelliJ IDEA), na to musí být člověk opravdový Swing expert. Což já nejsem, takže můj názor pochopitelně může být úplně mimo.

[Filip Jirsák]

V době uvedení byla architektura Swingu špička, nevím o tom, že by v té době existovala srovnatelná GUI knihovna třeba pro C++. Teď už možná .NET nebo Qt bude na obdobné úrovni, to nedokážu posoudit, protože tyhle knihovny neznám, ale GUI se pořád často píše v architektonicky daleko horších knihovnách, než je Swing. MVC samozřejmě není vynález Swingu, ale Smalltalku, ale pokud vím, Swing byl první, který tuhle technologii umožnil používat v nějakém široce používaném jazyce. Druhá věc je, že spousta lidí stále neumí MVC používat a snaží se Swing používat splácáním modelu a případně i ovladače do GUI komponent, pak jim Swing opravdu asi hází klacky pod nohy – to nedokážu moc posoudit, protože já zase neumím moc programovat s tím, když nemám GUI od modelu oddělené.

[alblaho]

Tak zaprvé, fonty v Javě se renderují hnusně bez ohledu na AA. Nebo když se AA zapne, tak je to aspoň nesnesitelně pomalé. To platí pro Linux, ve Win je situace o dost lepší a jEdit jsem tam s radostí používal. SWT (Eclipse) nemá s fonty problém.

Nevím, co říct k "architektuře" Swingu. Myslím, že API není ani špatné, ani výjimečně dobré. A jestli bylo první? Například obal nad Win32 co byl v Delphi/C++Builderu nebyl vůbec špatný. Čisté GTK je docela nepříjemné, ale GTKmm/PyGTK se používá docela dobře.

Já ve SWINGu zrovna teď dělám. Není problém to naprogramovat, ale výsledkem je dost pomalá a hnusně vypadající sračka. Skiny a "nativní" vzhledy jsou takové polovičaté. A udělat pořádné Drag&Drop v java5, to tedy není zas taková sranda (než člověk zjistí které všechny potrhlé listenery z dob AWT musí implementovat, tak pomalu zešediví).

Swing je zkrátka moc obecný, moc velký. Díky tomu vypadá hnusně a je pomalý. A taky mi začíná vadit spousta API-balastu ze starých časů. K některým věcem jsou snad 4 generace rozhraní a je to dost nepřehledné. Ale chápu, že je to menší zlo, než rozbít kompatibilitu.

[xkucf03]

Zkus si spustit tuhle aplikaci:

javaws http://frantovo.cz/projekty/SuperPostak/jws/launch.jnlp

Nativní vzhled sice nemá, ale IMHO se o ní nedá říct, že by vypadala hnusně a i s rychlostí jsem spokojený.

[Mraky]

9 sekund spouštění Java Web Start, pak stahování, několik otázek na zabezpečení (proč?) a 5 sekund spouštění aplikace. Vypadá divně - asi tím, že nevypadá nativně, takže ani nelze s ničím srovnat.

[Filip Jirsák]

Jakou verzi JRE používáte? U mne se splashscreen JavaWS zobrazoval 4 – 5 sekund, a během té doby se už stahuje JNLP soubor. Pak stahování, 2 potvrzení certifikátů (1 selfsigned a expirovaný, druhý podepsaný důvěryhodnou CA ale expirovaný), po odkliknutí druhého certifikátu se okno aplikace objevilo po 1 sekundě. Při druhém spuštění, kdy jsou už soubory v lokální cache, trvá start od spuštění příkazu do 1. dotazu na certifikát 3 sekundy.

[xkucf03]

 

9 sekund spouštění Java Web Start, pak stahování

 

Já mám cca po 6* vteřinách naběhlou aplikaci (od zadání příkazu v konsoli). Pravda, knihovny jsou už načtené v keši. Poprvé se stáhnout musí a s tím Java Web Start nic nenadělá – jsou tam ovladače pro několik DB a to se chvilku z Netu tahá.

 

několik otázek na zabezpečení (proč?)

Proč?? Aby to nebylo jako u Windows a ActivX a lidi neměli zavšivené počítače kdejakým svinstvem. Java také dokáže velice pěkně řídit oprávnění aplikace (např. ji lze omezit práva tak, aby mohla přistupovat pouze jen k souborům, které uživatel vybral v dialogu pro otevření/uložení souboru).

 

 

Vypadá divně - asi tím, že nevypadá nativně, takže ani nelze s ničím srovnat.

Spousta nativních aplikací má nejednotný vzhled a to i když pocházejí od jednoho výrobce (Microsoft je tím pověstný), přesto jde hodnotit jejich vzhled, zda se nám líbí nebo ne, zda je praktický… Já tenhle LaF hodnotím dobře, líbí se mi, ale nic ti nebrání, použít jiný Vzhled a Pocit (Look and Feel).

 

*) šest trval první strart, další starty byly už za tři vteřiny (pravděpodobně díky diskové mezipaměti).

[alblaho]

Nevypadá to vyloženě hnusně, ale trochu divně. Nemá to AA fonty. Ale hlavně, ta rozklikávátka se rozbalují-sbalují tak 3 vteřiny, hrůza.

Momentálně tu mám jen Javu 5, jinak Intel Core Duo 1.6 GHz, Ubuntu Intrepid.

[Filip Jirsák]

Nemá to AA fonty.

V Javě 1.5 od Sunu je pokud vím AA ve výchozím nastavení vypnutý, jde zapnout z příkazové řádky nebo z aplikace.

Ale hlavně, ta rozklikávátka se rozbalují-sbalují tak 3 vteřiny, hrůza.

u mne je to plynulá animace. Asi mám fakt Javu nějak špatně nainstalovanou a mám jí zrychlenou

[xkucf03]

$ java -version
java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02, mixed mode)

Taky dvou jádro a Ubuntu Jaunty. Rozbalování a sbalování je úplně plynulé. Ale taky jsem to už na nějakém počítači viděl trochu trhané.

Nechceš zkusit aktuální verzi Javy, ať víme, čím to je?

[tuxmartin]

martin@martin:~$ java -version
java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Java HotSpot(TM) Client VM (build 11.3-b02, mixed mode, sharing)
martin@martin:~$

Celeron 1,86GHz Ubuntu Jaunty a taky mi to jde plynule.

[alblaho]

Tak jsem to zkusil pod šestkou (na stejném počítači) a chová se to i vypadá _naprosto_ stejně. To ale bude nějaká buga, protože ostatní javovské programy mi fungují normálně. Btw, během toho rozbalování to vytíží procesor na 100%.

[Filip Jirsák]

Tak zaprvé, fonty v Javě se renderují hnusně bez ohledu na AA. Nebo když se AA zapne, tak je to aspoň nesnesitelně pomalé.

Já takovou zkušenost (ani z Linuxu) nemám, takže mám opravdu problém uvěřit tomu, že je problém v Javě a Swingu. Software se může shodou nějakých okolností, náhod a špatné konfigurace zpomalit, ale ne zrychlit.

Nevím, co říct k "architektuře" Swingu. Myslím, že API není ani špatné, ani výjimečně dobré. A jestli bylo první? Například obal nad Win32 co byl v Delphi/C++Builderu nebyl vůbec špatný.

Jenže ono Borlandí VCL jsou právě GUI komponenty „vše v jednom“, kdežto Swing je postaven na architektuře model–view–controller. A v tom je propastný rozdíl.

Já ve SWINGu zrovna teď dělám. Není problém to naprogramovat, ale výsledkem je dost pomalá a hnusně vypadající sračka. Skiny a "nativní" vzhledy jsou takové polovičaté.

S tou pomalostí opravdu nemám zkušenost (tedy až na některé špatně napsané aplikace), jako L&F používám JGoodies Looks a se vzhledem jsem spokojen (je o dost lepší, než spousta nativních aplikací, které bych ale asi mohl vylepšit použitím nějakého jiného než standardního tématu). Na dobře udělaných L&F nic polovičatého nevidím, nativní vzhledy mne nezajímají, protože jeden L&F je dneska utopie (funguje možná na MacOS). Vemte si třeba jen internetové prohlížeče, na Linuxu s KDE bude nativní jen Konqueror, jinde (na Linuxu i Windows) budou všechny prohlížeče mít vzhled odlišný od základního systému – Firefox, Opera, Google Chrome i MSIE. Nebo na těch slavných Windows s jednotným GUI – další dva „vlajkové“ produkty MS, MS Office a MSIE – oba dva mají odlišný vzhled od nativního operačního systému, a ještě každý jinak. Takže když mám v systému 3 druhy aplikací – GTK, Qt a Swing, a k tomu různé sólokapry jako Firefox nebo různé mutimediální příšery, opravdu mne zrovna Swing netrápí.

A udělat pořádné Drag&Drop v java5, to tedy není zas taková sranda (než člověk zjistí které všechny potrhlé listenery z dob AWT musí implementovat, tak pomalu zešediví).

To je pravda, ale zase když už se to člověk dobře naučí, nedělá mu problém to používat.

Swing je zkrátka moc obecný, moc velký. Díky tomu vypadá hnusně a je pomalý. A taky mi začíná vadit spousta API-balastu ze starých časů. K některým věcem jsou snad 4 generace rozhraní a je to dost nepřehledné. Ale chápu, že je to menší zlo, než rozbít kompatibilitu.

Mně ta obecnost vyhovuje, protože díky tomu není nutné tam něco násilím dobastlovat, ale můžete to udělat správně rovnou prostředky Swingu. Ale je pravda, že na to jak je to velká a obecná knihovna, chybí na ní vystavené nějaké zjednodušující obalující knihovny, respektive implementace. Knihovny pro binding jsou pár let staré, snadno použitelné layoutmanažery jen o něco starší, pořádná validační knihovna napojitelná na model pokud vím ještě není vůbec… A návodů, jak se Swingem pracovat správně také moc není, navíc je často problém v jejich neaktuálnosti. Ale aspoň ta jednoduchá obalující knihovna snad s JavaFX bude k dispozici, a zbytek se snad časem taky vyřeší – Swing podle mne předběhl dobu a teprve teď se začíná ukazovat, v čem je jeho síla.

[default]

Ani na tom Mac OS X to není ono. Třeba takový QuickTime používá plastická okna. Už si nepamatuji, jak se to přesně jmenuje, ale při vytváření NSWindow to jde nastavit. V oficiální dokumentaci je tuším napsáno, že se to používat nemá. A sám Apple to vesele dělá.

Další příklad jsou produkty Adobe. Mají vlastní panely nástrojů. Adobe Bridge — jediný, co používá systémovýho, jsou ty tři puntíky na ovládání okna.

Mám tu jeden stroj s Tigerem. Nový iTunes tam nezapadají, protože používají barevné schéma z Leopardu. Inu, proč ne, že?

Ale já to osobně vůbec neřeším. Je mi to jedno. Zkus si udělat Mayu ve stylu MS Wordu. To bychom doteď neměli jediný 3D obrázek natož scénu. Nebo naopak: udělej MS Word ve stylu Mayi. Popravdě, to by mi vyhovovalo. Nikdo by s tím neuměl a tudíž by to nikdo nepoužíval.

Co se Swingu týče, chybí mi generika v TableModel a tak podobně. Ale na dev.java.net se dá najít projekt, který generika doplňuje. Prý to snad bude v JDK7. Uvidíme. Dále se mi líbí Swing Application Framework, který je řízený anotacemi. Dělá se s tím velmi pohodlně a rychle… Ale moc jsem v tom toho neudělal, takže to třeba zandavá na jinejch frontách.

[Filip Jirsák]

Ani na tom Mac OS X to není ono.

Říkal jsem si, že se určitě najdou firmy, které svoje GUI považují za natolik úžasné, že kam se na ně hrabe nějaký Apple. No a že k nim patří i Apple, to mne ani nepřekvapuje…

Co se Swingu týče, chybí mi generika v TableModel a tak podobně. Ale na dev.java.net se dá najít projekt, který generika doplňuje. Prý to snad bude v JDK7. Uvidíme.

No jo, když si Sun teprve u Javy 6 po dlouhé době všiml, že Swing taky ještě existuje… Nedalo se čekat, že spraví hned vše najednou. Snad v Javě 7 spraví tohle a nechají být na pokoji jazyk jako takový.

[alblaho]

No já bych to shrnul asi tak, že Swing aplikace nemusí být až tak ošklivé a zas tak pomalé a programuje se v tom docela dobře. Ale dost často jsou o něco pomalejší a o něco míň hezké než nativní toolkit (Gtk, Qt).

Všechny ty moje výrazy typu "sračka" je potřeba brát s mírnou rezevou. Ale jako uživatel se javovským desktopovým aplikacím vyhýbám, což třeba neplatí o Mono-Gtk# nebo Pythonu-Gtk.

[J. M.]

Kde korotev píše o rychlosti nabíhání? Píše o tom, že ten program je pomalý, ne, že pomalu nabíhá. Někteří lidé mají rychlost nabíhání jako synonymum pro rychlost, ani netuší, že program může být rychlý nebo pomalý v něčem jiném...

Já jsem jEdit přestal používat přesně z toho důvodu. Je příšerně pomalý. Samotná editace v něm ani tak ne, ale každý aspoň trochu větší soubor jej strašně zpomalí při rolování, výběru textu atd. A to jak na Linuxu, tak na Windows (kde to je samozřejmě rychlejší než na Linuxu, ale pořád pomalejší než cokoli jiného na Windows).

[Filip Jirsák]

A z toho odvozujete, že je pomalá JVM? Já už jsem viděl tolik editorů napsaných v C nebo C++, které se při editaci velkého souboru zpomalily nebo dokonce úplně vytuhly…

[J. M.]

Ne, z toho odvozuji to, co tady pořád píšou všichni, kdo kritizují rychlost Javy – má pomalé GUI. Vykreslování, překreslování, renderování. Zkrátka cokoli, co něco zobrazuje na obrazovku, reaguje na uživatele. Např. ty dialogy, to, že ta okna jEditu se vůbec nedokážou plynule překreslovat při změně velikosti (ani na Linuxu, ani na Windows, kde je jinak plynulé překreslování, na rozdíl od Linuxu, naprostou samozřejmostí). To, že s delším dokumentem nedokáže plynule rolovat obsah okna posuvníkem. Atd. atd. To není o rychlosti JVM nebo rychlosti programu, ale rychlosti grafiky, GUI.

Java a JVM můžou být samy o sobě seberychlejší, ale jako uživateli desktopových aplikací je mi to k ničemu, protože to javové GUI je prostě neúnosně ultralíné.

(Ale když už tu byla řeč o rychlosti startu, tak samozřejmě i to, že mi javové programy startují několikanásobně pomaleji než běžné programy, mi taky dobrou náladu nepřidá.)

[Filip Jirsák]

Vykreslování, překreslování, renderování. Zkrátka cokoli, co něco zobrazuje na obrazovku, reaguje na uživatele. Např. ty dialogy, to, že ta okna jEditu se vůbec nedokážou plynule překreslovat při změně velikosti (ani na Linuxu, ani na Windows, kde je jinak plynulé překreslování, na rozdíl od Linuxu, naprostou samozřejmostí).

Pak to ale máte nějaké rozbité. Já nic takového nepozoruju.

To, že s delším dokumentem nedokáže plynule rolovat obsah okna posuvníkem. Atd. atd. To není o rychlosti JVM nebo rychlosti programu, ale rychlosti grafiky, GUI.

Ne, to není o rychlosti GUI, Javy ani ničeho jiného, to je pouze ukázka toho, že daná aplikace nebyla naprogramována tak, aby uměla s velkými dokumenty dobře zacházet. Je mnohem jednodušší editor naprogramovat tak, že se celý dokument nahraje do paměti a pracuje se s celým dokumentem najednou. Jenže při takovém způsobu samozřejmě začne editor u větších dokumentů ztrácet dech. Ale s GUI nebo vykreslováním to nemá vůbec nic společného.

[J. M.]

Pak to ale máte nějaké rozbité.

Pak to mají rozbité všichni, kdo tady celé roiky o Javě píšou totéž. To je ábíčkovský evergreen. Stejně jako slovní spojení „nějaké rozbité“, univerzální reakce těch, kteří to zpochybňují. To, že to je rozbité na celé paletě počítačů, grafických karet, ovladačů a dokonce i operačních systémů, je asi jenom shoda náhod.

Ale s GUI nebo vykreslováním to nemá vůbec nic společného.

Samozřejmě, že má. Tohle je tak strašně naivní pohled těch postarších low-level programátorů, kteří neustále vliv GUI bagatelizují. To je strašně staromódní, překonaný pohled na věc, který platil v 80. letech, kdy skutečně záleželo především na těch vlastních algoritmech v programu použitých, a GUI bylo zanedbatelné, ale dnes, v 21. století, to je hodně mimo.

Stačí si prohlídnout tytéž programy ve verzích, kdy třeba přešly z GTK+ 1.x na GTK+ 2.x nebo z Qt 3.x na Qt 4.x, stejně tak jako na rozdíl jak rychlé rolování v témže programu je pod Linuxem/X11 a pod Windows. Rychlost rolování je dnes zásadním, rozhodujícím způsobem ovlivněna grafickým frameworkem, nad kterým běží, vším od grafického ovladače, grafického/okenního subsystému, konfigurace (použitá hardwarová akcelerace atd.) až po použitý toolkit. Což koneckonců dokazují i benchmarky, které jasně ukazují velké rozdíly při rychlosti rolování (a řadě jiných věcí) při použití různých konfigurací. Jeden příklad z mnoha: u mě je třeba Opera ve verzi s Qt 4 při rolování asi tak 10x-100x pomalejší než přesně tatáž verze Opery zkompilovaná s Qt 3.

[Filip Jirsák]

Pak to mají rozbité všichni, kdo tady celé roiky o Javě píšou totéž.

Přičemž z většiny z nich nakonec vypadne, že Javovský program spouštěli naposledy v roce 1993 a byl to nějaký Applet.

Ale s GUI nebo vykreslováním to nemá vůbec nic společného.

Samozřejmě, že má. Tohle je tak strašně naivní pohled těch postarších low-level programátorů, kteří neustále vliv GUI bagatelizují. To je strašně staromódní, překonaný pohled na věc, který platil v 80. letech, kdy skutečně záleželo především na těch vlastních algoritmech v programu použitých, a GUI bylo zanedbatelné, ale dnes, v 21. století, to je hodně mimo.

To děláte schválně, nebo opravdu větu „to nemá s GUI nebo vykreslováním nic společného“ čtete jako „rychlost GUI není pro uživatele podstatná“?

Zkusíme si dát malý příklad. Editor zpracuje krátký dokument za 0,1 sekundu a zobrazí jej za 0,05 sekundy. Dlouhý dokument zpracovává 20 sekund a zobrazí jej za 0,05 sekundy. Je to známka pomalého GUI? Taková malá nápověda: vykresluje se jenom to, co je vidět na obrazovce. Pokud vám s dlouhým dokumentem neroste i obrazovka, vykresluje se pořád stejně velká plocha. Takže pokud je něco rychlé nebo pomalé v závislosti na velikosti dokumentu, není to rychlostí zobrazování, ale rychlostí vnitřního zpracování dokumentu.

[xkucf03]

 

To je ábíčkovský evergreen.

Spíš laciná póza – hodně lidí si rádo kopne do Javy (s podtextem, že „opravdoví programátoři“ přece píší v jazyce XYZ).

 

 

[Luk]

Já už jsem viděl tolik editorů napsaných v C nebo C++, které se při editaci velkého souboru zpomalily nebo dokonce úplně vytuhly…

Tohle mi dělá KWrite (a Kate) v KDE 4. Když je soubor velký, doba reakce na cokoliv (zejména manipulace s výběrem) je třeba i desítky vteřin. Naopak jEdit se s velkými soubory (desítky MB) vyrovná zcela bezproblémově, jen u těch extrémně velkých někdy selže otevření kvůli OutOfMemoryError (nedostatek paměti pro haldu - lze ovšem vyřešit změnou parametrů).

[xkucf03]

ok, o rychlosti nabíhání psal Luk, ne koroptev.

Co se týče rychlosti práce – teď jsem potřeboval v textu nahradit 'apostrof' za ''dva apostrofy'' v souboru s asi 250 řádky. Nejdřív jsem to dělal v pgAdminovi III, což je nativní C/C++ aplikace. Když jsem mu tuto jednoduchou úlohu zadal, začal vytěžovat procesor na 99-100% (ještě že mám druhé jádro) a trvalo mu to tak dlouho, že jsem ho raději killnul. Zatímco „pomalý“ jEdit si s tímto úkolem poradil hned a spolehlivě.

Jasně, asi se jedná o nějakou chybu v pgAdminovi, protože tohle není normální (nativní Kate zvládne tenhle úkol taky rychle a spolehlivě), ale já chci v první řadě spolehlivou aplikaci – až když je spolehlivá a dělá to, co chci, má cenu řešit nějaké optimalizace a rychlost – rychlý, ale chybový program je na nic. Pokud má někdo problémy s C/C++ (což se ani nedivím, je snadnější tam dělat chyby), tak ať píše radši v té Javě – celkový výsledek bude lepší – aplikace možná nebude superrychlá, ale aspoň bude dělat to, co od ní uživatel čeká.

[Luk]

ok, o rychlosti nabíhání psal Luk, ne koroptev.

To jsem nepsal já, ale to je jedno. jEdit nabíhá déle než jiné editory (záleží na počtu pluginů - například já jich používám docela hodně), ale pak už je práce s ním velmi svižná.

Zatímco „pomalý“ jEdit si s tímto úkolem poradil hned a spolehlivě.

Operace typu "náhrada" používám velmi často, mnohdy i s použitím výrazů. Nikdy jsem se nesetkal s tím, že by to jEditu trvalo pozorovatelně dlouho (tím myslím, že bych zaregistroval trvání, prostě to proběhne okamžitě).

[default]

jEdit nabíhá déle než jiné editory (záleží na počtu pluginů - například já jich používám docela hodně), ale pak už je práce s ním velmi svižná.

jEdit mi nabíhá rychleji než Firefox 3.5 a je i rychlejší při vlastní práci. Někdo tu psal, že změna velikosti okýnek mu zlobí. Že to nějak divně překresluje, či co. Ano, to je pravda. Ale nikoli na OS X. Kde je problém, to snad každému dojde.

[koroptev]

proboha a to je co? rychleji nez FF ...    nejaky cerny humor?

mozna ze jeden z duvodu, proc je TC ve Win tak oblibeny je i ten rychle prohlizeni souboru pres F3, jsou to opravdu malinke zlomky vteriny, ktere to trva po domacknuti, pro me pod hranici vnimani, tak tohle znamena rychle a v r. 2009 na dvoujadrovem stroji s 8GB RAM bych to rad videl vsude he, to je co

[Milan Jurik]

A co teprve editor MAT pod Atari TOS 2.6 na mem Atari MegaSTE s M68000 na 16MHz. To je teprve rychlost, kdyz se startuje z interniho SCSI disku. A to GUI, jedna basen, zadny sajrajt.

[Lojza]

 Tohle je teda ubohost (a to jsem C++ programátor).

Tak schválně: Srovnání rychlosti dokončení zadaného úkolu:

 Task 1: 1. Patrol 2. Zetor 3. Ferrari

Task 2: 1. Zetor 2. Patrol 3. Ferrari

 

No schválně - co byste si vzali na cestu z Prahy do Mnichova?

 

[kolemjdouci]

po poli anebo po dalnici?

[carnero]

Já bych si vzal Patrol protože mi stojí před domem, umím s ním jezdit a dobře ho znám ;) A i když Zetor nějaký blíže neurčený task zvládl rychleji, pořád je lepší když zvolím to co umím ovládat ač je to o trochu pomalejší (na druhém místě, druhý task) než to co je sice rychlejší ale já nemám páru, co s tím a než se to naučím dostatečně dobře, uplyne ještě hodně nafty.

[belisarivs]

Tys asi nepochopil pointu.

On se pozastavuje nad tim, ze to zhodnoceni je o nicem. Navic, ze je neco na druhem miste, neznamena to, ze to neni o mnoho horsi.

[Mti.]

4. vlak Bych to nemusel ridit ja.
Dokud se tu (kdekoliv) budete jak mali ogari hadat, kdo ho ma vetsiho, tak se stejne nedoberete niceho kloudneho. Vzdycky to nakonec bude na p..u. :-/

Benchmark programovacich jazyku narazi vzdy na to, ze se toho bud ujme zaujata osoba, co zvoli podminky testu aby vyznely tak jak potrebuje (nekdo tomu rika reklama/marketing) a nebo nezaujata, ale nekompetentni, ktera sice zacne s mozna dobrou virou si neco dokazat, ale zbabre to nesmyslnymi podminkami pro nektere ucastniky testu. (vzpominam jeden, kde v rekurzivni fuknci meli u c hromadu malloc/free s kazdou iteraci. Cckovy kod to ponekud znevyhodnilo, kdezto java na tom "straaasne" vydelala... no a pak se v diskusich rozhori 2 napul nezavisle brutalni flame, jak je ten jazyk na pytel a ze autor kodu je daky cyp :) )

Se mi to keca, kdyz posledni dobou delam jen na AVRku, kde kdyz se mi nelibi, co za mne "chce" udelat gcc, tak ten kus predelam do assembleru... jenze to je 8bit, kde je dane, na cem kod pobezi a na omezeny vykon/misto jeden narazi daleko driv :-/ A asi tady bude nekde ta zrada. Ne uplne kompilovane jazyky Vam sice "neuhnou" a tahnou ssebou veliky balik, ktery v ramce musi lezet taky ale zase nabizi jiste pohodli. A kazdy si za sebe musi rozhodnout (neni-li mu rozhodnuto tvrdou rukou zamestnavatele :( ) co uprednostni. Tahat cele mono do distribuce jen quli nejake blbosti, za kterou je i nahrada?

[Jan Včelák]

Nechápu smysl propojení těch bodů v tom grafu. Když už graf, tak bych čekal sloupce. Tohle je minimálně nepřehledné.

[mkoubik]

C++ je oproti Javě a .NET

Co je to za programovací jazyk, ten .NET? Už jsem o něm několikrát slyšel, ale furt ne a ne sehnat kompilátor.

[dayvee]

+1

[Ladicek]

Mínus milión, zprávička ani odkazovaný "článek" žádný jazyk .NET nezmiňují. Jako příležitostný puntičkář bych měl být tolerantní k podobným nesmyslům, ale tady je to spíš hledání smítka na hnoji…

[mkoubik]

To sice nezmiňuje, ale zní to jako "jablko je mnohem kyselejší, než banán a flotila na manévrech v jižním Pacifiku."

[Ladicek]

Tomu říkám kreativní čtení

[kozzi]

rekl bych ze je namysli C# :D

[Roger]

CIL?

[Messa]

Hm, raději bych měřil rychlost nějaké konkrétní implementace překladače/interpreteru jazyka na nějakém konkrétním příkladě, než rychlost jazyka.

[deda.jabko]

nějaké konkrétní implementace překladače/interpreteru jazyka na nějakém konkrétním příkladě

ono se to snadno rekne na nejakem konkretnim priklade... ale jak takove priklady vybrat... protoze, pak prijde nekdo (treba nejaky pan pankrac) a rekne ze ty priklady psal clovek, ktery v danem jazyce neumi programovat...

nebo dalsi peknym pristupem, jak se da shodit kazdy benchmark, je oznacit jej za ,,toy-example'' a kdyz je to neco slozitejsiho tak je dobre prohlasit, ze je spatna metodika a dane testovani neodpovida realnym podminkam...

[Filip Jirsák]

rekne ze ty priklady psal clovek, ktery v danem jazyce neumi programovat...

Což je bohužel velmi často pravda. Ale přece nemusí všechny příklady psát jeden člověk, dokonce i jeden příklad může být kolektivní práce.

Ale porovnávat rychlost má smysl opravdu jen u běhu na skutečném či virtuálním stroji. Porovnání jazyků by spíš znamenalo porovnávat, jak rychle půjde v nějakém jazyce něco napsat, jak snadné bude kód refaktorovat, jak je srozumitelný atd. A to by se pak spíš hodnotil jazyk + vývojové nástroje.

[deda.jabko]

Což je bohužel velmi často pravda. Ale přece nemusí všechny příklady psát jeden člověk, dokonce i jeden příklad může být kolektivní práce.

to ale nic neresi... predstavte si situaci... pokud chcete porovnat rychlost dvou programu napsanych v jazycich A a B, muzou nastat dve situace... programy jsou si vicemene ekvivalentni... v takovem pripade prijde rejpal, a rekne, ze program v jazyce A neni napsan nejoptimalneji. v druhem pripade, jsou programy v jazycich A i B napsany nejoptimalneji a tak prijde rejpal a bude remcat, ze programy nejsou ekvivalentni, a ze srovnavate nesrovnatelne....

Ale porovnávat rychlost má smysl opravdu jen u běhu na skutečném či virtuálním stroji. Porovnání jazyků by spíš znamenalo porovnávat, jak rychle půjde v nějakém jazyce něco napsat, jak snadné bude kód refaktorovat, jak je srozumitelný atd.

to si veci prilis idealizujete... ona totiz spousta lidi (i odborniku na programovaci jazyky) s neuveritelnou radosti masturbuje nad tim jak je X rychlejsi nez Y a honi se za milisekundama... a chce proste videt, ze ten jejich jazyk je ten nej...

...a nikomu pritom nevadi, ze miliony programatoru pisou programy v takovych vecech jako je PHP a Python...

[Filip Jirsák]

to ale nic neresi... predstavte si situaci... pokud chcete porovnat rychlost dvou programu napsanych v jazycich A a B, muzou nastat dve situace... programy jsou si vicemene ekvivalentni... v takovem pripade prijde rejpal, a rekne, ze program v jazyce A neni napsan nejoptimalneji. v druhem pripade, jsou programy v jazycich A i B napsany nejoptimalneji a tak prijde rejpal a bude remcat, ze programy nejsou ekvivalentni, a ze srovnavate nesrovnatelne....

Pokud jsou programy optimální a vyhovují zadání, považoval bych je pro účely srovnání za ekvivalentní.

[deda.jabko]

Pokud jsou programy optimální a vyhovují zadání, považoval bych je pro účely srovnání za ekvivalentní.

tak si vezme treba priklad: srovnejte rychlost vypoctu pruniku mnozin v jazycich treba C a LISP. programator v C, zvoli jako nejoptimalnejsi reprezentaci posloupnost bitu a provede nad nimi operaci AND... programator v LISPu zvoli jako nejoptimalnejsi reprezentaci spojove seznamy a bude nad nimi delat slevani...

oba programy splnuji zadani, nicmene o jejich ekvivalentnosti se da s uspechem pochybovat

[koroptev]

a to si ten programator v lispu neni vedom te rezie? nebo nevi, ze zavodi?

to je pekna demagogie

preci zadam vstup, znam pozadovany vystup a uvnitr at si to programavor  v jazyku A i B poresi nejlepe, jak umi, tou nejoptimalnejsi cestou, kterou muze

a pak se da bavit - napr.: je to rychlostne vyrovnane, ale v lispu to vypada hrozne, protoze to znasilnuje jazyk (a lisp asi pro rychlou implementaci one ulohy nebude nejvhodnejsi), nebo: c je o 5% rychlejsi, ale 10x vic radek kodu ..

 

[deda.jabko]

a to si ten programator v lispu neni vedom te rezie? nebo nevi, ze zavodi?

a co kdyz takove reseni vyjde jako nejoptimalnejsi?

to je pekna demagogie

jaka demagogie?

[koroptev]

demagogie: nu prispevek znel trochu jako "kdyz technologie v pozadi implementace ruznych jazyku pouzite pro reseni stejneho problemu jsou ruzne, pak nema smysl srovnavat rychlost programu v tech ruznych implementacich resicich onen stejny problem", a to samozrejme smysl ma, proc by me ta technologie mela zajimat nekoho, kdo to chce mit hlavne rychle

 

[Filip Jirsák]

Já jsem ale nepsal jen „vyhovují zadání“, ale také „jsou optimální“. Takže ten, kdo píše implementaci v Lispu, se podívá na zdroják v C, praští se do čela, řekne „aha“ a přepíše implementaci v Lispu také na AND nad posloupností bitů. Pokud bude tato implementace rychlejší (pokud kritériem hodnocení je rychlost), než slévání spojových seznamů, pak je zřejmé, že předchozí (pomalejší) varianta nemohla být optimální.

[deda.jabko]

proboha! to byl jenom hypoteticky priklad!

Takže ten, kdo píše implementaci v Lispu, se podívá na zdroják v C, praští se do čela, řekne „aha“ a přepíše implementaci v Lispu také na AND nad posloupností bitů. Pokud bude tato implementace rychlejší (pokud kritériem hodnocení je rychlost), než slévání spojových seznamů, pak je zřejmé, že předchozí (pomalejší) varianta nemohla být optimální.

a co kdyz mu to nevyjde? co kdyz v lispu budou rychlejsi seznamy ... v cecku zase bitove operace? co pak?

jinak ten problem neni zase tak uplne hypoteticky... pred casem jsem s timto problemem (i kdyz ve slozitejsi verzi) osobne setkal...

[Filip Jirsák]

a co kdyz mu to nevyjde? co kdyz v lispu budou rychlejsi seznamy ... v cecku zase bitove operace? co pak?

Pak se vrátí k původnímu řešení se seznamy, protože to je optimální řešení.

proboha! to byl jenom hypoteticky priklad!

Ale i na tom hypotetickém příkladu je vidět, proč jsem jako nutnou podmínku požadoval i optimálnost řešení. A i když těch příkladů vymyslíte nekonečně mnoho, pořád půjdou rozdělit na dvě kategorie – buď budete znát nějaké lepší řešení, pak to současné ale není optimální, nebo v případě všech porovnávaných jazyků máte ten nejlepší možný kód, a pak ty příklady můžeme považovat za ekvivalentní (samozřejmě při dodržení druhé podmínky, tedy stejných výstupů). Samozřejmě předpokládám správný význam slova „optimální“, tedy neexistuje nic „nejoptimálnějšího“, protože ten význam „nej“ už má v sobě samotné slovo „optimální“.

[deda.jabko]

Pak se vrátí k původnímu řešení se seznamy, protože to je optimální řešení.

a jsem zase u meho tvrzeni, ze programy jdou oznacit jako neekvivalentni. sice delaji totez, ale pokazde jinak...

[Filip Jirsák]

Napsal jsem hned na začátku, že pro účely takového srovnání je rozumné považovat programy za ekvivalentní, pokud dělají totéž (tentýž výsledek) a jsou optimální. Jinak by to srovnání ani nemělo smysl – pokud to ty programy budou dělat opravdu stejně, budou mít identický strojový kód a i výsledky benchmarku budou stejné.

[deda.jabko]

Napsal jsem hned na začátku, že pro účely takového srovnání je rozumné považovat programy za ekvivalentní, pokud dělají totéž (tentýž výsledek) a jsou optimální.

pak se nebude hodnotit jazyk (prekladac, intepreter), ale rychlost implementace nejakeho algoritmu v danem jazyce, pricemz porovnavane algoritmy nemusi byt totozne... tudiz ve svem dusledku je to neco neporovnatelneho

[Filip Jirsák]

Podle mne je to právě to jediné, co můžete porovnávat – rozhodující je přeci výstup programu, a aby nebyl nějaký překladač nebo interpretr bezdůvodně penalizován, použije se pro daný jazyk nejlepší řešení. Druhá možnost je porovnávat implementaci, která je pro daný jazyk „přirozená“ – jenže na tom, který algoritmus je pro daný jazyk „přirozený“ se programátoři nikdy neshodnou. Většina sice bude tvrdit, že v Lispu je přirozené řešení přes seznamy, ale někdo stejně bude tvrdit, že přirozené je to řešit přes bitové pole, stejně jako v C. Tenhle problém u optimální implementace nehrozí, protože tam je možné neoptimálnost prokázat jediným způsobem – naprogramováním lepšího kódu. A ten už pak zase můžete rovnou použít v benchmarku.

[koroptev]

100% souhlas a rekl bych, ze to by mel byt primo smysl benchmarku - ukazat (kdyz ted mluvime o rychlosti), jak to pro ten ktery problem dopadne, kdyz to udelam dobre v tom nebo v tom, to je preci zajimava informace

[deda.jabko]

Tenhle problém u optimální implementace nehrozí, protože tam je možné neoptimálnost prokázat jediným způsobem – naprogramováním lepšího kódu. A ten už pak zase můžete rovnou použít v benchmarku.

vite co, prestanme vest teoreticke reci... napiste mi dva netrivialni benchmarky pro dva ruzne jazyky... a ja vam je slavnostne rozcupuju nekterym z vyse uvedenych tvrzeni ;-]

[Filip Jirsák]

Co si představujete pod netriviálním benchmarkem? Rozcupovat výšeuvedeným tvrzením se samozřejmě můžete pokusit – jenže já vám na to odpovím, abyste příslušnou implementaci napsal lépe. Když to nedokážete, nemáte pro své tvrzení žádné opodstatnění, a když to dokážete, budu mít zdrojový kód, kterým nahradím ten původní. Pokud dokážete implementaci zlepšovat do nekonečna, asi ten benchmark nikdy neuděláme, ale pokud byste snad v nějakém okamžiku už na žádné vylepšení nepřišel, budeme ty dva jazyky moci konečně daným benchmarkem porovnat. Přičemž ten benchmark samozřejmě neporovná ty jazyky jako celek, ale pouze v té jedné úloze – třeba IO, výpočty apod. Pro vypovídající srovnání by bylo potřeba mít mix různých benchmarků „na různá témata“.

[deda.jabko]

Když to nedokážete, nemáte pro své tvrzení žádné opodstatnění, a když to dokážete, budu mít zdrojový kód, kterým nahradím ten původní. Pokud dokážete implementaci zlepšovat do nekonečna, asi ten benchmark nikdy neuděláme, ale pokud byste snad v nějakém okamžiku už na žádné vylepšení nepřišel, budeme ty dva jazyky moci konečně daným benchmarkem porovnat.

porad zijete v predstave, ze existuje nejaky optimalni kod...

casto mirne stacit pozmenit vstup programu a optimalni kod uz neni optimalni...

[Filip Jirsák]

Nežiju v představě, že existuje optimální kód sám o sobě. Pouze tvrdím, že z dostupných implementací daného benchmarku v jednom jazyce vyberu ty, které nejsou horší než jiná dostupná implementace – a tyto implementace pak budu porovnávat se stejně vybranými implementacemi v jiných jazycích (resp. zkompilovaných jinými kompilátory nebo běžícími pod jiným virtuálním strojem).

[koroptev]

no ale to je snad zrejme;  vzdyt v nejakem HL jazyku musim tak jako tak pocitat s tim, ze pod kapotou se mi deje neco vic (treba ty operace se seznamy) nez treba v C, kde to musim vsechno explicitne rict; presto to nemeni nic na faktu, ze lze pro dany problem vytvorit program v obou jazycich, tak nejlepe jak to bude mozne a zmerit rychlost techto implementaci  .. na zaklade toho pak vyvodit, pro problem XY je cesta s jazykem A vhodnejsi nez cesta s jazykem B, zni mi to naprosto prirozene

dotahnu li vasi myslenku ad absurdum, pak aby srovnani melo smysl, mela by moje snaha smerovat k tomu, aby mi oba zdrojaky vygenerovaly tentyz strojovy kod (proc mirit na to, abych pomoci jazykovych konstrukci nekde dole vyloudil stejne algoritmy, proc ne rovnou jeste dal ..) <- to by pak asi bylo srovnani na nic, ostatne o tom ty benchmarky jsou preci, zjistit, jak jsou ktere abstrakce (a to co se za ne plati) efektivni a dostatecne obecne

[deda.jabko]

na zaklade toho pak vyvodit, pro problem XY je cesta s jazykem A vhodnejsi nez cesta s jazykem B, zni mi to naprosto prirozene

jo, s tim souhlasim... ale tim se dostavame uplne jinam... problem benchmarku je, ze se snazi rict, ze A je lepsi nez B nebo naopak

dotahnu li vasi myslenku ad absurdum, pak aby srovnani melo smysl, mela by moje snaha smerovat k tomu, aby mi oba zdrojaky vygenerovaly tentyz strojovy kod (proc mirit na to, abych pomoci jazykovych konstrukci nekde dole vyloudil stejne algoritmy, proc ne rovnou jeste dal ..) <- to by pak asi bylo srovnani na nic, ostatne o tom ty benchmarky jsou preci, zjistit, jak jsou ktere abstrakce (a to co se za ne plati) efektivni a dostatecne obecne

vy porad uvazujete s premisou, ze jde neco udelat optimalne... jenomze zijeme v realnem svete a zadny prekladac se nechova optimalne... takze pozadvek na stejny strojovy kod je nesmyslny

[koroptev]

problem benchmarku:  rika kdo? co to tu ctu, tak ted to zaznelo poprve, doted jsem si myslel, ze oba dokazeme interpretovat, co rika vysledek benchmarku, nebo snad hledame benchmark, ktery toto rekne? to se pak opravdu posouvame uplne jinam ..

ale jsem rad, ze se to posunulo od "neni pravda ze Pokud jsou programy optimální a vyhovují zadání, považoval bych je pro účely srovnání za ekvivalentní" k "jo, s tim souhlasim"

premisa: vsiml jste si ad absurdum? nedelejte, ze nerozumite, co jsem tim chtel rict, o schopnostech prekladace to opravdu nebylo, vznasite li vy pozadavky typu "abysme mohli merit, musely by obe implementace ruznych prekladacu prevest kody vyuzivajici naprosto rozdilnych abstrakci na stejne algoritmy, jinak to nema smysl" - ja jen dodavam, no a proc si nedat rovnou pozadavek at z tech kodu vyrobeji stejnej strojak .. coz je stejne absurdni jako ten vas pozadavek 

proste jestli se v lispu (priklad) neda elegantne pracovat s bitovymi polemi, nebo je to zcela neprirozena technika a nikdo to tak delat nebude a z cecka to jde v pohode, tak holt na ulohy, na ktere se to bitove pole hodi, to cecko asi bude vykonnejsi a je proste fer rict "mame v lispu tuhle abstrakci, ale na tohle je draha a navic to jinak moc dobre nejde"  - smest to tim vasim "ale c to dela pres pole a ne pres seznam, srovnavame nesrovnatelne" je proste mimo misu, znovu no a co, to tu prave merime, jak se toho ceho a za kolik v kterem jazyce dobrat, cil neni nejaky konkretni postu, cil je vysledek, ktery bude stejny v obou pripadech

jen rikam, ze benchmarkovat ma smysl, kdyz vim co a co se tim dozvim (dovoluji si u sebe i u vas predpokladat), vy mam pocit tvrdite, ze benchmarkovat nema smysl

[deda.jabko]

Samozřejmě předpokládám správný význam slova „optimální“, tedy neexistuje nic „nejoptimálnějšího“, protože ten význam „nej“ už má v sobě samotné slovo „optimální“.

to by bylo taky na delsi diskuzi... UJC tvrdi mj.:

Přídavné jméno optimální není třeba stupňovat, ale stupňované tvary tolerovat lze.

Na druhé straně však lze argumentovat tím, že přídavné jméno optimální znamená (jak se lze dočíst v Slovníku spisovné češtiny) relativně nejlepší, nevhodnější, nejpříhodnější. Optimálnost je vlastnost relativní.

[kapo]

Ze bych vytahl skripta z PARu a prepsal sem definici slova "optimalni" ? :) Pokud chcete tolerovat i stupnovane tvary slova optimalni, pak muzete, ale jejich vyznam musite brat uplne stejne jako u puvodniho slova. Tzn. ze optimalni = optimalnejsi = nejoptimalnejsi. Pokud byste mezi ne chtel dat znamenka nerovnosti, pak se dopustite vyznamove chyby.

Ono pokud se tu chceme bavit dale, tak asi pro vzajemne pochopeni budeme muset zacit od lesa: nadefinovat vyznamy jednotlivych hodnoticich slov.

[deda.jabko]

Ze bych vytahl skripta z PARu a prepsal sem definici slova "optimalni" ?

klidne si vytahnete co chcete... sice nevim, kdo ty skripta psal a jaka je to autorita... ale pochybuju, ze to bude v teto oblasti vetsi autorita nez ustav pro jazyk cesky akademie ved, ktery ma mj. vyjasnovani takovychto problemu v popisu prace... viz odkaz

[kapo]

Tak treba ve Vami postovanem odkazu je mj. toto: "Utvoříme-li od tohoto tvaru pomocí pravidelné české stupňovací přípony tvar druhého stupně optimálnější a od něj dále pomocí předpony nej- tvar třetího stupně nejoptimálnější, vyjadřujeme, nadbytečně, dvakrát totéž a pravdu mají ti, kdo tyto tvary z tohoto důvodu odmítají." Dale tam pak ukazuji i jine vyznamy a co je mozne pouzivat. Dle mne neni jejich postoj k vyznamu slova vyhraneny.

Takze se muzeme klidne dohadovat, ale stejne skoncime u toho, co jsem uz napsal: budeme se muset shodnout na definici slova optimalni, abychom si syncli jeho vyznam.

[deda.jabko]

Dle mne neni jejich postoj k vyznamu slova vyhraneny.

kdybyste si precetl muj puvodni prispevek, tak nemusite nad tim moc spekulovat, protoze tam primo cituji: Přídavné jméno optimální není třeba stupňovat, ale stupňované tvary tolerovat lze.

[Filip Jirsák]

Což ale nic nemění na významu slova optimální v základním tvaru. Pořád nemůžete za „optimální“ označit program, který je ve srovnávaných parametrech horší, než jiný program.

[kapo]

Ano, tam to pisete, ale treba zde nebo zde jej pouzivate v jinem vyznamu. Proto jsem se vubec ozval.

Ale nebudu uz dal zaplevelovavat diskuzi. Me chapani vyznamu slova optimalni je proste ponekud vyhranene.

Mejte pekny vecer :)

k.

[xkucf03]

Když už tolerovat ten druhý a třetí stupeň, tak v trochu jiném smyslu:

• optimální – jediné absolutní maximum, pravděpodobně nedosažitelné (něco jako dokonalost), můžeme se k němu jen přibližovat.
• optimálnější – optimálnější je to, co má blíže k optimálnímu. Optimálnější tedy znamená suboptimální, ale lepší než něco jiného.
• nejoptimálnější – z daných možností má k optimu nejblíže, ale stále je suboptimální.

[kapo]

Tak do toho bych nesel. Radeji bych ty dva stupne vubec nepouzival a napsal i viceslovne ten jiny vyznam. Zkracovat za kazdou cenu se nemusi vyplatit. Ale mozna jsem jen malo pruznej :).

[koroptev]

shodit benchmark .... asi stejne obtizne (a mozna caste) jako zmanipulovat benchmark

[Radek Hladik]

Mně by spíš docela zajímalo nějaké rozumné srovnání C/C++/Javy s těmi interpretovanými jazyky. Tady čísla jako že něco je 22573x krát nebo kolikrát rychlejší mi moc nepostačují.  O co mi jde, docela dost jsem si zvyknul programovat v PHP i různé systémové věci a začínám získavat pocit,  že v tom extra velký rozdíl není.

Například jsem tvořil backend do powerdns, který bude načítat data z tinydns zonefile. V principu se jedná o načtení texťáku, vyhledání patřičného záznamu a jeho vrácení. Programování bylo hrozně snadné, víceméně šlo o pěkný návrh objektů, jejich naplnění atd... Vyhledávání přes hash pole už PHP dělá skoro samo atd...  Takže z vývojářského pohledu idylka. A samozřejmě mě zajímá výkon. Nemám a nechci psát nějakou implemetnaci v C, abych změřil rozdíl. Ale vzal jsem zónový soubor o asi 4000 doménách s celkem asi 35000 záznamy. V paměti celé PHP zabralo asi 30MB, tedy i se vší řežií něco okolo 800B na záznam. Dělal jsem to na nějaké PIII 700MHz nebo tak nějak a stíhalo mi to odpovídat na několik tisíc dotazů za vteřinu. Jinými slovy, paměť možná využitá neefektivně, ale v množství, které není problém a výkon naprosto dostačující.... A z hlediska vývoje, než rešit nějaké binární nebo hashovací vyhledávání, programovat to nebo na to hledat knihovny, vs $vysledek=$pole[$klic]....

[xkucf03]

Jak často se ten program bude spouštět? Pokud to je totiž jen jednou „za čas“, tak zjistíš, že výkon vůbec nemá cenu řešit a že jsou jiné priority – pracnost vývoje, bezpečnost, možnost dělat snadno úpravy a udržovat kód… já mám radši Javu než PHP, ale každému sedne něco jiného.

[Radek Hladik]

Poběží jako součást démona powerdns a ten určitě posílá víc dotazů jednomu procesu (tzn. nespouští na každý dotaz nový proces). A dotazů bude řádově míň než při testování a stroj bude výrazně výkonější s dostatkem RAM.

Ale to je právě to, co jsem myslel tím, že by mě zajímaly nějaké rozumné srovnání C apod. s interpretovanými jazyky. Já jsem v tomhle případě přesvědčený,  že PHP je lepší volba, ale zajímalo by mně, jestli jsou i další lidi s obdobným názorem nebo zkušenostmi.... A jestli někdo třeba nenapsal stejnou věc v nějakém php,perlu nebo pythonu a v C, C++ nebo Javě a nezjistil, jak je to s výkonem a paměťovou náročností. Prostě něco, jako je ten odkazovaný článek, ale seriózně napsané a podložené. Abych se mohl kouknout a říct: "tak tenhle problém řešený v C je 5x rychlejší a s poloviční paměťovou náročností než v perlu....".

[ed]

pri php je hlavne problem s tym, ze to ma zrejme tendenciu dost intenzivne memleakovat. neviem si inac vysvetlit, ako je mozne, ze "demon" napisany v PHP dokazal po dokladnom prehladani zdrojaku a zapise zodpovedajuceho poctu unset-ov za tyzden naalokovat vyse 2GB ram. ale taktiez je mozne, ze to bolo sposobene fragmentaciou pamate.

[xkucf03]

U PHP se asi nepředpokládá, že ten program poběží týden v kuse – ale že poběží v řádech milisekund než obslouží jeden HTTP požadavek.

[Radek Hladik]

A proč by nemohlo? Osobně mi pár takových běží a memory leaků jsem si nevšiml... Právě jde o to, vymanit PHP z jazyka výhradně pro web a udělat z něj jazyk i pro ostatní situace, alespoň podle mně....

[xkucf03]

Mohlo, ale to spíš záleží na jeho vývojářích (až „to spraví“) než na uživatelích (až to začnou používat i jinak než na web). Sice už jsem v PHP taky pár ne-webových jedoúčelových skriptů napsat, ale dovedu si představit lepší jazyky, zvlášť pokud to má být něco robustního a záleží mi na tom.

[mkoubik]

Právě jde o to, vymanit PHP z jazyka výhradně pro web a udělat z něj jazyk i pro ostatní situace, alespoň podle mně....

Jen to ne. Podle mne jde o to, udělat z ruby jazyk pro web (úkol pro webhostery).

[default]

No, já se na to dívám takto. Jestli ti nejde o výkon, pak piš v čem chceš. Pokud ti o výkon jde, pak použij to, co bylo na tvůj problém navrženo.

Máme tady jednu komponentu v Javě. Ano, je to děsně špatně napsaný. O tom žádná. Ale zkrátka ten proces trval nějakých dvacet hodin. Ten proces se musel spouštět pětkrát, tak si to umíš představit. Já jsem tu komponentu přepsal do PL/SQL. Se vším všudy. Má komponenta má stejné chování, jako ta Javí. Plus samozřejmě pár věcí navrh. A celý dohtomady mi to trvá deset minut a to ještě jen proto, že ty datový struktury tý aplikace jsou naprosto denormalizovaný.

Druhý příklad je podobný.

Mějme tabulku TEMPLATES, která obsahuje

TEMPLATE_ID | TEMPLATE_FORMULA
------------+------------------
         10 | 1
         11 | A(1) + B(<10>)
         12 | C(<10>) - D(<10>)
         13 | (<11> + <12>)

Ta čísla, která jsou uzavřena mezi < a >, jsou odkazy na jinou formuli. Očekávám následující výsledek:

TEMPLATE_ID | TEMPLATE_FORMULA
------------+----------------------------
         10 | 1
         11 | A(1) + B(1)
         12 | C(1) - D(1)
         13 | (A(1) + B(1) + C(1) - D(1))

Prostě doplnit formuly tak, abych se zbavil všech odkazů.

Implementace je triviální. Prostě rekurzivně nahradím všechny reference:

CREATE OR REPLACE FUNCTION complete_formula(
        p_formula_id IN NUMBER) RETURN VARCHAR2 IS
    v_formula VARCHAR2(4000);
BEGIN
    FOR EACH referenced_id FROM get_template_formula(p_formula_id):
        v_formula := complete_formula(referenced_formula);
        replace_referenced_id(current_formula, referenced_id, v_fromula);
    END FOR;

    RETURN current_formula;
END complete_formula;
/

Je to jen metajazyk, ale na první pohled je patrné, co to dělá. Reálná implementace nemá víc než třicet řádek kódu.

No, ani jsem to nezkoušel pouštět. Na první pohled je jasné, že to bude pomalý jak prd€l.

Tak doplníme cache. Výsledkem je, že celý package je příšerně obfusknutý. Je to plný PL/SQL tabulek, polí a asociativních polí. Fajn, víc z toho asi nevymáčkneme. Na vývojovém prostředí jsem se dostal někam ke dvěma minutám. Pardon, ale tudy cesta nevede. Po vzoru Waltera Součka a jeho výroku "Ten chdí!", jsem prohlásil, že to jde v obyčejném SQL! A ono taky že jo!

Prostě teď mám něco ve smyslu:

CREATE OR REPLACE VIEW rendered_templates AS
SELECT
…
/

Výsledek? Nějaká ta vteřina nad statisícem formulí. To už beru. Bejt tu Oracle 11g, tak to ještě stáhnu. Teď, jak to píšu, tak mě napadlo použít materializovaný pohled s MVIEW LOGem nad původní tabulkou. Schválně, jestli borec objeví ty závislosti. Vyzkouším.

Takže asi tak. Umění je v tom vybrat správný nástroj na správnou věc s ohledem, jak dlouho ti to bude trvat.