[Java lista] Oracle Java performance

[Vig Balázs]

Hali!

Elvileg lehet a problémát több szálon megoldani, de Oracle alatt nincs értelme. Egyszerre mindig csak egy szál fog futni, szépen sorbarendezgetve (kipróbáltam). De mondjuk a doksi is ezt írja. A egy másik kérdés hogy valószínüleg akkor több pédányban fogom futtatni az alkalmazást, de ez akkor is 20 szál elindítását feltételezni azonos teljesítmény eléréséhez. És akkor még nem beszéltünk a párhuzamos futtatás okozta gondok miatti overheadról.

Bevallom férfiasan, hogy sosem követtem, mennyivel növekedett a teljesítmény a verziók között, csak azt figyeltem, milyen új nyelvi elemek jelennek meg.

Szóval gyakorlatilag a végeredmény a következő: esélyem sincs az elavult VM miatt. Hát pedig ha sikerülne a sebességkülönbséget 5x-re csökkenteni, akkor már használható lenne a cucc... Azért még a mai napot rászánom.

Kösz mindenkinek az építő hozzászólást!

VigB.
________________________________
Feladó: javalist-bounces at javagrund.hu [javalist-bounces at javagrund.hu], meghatalmazó: Gabor Szokoli [szocske at gmail.com]
Küldve: 2009. június 23. 6:26
Címzett: javalist at javagrund.hu
Tárgy: Re: [Java lista] Oracle Java performance

Sziasztok!

Nagyon hamar ki fog derulni, hogy eletemben nem fejlesztettem Oracle-re javaban, (fene, maris kiderult,) de azert had probalkozzak, mielot elfogynak a libak:

2009/6/22 Vig Balázs <Balazs.Vig at dataexplorer.hu<mailto:Balazs.Vig at dataexplorer.hu>>
Ma már nem, de holnap szétszedem az algoritmust,

Ha mar szeded, es az adott kornyezetben indithatsz threadeket, akkor probald meg parhuzamositani az algoritmust.

Csak azert gondolom, hogy ez segithet, mert ha nekem kellene adatbazist, ala JVMet, az ala OSt, az ala meg vasat terveznem, akkor abban akar az egyes szalak teljesitmenyenek rovasara is novelnem a parhuzamosan kiszolgalhato lekerdezesek szamat.
Szemben az egyfelhasznalos elemenyre optimalizalt desktoppal, amin gondolom tesztelsz.

Persze ugyanezen elv alapjan a serverekben nyugodtan lehet aranylag kevesebb a lebegopontos loero, akar hianyozhat is a lovoldozos jatekokhoz valo SIMD matrixnyomorgato utasitaskeszlet. (az sshgyorsitokartya-arusoknak is meg kell elni valamibol.) De ezzel tul sokat nem tudsz kezdeni, esetleg berakni a datacenterbe par gamer PCt (100kHUF/darab), es kiemelni rajuk ezt a service-t. Ugy akar OpenCLben is irhatod, es akkor nagyon gyors lesz.

Kliensen 1.6 van, db-ben 1.4 de szerintem ez a különbség nem okozhat ekkora eltérést.

Konkretan az 1.6 -ot nem pont a teljesitmenynovelessel reklamoztak az 1.5hoz kepest?
1.4.2-t pont a lebegopontos aritmetikai teljesitmenynovekedessel? (Mondjuk ezek lehet, hogy sun jvm specifikus lepesek voltak.)

Szocske

Ps: A memoriaallokaciok sebessege kozti elterest en arra fognam, hogy az egyik JVMet frissen inditottad a teszthez es szabadrab^W eredeti tokefelhalmozas folyik a memoriaban, a masik meg vegtelen ideje fut, guberalni kell a helyet, es a te programod nem eppen a bejaratott memoriaszelet-meretekkel dolgozik. De ezt mar kimerted, hogy nem lenyeges faktor, csak szerintem erdekes.
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: http://javagrund.hu/pipermail/javalist/attachments/20090623/21ad8b04/attachment.html