Názory k článku Valgrind - závěr
-
Ondra Nekola (neregistrovaný)
Valgrid je nepochybne velice uzitecny, protoze mnoho veci nelze statickou analyzou kodu odhalit. Na druhou stranu se nemohu ubranit dojmu, ze jde o pomerne brutalni program, ktery leckdy pracne resi problemy, ktere by v rouzmnejsim programovem prostredi (Java...) vubec nenastaly.
Pokud jsem nucen neco stvorit v C, tak Valgrid samozrejme pouzivam. -
Michal Barta (neregistrovaný)
Pro C/C+ ale zatim neexistuje nic podobne valgrindu. Ani dalsi nastroje jako Electric Fence neumi odhalit nektere chybicky, ktere valgrind najde. Java je sice mnohem bezpecnejsi jazyk, protoze k vetsine techto chyb tam dojit nemuze, ale programy jsou zase patrne pomalejsi, coz muze v nekterych pripadech hrat velikou roli. Ja jsem valgrind zatim nepouzival, ale pote, co jsem se dovedel, co vlastne umi, urcite zacnu :-).
Dekuji autorce za zajimavy serial.
MB -
Ondra Nekola (neregistrovaný)
EF me moc uzitecny neprisly, ale to je asi vec osobni zkusenosti.
Java je pomalejsi (v prumeru tak o 30-50% proti C++), ale zase je schopna delat nektere runtime optimalisace. A vetsinou je preferovana rychlost vyvoje a bezpecnost vysledneho kodu.
Samozrejme neni Java vhodna na vsechno, ale na ledacos (imho vetsinu veci) je lepsi. Tam, kde jsem nucenej pouzit C/C++ je ovsem valgrid sqela pomucka. A proto autorce: "diky za fain clanek". -
Quasimodo (neregistrovaný)
Mno, sice to sem ne zcela patri, ale... dle mych zkusenosti to neni 30-50%, ale Java byva zhruba 2-4x pomalejsi. Pomer se samozrejme rapidne zlepsi, kdyz napisu stejne neefektivne program v C a v Jave. Tam pak runtime optimalizace muze vyrazne pomoct. Navic narocnost javy co se tyce pameti - musim natahat celou JVM pro sebemensi ptakovinu... myslim ze C/C++ a tim padem i programmy jako Valgrind jeste dlouho budou zapotrebi.
Jeste kdyby tak nekdo udelal podobny clanecek/serial treba o [lc|sp]lint-u nebo nejake jeho obdobe pro C++ :-) -
Ondra Nekola (neregistrovaný)
Ano, java neni rozhodne (zatim) pro operace typu spusti, vypis datum, otevri soubor v parametru, vypis jeho prvni radek a skonci.
Ted pisu par veci v C, protoze je pro ne lepsi a valgrid je na to super, ale na vetsi veci, kde nemusi mit rychlost 100% je imho volba jasna.
BTW: co bezi 4* pomaleji v Jave? -
Quasimodo (neregistrovaný)
No, mne nekolikanasobne pomaleji bezely praktickky vsechny elementarni vyukove programky, ktere jsem psal v dobe kdy jsem se o Javu zajimal - odhadem tak dva roky tomu nazad.
Pokusy typu rekurzivni vypocet n-teho prvku fibonacciho posloupnosti, nebo n!, nebo sorty, nebo ptakovinka typu mam pole prvku a do druheho na n-tou pozici uloz prumer prvku 0-n z pole prvniho a podobne veci, kde se nespolupracuje s nejakym pomalym zarizenim - operace s diskem, siti, interakce s uzivatelem.
Mimochodem ve SWINGu napsane rozhrani se mi zda ze take rychlosti odezvy na udalost nevynikalo, ale to se da jen tezko objektivne zmerit. Psat si extra program na odchyceni stisku mysitka predtim, nez ho dam Jave se mi fakt nechce. :-)
Skutecne jsem tenkrat delal testovani rychlosti, protoze se mi Java, kvuli sve prenositelnosti libila a je hodne podobna C++, ktere vcelku slusne umim.
Postup: nacti ze souboru vstupni data do pole, uloz timestamp, na vsechna vstupni data pouzij v cyklu funkci a zase timestamp. Vytiskni rozdil casu. Jednoduche a na nezatizenem systemu vcelku spolehlive mereni, pokud je vstupnich dat dost na to, aby vypocty bezely alespon par desitek sekund. (Tolik se jich obvykle nevejde do pameti, ale zase tak moc to nevadi, protoze to muzeme smele prohrant cyklem. Celkem staci, kdyz je dostatek dat na to, aby nezustavala v datove cache.)
Kolega se pokusil pouzit Javu pro psani uzivatelskeho interface k nasemu mericimu softu pod RTLinuxem. Realtime cast jsem si napsal v C++ a v Jave napsany interface mel slouzit jen k ovladani a zobrazovani namerenych hodnot - vcelku jednoduche kresleni posouvajicich se krivek. Presvedcil nas, ze to bude za mnohem rychlejsi vyvoj stat a na ovladani systemu ze to bohate staci. Take tvrdil, ze Java je jen o malo pomalejsi nez C. Muselo se to nakonec prepsat do C++ a GTK. Java naprosto nestihala, sezrala prakticky veskery dostupny vykon a navic se obcas interface na chvili zamyslel a nereagoval na uzivatelsky vstup. Samozrejme, neprozkoumal jsem nijak dukladne jeho kod a mozna to delal hodne blbe, ale moje mineni o Jave to proste nevylepsilo. -
Jarda (neregistrovaný)
Mno pokud jste Javu videl naposled pred dvema lety a mate ty testovaci programky nekde schovane, zkuste je na nejnovejsi verzi JDK, mozna budete prijemne prekvapen, zvlast pokud bezi delsi dobu a dovoli JITC aby predvedl co umi.
To ze je odezva rozhrani ve SWINGu 'ponekud' slaba se Vam bohuzel nezdalo, je to smutne, ale je to tak. I kdyz i v tomhle smeru se SUNi docela zlepsili a kdyz ho clovek umi pouzivat tak se v tom daji psat i pomerne svizne veci. Jinak krome nej existuji i jine knihovny na tvorbu gr. rozhrani, napr. SWT pouzita pro IDE Eclipse, ktera sice neni pure java ale zato je dabelsky rychla. Vrele doporucuji vyzkouset, nejen quli te rychlosti, ale to rozhrani je proste super ;).
-
Ondra Nekola (neregistrovaný)
Imho je nejvetsi prinos Javy v tom, ze dostavam pomerne slusne a pomerne rychle sady standardnich nastroju. Kdyz chci pouzit Hashtabulku, tak ji mam hotovou a neni co resit. A napsat ji rychleji sice jde, ale kdo by se s tim (vetsinou) delal. Posix a stdC knihovny v kombinaci se STL ani glib mi neprijdou jako adekvatni konkurence pro Java API.
-
Linear (neregistrovaný)
1. Zrovna delam grafickou aplikaci v Jave s nejnovejsim Javovskym SDK od Sun (1.4.1) a zda se mi ze vykreslovani je minimalne 5-6 krat pomalejsi nez v C++. Java je dobra tak maximalne na GUI aplikaci ktere nezobrazuji prilis narocna graficka okna.
2. STL neni konkurence Java API protoze to je jako porovnavat porsche s nakladakem. U aplikaci ktere zpracovavaji stovky megabajtu dat, nebo delaji neco s multimedii Java je naprosto nepouzitelna. Na druhu stranu C++/STL je mozne pouzit pro vsechny projekty krome systemovych funci, ovladacu apod. -
Zuzka Vlckova (neregistrovaný)
Ja se domnivam, ze valgrind je teprve prvnim pokusem ve snaze napsat neco jako optimalni testovaci program. Autori o chybach a nedostatcich vedi a kazda novejsi verze je pouzitelnejsi. Verim tomu, ze kdyz budou spokojeni autori i programatori, tak uz bude jenom otazkou casu, kdy budou tyto algoritmy aplikovany pro jine front-endy, ne jenom c/c++.
Takze doufam, ze se jeste mame na co tesit :).
S EF nemam zadne zkusenosti, takze srovnani s valgrindem ponecham odbornikum..
Zuzka Vlckova -
Petr Zika (neregistrovaný)
Dekuji autorce za hezke a prinosne clanky. Vyzkousel jsem valgrind a behem 10ti minut jsem nasel ve svem programu chybny pristup do pameti, ktery se mi nepodarilo odladit predtim ani rucne (debugovaci struktury), ani pomoci Electric Fence. Ten ve skutecnosti v mem pripade zpusobil spise oddaleni a zamaskovani chyby, nez jeji odhaleni. Souhlasim s Ondrou, ze je rozhodne lepsi programovat bezpecne, ale priznejme si to, nikdo neni neomylny, ani s Javou za zady. V kazdem programu je alespon jedna chyba. Tedy pro jiz hotove projekty je valgrind urcite cerstvy vitr do plachet.
ČLÁNKY DO MAILU