Link alla notizia: http://news.hwupgrade.it/12300.html

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

Click sul link per visualizzare la notizia.

Basta che non sia pesante come programmi Java...

se sun diventa il riferimento in ambito di desktop linux viste le recenti alleanze con microsoft direi che siamo nella "nutella" fino al collo

Beh dai.. vedila positivamente...

Two è meglio che One! ;)

mah...

se sun diventa il riferimento in ambito di desktop linux viste le recenti alleanze con microsoft direi che siamo nella "nutella" fino al collo

se la collaborazione punta a snellire la Virtual Machine della Sun e a riportarla com'era una volta quella MS, io sarei ben contento.

Non credo che gli accordi si spingano molto + in là anche perchè il Java Desktop è pensato appositamente per i mercato orientali che non ne vogliono minimamente sapere delle piattaforme Windows.

Per capire dove vuole arrivare sun date uno sguardo all'interfacia "Looking Glass" che sta preparando.

Originariamente inviato da DioBrando
se la collaborazione punta a snellire la Virtual Machine della Sun e a riportarla com'era una volta quella MS, io sarei ben contento.


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 :D). 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 :D) sterzino verso Linux (almeno un pochino).

mi piacerebbe vedere il codice con cui sono stati effettuati questi test.

dimenticavo, non metto in dubbio i dati riguardanti le varie versioni di JVM, ma che un programma java giri + veloce di uno C++ procedurale nativo x86...beh...scusa ma stento a crederci:)

puoi darci maggiori

Non vorrei dovermi quotare: non ho postato per dire che Java sia più veloce di C++, l'ho fatto per dire che Java è più veloce di Java.

http://www.coyotegulch.com/reviews/almabench.html

Il link per il codice sorgente è in blu, poco prima di metà pagina.

Il sistema su cui ho fatto la prova con il codice:

WinXp Pro, 2xAMD MP2400+, 1gb DDR266

Non avendo la funzione time di Linux ho aggiunto 2 istruzioni getTime e 1 output al codice C++ e al codice Java, nella stessa posizione, subito prima del ciclo esterno (tempo iniziale) e subito dopo il ciclo esterno, più un output a cose fatte. (clock() per C++ e System.nanoTime() per Java)

Il codice C++ è stato compilato con g++, senza flag. Il codice Java è stato compilato con javac, versione 1.5.0-beta, su codice 1.4 (cioè non ho volutamente modificato il codice perchè tenesse conto delle ultime "new entry"). Senza flag...anche perchè non ce ne sono :D

L'esecuzione è avvenuta da linea di comando. Per java ho usato la macchina virtuale Sun client 1.5.0-beta-b32c.

Confesso di essere molto incuriosito dalle prestazioni della HotSpot 1.5 su macchine diverse dalla mia, se qualcuno dovesse provare magari faccia un pensierino sull'apertura di un thread nella sezione programmazione, perchè qui nelle news forse non è il luogo più adatto.

Originariamente inviato da The3DProgrammer
mi piacerebbe vedere il codice con cui sono stati effettuati questi test.

Se andate al seguente sito:
http://www.alessandropulvirenti.it/programmazione/

troverete un Test dei vari linguaggi di programmazione.

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 :)

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 :D). 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 :D) 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.

;)

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.

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.

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 :D). In effetti, però, è apparso in sordina, io ho visto che c'era l' 1 dopo aver letto dell'uscita del 2 :D

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". ;)

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.

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".

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/article.asp?p=170176&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.

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 per lui è 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/article.asp?p=170176&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...

Originariamente inviato da cdimauro
....
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.
.....
Il codice che un compilatore può generare può essere diverso, oppure esattamente uguale, ma questo nessuno lo garantisce


Hai ragione, java non definisce uno standard di compilazione programmaticamente (Un approccio interessante utilizzato ad esempio in Squeak (http://users.ipa.net/~dwighth/squeak/oopsla_squeak.html) in cui la VM viene generata a partire da una codice di alto livello, in modo da garantire un esecuzione bit-identica su differenti architeture) , ma fornisce specifiche documentali.

Ma dato che quello che si sta producendo e' bytecode che deve essere conforme all'architettura specificata della JVM, le differenze prodotte da vari compilatori sono relativamente ridotte. (E' chiaro che si possono o no utilizzare algoritmi per fare inlining, come tipicamente avviene per i field e metodi final, e altre cose, ma si tratta di ottimizzazioni rispetto all'architettura della JVM, non rispetto alla macchina fisica che seguira' il codice)

Da questo punto di vista il bytecode ha si subito una prima fase di elaborazione, ma questa non e' dipendente dalla macchina fisica su cui verra' eseguito.

Originariamente inviato PGI
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.).


Questo e' il secondo step di compilazione, che a questo punto puo' essere specifico a seconda dall'implementazione della JVM per l'architettura fisica.
L'ottimizzazione e' basata sul bytecode prodotto e non vedo difficolta rispetto a quella del sorgente originario (E' una rappresentazione in larga parte 'equivalente' )

Certamente c'e' un trade-off: alcune delle scelte di ottimizzazione fatte durante la compilazione Sorgente-Bytecode possono avere impatti diversi su diverse JVM. Un processo di compilazione unico Sorgente-Codice macchina potrebbe essere potenzialmente piu' efficiente anche se non portabile (e quindi addio ad uno dei benefici di java, non potrei usare il mio IDE preferito sotto windows e sotto linux ;) ).

Originariamente inviato PGI
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).


Anch'io ho forti dubbi, dal codice delle librerie di java (mi vengono immente il Java3D o l'ImageToolkit), molte scelte di ottimizzazione per piattaforma sono trattate a livello applicativo con pattern di tipo AbstractFactories per istanziare implementazioni alternative, che magari si agganciano a API native.

Discorso interessante, se qualcuno ha altre info, sono curioso

Ciao :)

OK, la situazione adesso è chiara. :)

P.S. Il pattern "AbstractFactories" a cui ti riferisci è il famoso "Facade" pattern (con la "c" spagnola)?

No, non e' la stessa cosa della Façade. ma e' collegato.
Ti faccio un breve esempio:

In pratica esiste una classe astratta (questa e' l'Abstract Factory) che ha un metodo statico per costruire un oggetto; questo metodo richiama un metodo di istanza della factory concreta.
L'oggetto restituito implementa un interfaccia (E qui ci sta il Façade pattern :) ) ma l'implementazione concreta dipende da quale istanza concreta della classe e' stata usata per costruire l'oggetto. Tipicamente si controllano delle properties di sistema, e poi si usa la reflection per instanziare la factory concreta.

Su internet si trovano un sacco di pagine sui pattern, ma io partirei dal mitico wiki di Ward Cunningham:
http://www.c2.com/cgi/wiki?AbstractFactory

Ciao

Ti ringrazio per la precisazione e per il link. :)