- A hozzászóláshoz be kell jelentkezni
- 4765 megtekintés
Hozzászólások
Ha jól látom... 6:1
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Remeljuk 2.6.28-al 7:0 lessz :)
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Nyilván nem az az érdekes, ami már a gyártója szerint is nyugdíjba vonult.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Az OSNews kommentelői szerint azért nem teljesen volt minden rendben a teszttel: a linuxon server vm futott, a winen kliens vm.
- A hozzászóláshoz be kell jelentkezni
Szerintem az MS fizette őket ezért a tesztért.
- A hozzászóláshoz be kell jelentkezni
Hát nekem is az jutott eszembe, hogy ezzel a Java sírját ássák.
- A hozzászóláshoz be kell jelentkezni
MS=Mark Shuttleworth, így akarja az ubuntut jobb színben feltüntetni.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
+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.
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
Már felvetették neki a fórumban. Reméljük, hogy megismétli a teszteket.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Szerintem ez a teszt arra vonatkozott, hogy mennyire lehet hülyének nézni az embereket. Szerencsére van alsó határ.
"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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...
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Azt sem tudom mi az a phoronix, de valami olyasmi rémlik, hogy legutóbb, mikor itt ez a sztring megjelent, valami hasonló benchmarkkal, hasonló hozzászólások voltak.
Rosszul emlékszem?
- A hozzászóláshoz be kell jelentkezni
Jol emlekszel, de akkor default disztribucio installokat hasonlitottak ossze, tehat jogos volt a kulonbozo jvm.
Most viszont ok telepitettek kezzel a cuccot es elkepezelesem sincs, honnan szedtek egyaltalan u7-et Windows-ra.
- A hozzászóláshoz be kell jelentkezni
Ah so, tényleg valami ilyesmi volt.
Lehet, hogy olyan volt a haver gépén. :)
- A hozzászóláshoz be kell jelentkezni
+1
Durva kulonbsegek vannak egyebkent Swing megjelenites / Java2D teljesitmenyben update 11-el nezve Linux es Windows XP kozott, az utobbi javara.
Remelem az XRender-es peccs fel fogja hozni a linuxos oldalt.
- A hozzászóláshoz be kell jelentkezni
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 ! -
- A hozzászóláshoz be kell jelentkezni
nem kéne arra a szintre süllyedni. szerintem az foss-világ nem egy új microsoft-világ akar lenni
bízom benne...
- A hozzászóláshoz be kell jelentkezni
ja, vegulis ironia volt.
szerk: meg kene ismetelniuk a tesztet jol, vegeredmenytol fuggetlenul, ha meg akarjak orizni a hiteluket.
- Use the Source Luke ! -
- A hozzászóláshoz be kell jelentkezni
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.)
- A hozzászóláshoz be kell jelentkezni
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 :-)
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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 :-) )
- A hozzászóláshoz be kell jelentkezni
í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%]
- A hozzászóláshoz be kell jelentkezni
Thx! Ilyenekre :-)
Miért 3.4.5 gcc? Miért nem 4.3? Az első 4.0, 4.1-et megérteném... Miért win miért nem linux (natív gcc?) ?
Nem kötekedés, hanem veszett kíváncsiság!
- A hozzászóláshoz be kell jelentkezni
-funroll-all-loops
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
Minden programodat így fordítod? :)
--
http://wiki.javaforum.hu/confluence-2.8.2/display/FREEBSD
- A hozzászóláshoz be kell jelentkezni
tdmmingw -féle gcc 4.3.2 (tdm-mingw-1.812.0-f1) -O3 -funroll-all-loops -al forgatva
1.scimark2 in-cache 445 MIPS [137%]
2.scimark2 out-of-cache 250 MIPS [ 82%]
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
"Nem sok minden változott ... az eredményekben sem" ???
Kivéve, hogy gyorsabb lett a teszt szerint a java mint a gcc...
Leírhatnád a gcc paramétereit, meg a processzort (ath 64 1800?)! Már ha érdekelt vagy a teszt folytatásában vagy összehasonlításában!
?
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Javanak foleg containerei lassuak.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
- A hozzászóláshoz be kell jelentkezni
erre is kiváncsi voltam
- A hozzászóláshoz be kell jelentkezni