[Java lista] Oracle Java performance

[Gabor Szokoli]

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>

> 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/95659c4c/attachment-0001.html