Java teljesítmény: Ubuntu vs. Windows Vista

Címkék

A Phoronix-os Michael Larabel arra vállalkozott, hogy összehasonlítja a Windows Vista Home Premium SP1 és az Ubuntu 8.10 Java teljesítményét. A tesztekhez egy 2GHz-es Intel Core 2 Duo T5800 processzorral, 3GB DDR2 memóriával, 250GB Hitachi HTS543225L9A300 merevlemezzel, integrált Intel 965 grafikus chippel szerelt Dell Inspiron 1525 notebookot használt. A tesztek alatt mindkét operációs rendszer az alapértelmezett beállításokkal - beleértve a standard desktop effekteket is - szerepelt. Az eredmények itt láthatók.

Frissítés: úgy tűnik, hogy a Phoronix a tesztelés során durva hibákat vétett, így többek egybehangzó véleménye az, ahogy az eredmények fals képet adnak. Részletek itt.

Hozzászólások

Ha jól látom... 6:1

--
trey @ gépház

sokan fikázzák a phoronix-ot, de szerintem egy eléggé egyedülálló openszósz-mániás közösség, jó, hogy van ilyen is

XP-vel szemben nem vagyok benne biztos, hogy ilyen jól szerepelne. a Vista az tényleg katasztrófálisan lassú, akármit is csinál alatta. Nem csak a Java, de a natív program is lassú rajta. A fájlműveletekről nem is beszélve. A múltkor 5 mega másolásán dolgozott legalább 10 másodpercig. Már nevettem kínomban.

Ez a teszt nagyon rossz!

Teljesen mas beallitasokkal futtatnak teljesen mas verziot es igy akarnak ket oprendszert osszehasonlitani.

Az egyiket server VM beallitassal csinaljak (Linux) a masikat (Windows) client-tel. A matekos, stb tesztekben a kulonbseg innen adodik, es nem az oprendszerbol! Nyugodtan ki lehet probalni ugyanazon az oprendszeren ezekkel a kulonbozo beallitasokkal, hasonlo eredmenyek fognak szuletni.

A masik, hogy u7 -et futtatnak windowson, es u10 verziot linuxon. Namost _elegge_ sok performance dolog kerult bele u7 ota. Itt nem kis dolgokrol beszelek, hanem bizonyos esetekben alapvetoekrol. Pl. komplett hardveresen tamogatott grafikai muveletek Windows platformon.

Ez igy teljesen amator.

+1

Eddig nem volt semmi bajom a Phoronix tesztjeivel, de ez most elég hiányos. Alapból az u_7 vs u_10 nem igazán állja meg a helyét, kihagyta, hogy melyik OS milyen platformon fut (x86/x64_86), ráadásul ha valamit tesztelni lehetne, akkor az a legfrissebb stabil (u_11) vagy beta (u_12) verzió lenne. Az jegestea nyilván akkor kicsit lemaradottabb lenne, de úgy egy sokkal objektívebb képet kaphatnánk a helyzetről. Eben így semmi informatív nincs.

Finoman fogalmaztal, nemhogy nem informativ, de teljesen megteveszto. A valosagban nincs ilyen differencia a platformok kozt, sot szerintem Windowson jobb, ezenkivul u11 ota a GUI alkalmazasok a directx support miatt khm... ossze sem hasonlithatok. (igaz, kivalasztottak pont azt a chipsetet, amin nem menne a directx support. bar abban a tesztben igy is a windows nyert)

Valószínűleg ő is tudta, hogy egy ilyen tesztet, ilyen eredménykülönbségek mellett szét fognak szedni darabokra. Nem hiszem, hogy szándékos volt, mert akkor nagyon hülye.

Szerintem egyszerűen csak a) elnézett valamit b) fogalma sem volt arról, hogy ilyen különbségek vannak (server vs. kliens)

Tanulság: aki nem ért a Java-hoz, az ne csináljon Java tesztet.

(megjegyezem, nekem sem tűnt fel a különbség, mert k.rván nem értek a Java-hoz és nem is csinálok úgy, mintha értenék)

--
trey @ gépház

Ilyet nem szabad "elnézni". Ha meg fogalma sincs arról, hogy a ilyen különbségek vannak, akkor meg miért mond véleményt? Ezzel nagyjából-egészéből sikerült magából igen-igen nagy hülyét csinálni.

Persze, örült, mint majom az alkatrészének, hogy ilyen különbség jött ki, de mielőtt nagydobra veri, legalább megmutatta volna olyannak, aki látott már mérési jegyzőkönyvet...

Egyetértek, nem szabad elnézni, ezért is mondtam, hogy aki nem ért a Java-hoz, ne csináljon Java tesztet. Én csak azt mondtam, hogy valószínűleg nem rosszindulatból csinálta így. Szerintem egyszerűen tudatlanság állt a háttérben. A Slashdot-on említette egyébként valaki - nem tudom igaz-e -, hogy

"all jvms except for the 32 bit win32 version default to -server for this type of hardware"

Szóval szerintem azt nem tudta - ha igaz a fenti kijelentés -, hogy a Win32 jvm kakukktojás. Valószínűsítem, hogy az átlag ember nem tudja.

Persze ez nem menti fel, sőt, az sem, hogy noha már felrótták neki, nem egészítette ki a cikkét ezzel az infóval.

--
trey @ gépház

szerintem a modszerbeli hibakkal egyutt ez melto valasz a microsoft get the facts kampanyara! :)

gy.k.: az is kb. ennyire volt hiteles (de inkabb ennyire se)

- Use the Source Luke ! -

1 java progim van, amivel sebességet tudok tesztelni, de az egyértelműen a windowst hozza ki győztesnek. Ez pedig a krut. Nem tudom fejből a különbséget, de olyan 2-4x-es különbség van a 2 rendszer között fps-ben alap beállításokkal. Bár igaz, windowson a legfrissebb jre van fenn, míg linuxon az, amelyik csomagolva jött. (Bár csak 1 update van a 2 között.)

Most akkor te is ugyanazt a baromságot csinálod, mint a phoronix, csak a másik oldal javára "de egyértelműen a windowst hozza ki győztesnek".
Mikor megláttam a cikk címát a főoldalom, hogy java teljesítmény, meg összehasolítja, és windows-linux gyorsan visszaolvastam, hogy a phoronix csinálta-e? Igen, az csinálta... Akkor semmi információ értéke nincs számomra. A pirosbetűs "frissítés" sokkal információgazdagabb: mire kell figyelni, ha az ember benchmarkot csinál, mit lehet elb,,,ni?
A phoronix szerintem egy lelkes csapat, amelyik elkötelezett, jó célokkal, csak attól még lelkes amatőrök maradtak, a szó rossz értelmében. Nem túl okosak :-)

Kíváncsi lettem a c++ / java sebesség viszonyra windows-on.
A scimark2.0a tesztet használtam, aminek van c és java változata is. A c verziót agresszív optimalizációval, 2005-ös visual c++-al forgattam le, persze release módban. A java-hoz a legújabb Server VM-et használtam. Az eredmény számomra egy kicsit meglepő lett.

Hardware: Pentium4 3GHz Prescott HyperThreading on 1MB L2 cache


    test                  java result [MIPS]   c result [MIPS]
------------------------  ------------------   ----------------
1.scimark2 in-cache          324 [100%]            554 [171%]
2.scimark2 out-of-cache      306 [100%]            296 [ 97%]

Tehát ha olyan problémánk van, ami befér a cache-be, akkor a c-s megoldás még mindig durván jobb (70%-kal). Ha viszont out-of cache problémánk van, akkor a Java gyorsabb is lehet.

Példa java kimenet:

java -server jnt.scimark2.commandline -large
 
SciMark 2.0a
 
Composite Score: 306.32828805024263
FFT (1048576): 41.23158044036079
SOR (1000x1000): 624.9202988545162
Monte Carlo : 129.17972951336836
Sparse matmult (N=100000, nz=1000000): 362.0933434006447
LU (1000x1000): 374.2164880423233
 
java.vendor: Sun Microsystems Inc.
java.version: 1.6.0_11
os.arch: x86
os.name: Windows XP
os.version: 5.1

A 3% különbség kb. hibahatáron van, szerintem az egyforma, meg 3% nem különbség.
Nem akarsz írni egy kicsit erről, mert régóta nagyon érdekel a java vs c sebesség? (Egyenlőre lusta vagyok lefuttatni ezt... még) Mekkora mennyiségű adattal dolgozik az OOC-s, és milyenekkel?
Régebben futtattam pár tesztprogramot, amiben a java volt gyorsabb nem 3%-kal. És hihetetlennek tartom. Bár a források átnézése után láttam pár dolgot, ami a c-s változat sebességét hátrányosan befolyásolta (pl. szükségtelen calloc malloc helyett), de még ehhez képest is túl nagy volt a különbség.
Szóval megdobnál minket egy kicsivel több részlettel?

(Az OOC viselkedés mondjuk nem csoda, mert a nagymennyiségű adat esetén a cache nyilván a memóriára várakozik az pedig ugyanakkora idő mindkét esetben, de a c-s akkor is lehetne gyorsabb kicsivel :-) )

így van, a 3% nem jelent semmit, csak azt, hogy pariban van a két megoldás.

- az out-of-cache az ~2MB méretű problémát jelentett 1MB cache-es gépen.
- a c-s és a java-s kód is olyan, ahogyan azt a forrás honlapról letöltöttem, semmit sem módosítottam rajtuk, direkt az összehasonlíthatóság kedvéért.

Java src: http://math.nist.gov/scimark2/scimark2lib.zip
c src: http://math.nist.gov/scimark2/scimark2_1c.zip

milyen további részletre gondolsz?
nincs igazából mit mondani hozzá, legfeljebb azt, hogy én c++-ban dolgozom, és csak a magam megnyugtatása végett szoktam java-t benchmarkolni ;)

esetleg apró adalék:
- nem ilyen jó c compilerrel (pl Borland/CodeGear) a java már szignfikánsan gyorsabb (~30%-kal), mint a C

+adalék: mingw-féle gcc-3.4.5-20060117-3 -el -O2-el forgatva

1.scimark2 in-cache          416 MIPS [128%]
2.scimark2 out-of-cache      243 MIPS [ 79%]

Nem hihetetlen, tobbek kozott epp amit emlitettel a memoriakezelese gyorsabb a javanak, mert o manageli a memoriat, nem az os.
Plusz ugye a futas kozbeni, hotspotos optimalizacio (surun hasznalt ciklusok szekvenciaba alakitasa, java6 nal mar a rekurziokat is kepes ciklussa alakitani a jvm, stb.) - ezek foleg mondjuk szerver modban mutatjak ki a foguk feherjet.