Newsgroup: it.comp.java
Titolo: [OT?]Differenze prestazionali tra Java 1.5  e Java 1.6...

Salve a tutti, ho realizzato una mini applicazione per prendere confidenza 
con gli algoritmi genetici (libreria jgap)e, dopo varie prove su due pc 
diversi (notebook con p IV 3 ghz JRE 1.5 ,  512 mb ram e fisso athlon 2000+ 
384 ram JRE 1.6 )
la differenza prestazionale è ABISSALE (il secondo con 0,1sec/iterazione 
batte il primo con 0,2sec/iterazione)....ora, la configurazione del primo 
dovrebbe essere molto migliore del fisso....e' possibile che la JRE 1.6 
porti un effettivo aumento delle prestazioni?O e' colpa del notebook (magari 
troppi processi in esecuzione....anceh se sono praticamente gli stessi, e la 
quantità di ram libera è la stessa nei due pc...) 

 384 ram JRE 1.6 )
A margine c'è da chiedersi cosa ci facciano un P IV 3GH con 512MB di RAM ed
un Athlon 2000+ con 384 MB: è semplicemente assurdo!!!


....e perchč? 

 ....e perchč?
Non usi Windows, vero?


Con entrambi..il protatile non supera mai i 300 e rotti MB di Ram occupata 
(con Eclipse,Outlook che da solo ne succhia come un secondo SO,e aggeggi 
vari), l'altro in questo momento sta a 320 MB occupati (ho sbagliato prima, 
ha anche lui 512MB di ram...e pensare che l'ho aggiunta due settimane fa e 
non me ne ricordavo!!!!)
Windows succhia ram, ma basta configurarlo un minimo, tipo togliere i 
servizi inutili , e va quasi come un treno.....anzi, premettendo che ritengo 
linux molto piu' affidabile, e lungi da me aprire una discussione sui pro e 
contro di win, lo uso senza antivirus da ormai due anni (solo un firewall 
integrato nel router per connettermi in internet che agisce solo sulle 
porte) e mai preso nulla (ovviamente ogni tanto installo avast o nod32 e 
faccio una bella scansione,mai trovato nulla,neanche add-aware)
Ripeto, in ambiente server o comunque "critico" non esiterei a scegliere 
unix e famiglia, ma windows secondo me e' troppo maltrattato.... 

 writes:
T> ram e fisso athlon 2000+ 384 ram JRE 1.6 ) la differenza
T> prestazionale è ABISSALE (il secondo con 0,1sec/iterazione batte il
T> primo con 0,2sec/iterazione)....ora, la configurazione del primo
T> dovrebbe essere molto migliore del fisso....
L'hardware, questo sconosciuto...
Il primo è un "mobail", ergo va a favorire lo scarso consumo a scapito
delle prestazioni.
Senza andare a toccare il  clock (che sui mobile può essere rallentato
- tanto hai degli idle vicini  al 100% con le applicazioni interattive
tradizionali), non  è che la ram  del portatile è più  lenta di quella
del fisso ?  Come siamo con le cache, quanta di  livello L1, quanta di
livello L2 ? Ne abbiamo di livello L3 ?
Sono tante le componenti delle prestazioni, non solo la quantità di ram
ed il clock...
-- 
 /\           ___
/___/\_|_|\_|__|___Gian Uberto Lauri_____
  //--\| | \|  |   Integralista GNUslamico
\/                 e coltivatore diretto di Software

 batte il primo con 0,2sec/iterazione)
Solo per scrupolo, sicuramente sbaglio... ma non è che i valori vengono 
approssimati alla prima cifra decimale? Magari sono 1,45 e 1,55, e il 
primo viene approssimato per difetto, mentre il secondo per eccesso... 
oppure entrambi vengono approssimati per difetto (troncamento della 
parte decimale), e sono 1,95 e 2,05...


Il portatile vince su tutto....frequenza della ram (DDR333 contro PC133), L1 
uguale,L2 (512KB contro 265 KB)...in generale il portatile ha un paio di 
anni, il fisso almeno 5-6...come hardware non dovrebbero esserci 
paragoni.....forse il bus tra hd e scheda madre...ma non credo possa 
influenzare una applicazione da pochi kB....no?


Il programma restituisci i millisecondi che ha impiegato....e comunque si 
passa tra i 20 secondi medi del portatile ai 9-10 del fisso (in 
media,essendo comunque un algoritmo iterativo) 

 writes:
T> Il portatile vince su tutto....frequenza della ram (DDR333 contro
T> PC133), L1 uguale,L2 (512KB contro 265 KB)...in generale il
T> portatile ha un paio di anni, il fisso almeno 5-6...come hardware
T> non dovrebbero esserci paragoni.....forse il bus tra hd e scheda
T> madre...ma non credo possa influenzare una applicazione da pochi
T> kB....no?
Una  applicazione non  vive da  sola. Se  poi non  ha il  focus, sotto
Windows, ha possibilita` di prendere la  CPU solo se (mi pare) tutti i
thread dell'applicazione col focus non sono ready. Quindi se occorrono
pagine libere... :>. Per esserne sicuri bisognerebbe seguirla col task
manager per vedere se ha swap in e swap out.
Secondo,  mi sa  che il  mobile, proprio  perché č  tale, non  tira al
massimo con il ferro disponibile (per non rischiare di trovarsi con un
portatile "a la Salvador Dalě".
Ci sono vari fattori HW. Dovresti installare la 1.5 dove hai solo la
1.6 (o viceversa) e vedere le differenze...
-- 
 /\           ___
/___/\_|_|\_|__|___Gian Uberto Lauri_____
  //--\| | \|  |   Integralista GNUslamico
\/                 e coltivatore diretto di Software
A Cesare avrei detto di scrivermi a 
fn...@rat.vg

 influenzare una applicazione da pochi kB....no?
hai parlato di HD. l'applicazione usa molto il disco?
i dischi dei portatili, tranne innovazioni recentissime, vanno al massimo
a 5400RPM contro i, di norma 7200, dei desktop e la differenza si sente.
un'altra osservazione si potrebbe fare sui calcoli in virgola mobile che,
direi a naso dalla tipologia, la tua applicazione usa. forse la versione
mobile della cpu e' penalizzata in tal senso per questioni di consumo? io
non lo so.
ultima osservazione. sui portatili e' spesso possibile impostare la
velocita' della cpu per ottimizzare i consumi a scapito delle prestazioni.

 a 5400RPM contro i, di norma 7200, dei desktop e la differenza si sente.
ma pesa solo 392 kB.....e non accede a nulla, ne db, ne file, ne altro...o 
meglio, si appoggia ad una libreria (compresa nei 392 kB)...ma questa non 
viene caricata in memoria insieme all'applicazione? 


Credo che alla fine faro' cosi....e vediamo cosa succede 

 viene caricata in memoria insieme all'applicazione?
allora rimane il sospetto sulla virgola mobile e sulle questioni aperte
dagli altri.
ti esorto anch'io a fare un test usando le stesse jre.
ad esempio, probabilmente non e' il tuo caso, la differenza prestazionale
nella decodifica dei JPEG e' enorme passando da 5 a 6.