 |
|
A natív kód vége?
A minap jelent meg egy cikk a Slashdoton, amiben a szerző arra a kérdésre próbál választ kapni, hogy vajon a natív kódot generáló programozási környezetek, mint például a C, C++, Fortran, Ada stb. háttérbe fognak-e szorulni (ha már nincsenek is abban) az értelmezett (interpreter) nyelvekkel szemben. Különös tekintettel arra, hogy a JIT (Just-in-time) fordítók igen jó eredményeket tudnak felmutatni. A kérdéshez adalékként végeztem egy-két egyszerű teljesítmény tesztet az alábbi nyelvekkel: C, Java, python, php, perl, ruby.
Mielőtt ismertetem az eredményeket néhány megjegyzés:
- a teljesítmény tesztek, különösen a nyelveket összehasonlítóak, mindegyike a vita, a flame melegágyai, ezt szeretném elkerülni azzal, hogy kijelentem: az adatok tájékoztató jellegűek, igen speciális körülményekre és feladatokra vonatkoznak, továbbá fenntartom magamnak a tévedés jogát, amire mindenki az adott fórumon felhívhatja a figyelmemet. Meg még ezeket is tessék figyelembe venni.
- a mérésekkel még csak a látszatát is el szeretném kerülni annak, hogy bármilyen módon versenyezni kívánok a nagy összehasonlító projektekkel, mint például a http://shootout.alioth.debian.org/ címen található adatbázis és annak elődjeivel. Ez inkább csak egyfajta kiegészítés akar lenni.
Tesztek
Elsősorban a lebegőpontos (math) és egész aritmetikára (int) az objektumok kezelésére (obj), a rekurzív függvények használhatóságára (ackermann) és néhány tipikus listákkal kapcsolatos elemi feladatra koncentráltunk (lists). Továbbá egy egyszerű rendezési algoritmus (heapsort) és az elemi I/O műveletek sebességét is mértük. A tesztek nem generikus hanem speciális feladatok voltak. A forráskódok letölthetők innen. Többnyire a referenciában megadott helyekről szedtem össze és egészítettem ki őket.
Eredmények
Alább csak relatív eredményeket közlök mivel az összehasonlítás volt a cél nem az abszolút bajnok keresése. Volt néhány hibás mérés, amikor általában a program kifutott a rendelkezésre álló virtuális memóriából. A C nyelv esetén értelem szerűen objekum kezelést nem mértem, még akkor sem ha elvileg lehetséges lenne.
| Nyelv/Teszt | int | math | ackermann | heapsort | lists | io | obj |
|---|---|---|---|---|---|---|---|
| C 3.3.5 -02 | 100 % | 100 % | 100 % | 100 % | 100 % | 100 % | - |
| Java 1.5.0-7 -server | 98.9 % | 5.9 % | 72.8 % | 95.7 % | 2.58 % | 38.5 % | 100 % |
| Perl 5.8.4 | 3.2 % | 16.9 % | 0.2 % | 2.9 % | 5 % | 46.3 % | 0.4 % |
| PHP 5.1.2 | 2.9 % | 9.79 % | 0.17 % | 2 % | hiba | 9.4 % | 0.5 % |
| Python 2.3.5 | 2.4 % | 7.1 % | 0.3 % | 3.4 % | 2.91 % | 29 % | 2 % |
| Ruby 1.8.2 | 0.8 % | 8.56 % | hiba | 1.3 % | 4.2 % | 14.7 % | 0.5 % |
Megjegyzés az eredmények értelmezéséről: a fenti táblázatban a százalékok úgy értendőek, hogy a C program teljesítményének hány százalékét hozta a más program. Az objektum kezelés tekintetében a Java-hoz lett hasonlítva a többi.
Összefoglalás
Persze a teljesítmény nem minden! Manapság, mikor az emberi munkaerő a legdrágább és egyre nehezebb jó képességű fejlesztőket találni nagyon fontos szempont, hogy egy programozási nyelvhez mennyire kiforrott fejlesztő eszközök tartoznak illetve, hogy egységnyi idő alatt milyen komplexitású feladat teljes fejlesztési ciklusát lehet végrehajtani. E tekintetben tapasztalatom szerint az értelmezett nyelvek sokkal jobban állnak, mint a natív kódot előállítók. Ezen belül is többek véleménye szerint még a legnépszerűbb és igen hatékonynak kikiáltott Java alapú fejlesztésnél is lehet gyorsabban, olcsóbban, hatékonyabban dolgozni például Rubyban vagy Pythonban.
Referenciák
http://www.osnews.com/story.php?news_id=5602&page=2
http://scutigena.sourceforge.net/index.html
http://twistedmatrix.com/~glyph/rant/python-vs-java.html
http://www.pankaj-k.net/spubs/articles/beanshell_rhino_and_java_perf_comparison/index.html
Néhány adalék a fentiekhez:
1. Az oldal és a tesztek nem webre voltak kihegyezve
2. A cím természetesen provokatív, szándékosan
3. A legtöbb mobil eszközön már van java VM, vagy python interpreter
4. Python megjelenik biztonságos rendszerekben is, pl tűzfal konfiguráciüban
5. Elosztott rendszert mi írunk pythonban és jól megy, nagyon jól. De írunk C++ is és az is jól megy :)
6. Párhuzamos programozási könyvtárak majd mindegyike használható script nyelvből. E tekintetben nem elsőssorban az számít, hogy mi hatékony és mi nem. A mérnökök kutatók java része már nem tud, akar C szintű nyelven problémát megoldani. Vagy rábízza egy programozócsapatra, hogy csináljanak neki gyors, hatékony kódot. Ez általában túl sok idő és addig a tudományos problémát megoldja más, ott is verseny van. Vagy megoldja a problémát magas szintű nyelven. Akár matlaban.
A tanúság: a növekvő mennyiségű magas szintű script nyelv megnyitja a lehetőséget olyanok számára is az algoritmikus probléma megoldásra, akik nem programozók a hagyományos értelemben.
Elkezdtem átírni a stuffot free pascal-ba. Hétvégére szerintem meglesz. Hova küldhetem?
A java megvalósításhoz lenne ket eszrevetelem: (Int, Math)
long startTime = (new Date()).getTime();
..
long stopTime = (new Date()).getTime();
1. A System.currentTimeMillis() alkalmazasa helyesebb lenne, mert akkor
nem "kell" objektumot letrehoznia a javanak..
2. A C-s peldaban a startTime es a stopTime valtozok dekralarasa a fuggvenyhivas
(..) elott tortenik.
3. Ilyen "szamitasi" tipusu feladatoknal pl (math) lehet hasznalni nativ konyvtarat (is), ami
nagysagrendekkel gyorsabb.
Egybe meg belekukkantottam, a listbe..
1. statikus fuggvenyt hivsz meg, pedig a statikus hozzaferesek lassúk a javaban.
2. a LinkedList megvalositas nem a legszerencsesebb ebben az esetben, mert lassu, szemben egy
array-os megvalositassal (foleg mert a meret ismert)
3. Kicsit csaloka az osszehasonlitas.. ugyanis ha jol emlekszem (lehet tevedek) a LinkedList szalbiztos..
vajon a C-s megvalositas az?
Udv.
Fri
1-2 észrevétel jogos, de nem hiszem, hogy az eredményt lényegesen befolyásolja.
3. 10 év HPC feladatmegoldásra alapozva állíthatom, hogy legalább fél nagyságrend külömbnséget tudok kihozni a C javára a Javahoz képest ilyen feladatokban.
A math biztos hogy jo?
Nalam a math-es test local valtozok kiirasaval (sine, cosine, tangent, logarithm, squareRoot):
gcc 3.4.4 -O2:
- 10000000 19.594
java server hotspot 1.5.0_06:
- 10000000 40.076
Szval nalam 50% kornyeken van.
Masik gepen:
solaris 9 UltraSPARC IIIi 1.06-GHz
gcc (GCC) 3.4.2
10000000 38.05
java version "1.5.0_03" Server HotSpot
10000000 42.007
A list "turbozasa" megfelel?
Annyi időt tudok szakítani, hogy a "nem hiszem, hogy az eredményt
lényegesen befolyásolja"-ra megprobáljak cáfolatot adni.:) Ez es a math
az a ketto teszt amiben nagyon "leszerepelt" a java.
Amugy a fel nagysagrend kicsit eleg ködös megfogalmazas nem?:)
Fri
A nem hiszem, hogy befolyásolja nem a listára hanem arra vonatkozott, hogy és számolom az start, stop időt :)
Apropó. Ez ugye csak vicc:
"nagy összehasonlító projektekkel, mint például a http://shootout.alioth.debian.org/"
Ugyanis az is hemzseg a "kodolasi" hibaktol java vonatkozasaban.. akárki is irta azokat
csak a felszinet kapargatja a dolgoknak.
Fri
OK. Csak ha mar teszt, akkor illik kihegyezni mindent a sok kicsi sokra megy alapon.
Amugy most néztem át a két list megvalósitást.. ahogy zero irta:
"Mindenesetre nemtudom hogy a c-s linkedlist implementacio mennyire egyenerteku a javassal."
.. nos a válasz: sehogy.
Koszono viszonyban sincs a ketto egymassal..
- c-ben int van használva a java-ban Integer
- a c-ben pointerek "másolgatása" dolgozik, a javaban a LinkedList altal komplex tombkezeles..
Tipikusan suszter es kaptafa esete, igy nem csoda, hogy a C-s alazta a java-s megvalositast.
Fri
Ui.: holnap delutan erek csak ra, igy estefele kuldom.
Úgy hiszem itt kezdünk flame-be átmenni, amit szerettem volna elkerülni. Úgyhogy részemről ez az utolsó hozzászólás a témához. Szívesen látom a javított lista kezelést természetesen.
Ami meg a shootout és társait illeti úgy hiszem senki nem lett megverve azért mert beküldött egy jobb verziót.
És még valami: nem hiszem, hogy az lenne a cél, hogy bemutassuk, hogy lehet adott nyelven sokkal jobban is programozni, mint ahogy én tudok, vagy mások tudnak. Mindig meg lehet csinálni dolgokat jobban és ez a szép benne. Amúgy nem hiszem, hogy ne lenne kézenfekvő az Javas implementáció, még akkor is ha nem a legoptimálisabb. Sok millió kódsor Java programot láttam ami hasonló implementációs hiányosságoktól hemzsegett, de vannak általános design patternek amiket sokan követnek és hiába nagyon jól optimalizálható egy kód egy másik megoldással, ha a programkódok 90 %-a nem azt használja (teljesen általánosan értem, nem a konkrét esetre nézve).
A tesztek során kifejezetten visszafogtam magam az eredmények értelmezéséeben pedig nyilván nekem is megvannak a preferenciáim. Soha nem állítottam, hogy a tesztjeim általános érvényűek ill. relevánsak lennének különösen egy komplex feladat megoldásának szempontjából.
Meggyőződésem, hogy egy az egyben nem is lehet leképezni egyik nyelv képességét a másikra, mivel eleve mások a nyelvek adta lehetőségek.
Természetesen ha elküldöd az szferi at gluon dot hu-ra megnézzük mit tud.
Fizikus vagyok nekem a fél nagyságrend pontos fogalom :) HPC alkalmazások esetén életszerű körülmények között a Java alkalmazások 5-öd 8-ad olyan sebességűek voltak mint a C-sek. Es 3 annyi idő volt megcsinálni őket. De ez tulajdonképpen irreleváns, hiszen nem is erre talaltak ki a Java-t.
En ugytudom a java.util.LinkedList nem szalbiztos. Mindenesetre nemtudom hogy a c-s linkedlist implementacio mennyire egyenerteku a javassal.
Szia,
Egy fontos dologra hivnam fel a figyelmedet amit most vettem eszre. Az intresultnal (de szerintem a math-nel is bar ott nem ellenoriztem) -O2 vel forgatva nem szamol semmit az intresulttal mivel azt a valtozot kesobb semmire nem hasznalod ezert full skipeli, a ciklus magjaban csak egy "add eax, 4" van, mivel "i++" 4x szerepel. De se osztas se szorzas se semmilyen szamolas intresulttal. Rakjal a fuggveny vegere egy "printf( "ires: %d\n", intResult );"-t es akkor nem fogja eldobni a valtozodat, bele fogja forditani a szamolgatos kodot. Igy viszont teljesitmenyben alig fogja felul mulni a javat. Szoval erre ertettem hogy nem biztos hogy tul eletszeru ha azt vesszuk alapul melyik fordito tudja jol detektalni a donothing loopokat :)
Érdemes megnézni a pike teljesítményét is. A Javaét közelíti, messze maga mögött hagyva a php-t, pythont.
Ismerőst már kérdeztem, hogy átírná-e a teszteket pike-ra. Meglátjuk, azonban nem hiszem, hogy érdemben tudnánk versenyezni a http://shootout.alioth.debian.org/-al. Inkább oda kéne elküldeni a pike-os teszteket.
Hello,
A psycos-at is ki lehetett volna rakni szerintem, hagy tudja meg a nep hogy pythonnal is lehet jittelni es eleg sokat dob rajta.
Erdekessegkeppen megjegyzem hogy -O2 nelkul a java kb 2x jobban tejlesitett nalam mint a c-s. Az int-es meg math-es pelda pedig nemtudom mennyire eletszeru, a heapsort mar annal inkabb, ott pedig -O2vel sem volt nagy kulonbseg. Szoval szerintem ez egy olyan teszt hogy mindenki azt von le belole amit szeretne :)
Az -O2 azért gondoltam használni, mivel szinte minden csomag így van fordítva egy Linux terjesztésben, viszont ennél több optimalizációt már csak a forrásból dolgozó terjesztések szoktak csinálni. Ami a python-t illeti: tervezek egy kis python specifikus tesztet ennek folytatásaként: -OO, psyco, IronPython hármassal. A tesztek életszerűségéhez meg csak annyit, hogy nem volt cél, hogy életszerű legyen. Mivel én javarészt tudományos műszaki számításokra használtam C-t így beidegződéssé vált, hogy az int és math-ra figyeljek.
Itt megint bejatszik, hogy ki mire hasznalja. Ahogy eszrevettem, ez az oldal inkabb webbel foglalkozik, mar pedig a vilag osszes processzorara irt programoknak eleg kis hanyada a webes alkalmazasok. Persze, mint ertelmezo teren, a script nyelvek elonyt elveznek, mert bar lassuak, de egy esetleges programhiba eseten nem szall el az egesz rendszer (bar ez kikuszobolheto egy forditott programnal is). De azert azt is vegyuk figyelembe, hogy van rengeteg eszkoz, amihez nem lehet interpretert csatolni, mert mar maga a merete sem engedi (bar a jovoben a memoriameretek csak nonek). Szoval ezt a cimet, hogy a nativ kod vege nem mernem allitani, mert egy eleg eros kerdesfelvetes. Meg azert egy biztonsagos rendszert nem pythonban vagy rubyban fogok leprogramozni, hanem inkabb ADAban... Ja es megegy... Parhuzamos programok teren, azert meg van hova fejlodniuk, mert ha egy osztott rendszert tekintek, haat...