Java Desktop System 2 di Sun: esce a Maggio

[Redazione di Hardware Upg]

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.

[Dias]

Basta che non sia pesante come programmi Java...

[NJoy]

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

[Imperatore Neo]

Beh dai.. vedila positivamente...

Two è meglio che One!

[DioBrando]

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.

[lamp76]

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

[PGI]

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

[The3DProgrammer]

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

[The3DProgrammer]

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

[PGI]

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

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.

[AlexPulv]

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.

[PGI]

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

[DioBrando]

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.

[starless]

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.

[cdimauro]

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.

[PGI]

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

[cdimauro]

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

[theClimber]

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.

[cdimauro]

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

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

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/art...70176&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.