Programozási nyelvek teljesítményének összehasonlítása

Programozás

Egy Slashdot hír kapcsán készítettem néhány teljesítmény-tesztet különféle programozási nyelvek összehasonlítására. Az eredmények ugyan nem általános érvényűek de talan tanulságosak lehetnek. A részletek itt.

( nevergone v | 2006. 06. 15., cs – 20:44 )

Éppen a napokban gondolkoztam el rajta, hogy érdemes -e C nyelven lekódolni bármit is (teljesítmény szempontjából), mert a Java, Python, C#, stb. hatalmas sebességgel fejlődik.
Nos, a teszted azért elég jól megválaszolta a kérdést.
Köszönöm. :)

--- GTK programozás C nyelven ---
http://hu.wikibooks.org/wiki/GTK%2B_programoz%C3%A1s_C_nyelven

Fejlődik mint állat, csak aztán azt veszed észre, hogy a kiváló JAva megette mind a 16GB memóriát a szerverben. (És nem, nem én írtam a kódot.) Tudom hogy elég frusztráltan hangzik, de én még nem találkoztam normálisan futó (itt én sebességet és memória zabálást is értek) java programmal, mondjuk tipikusan enterspájz alkalmazásoknál.

Megint a Cisco VPNSC/ISC nevű csodát hoznám fel példának, aki használt már olyat tudja miről beszélek.

Üdv
Godot

Nem is a teljesítmény szempontjából, de van egy projektunk, a GUG ami egy Python alapú elosztott rendszer és az volt a látványos, hogy 5 hónap alatt olyan rendszert sikerült összerakni 0-ról, ami azóta is kiválóan működik, egy játéknak alig tekintő rendszeren, a ClusterGrid-en. Én nagyon elégedett vagyok a fejlesztési hibajavítási ciklussal és a produktivitással.

Kérdés, mi a feladat.

Ha gyors programot kellene írnom, bizonyára C++-ban állnék neki. Ha inkább hamar kell kifejleszteni, és nem baj, ha fél mp helyett mondjuk 4 mp a futás ideje, akkor meg python.

A pythonnal egy bajom volt, hogy jó lazán bánik a memóriával, tehát ha több százezer objektumot létrehozok (fájlból töltöttem láncolt listát), akkor hajlamos megzabálni a memóriát.

Mindenesetre itt is igaz: megfelelő szerszámot a munkához.

G

( fdavid | 2006. 06. 15., cs – 20:45 )

A D nyelvet erdekes lett volna felvenni. Ugyanazt a kodot fordithatod es interpretalhatod is. Ezzel kapcsolatban egy apro megjegyzes: a nyelv nem feltetlenul hatarozna meg, hogy forditod vagy interpretalod. (Tehat nem nyelveket, hanem forditokat illetve futtatasi kornyezeteket hasonlitasz ossze.) Ebbol adodik az is, hogy egy kicsit torz a kijelenetes, hogy az interpretalt nyelvekben hatekonyabban lehet programozni. Termeszetesen ez igaz, de nem azert, mert a nyelv interpretalt, hanem azert, ment az interpretalt nyelvek nagy resze modern nyelv. Es a modern nyelvek rendelkeznek azokkal az eszkozokkel, amelyekkel hatekonyabban lehet dolgozni.

( Chain-Q v | 2006. 06. 15., cs – 20:47 )

Ah, pedig mar vartam az okos otleteket a Ruby-ban irt OS-hez me'hogy a C elavult, meg az assembly is. :) Most csalodtam. Tenyleg, meg lehet kapni a referencia kodokat? Lehet hogy atirnam Free Pascalba, csak a poen kedveert, a legujabb 2.1.1 SVN fordito ugyanis tud par aranyos optimalizalos aprosagot, aztan furja a kivancsisag az oldalam. :P

( sz | 2006. 06. 15., cs – 20:49 )

Azok a százalékok ott a táblázatban ugyan mit jelentenek vajon?

Még mindig nem értem.
Konkrét példával: a C-s int test 100%, a javas 2%, akkor ezt a két értéket hogyan kell szoroznom/osztanom/összeadnom/stb, h valami értelmes mérőszámot kapjak? (merthogy az általad írt "Futási idő C program/Futási idő más program"-ból az jön ki, h a java 50x gyorsabb, mint a C, ami azért engem meglep (; nem beszélve a ruby 0.01%-áról...)

A fenti állítás szerint, C idő/X idő. Ha ez százalék akkor azt kapod, hogy a C ideő hány százaléka az éppen adott nyelven írt prog idejének. Akkor viszont a Rubynak kell 10000szer annyi idő..Az viszont irdatlan nagy számnak tűnik.

Software is like sex, it's better with a penguin. :D (r)(tm)(c)

( Coornail | 2006. 06. 15., cs – 21:00 )

En nagyon kivancsi lennek a gcc 4.0ra vagy 4.1re -O2vel.

( vomberg | 2006. 06. 15., cs – 21:55 )

He-he... azért 100% fölötti érték egy sem volt...:-)))

Magyarul a mezei C kódolásnál semmiféle faxnis csicsa-micsa cucc nem ad gyorsabb kódot, más kérdés, hogy egy kisebb webes munkár épeszű ember PHP-ban ír meg és nem C-ben szerveroldali alkalmazásként.

( syntern | 2006. 06. 15., cs – 22:05 )

Egy tipp a Java-hoz: a -server kapcsolót akkor használd, ha _hosszú_ ideig tudod futtatni a tesztet. Néhány tesztesetednél esélye sincs a JVM-nek arra, hogy optimalizáljon. Valahogy a listás tesztet nem fogtam, hogy ott mit is vizsgáltál, de most idő hiányában csak rápillantottam. Ha érdekel, akkor segíthetek rendbetenni a Java-s részt.

( arpi_esp v | 2006. 06. 15., cs – 22:26 )

Ami azert elegge be tudja folyasolni az eredmenyeket:

- a vas (foleg az architektura) amin teszteltel
(mondok egy peldat: tavaly proof-of-concept gyanan megirtam egy grafikai effektet pure c-ben, semmi asm/mmx. 2.5ghz ppc g5-on 80fps-t ment, egy p3 1000-esen 2 fps-t. elsosorban cache/memoria kezelesi kulonbsegek miatt. ugyanazzal a gcc verzioval, -O3 mindket esetben).
erdemes lenne kulonbozo vasakon is letesztelni.

- a compiler opciok (gondolom max optimalizacion toltad)
foleg gcc-nel eleg sok varoacio van.

- java eseten a JIT nagyon sokat dob, ugy hallottam 80-90% kozeli eredmenyt lehet elerni a C-hez kepest. a nektek kijott 2% nem valami meggyozo...

- java eseten meg lehetne nezni pl. a gcj-t is (a gcc java compilere), ez nativ kodot fordit java forrasbol.

A'rpi

ps: a python nagyon jo, ha pl. szoveg fileokat kell feldolgozni/generalni vagy egyszeru cgi scriptet kell irni, es az embernek nincs gyomra a perl-hez, de matekozni szerintem nem valami hatekony benne... :(

1. Dell 2650 dual Xeon 2Ghz-n teszteltem 1G memória
2. Nem optimalizáltam ki a végletekig semmit sem (idő hiány)
3. Sok mindent meglehetne nézni még csak bird idővel és erővel
4. Nem is akarok python-ban matekozni, de a tesztek azt mutatják, hogy semilyen script nyelven nem érdemes matekozni, főleg lebegő pontos műveleteket.

( torokze | 2006. 06. 16., p – 06:29 )

Üdv,

Ez az összehasonlítás szép és jó, de hasznos akkor lett volna, ha nem a C-hez hasonlítjuk az interpretált nyelveket, hanem egymáshoz.
Bár így is össze lehet őket vetni egymással, de a C teljesítményével nem összemérhetőek.

Azt is figyelembe kellene venni, hogy az interpreterek nagy részét (ha nem mindet) C/C++-be(a)n írják. És persze mind más optimalizációval/fordítóprogrammal.

Zolee

A kérdés úgy merült fel, hogy a natív (C, Fortan)-hoz képest eljött-e már az interpretált nyelvek ideje, a konkrét, esetben teljesítményben. Szerintem én össze tudnám hasonlítani a fenti táblázat alapján a csak interpretált nyelveket egymáshoz képest is. (az osztás művelet csodákra képes :)

( Som-Som | 2006. 06. 16., p – 10:46 )

Nem értem, miért olyan rossz a Perl objektum kezelése. Pedig nincs is annál hatékonyabb, mint amikor egy objektum attributumait név (string) szerint egy hash táblából keressük ki.

Na de komolyra fordítva a szót: Valami több platformos, GUIs, netet használó alkalmazást kéne összehasonlítani, amiben mondjuk kis szöveg parse-olás is van. (Pl. böngésző, SIP kliens vagy épp IP Centrex.)

( szferi | 2006. 06. 16., p – 13:36 )

Szolgálati közlemény: Az int mérés el volt rontva, mint arra felhívták a figyelmemet a hozzászólások között. Köszönöm. A -O2 kapcsoló hatására a fordító kioptimalizálta az egész loop-ot ennek volt köszönhető a nagy eltérés a nyelvek között ebben a szekcióban. Szégyellem magam, hogy nem vettem észre :( Javítva.

A megállapítással tökéletesen egyetértek, ahány nyelv annyiféle cél, fókusz. Mindegyiknek megvan a maga létjogosultsága. Akkor még nem is beszélünk az olyan egzotikumoknak számító nyelvekről, mint a prolog, az scheme, sml stb.
Sokan sokféle testet futtattak már ez ügyben a leírásban találsz linkeket is.
Nem áll szándékomban a végletekig csiszolni a dolgot arra sajnos nincs időm :)

Csak arra akartam reagálni, amit korábban is írtak, hogy a teszt eredményét nagyban befolyásolják a körülmények. A java pl. elég jól vette ki magát, pedig a virtuális gép élből bekapkodja a maga százegynehány MB-ját. Tehát ha egy indulástól befejezésig tesztet nézzük 128MB RAM-on, akkor gyakorlatilag az utolsó helyen végezne a java, itt pedig a második.

A nyelv csak egy eszköz, az, aki fejleszt vele, tudja, mik a határai és a körülményeket úgy alakítja, a kitűzött célt megvalósítsa. Nem elvárható, hogy egy fejlesztő 2-nél több nyelven beszéljen „anyanyelvi szinten”, de az sem, hogy minden egyes új projekthez egy új csapatot kelljen verbuválni. Ennek a költségei jóval magasabbak a körülmények alakításánál.
--
Aries
http://aries.mindworks.hu
http://mindworks.hu/blog/aries

Ahogy a mondás is tartja:
"Az igazi programozó akármilyen nyelvben is bír FORTRAN programokat írni."

Valahogy ez úgy működik, hogy az ember megtanul egy nyelvet, akkor már könnyen megtanul újakat, szinte bármennyit.
De az, hogy valaki "anyanyelvi szinten" használjon egy nyelvet az egész más. Ahhoz fel kell venni a nyelv gondolkodását. Ilyen szinten tényleg nem lehet több nyelvet tudni, max 1-2-t.

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

( gabor v | 2006. 06. 17., szo – 04:48 )

Lazán kapcsolódik a témához, néhány esszé programozási nyelvekről és egyebekről:
http://www.paulgraham.com/articles.html

Kicsit osztja az észt de azért többnyire van benne valami, meg hát le is tett valamit az asztalra. Asszem.