Java Desktop System 2 di Sun: esce a Maggio

Java Desktop System 2 di Sun: esce a Maggio

Sun ha annunciato che la seconda release di Java Desktop System sarà rilasciata il prossimo mese di maggio

di pubblicata il , alle 15:06 nel canale Programmi
 
I migliori sconti su Amazon oggi
24 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
PGI27 Aprile 2004, 13:49 #11
Originariamente inviato da AlexPulv
Se andate al seguente sito:
http://www.alessandropulvirenti.it/programmazione/

troverete un Test dei vari linguaggi di programmazione.


Senza codice sorgente non è un test (però il programma è molto bello).

[aggiunto]

Beninteso, non nel senso che non mi fidi (sono l'ultimo che possa proferir verbo su come si costruisca un benchmark per linguaggi), ma così non si possono provare diverse versioni dei compilatori. Ri-ripeto, parlavo sempre dell'evoluzione delle performance di Java rispetto a Java. La questione è curiosoa perchè molti utenti Linux ritengono l'ambiente java non "lento" ma "molto, troppo, lento". Gettandosi a capofitto nel mondo delle distribuzioni Linux, con una cosa che si chiama "Java Desktop System", Sun rischia di portarsi dietro la lentezza di java, vera (in molti casi) o presunta (in tanti altri) che sia. Per me dovrebbe puntare più sui confronti evolutivi delle performance della sua piattaforma anzichè sbandierare confronti tra JVM e linguaggi precompilati. Naturalmente IMHO
DioBrando27 Aprile 2004, 15:37 #12
Originariamente inviato da PGI
Il detto circola da più parti, ma sarebbe bene sfatare la favola, in cui moltissimi credono ed in assoluta buona fede.

Le prestazioni delle "VM di una volta" sono, come tutte ciò che "era una volta": un mito. L'interpretazione del codice della VM 1.1 genera un risultato costantemente da 30 a 40 volte più lento del corrispondente codice C++ compilato con gcc, su piattaforma Unix [Marner 2002].

Java 1.1 = "una volta" = anno domini 1997.

Java 1.3, Sun introduce la tecnologia HotSpot (la macchina virtuale carica il codice in modalità interpretata, mentre è in esecuzione analizza il bytecode e traduce le parti che ritiene ottimizzabili direttamente in codice macchina). Java cessa di essere un linguaggio "interpretato" e diventa misto, compilato-interpretato. Quanto è efficente il JIT di Sun? Poco in assoluto, enormemente per la differenza [Ladd 2002]: codice C++ (procedurale, gcc 1.3) batte java 1 a 1.2 (jvm 1.3) e addirittura 1 a 3 con la versione successiva di Java 1.4.0 (!!! l'alcool gira anche a Palo Alto ). La server vm 1.3 di IBM in compenso fa tirare un sospiro di sollievo a tutti e strappa uno stupefacente 1 a 0.9 (a casa Big Blue sono per fortuna astemi).

Java 1.3 = "ieri" = anno domini 2001.

Oggi, 2004 il pc di casa mia, almabench, lo stesso della storiella che vi ho raccontato. La jvm (Sun HotSpot 1.5 beta 1) stacca l'exe C++ (procedurale) dell' 11.4% (54.7 vs 61.2, tempi medi).

La morale della favola non è che Java sia più veloce di C++ (perchè è solo un benchmark), ma che dire "ahh la vecchia VM 1.1 di Sun, MS, IBM" è come dire "ahhh, la torta della nonna" quando la nonna le torte le bruciava tutte.

Per curvare un po' più on-topic, io ho letto con interesse una dichiarazione del CEO di Sun, in merito alle strategie per lo sviluppo della compagnia, secondo cui Sun punterebbe su Javadesktop perchè ha stretto accordi con la Cina per portare Linux+StarOffice (al posto di chi sappiamo) nella pubblica amministrazione, col nemmeno troppo velato intento di sfruttare la cosa per poter poi vendere i suoi server, oltre a tutto l'amabaradan che va dietro a Java versione "enterprise" (certificazioni, corsi di formazione, application server ecc.).

Mi sembra, tutto sommato, una cosa buona che marchi storici sani (vedi IBM) e un po' meno sani, ma sempre storici (Sun ) sterzino verso Linux (almeno un pochino).


beh io n ho pretese di sapere com'era una volta in toto e come sarà, dato che queste cose le stò ancora studiando.

Però sulla base della mia esperienza personale e di altri amici, ho potuto constatare come la Java Virtual Machine Micrsooft fosse + veloce a caricare le applet ad es di quanto n lo è quella della Sun, che trovo troppo barocca e completa per certi punti di vista.

E se hai letto bene n stavo facendo nessun paragone con linux, ci mancherebbe.

starless27 Aprile 2004, 19:58 #13

Quando è uscito il primo?

Scusate, ma allora... la prima versione del Java Desktop System è già uscita? Quando? Me la sono persa?
Non ho visto neanche una recensione...

Oltretutto avrei dovuto anche riceverne un CD demo gratuito, per una iscrizione che avevo fatto sul sito Sun.
cdimauro28 Aprile 2004, 07:34 #14
Codice Java (compilato) che va più veloce di codice C++ mi sembra incredibile. Compilando un sorgente Java in bytecode si perdono già parecchie informazioni che provengono dal sorgente, per cui è ben più difficile tirare fuori del codice eseguibile "veloce" analizzando direttamente il bytecode. Un compilatore C++, avendo a disposizione i sorgenti, dovrebbe permettere di avere un codice migliore.
A questo punto, visto che i compilatori (Sun vs Gnu) sono diversi, è probabile che il back-end utilizzato da Sun per generare il codice eseguibile finale sia migliore di quello di Gnu. Se fosse utilizzato al posto di quello Gnu, il compilatore C++ tirerebbe sempre fuori codice migliore rispetto a quello derivante dal byecode.
PGI28 Aprile 2004, 16:28 #15
La differenza maggiore risiede nel fatto che un compilatore qualsiasi che generi codice dipendente dalla piattaforma è in grado di ottimizzare in funzione delle istruzioni specificamente supportate dal processore (è facile vedere, anche nella pagina che ho segnalato, come ci sia un abisso tra la migliore prestazione ottenibile da una jvm e il risultato di un compilatore a cui siano passate istruzioni di ottimizzazione).

Che sia più difficile generare codice macchina efficente a partire dal bytecode mi sembra un po' bizzarro. Sono tutto fuorchè un esperto di codice macchina, tuttavia il set di istruzioni per la macchina virtuale java è nato con la specifica esigenza di essere "silicabile" (orrendo termine [Chang 1997]), come per altro ancora testimoniato nell'introduzione alle specifiche della JVM (Sun, The Java Virtual Machine Specifications, 2nd ed.).

Se il bytecode non può sfruttare, ad esempio, il set SSE, non è detto che non possa farlo il compilatore JIT (personalmente però ho forti dubbi che la HotSpot vada a verificare il tipo di processore).

xStarless.

Java Destop System 1 è già uscito, con un motore di ricerca si trovano anche alcune recensioni (non troppo entusiastiche a dire il vero ). In effetti, però, è apparso in sordina, io ho visto che c'era l' 1 dopo aver letto dell'uscita del 2
cdimauro29 Aprile 2004, 22:23 #16
Mi riferivo al fatto che un sorgente, una volta compilato in bytecode, perde molto delle informazioni in esso presenti, per cui è comunque più difficile per un compilatore capire in che modo creare del codice più efficiente a partire da esso. Poco importa che Java sia "silicabile".
theClimber30 Aprile 2004, 00:24 #17
Non e' che il bytecode java abbia molte meno informazioni del sorgente stesso ... Se provi a decompilare codice java, l'unica cosa che di solito non trovi piu' sono i commenti del programmatore
Questo rende anche piu' facile ottimizzare il codice, dato che vengono rimosse parti inutili (x la macchina) del sorgente.

Vantaggio ulteriore non da poco della compilazione Hot Spot e' anche il fatto che il codice si ottimizza in base a come viene usato, in questo modo un programma magari parte lento, ma si ottimizza man mano che viene usato, in base all'uso stesso.


cdimauro30 Aprile 2004, 07:47 #18
In pratica è ciò che fa il code morphing di Transmeta o il Dynamo sviluppo da HP (il primo ad essere sviluppato).
Comunque, non conosco bene "l'ISA" di una virtual macchine java, ma non credo che siano stati implementati dei costrutti ad alto livello. Il sorgente che viene fuori da una decompilazione dipende fortemente dal tipo di applicazione: se è fortemente basata sull'utilizzo di classi/oggetti, è chiaro che si può risalire quasi per intero a quello originale (commenti esclusi, ovviamente), ma nel caso di implementazioni di algoritmi di una certa consistenza, dubito che il bytecode riesca a conservare abbastanza informazioni per ricavare un sorgente "paragonabile".
theClimber01 Maggio 2004, 10:21 #19
Che cosa intenti per 'algoritmi di una certa consistenza' ? Mi sembra che il problema potrebbe emergere nel caso in cui alcuni costrutti del linguaggio non siano mappati in modo biunivoco nel byte code.

Se togli classi/oggetti cosa ti rimane in java: i tipi primitivi, le operazioni di controllo di flusso, i cicli. Tutti questi costrutti sintattici del sorgente hanno la loro rappresentazione univoca nel byte code.

Questo deve accadere per permettere alle JVM specifiche per ogni piattaforma HW di tradurle in istruzioni macchina specifiche per la rispettiva architettura.

Sicuramente possono esistere casi in cui non riottieni esattamente il codice originale, per esempio in java 1.5 con i Generics (http://www.informit.com/articles/ar...76&seqNum=4 ) e l'auto boxing/unboxig dei tipi primitivi. Questo tipo di feature del linguaggio sono orientate alla generazione di byte code comunque compatibile x tutte le architetture.

cdimauro01 Maggio 2004, 15:25 #20
Originariamente inviato da theClimber
Che cosa intenti per 'algoritmi di una certa consistenza' ? Mi sembra che il problema potrebbe emergere nel caso in cui alcuni costrutti del linguaggio non siano mappati in modo biunivoco nel byte code.

Esattamente. Quando si utilizzano classi e methodi, è facile riuscire a ricostruire il sorgente originale, mentre con l'uso di costrutti ad alto livello non è sempre facile che ciò avvenga, anzi.
E questo capita anche con algoritmi un po' meno banali: ad esempio, se prendiamo quello di compressione o decompressione di dati in formato ZIP, che consta di diversi passi e di routine abbastanza lunghe, difficilmente riotterremo lo stesso sorgente.
Se togli classi/oggetti cosa ti rimane in java: i tipi primitivi, le operazioni di controllo di flusso, i cicli. Tutti questi costrutti sintattici del sorgente hanno la loro rappresentazione univoca nel byte code.

Non credo che sia univoca. Tanto per fare un esempio: il for di Java/C è assimilabile a un while. E' talmente assimilabile che a volte non è possibile effettivamente decidere se nel sorgente originale c'era il primo o il secondo.
Questo deve accadere per permettere alle JVM specifiche per ogni piattaforma HW di tradurle in istruzioni macchina specifiche per la rispettiva architettura.

E' chiaro che il bytecode, di per sé, rappresenta un'architettura ben definita, per cui la macchina host deve interpretare in maniera univoca il suo contenuto ed eseguirlo correttamente. Ma ciò non implica assolutamente (e non è proprio così che, a partire da un sorgente, un qualunque compilatore debba produrre lo stesso bytecode in output. Ognuno effettuando il parsing si costruisce una propria rappresentazione interna di ciò che ha letto dal sorgente, e il proprio ottimizzatore provvederà poi a interpretare le tuple e generare un codice che [U]per lui[/U] è migliore.
Sicuramente possono esistere casi in cui non riottieni esattamente il codice originale, per esempio in java 1.5 con i Generics (http://www.informit.com/articles/ar...76&seqNum=4 ) e l'auto boxing/unboxig dei tipi primitivi. Questo tipo di feature del linguaggio sono orientate alla generazione di byte code comunque compatibile x tutte le architetture.

Indubbiamente. Ma come tu ben sai, nei seguenti casi:
x = x + 1;
x += 1;
x++;
++x;
Il codice che un compilatore può generare può essere diverso, oppure esattamente uguale, ma questo nessuno lo garantisce. E come questo che è un caso estremamente semplice, immagina cosa possa accadere un codice più complesso e con dei costrutti ad alto livello...
« Pagina Precedente     Pagina Successiva »

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^