Looking Glass: desktop 3D da Sun [Archivio]

ZerOFraG

28-10-2004, 09:17

Originariamente inviato da cionci
Certo che se lo fanno in Java è ovvio che sia lento..

Originariamente inviato da Banus
Stessa opinione :D
Dopo aver visto che fantastica quantità di memoria mi divorava NetBeans sotto Win ho perso la fiducia nella fattibilità di applicazioni visuali complesse in Java...

Basta con queste frasi fatte.
Se non conoscete a fondo java e il suo mondo non parlate a vanvera.
Java è un linguaggio server-side e, pur essendo intrepretato, non è affatto lento.
Le applicazioni client soffrivano di una certa lentezza nella prima versione (1.0 - 1996 se non ricordo male), già dal jdk 1.1 furono cambiate api e jvm.
Oggi, con le varie ottimizzazioni che si sono susseguite e con l'utilizzo di hotspot, anche le applicazioni lato client e soprattutto l'interfaccia utente sono veloci come la controparte scritta in c++ sotto win.
Se poi uno non sa programmare, riesce a scrivere codice lentissimo anche in c++, ve l'assicuro.

Quindi, invece di usare netBeans o eclipse, che sono dei mastodonti abominevoli, che non girerebbero fluidi manco su un amd64 con 2 GB di RAM e dischi fissi raptor in raid 0, provate qualcosa che è anni luce avanti. Provate il precursore degli ambienti di sviluppo moderni, quello che per primo ha implementato le funzionalità di refactoring (poi copiate da eclipse e da netbeans).
Se non lo conoscete, si chiama intellij idea. Il sito è questo (http://www.jetbrains.com/) e qui (http://www.jetbrains.com/idea/download/) potete scaricare la versione full demo.

Provatelo, poi mi dite se java è lento client-side...
Ah, chiaramente è scritto completamente in java.

P.S. certo che sentire certe affermazioni da un moderatore... :rolleyes:

cionci

28-10-2004, 09:58

Originariamente inviato da ZerOFraG
Provatelo, poi mi dite se java è lento client-side...
Ah, chiaramente è scritto completamente in java.

P.S. certo che sentire certe affermazioni da un moderatore... :rolleyes:
E ti dirò di più, sono anche moderatore di Programmazione :rolleyes:
Nessuno mette in discussione i vantaggi di Java dal punto di vista server-side...e nemmeno le prestazioni in questo ambito...
Ma per favore lasciamo perdere il client-side...e per di più una interfaccia grafica...e per gunta tridimensionale... :rolleyes:

Quindi diamo ad ogni linguaggio il suo campo di utilizzo opportuno...il lato-client non è quello di Java...

Narmo

28-10-2004, 10:06

A dire il vero vedo solo un altro desktop manager, bello quanto volete, ma per giudacarlo, oltre alle prestazioni pure, è necessario vedere come se la caverà di fronte ai due giganti KDE e GNOME.....

In verità penso che alla Sun la vera sfida non sia quella di scrivere un Desktop Manager in 3D ma semplicemente di farlo usando Java

sheijtan

28-10-2004, 10:08

Originariamente inviato da ziozetti
Ho visto le immagini del desktop 3d della Sun... mi sembra di una inutilità pazzesca. Sarò retrogrado? :D

sì, sei decisamente retrogrado...
ma come fai a non intravederne le enormi potenzialità? per me già i desktop virtuali delle gui linux hanno rappresentato una svolta e un modo per organizzare meglio il lavoro (e di fatto aumentano semplicemente l' area dell' ambiente desktop), pensa avere a disposizione una terza dimensione!

p.s: daje bill! forza a copiare!

ilsensine

28-10-2004, 10:11

Originariamente inviato da cionci
E ti dirò di più, sono anche moderatore di Programmazione :rolleyes:
Nessuno mette in discussione i vantaggi di Java dal punto di vista server-side...e nemmeno le prestazioni in questo ambito...
Ma per favore lasciamo perdere il client-side...e per di più una interfaccia grafica...e per gunta tridimensionale... :rolleyes:

Quindi diamo ad ogni linguaggio il suo campo di utilizzo opportuno...il lato-client non è quello di Java...
Pesantuccio lo è, comunque lo ho provato al Linux World Expo e non è affatto male (non so che bestia di computer avevo sotto). Quello che mi ha stupito è che qualsiasi applicazione per X sfrutta il look'n'feel 3d (nella buona tradizione unix di scorporare il server X dal window manager, che molti criticano).

C'è anche un simile progetto in c:
http://insitu.lri.fr/~chapuis/metisse/index.html
però ha delle limitazioni e qualche bugghetto (fa già delle belle cose, ho provato anche questo)

ziozetti

28-10-2004, 10:43

Originariamente inviato da sheijtan
sì, sei decisamente retrogrado...
ma come fai a non intravederne le enormi potenzialità? per me già i desktop virtuali delle gui linux hanno rappresentato una svolta e un modo per organizzare meglio il lavoro (e di fatto aumentano semplicemente l' area dell' ambiente desktop), pensa avere a disposizione una terza dimensione!

p.s: daje bill! forza a copiare!
Mi trovi d'accordo sui desktop virtuali, in quel caso hai un desktop di area doppia/tripla/quadrupla.
La terza dimensione invece è ancora più virtuale, non vedo alcuna potenzialità.
Senza polemica, spiegami cosa intendi. :)

ZerOFraG

28-10-2004, 11:05

Originariamente inviato da cionci
E ti dirò di più, sono anche moderatore di Programmazione :rolleyes:

Mi spiace dirlo, ma questo rende l'affermazione ancora più grave.
che ricordo, è:

Originariamente inviato da cionci
certo che se lo fanno in Java è ovvio che sia lento..

Ma per favore lasciamo perdere il client-side...e per di più una interfaccia grafica...e per gunta tridimensionale... :rolleyes:

Quindi diamo ad ogni linguaggio il suo campo di utilizzo opportuno...il lato-client non è quello di Java...

Allora, dato per assodato che java è (allo stato attuale, per carità) IL linguaggio server-side, questo non significa che non si possa scrivere un client veloce.
Ripeto, se non si hanno esperienze o si hanno pregiudizi, meglio farsi un esema di coscienza e abbandonare un ruolo che dovrebbe essere "super partes" e richiedere un po' di attenzione quando si scrive, dato che molti (soprattutto chi è nuovo o non è ferrato su un certo argomento) giustamente prendono quello che scrivono i moderatori come riferimento.

Kars

28-10-2004, 11:14

Non criticate questo progetto, lo seguo da diverso tempo ed e' fenomenale , il suo successo cmq dipendera' molto dalla sua data di uscita che spero sia molto presto.

Per chi dice che sara' di una lentezza mostruosa , gli rispndo di guardarsi i video dimostrativi, nei quali si puo' ampiamente vedere la velocita', quindi leggerezza, del sistema mentre gira su un portatile :)

ErPazzo74

28-10-2004, 11:18

le interfacce 3d son decenni che vengono sperimentate nn ci vedo niente di male, a me sembra solamente paura del diverso e del dover imparare qualcosa....cmq l'importante e' che si sviluppino cosi' ognuno scegliera'....

RaouL_BennetH

28-10-2004, 11:19

Originariamente inviato da Kars

Per chi dice che sara' di una lentezza mostruosa , gli rispndo di guardarsi i video dimostrativi, nei quali si puo' ampiamente vedere la velocita', quindi leggerezza, del sistema mentre gira su un portatile :)

Ho solo una cosa da obiettare ma forse per inesperienza, ovvero che non mi pare che la velocità sia sinonimo di leggerezza. Nel senso che anche un videogame, può girarti velocemente se hai un buon hw, ma non è detto che sia leggero. O sbaglio?

cionci

28-10-2004, 11:35

Originariamente inviato da ZerOFraG
Mi spiace dirlo, ma questo rende l'affermazione ancora più grave.
che ricordo, è:

Allora, dato per assodato che java è (allo stato attuale, per carità) IL linguaggio server-side, questo non significa che non si possa scrivere un client veloce.
Ripeto, se non si hanno esperienze o si hanno pregiudizi, meglio farsi un esema di coscienza e abbandonare un ruolo che dovrebbe essere "super partes" e richiedere un po' di attenzione quando si scrive, dato che molti (soprattutto chi è nuovo o non è ferrato su un certo argomento) giustamente prendono quello che scrivono i moderatori come riferimento.
Chi l'ha detto che un moderatore debba essere superpartes ? Io non posso avere i miei gusti e consigliare/sconsigliare secondo la mia esperienza ?
Poi cosa ho detto ? Ho detto che se si cercano le prestazioni e la leggerezza Java non è sicuramente il linguaggio migliore...
Mi puoi dare torto ? Magari si potranno anche creare applicazioni client-side leggere e prestanti in Java...è probabile...ma vallo ad insegnare ai milioni di sviluppatori che ci sono in giro perchè ogni programma scritto interamente in Java che ho usato (parlo da utente in questo caso, perchè è bene o male l'obiettivo di un programma client-side) è mostruosamente lento ed impegnativo per il sistema...

Riguardo alla mia moderazione...sono prima di tutto un utente e poi un moderatore...perchè mi devo riguardare in quello che scrivo ? Qui non mi pagano e per questo non devo modificare il mio comportamento per venire incontro a chi, come te, se la prende se gli toccano il suo gioiellino...

Kars

28-10-2004, 11:41

era nel contesto del fatto che il sistema girava su un portatile , non a caso e' stato scelto per fare la dimostrazione.

Nel senso che anche un videogame, può girarti velocemente se hai un buon hw, ma non è detto che sia leggero

Per il fatto di velocita' = leggerezza potremmo parlarne per giorni , ognuno poi ha i suoi concetti, io la vedo cosi'

Un videogame pesante richiedera' comunque un hardware potente per girare veloce, un videogame leggero potrebbe cmq richiedere hw potente per girare veloce, non e' importante l' hw che hai sotto ma il software che ci girera' :)

Banus

28-10-2004, 12:28

Originariamente inviato da ZerOFraG
Basta con queste frasi fatte.

[cut]
Se non lo conoscete, si chiama intellij idea. Il sito è questo (http://www.jetbrains.com/) e qui (http://www.jetbrains.com/idea/download/) potete scaricare la versione full demo.
Non sono frasi fatte. Io mi baso sulla mia (limitata) esperienza e ho notato che le applicazioni Java sono spesso molto più lente di applicazioni scritte in codice nativo di pari complessità.

L'applicazione che hai citato l'ho scaricata per vedere se i miei fossero solo pregiudizi. E' abbastanza leggera e veloce rispetto alle altre applicazioni Java che mi è capitato di conoscere, e ne sono contento perchè almeno qualcuno si preoccupa anche delle prestazioni...
Ma il menu ha un refresh molto lento e vedendo nel task manager vedo che occupa 57 MB in memoria (senza progetti aperti). Di contro, Visual Studio (paragonabile come complessità e usi suppongo) neo occupa 35.
Di questo non mi stupisco, dal momento che Java si basa su bytecode interpretato, e quindi anche nelle condizioni migliori difficilmente potrà essere più veloce e efficiente di codice nativo ben programmato.

lamp76

28-10-2004, 12:31

Per il progetto LG3D si sta cercando di far fare un'altro passo avanti a Java, creando un'interfaccia ad alte prestazioni in 3D.
In poche parole questo Window Manager scritto in java utilizzerà delle librerie grafiche che sfuttano le accelerazioni HW delle schede grafiche per il 3D.
A differenza di altri progetti sperimentali, LG3D intoduce dei nuovi modi per organizzare le finestre sul desktop ed una nuova gestione del multi desktop sfruttando la rotazione del campo di vista.
SECONDO ME LA COSA SARA' RIVOLUZIONARIA! In piu' se fatta in Java TAPPERA' PER SEMPRE la bocca di chi non sa fare altro che dire che "Java è lento ..." quando non ha nemmeno idea di cosa si stia parlando!

sheijtan

28-10-2004, 13:08

Originariamente inviato da lamp76
Per il progetto LG3D si sta cercando di far fare un'altro passo avanti a Java, creando un'interfaccia ad alte prestazioni in 3D.
In poche parole questo Window Manager scritto in java utilizzerà delle librerie grafiche che sfuttano le accelerazioni HW delle schede grafiche per il 3D.
A differenza di altri progetti sperimentali, LG3D intoduce dei nuovi modi per organizzare le finestre sul desktop ed una nuova gestione del multi desktop sfruttando la rotazione del campo di vista.
SECONDO ME LA COSA SARA' RIVOLUZIONARIA! In piu' se fatta in Java TAPPERA' PER SEMPRE la bocca di chi non sa fare altro che dire che "Java è lento ..." quando non ha nemmeno idea di cosa si stia parlando!

m' hai dato le conferme che aspettavo per gridare al miracolo:
Finalmente un applicativo di uso comune che sfrutta le moderne schede grafiche per qualcosa di diverso dai giochi 3d! Diamo un senso ai 300 euro!
daje sun! daje!

robibo68

28-10-2004, 13:19

ma come piffero si scarica?

cdimauro

28-10-2004, 13:30

Originariamente inviato da ZerOFraG
Basta con queste frasi fatte.
Se non conoscete a fondo java e il suo mondo non parlate a vanvera.
Java è un linguaggio server-side e, pur essendo intrepretato, non è affatto lento.
Le applicazioni client soffrivano di una certa lentezza nella prima versione (1.0 - 1996 se non ricordo male), già dal jdk 1.1 furono cambiate api e jvm.
Oggi, con le varie ottimizzazioni che si sono susseguite e con l'utilizzo di hotspot, anche le applicazioni lato client e soprattutto l'interfaccia utente sono veloci come la controparte scritta in c++ sotto win.
Se poi uno non sa programmare, riesce a scrivere codice lentissimo anche in c++, ve l'assicuro.
Le frasi non sono fatte: sono i tuoi paragoni ad essere completamente sballati, visto che parli con assoluta leggerezza di cose di cui dimostri di non conoscere il significato. E per di più pretendi di zittire e fare la paternale agli altri: ma stai un po' zitto tu e colma la tua ignoranza in materia! :rolleyes:

Java E' LENTO, proprio perché è un linguaggio che, una volta compilato in bytecode, dev'essere INTERPRETATO dalla virtual machine. Sai cosa vuol dire interpretato? Se ti spacci per programmatore, dovresti esserne a consoscenza.

E' ASSURDO il fatto che tu pretendi di metterlo a confronto con C++ e con linguaggi che producono un binaro che gira nativamente per la piattaforma per la quale sono stati compilati: non c'è assolutamente paragone.

Il paragone si può fare se per il bytecode viene utilizzata qualche tecnica JIT.

L'unica cosa su cui mi puoi trovare d'accordo è sul fatto che GENERALMENTE le interfacce utente NON HANNO bisogno di essere veloci. Ma questo è un discorso a sé stante.

Buono studio.

ziozetti

28-10-2004, 13:36

Mi spiegate, di grazia, in cosa sarà rivoluzionario?
Sinceramente non riesco a capirlo...
PS: Sono retrogrado, me l'hanno già scritto...

Banus

28-10-2004, 14:50

Mi sono visto il video per curiosità.
Le idee proposte sono molto interessanti. Ho notato una certa cura nella facilità d'uso. Geniale la possibilità di inserire note o informazioni di supporto sul retro della finestra, davvero molto comodo :D

cionci

28-10-2004, 14:52

Originariamente inviato da Banus
inserire note o informazioni di supporto sul retro della finestra, davvero molto comodo :D
Roba che uno usa la prima volta per provarlo...e poi si dimentica di averla :)

bejo

28-10-2004, 15:05

devo dire che le potenzialità intraviste dal videosembrano mooooolto elevate...per l'utilità ne riparleremo ma non vedo l'ora di provarlo!!!

midian

28-10-2004, 15:12

Le risorse hardware richieste non sono però così ridotte, si vocifera che per supportare il tutto sarà necessaria una CPU da 2 Ghz e 512MB di RAM. :muro: :muro: :muro:
e su quanti pc girera fluidamente???

bejo

28-10-2004, 15:28

su tutti i pc usciti da 2 o 3 anni.
Il mondo va avanti.

ZerOFraG

28-10-2004, 15:33

Originariamente inviato da cdimauro
Le frasi non sono fatte: sono i tuoi paragoni ad essere completamente sballati, visto che parli con assoluta leggerezza di cose di cui dimostri di non conoscere il significato. E per di più pretendi di zittire e fare la paternale agli altri: ma stai un po' zitto tu e colma la tua ignoranza in materia! :rolleyes:

Java E' LENTO, proprio perché è un linguaggio che, una volta compilato in bytecode, dev'essere INTERPRETATO dalla virtual machine. Sai cosa vuol dire interpretato? Se ti spacci per programmatore, dovresti esserne a consoscenza.

E' ASSURDO il fatto che tu pretendi di metterlo a confronto con C++ e con linguaggi che producono un binaro che gira nativamente per la piattaforma per la quale sono stati compilati: non c'è assolutamente paragone.

Il paragone si può fare se per il bytecode viene utilizzata qualche tecnica JIT.

L'unica cosa su cui mi puoi trovare d'accordo è sul fatto che GENERALMENTE le interfacce utente NON HANNO bisogno di essere veloci. Ma questo è un discorso a sé stante.

Buono studio.

Eccone un altro che non legge prima di scrivere. Vorrei proprio sapere DOVE ho dimostrato di parlare con leggerezza o in che occasione ho espresso concetti di cui non capisco il significato.
Innanzitutto non è mio costume parlare di cose che non conosco approfonditamente.
Poi, per tua conoscenza, il mio primo progetto in java (un application server, se sai cosa significa) l'ho fatto nel '98.
Da allora ho sempre usato (e uso tuttora) java, sia SE ma soprattutto EE.
E questa è la mia esperienza professionale puramente pragmatica in java. Ti risparmio i titoli accademici e non a riguardo, perchè non è il luogo adatto.
Quindi ti assicuro che non devi venirmi a insegnare tu cosa sia un compilatore, un linker, cosa sia un linguaggio intrepretato, un bytecode, perchè probabilmente sarei io a doverti insegnare qualcosa.
Tornando a noi, sai da quanto esiste un JIT per la JVM? E sai da quanti anni è attivata di default? Sai cos'è HotSpot? Credo proprio di no, altrimenti non scriveresti certe cose.
Per cui, lasciati dare un consiglio: la prossima volta, prima di provare a spalare m***a su qualcuno, pensaci perchè ci corri il rischio di rimanerci sotterrato come questa volta.

Tornando IT, mi spiace, ma si stava parlando di tutt'altro.
Di interfacce utente, di gui e della velocità di una di una applicazione con una gui scritta in java. E io ho affermato (e continuo a farlo) che non è necessariamente vero che le GUI scritte in java debbano essere lente e che possono essere paragonate a quelle scritte in c++ (e limitiamoci al mondo windows).
Se qualcuno come te ha voluto leggerci qualcosa di diverso, problemi suoi. Io dico la verità, facilmente constatabile, altri probabilmente difendono una "fede". :rolleyes:
Se poi un utente riesce a rendersi conto di una differenza all'ordine dei millisecondi nell'apertura di una finestra o di un menù a tendina, presentatemelo.

Comunque, il concetto è proprio questo: a furia di fare affermazioni all'acqua di rose ("java è lento"), i post come il tuo sono il risultato.

Mah...

ZerOFraG

28-10-2004, 15:41

Originariamente inviato da cionci
Chi l'ha detto che un moderatore debba essere superpartes ? Io non posso avere i miei gusti e consigliare/sconsigliare secondo la mia esperienza ?

Certo, era quello che intendevo. Ma presumo che l'esperienza, per dare consigli, deve essere vasta, altrimenti si rischia di fuorviare. Oppure si può consigliare solo per quello che si conosce...

Poi cosa ho detto ? Ho detto che se si cercano le prestazioni e la leggerezza Java non è sicuramente il linguaggio migliore...
Mi puoi dare torto ? Magari si potranno anche creare applicazioni client-side leggere e prestanti in Java...è probabile...ma vallo ad insegnare ai milioni di sviluppatori che ci sono in giro perchè ogni programma scritto interamente in Java che ho usato (parlo da utente in questo caso, perchè è bene o male l'obiettivo di un programma client-side) è mostruosamente lento ed impegnativo per il sistema...

Mi spiace ammetterlo ma è proprio così: non è questo il posto giusto e non mi va di alimentare ancora la discussione in questo senso, per cui non proseguo, ma hai centrato il punto.

Riguardo alla mia moderazione...sono prima di tutto un utente e poi un moderatore...perchè mi devo riguardare in quello che scrivo ? Qui non mi pagano e per questo non devo modificare il mio comportamento per venire incontro a chi, come te, se la prende se gli toccano il suo gioiellino...

Il perchè te l'ho scritto, ma noto che abbiamo un concetto di moderazione profondamente diverso. Poi per carità, se devi prendertela così tanto, mi asterrò da ulteriori consigli.

ZerOFraG

28-10-2004, 15:56

Originariamente inviato da Banus
Non sono frasi fatte. Io mi baso sulla mia (limitata) esperienza e ho notato che le applicazioni Java sono spesso molto più lente di applicazioni scritte in codice nativo di pari complessità.

Potrebbe anche essere vero, ma potrebbe anche non dipendere da Java in sè...

L'applicazione che hai citato l'ho scaricata per vedere se i miei fossero solo pregiudizi. E' abbastanza leggera e veloce rispetto alle altre applicazioni Java che mi è capitato di conoscere, e ne sono contento perchè almeno qualcuno si preoccupa anche delle prestazioni...
Ma il menu ha un refresh molto lento e vedendo nel task manager vedo che occupa 57 MB in memoria (senza progetti aperti). Di contro, Visual Studio (paragonabile come complessità e usi suppongo) neo occupa 35.
Di questo non mi stupisco, dal momento che Java si basa su bytecode interpretato, e quindi anche nelle condizioni migliori difficilmente potrà essere più veloce e efficiente di codice nativo ben programmato.

Ti ringrazio per la fiducia e per aver perso del tempo.
Spero abbia comunque contribuito a far crescere la tua esperienza in merito.
Per quanto riguarda i menu, a me non ha mai dato questo problema, ma magari ho un computer più veloce.
Per quanto riguarda l'occupazione di memoria, credo che il task manager faccia vedere anche quella occupata dalla JVM associata al programma in esecuzione, per cui, quello che vedi è la somma di JVM + Idea, tant'è che a me, con un progetto di 224 classi e tutte le librerie di progetto caricate ne occupa intorno ai 50 (chiaramente dipende da quando interviene il GarbageCollector a ripulire la memoria).
Per quanto riguarda la diatriba interpretato/compilato, può anche essere vero (e sarebbe troppo lungo e fuori luogo spiegare l'uso del condizionale) e in genere lo è, ma qui stavamo parlando specificatamente di GUI, non dimentichiamolo.
Quello che tenevo a far notare è che non è detto che una gui scritta in java debba necessariamente essere lenta e di stare attenti a non cadere nel facile e ancora più impreciso (nonchè sostanzialmente falso) paradigma "java=lentezza".

Saluti.

krokus

28-10-2004, 18:41

Originariamente inviato da bejo
non mi pare che con i ben amati giochi 3d si vada a ravanare con la mano dentro al monitor hehehe

Appunto, hai ragione, ed è per questo che non vedo grandi rivoluzioni, anche se quelli della Sun ci vogliono far credere il contrario....
Per inciso, poi smetto, dal punto di vista dell'interazione nei giochi siamo praticamente fermi dai tempi di Doom2 e la sua prospettiva in prima persona...tuttora i vari Doom3, UT2004, Far Cry e compagnia hanno lo stesso tipo di visuale, affinato finchè si vuole, ma mai "rivoluzionario" come fu ai suoi tempi Wolf3D e il fratello Doom.
Ogni tanto qualcuno sforna una perla, tipo Starcraft e il suo 2D e mezzo, ma niente rivoluzioni...

Banus

28-10-2004, 20:33

Se la vogliamo mettere così è impossibile avere rivoluzioni... La visuale 3d in prima persona c'era da prima di Wolf3D (se ne parlava in un thread che non ho voglia di cercare), le finestre e la metafora della scrivania sono di Apple, la barra con le icone ancora di Mac OS...
Secondo me il metro dovrebbe essere: cosa me ne faccio di un ambiente desktop 3d? mi facilita le operazioni?
La Sun mi pare che si sia concentrata su quest'aspetto.

Se neppure questa è rivoluzione allora chiediamo a gran voce lo schermo virtuale alla Minority Report :D :D

Mason

28-10-2004, 20:48

Originariamente inviato da ilsensine
Pesantuccio lo è, comunque lo ho provato al Linux World Expo e non è affatto male (non so che bestia di computer avevo sotto). Quello che mi ha stupito è che qualsiasi applicazione per X sfrutta il look'n'feel 3d (nella buona tradizione unix di scorporare il server X dal window manager, che molti criticano).

C'è anche un simile progetto in c:
http://insitu.lri.fr/~chapuis/metisse/index.html
però ha delle limitazioni e qualche bugghetto (fa già delle belle cose, ho provato anche questo)

azz a saperlo che eri al linuxworldexpo (quello nel hotel a milano giusto?)...

concordo per metisse, e carino e gira benone:

http://mason.altervista.org/immagini/metisse.jpg

sotto freedesktop c'era il prototipo di un altro desktop manager 3d, ma sembrava abbastanza radicale nel concetto:

http://www.opencroquet.org/

cmq lo specchio si basa sulle java3d, che non e altro che un grafo di scena (non solo cmq) con mappate le chiamate verso opengl o directx(dipende dal estensione runtime che si sceglie), non penso che sia lento per la grafica, ma piu che altro penso sia lento a lato cpu, ovvero nella gestione logica delle finestre, non nella loro mappatura su schermo, rotazione o alpha blending

cdimauro

29-10-2004, 07:45

Originariamente inviato da ZerOFraG
Eccone un altro che non legge prima di scrivere. Vorrei proprio sapere DOVE ho dimostrato di parlare con leggerezza o in che occasione ho espresso concetti di cui non capisco il significato.
Ti rispondo dopo.
Innanzitutto non è mio costume parlare di cose che non conosco approfonditamente.
Poi, per tua conoscenza, il mio primo progetto in java (un application server, se sai cosa significa) l'ho fatto nel '98.
E allora? Lo stesso vale per me (guarda caso lo stesso anno).
Da allora ho sempre usato (e uso tuttora) java, sia SE ma soprattutto EE.
E questa è la mia esperienza professionale puramente pragmatica in java. Ti risparmio i titoli accademici e non a riguardo, perchè non è il luogo adatto.
Idem. ;)
Quindi ti assicuro che non devi venirmi a insegnare tu cosa sia un compilatore, un linker, cosa sia un linguaggio intrepretato, un bytecode, perchè probabilmente sarei io a doverti insegnare qualcosa.
Nei sei così sicuro? Esprimi sempre dei giudizi così affrettati senza conoscere le persone che ti sono davanti?
Tornando a noi, sai da quanto esiste un JIT per la JVM? E sai da quanti anni è attivata di default? Sai cos'è HotSpot? Credo proprio di no, altrimenti non scriveresti certe cose.
Per cui, lasciati dare un consiglio: la prossima volta, prima di provare a spalare m***a su qualcuno, pensaci perchè ci corri il rischio di rimanerci sotterrato come questa volta.
Beh, sei tu che hai scritto questo:
Java è un linguaggio server-side e, pur essendo intrepretato, non è affatto lento.
Quindi non mi sembra che lato server ci siano GUI che "aspettano" l'input dell'utente. E se è interpretato e non compilato, come dici, non può essere veloce nell'eseguire le richieste.
Ti ricordo che se funziona la JVM parliamo di interpretazione, e se invece è attiva la JIT parliamo di compilazione.
Per cui nella tua stessa frase ti sei smentito da solo: complimenti! :rolleyes:
Tornando IT, mi spiace, ma si stava parlando di tutt'altro.
Di interfacce utente, di gui e della velocità di una di una applicazione con una gui scritta in java. E io ho affermato (e continuo a farlo) che non è necessariamente vero che le GUI scritte in java debbano essere lente e che possono essere paragonate a quelle scritte in c++ (e limitiamoci al mondo windows).
Se qualcuno come te ha voluto leggerci qualcosa di diverso, problemi suoi. Io dico la verità, facilmente constatabile, altri probabilmente difendono una "fede". :rolleyes:
Se poi un utente riesce a rendersi conto di una differenza all'ordine dei millisecondi nell'apertura di una finestra o di un menù a tendina, presentatemelo.
Difatti, se avessi letto con pià attenzione quello che ho scritto:
L'unica cosa su cui mi puoi trovare d'accordo è sul fatto che GENERALMENTE le interfacce utente NON HANNO bisogno di essere veloci.
ti saresti risparmiato quest'ultima parte del messaggio... :rolleyes:
Comunque, il concetto è proprio questo: a furia di fare affermazioni all'acqua di rose ("java è lento"), i post come il tuo sono il risultato.

Mah...
A me sembra proprio sei stato tu a fare confusione e a tirare fuori giudizi campati per aria... E poi impara a leggere TUTTO quello che viene scritto, prima di rispondere affrettatamente... :mc:

ZerOFraG

29-10-2004, 08:08

Rispondo solo su una cosa tecnica, visto che tanto riesci a rigirare il resto come ti pare e come ti fa più comodo, travisando e male interpretando (un bug?) la realtà, per cui ritengo inutile continuare a perdere tempo.

Originariamente inviato da cdimauro
Ti ricordo che se funziona la JVM parliamo di interpretazione, e se invece è attiva la JIT parliamo di compilazione.
Per cui nella tua stessa frase ti sei smentito da solo: complimenti! :rolleyes:

Non funziona proprio così, o meglio, cerchiamo di essere precisi: il JIT è NELLA VirtualMachine, a fianco dell'interprete, per cui il bytecode o viene interpretato o viene "compilato" dal compilatore JIT, ma il tutto avviene dentro la virtual machine. Altrimenti potrebbe intendersi che ci possa essere del codice nativo che gira al di fuori della virtual machine, cosa non vera, per cui non ha senzo dire "se funziona la JVM".
Però il JIT java è stato abbandonato in favore di HotSpot, che non è propriamente un JIT, ma piuttosto un "interprete ottimizzato" , che contiene cioè un motore di ottimizzazione in grado di lavorare a runtime per l'individuazione degli "HotSpots" (e non mi dilungo a spiegare la teoria degli HotSpots). Dico che HotSpot non è un JIT perchè si basa su tecniche completamente diverse anche se, tra le ottimizzazioni che può decidere di applicare su uno spot individuato può esserci anche la compilazione.
Questo per la precisione.

midian

29-10-2004, 08:15

Originariamente inviato da bejo
su tutti i pc usciti da 2 o 3 anni.
Il mondo va avanti.

ma alcune persone rimangono indietro
:rolleyes: :rolleyes: :rolleyes:
(dico con i pc)

robibo68

29-10-2004, 08:16

ma come si scarica? non sono interessato a programmazione, pero' la cosa mi piace e vorrei installarla. mi aiutate?

Kars

29-10-2004, 08:41

Originariamente inviato da midian
ma alcune persone rimangono indietro
:rolleyes: :rolleyes: :rolleyes:
(dico con i pc)

Scusa ma che ti aspettavi ? una versione di w95 fatta in java :confused: , +o- sono le stesse richieste di wxp :fagiano:

midian

29-10-2004, 11:23

Originariamente inviato da Kars
Scusa ma che ti aspettavi ? una versione di w95 fatta in java :confused: , +o- sono le stesse richieste di wxp :fagiano:

beh alla fine si :oink: :oink: :oink: :oink:

cdimauro

29-10-2004, 12:27

Originariamente inviato da ZerOFraG
Rispondo solo su una cosa tecnica, visto che tanto riesci a rigirare il resto come ti pare e come ti fa più comodo, travisando e male interpretando (un bug?) la realtà, per cui ritengo inutile continuare a perdere tempo.
Certo, certo. Dicono tutti così...
Non funziona proprio così, o meglio, cerchiamo di essere precisi: il JIT è NELLA VirtualMachine, a fianco dell'interprete, per cui il bytecode o viene interpretato o viene "compilato" dal compilatore JIT, ma il tutto avviene dentro la virtual machine. Altrimenti potrebbe intendersi che ci possa essere del codice nativo che gira al di fuori della virtual machine, cosa non vera, per cui non ha senzo dire "se funziona la JVM".
Questo è soltanto un dettaglio: che la fase di JIT venga eseguita dentro la VM o meno, quel che importa è il risultato, cioé che il bytecode alla fine viene compilato.
Però il JIT java è stato abbandonato in favore di HotSpot, che non è propriamente un JIT, ma piuttosto un "interprete ottimizzato" , che contiene cioè un motore di ottimizzazione in grado di lavorare a runtime per l'individuazione degli "HotSpots" (e non mi dilungo a spiegare la teoria degli HotSpots). Dico che HotSpot non è un JIT perchè si basa su tecniche completamente diverse anche se, tra le ottimizzazioni che può decidere di applicare su uno spot individuato può esserci anche la compilazione.
Questo per la precisione.
Bene. Dopo tutto ciò sei ancora convinto che la velocità di Java sia paragonabile a quella di un binario ottenuto compilando direttamente per il sistema target?

krokus

29-10-2004, 13:23

Originariamente inviato da Banus
Se la vogliamo mettere così è impossibile avere rivoluzioni...

Eh beh, in effetti la penso proprio così!!
Almeno fino a quando compariranno desktop olografici!
:D

cionci

29-10-2004, 14:37

Mi piacerebbe conoscere l'opinione di chi ha partecipato alla discussione precedente su questa cosa: supponendo di dover realizzare su commissione un desktop 3D, con un approccio ingegneristico al problema scegliereste Java comunque per realizzare un sistema del genere ?
Io francamente no...

ZerOFraG

29-10-2004, 15:39

Originariamente inviato da cionci
Mi piacerebbe conoscere l'opinione di chi ha partecipato alla discussione precedente su questa cosa: supponendo di dover realizzare su commissione un desktop 3D, con un approccio ingegneristico al problema scegliereste Java comunque per realizzare un sistema del genere ?
Io francamente no...

Mah, dipende. Ad oggi, dal punto di vista prestazionale puro, probabilmente no, perchè java è un linguaggio che esprime tutte le sua potenzialità quando utilizzato per applicazioni server-side.
Però dipende da quali sarebbero i target della commissione: probabilmente scritto in java costerebbe meno, si svilupperebbe molto più rapidamente e sarebbe molto più robusto. In c++ (non vedo altre alternative valide) si otterrebbero prestazioni migliori, ma costerebbe di più in termini di tempo e risorse e di mantenimento.
Senza contare che una volta scritto in java non si avrebbero problemi di porting.
Però, non dimenticatevi delle api java3D: esse si basano sulle api di basso livello OpenGL e DirectX, per cui non si tratterebbe di delegare alla CPU tutti i calcoli della scena, ma si potrebbero sfruttare gli acceleratori grafici alla stregua di un programma scritto in nativo. Queste api sono relativamente giovani, ma sono pubbliche e hanno il supporto di una grossa comunità di sviluppatori, per cui mi aspetto una ulteriore crescita prestazionale nel breve-medio periodo.
Insomma, come al solito, purtroppo dipende dal tipo di commessa...

cionci

29-10-2004, 16:17

Anche con C++ puoi usare OpenGL...senza layer aggiuntivi e problemi di porting ;)
Comunque credi che un oggetto così complesso fatto interamente in Java non abbia problemi di porting ? Cioè te prendi e lo metti direttamente senza modifiche su un altro SO con l JVM ? Dubito altamente...

Banus

29-10-2004, 17:02

Originariamente inviato da ZerOFraG
In c++ (non vedo altre alternative valide) si otterrebbero prestazioni migliori, ma costerebbe di più in termini di tempo e risorse e di mantenimento.
Il codice manutenibile dipende da chi lo scrive. C++ si può usare con una programmazione fortemente strutturata ad oggetti. Vero che Java ha un ottimo tracciamento e gestione delle eccezioni.

Però, non dimenticatevi delle api java3D: esse si basano sulle api di basso livello OpenGL e DirectX,
Non le definirei di basso livello, visto che le ho provate entrambe :p
Chiedi a chi ha dovuto programmare giochi per la Playstation 2 cosa significa "basso livello" :D
L'uso delle librerie grafiche aiuta le prestazioni di Java e permette cose come la rotazione fluida di finestre in tempo reale, ma considera che le prestazioni di un programma 3d sono molto influenzate dal modo in cui vengono passati i dati alla scheda grafica e in questo passaggio interviene parecchio il processore. Può succedere il processore sia il collo di bottiglia perchè ci sono troppi cambi di stato.
Per Looking Glass queste considerazioni sono marginali ma perchè la geometria coinvolta è molto semplice. Per progetti più ambiziosi (tipo Croquet che è stato postato nell'altra pagina) hanno importanza.

cdimauro

30-10-2004, 06:26

Originariamente inviato da cionci
Mi piacerebbe conoscere l'opinione di chi ha partecipato alla discussione precedente su questa cosa: supponendo di dover realizzare su commissione un desktop 3D, con un approccio ingegneristico al problema scegliereste Java comunque per realizzare un sistema del genere ?
Io francamente no...
Direi di no: il C++ è un linguaggio più ricco di Java (offre molti più strumenti "espressivi") e soprattutto è decisamente più veloce. Anche se inizialmente i desktop 3D saranno abbastanza leggeri (almeno spero :D), c'è da tenere in considerazione le risorse "consumate" dalla pipeline grafica.

Attualmente può essere suddivisa rozzamente in due parti: la prima a carico della CPU per l'elaborazione delle scene e la seconda (tramite API OpenGL o DirectX) per rendering finale a carico della GPU (supponendo che implementi in hardware tutte le funzioni richieste da questa fase).

E' chiaro che la prima fase attualmente è la più pesante (abbiamo GPU semplicemente mostruose oggi, per quello che serve per un desktop 3D ;)), ed è quella che andrebbe più lenta se scritta in Java, sia pur facendo uso di tecniche di JIT o HotSpot. Scritta in C++, invece, è naturale che possa beneficiare pienamente (nei limiti delle ottimizzazioni concesse dai compilatori) del sistema per cui sarà compilato.

Quanto al porting, il C++, come qualunque altro linguaggio, permette di scrivere codice in grado di girare su qualunque piattaforma: basta non usare il linguaggio giocando sporco (es: trattare interi e puntatori come fossero la stessa cosa :rolleyes: ) e fare assunzioni sui tipi di dati e su come sono memorizzati. Ma questo un buon programmatore dovrebbe farlo sempre... ;)

Infine, sulla scelta del linguaggio, si tratta sempre di una questione di gusti (e buon senso: farlo in Prolog ne avrebbe poco ;)): a me non piaccono né Java né C né C++, pur avendoci lavorato.

ZerOFraG

30-10-2004, 09:09

Originariamente inviato da cionci
Anche con C++ puoi usare OpenGL...senza layer aggiuntivi e problemi di porting ;)

Per carità, questo lo davo per scontato...

Comunque credi che un oggetto così complesso fatto interamente in Java non abbia problemi di porting ? Cioè te prendi e lo metti direttamente senza modifiche su un altro SO con l JVM ? Dubito altamente...

Mah, che dirti. In tanti anni che uso java, non mi sono mai dovuto preoccupare di fare il porting dei progetti.
Ti dirò: di solito il gruppo di sviluppo di cui mi occupo ha piena libertà di scegliersi l'ambiente di sviluppo che più gli aggrada (nei limiti delle licenze disponibili), per cui lo stesso progetto si sviluppa in ambienti eterogenei. Non ho mai riscontrato problemi di porting nel passare poi in fase di test e produzione.
Se, nel caso, si dovessero presentare, verrebbe a mancare uno dei cardini di java (write once, run everywhere) e il problema sarebbe da imputare a chi ha scritto la VM e le api, non a chi ha scritto il programma.

ZerOFraG

30-10-2004, 09:23

Originariamente inviato da Banus
Il codice manutenibile dipende da chi lo scrive. C++ si può usare con una programmazione fortemente strutturata ad oggetti. Vero che Java ha un ottimo tracciamento e gestione delle eccezioni.

Vero. Però devo ammettere che il codice scritto in java è mediamente un ordine di grandezza più stabile e manutenibile ripsetto a quello scritto in c/c++.
E questo è allo stesso tempo la forza e anche il limite di java.
Il c++ permette di fare cose che in java non è possibile fare e quindi lo paragoneri più ad un bisturi che, messo in mano ad un bravo chirurgo può risultare una manna, ma messo in mano ad un macellaio può fare tanti danni. E purtroppo sono più i macellai che i chirurghi nel nostro mondo.

Non le definirei di basso livello, visto che le ho provate entrambe :p
Chiedi a chi ha dovuto programmare giochi per la Playstation 2 cosa significa "basso livello" :D

Bon, sono api anch'esse, per cui non saranno mai così a "basso livello" :p
Diciamo che "operano" a basso livello. Meglio? ;)

L'uso delle librerie grafiche aiuta le prestazioni di Java e permette cose come la rotazione fluida di finestre in tempo reale, ma considera che le prestazioni di un programma 3d sono molto influenzate dal modo in cui vengono passati i dati alla scheda grafica e in questo passaggio interviene parecchio il processore. Può succedere il processore sia il collo di bottiglia perchè ci sono troppi cambi di stato.
Per Looking Glass queste considerazioni sono marginali ma perchè la geometria coinvolta è molto semplice. Per progetti più ambiziosi (tipo Croquet che è stato postato nell'altra pagina) hanno importanza.

Niente da dire a riguardo. Ma questo "problema" non ci sarebbe anche senza java?
Cioè, la scena deve essere comunque calcolata...
O sbaglio?

ZerOFraG

30-10-2004, 09:33

Originariamente inviato da cdimauro

Quanto al porting, il C++, come qualunque altro linguaggio, permette di scrivere codice in grado di girare su qualunque piattaforma: basta non usare il linguaggio giocando sporco (es: trattare interi e puntatori come fossero la stessa cosa :rolleyes: ) e fare assunzioni sui tipi di dati e su come sono memorizzati. Ma questo un buon programmatore dovrebbe farlo sempre... ;)

Mi ero ripromesso di non rispondere, ma sono un debole...

Chiaramente qui si è dimenticato di dire che il C/C++ e tutti gli altri hanno necessità di essere ricompilati su ogni piattaforma.
Java no: il "compilato" (il bytecode, le classi, l'eseguibile, chiamatelo come volete) gira su ogni JVM di ogni piattaforma senza ulteriori passaggi.
Quindi, con java il porting semplicemente non esiste, con gli altri linguaggi, si. Anche se il codice fosse scritto in modo perfettamente portabile (e nella mia vita non me ne è mai capitato di vederne uno mediamente complesso o che facesse qualcosa in più che stampare "Hello, world!" sulla console), in modo che non si debba rimetter mano a nessuna linea di codice o parametri di compilazione e/o di preprocessore, comunque andrebbe ricompilato su ogni piattaforma su cui lo si vorrebbe far girare.

cionci

30-10-2004, 11:19

Originariamente inviato da ZerOFraG
il problema sarebbe da imputare a chi ha scritto la VM e le api, non a chi ha scritto il programma.
Pensa proprio alla situazione di Looking Glasses...un desktop 3d che interagisce con X o con Windows...pensi che una applicazione del genere scritta solamente in Java possa girare su entrambi i sistemi senza modifiche o senza comunque predisporre un layer aggiuntivo che adatta il codice ad entrambi i sistemi operativi ?

cdimauro

30-10-2004, 21:29

Originariamente inviato da ZerOFraG
Vero. Però devo ammettere che il codice scritto in java è mediamente un ordine di grandezza più stabile e manutenibile ripsetto a quello scritto in c/c++.
Potresti essere più chiaro?
E questo è allo stesso tempo la forza e anche il limite di java.
Il c++ permette di fare cose che in java non è possibile fare e quindi lo paragoneri più ad un bisturi che, messo in mano ad un bravo chirurgo può risultare una manna, ma messo in mano ad un macellaio può fare tanti danni. E purtroppo sono più i macellai che i chirurghi nel nostro mondo.
Questo è un problema del programmatore, non del linguaggio, come hai già detto in qualche messaggio addietro.
Niente da dire a riguardo. Ma questo "problema" non ci sarebbe anche senza java?
Cioè, la scena deve essere comunque calcolata...
O sbaglio?
Certamente. Ma la differenza la farebbe la velocità di calcolo, e si tratta di calcoli abbastanza pesanti.

cdimauro

30-10-2004, 21:57

Originariamente inviato da ZerOFraG
Mi ero ripromesso di non rispondere, ma sono un debole...
Non vedo perché dovresti privarti di rispondere, anche se abbiamo avuto degli screzi: se c'è qualcosa d'interessante, io non mi privo certo di dire la mia, anche se un secondo prima sono volati i coltelli...
Chiaramente qui si è dimenticato di dire che il C/C++ e tutti gli altri hanno necessità di essere ricompilati su ogni piattaforma.
Java no: il "compilato" (il bytecode, le classi, l'eseguibile, chiamatelo come volete) gira su ogni JVM di ogni piattaforma senza ulteriori passaggi.
Quindi, con java il porting semplicemente non esiste, con gli altri linguaggi, si. Anche se il codice fosse scritto in modo perfettamente portabile (e nella mia vita non me ne è mai capitato di vederne uno mediamente complesso o che facesse qualcosa in più che stampare "Hello, world!" sulla console), in modo che non si debba rimetter mano a nessuna linea di codice o parametri di compilazione e/o di preprocessore, comunque andrebbe ricompilato su ogni piattaforma su cui lo si vorrebbe far girare.
Beh, non vedo grosse differenze. Prima hai scritto:
Se, nel caso, si dovessero presentare, verrebbe a mancare uno dei cardini di java (write once, run everywhere) e il problema sarebbe da imputare a chi ha scritto la VM e le api, non a chi ha scritto il programma.
Questo presuppone, ovviamente, che sia stato fatto un bel lavoro per sviluppare la VM per una certa piattaforma (hardware e software).

Se consideriamo Linux, tanto per fare un esempio, notiamo che esistono abbastanza similitudini nel modo di effettuare il porting di questo s.o. e delle applicazioni di base (compilatore GCC e tool vari) con lo scrivere la virtual machine Java.

D'altra parte lo scopo è sempre lo stesso: ottenere un "ambiente" in cui sia possibile compilare programmi scritti in un certo modo. Se prendo un sorgente e lancio la compilazione, mi aspetto che produca un eseguibile e che il programma funzioni per come è stato progettato. Idem se prendo un compilato bytecode e lo eseguo su una VM.

Giusto per farti un esempio. Qualche mese addietro, per la mia tesi di laurea, ho realizzato un prototipo di decoder JPEG2000 (manca soltanto qualche dettaglio dello standard) per conto della STMicroelectronics, scritto interamente in ANSI C puro.
Come ambiente di sviluppo ho utilizzato il VisualStudio 6.
Ebbene, compilato anche con il GCC sotto Cygwin funziona allo stesso modo (a parte qualche warning che s'è inventato il GCC, visto che il codice è sintatticamente e semanticamente corretto).
Allo stesso modo, compilato per un compilatore per l'architettura VLIW LX di STM (completamente diversa da quella x86, e tra l'altro che utilizza la notazione bigendian anziché la little endian), funziona esattamente allo stesso modo.

Questo per dire che si può scrivere benissimo un programma che vada ben oltre il banale "Hello, world!", che funziona su qualunque piattaforma: basta avere l'accortezza di includere il classico header con le definizioni dei tipi "giusti".
E' un lavoro che ha realizzato chi ha fatto il porting di un compilatore o di un s.o, e che ha fatto anche chi ha scritto la JVM (anche se l'utente lo "utilizza" poi indirettamente).

cdimauro

30-10-2004, 21:59

Originariamente inviato da cionci
Pensa proprio alla situazione di Looking Glasses...un desktop 3d che interagisce con X o con Windows...pensi che una applicazione del genere scritta solamente in Java possa girare su entrambi i sistemi senza modifiche o senza comunque predisporre un layer aggiuntivo che adatta il codice ad entrambi i sistemi operativi ?
E' un lavoro che deve fare chi fa il porting della JVM per un certo sistema: è suo il compito di "traslare" le chiamate alle librerie standard di Java in quelle del s.o. ospite. Ed è un lavoro decisamente non banale.

Banus

30-10-2004, 22:36

Originariamente inviato da cdimauro
D'altra parte lo scopo è sempre lo stesso: ottenere un "ambiente" in cui sia possibile compilare programmi scritti in un certo modo. Se prendo un sorgente e lancio la compilazione, mi aspetto che produca un eseguibile e che il programma funzioni per come è stato progettato.
Questo in teoria. Molto spesso si ricorre a librerie per accedere a funzionalità (come l'interfaccia grafica) che sono pesantemente dipendenti dal sistema operativo. O si tiene conto di tutti i possibili scenari oppure si decide una piattaforma di riferimento e si programma per quella. Le librerie di classi standard di Java sono fatte per aggirare questo problema, che ovviamente è spostato sulla JVM.
Con librerie cross-platform invece è come Java (OO a parte :p). Sto sperimentando le wxWidget e salvo qualche #ifdef necessario per catturare caratteristiche specifiche degli ambienti il codice è indipendente dalla piattaforma.

Giusto per farti un esempio. Qualche mese addietro, per la mia tesi di laurea, ho realizzato un prototipo di decoder JPEG2000
Adesso capisco perchè sei così informato sulle wavelet :p :D :D
L'esempio che hai fatto si riferisce a un caso abbastanza favorevole. Con un po' di accortezza sui tipi si riesce ad avere codice perfettamente portabile. Passare dal prototipo alla versione ottimizzata la vedo più dura ;).

Norbornano

30-10-2004, 23:29

Ho appena finito di leggere questo thread e dopo tanto tempo di banali e stupidi commenti assito ad una discussione CIVILE TECNICA ISTRUTTIVA.....senza i soliti stupidi commenti......

VORREI CHE "TUTTI" IMPARASSERO A LEGGERE "BENE" E SCRIVERE SOLAMENTE QUANDO SI HA COGNIZIONE DI CAUSA.

questo è il mio tipo di forum ideale....ciao ragazzi del forum *_*

cdimauro

31-10-2004, 06:02

Originariamente inviato da Banus
Questo in teoria. Molto spesso si ricorre a librerie per accedere a funzionalità (come l'interfaccia grafica) che sono pesantemente dipendenti dal sistema operativo. O si tiene conto di tutti i possibili scenari oppure si decide una piattaforma di riferimento e si programma per quella. Le librerie di classi standard di Java sono fatte per aggirare questo problema, che ovviamente è spostato sulla JVM.
Con librerie cross-platform invece è come Java (OO a parte :p). Sto sperimentando le wxWidget e salvo qualche #ifdef necessario per catturare caratteristiche specifiche degli ambienti il codice è indipendente dalla piattaforma.
Beh, e non è quello che ho detto io? ;)
Tutto sta nell'avere un "ambiente" (meglio ancora il concetto di "framework", che ormai ha sta prendendo piede) multipiattaforma.

Un esempio sono compilatori e librerie come GNU e QT. Oppure, se prendiamo Delphi, è un IDE che permette di scrivere applicazioni compilabili per Windows o Linux.

Lo sforzo è quello di scriverli questi compilatori e queste librerie, ma lo stesso vale per Java: "adattare" le sue classi è un compito oneroso che va fatto per ogni nuovo sistema su cui si vuol fare girare la VM...
Adesso capisco perchè sei così informato sulle wavelet :p :D :D
Pensavo lo sapessi già: è un da un pezzo che ne parlo nel forum... ;)
L'esempio che hai fatto si riferisce a un caso abbastanza favorevole. Con un po' di accortezza sui tipi si riesce ad avere codice perfettamente portabile.
Esatto, e richiede pochissimo sforzo. Ben ricompensato dalle performance che si riusciranno ad ottenere... ;)
Passare dal prototipo alla versione ottimizzata la vedo più dura ;).
Non credo: l'obiettivo è quello di utilizzarlo nei futuri sistemi embedded, per cui l'ho già "pensato" e scritto per architetture di questo tipo. ;)
Al più potrebbero decidere (ormai mi sono laureato, per cui il progetto non è più in mano mai :p) di realizzare dei circuiti ad hoc per implementare alcuni moduli "critici" (decodificatore aritmetico, bitmodeler, dequantizzatore, wavelet inversa), che poi sono quelli che fanno perdere più tempo. Questo lo deciderà lo staff che si occupa di prendere il codice C e "convertirlo" in circuiti elettrici.
Avevo altre idee per sfruttare al meglio alcune peculiarità dei sistemi embedded, ma ormai penso che rimarranno nel cassetto...

Comunque il codice rimarrà praticamente lo stesso, fatta eccezione per l'implementazione di alcuni dettagli mancanti.

cionci

31-10-2004, 09:42

Originariamente inviato da cdimauro
E' un lavoro che deve fare chi fa il porting della JVM per un certo sistema: è suo il compito di "traslare" le chiamate alle librerie standard di Java in quelle del s.o. ospite. Ed è un lavoro decisamente non banale.
No...non hai capito... L'esempio è sempre quello di looking glasses... E' scopo delal VM far interagire l'applicazione Java con il SO ospitante....e qui siamo d'accordo, ma è compito di looking glasses interfacciare le altre applicazioni non Java con l'utente... e le operazioni dell'utente con il SO... Queste operazione non sono portabili in senso stretto, perchè fortemente dipendenti dal sistema operativo...e dubito che queste funzionalità siano previste dalla VM... Quindi è impossibile scrivere codice Java per queste operazioni che sia sterttamente portabile, viste le differenza tra X e Windows...
Chiaramente una soluzione ci sarebbe...scrivere un layer in C++ o in C che fa da interfaccia...quindi dimostrerebbe che non è possibile scrivere l'intera applicazione in Java...

midian

31-10-2004, 14:20

Originariamente inviato da Norbornano
Ho appena finito di leggere questo thread e dopo tanto tempo di banali e stupidi commenti assito ad una discussione CIVILE TECNICA ISTRUTTIVA.....senza i soliti stupidi commenti......

VORREI CHE "TUTTI" IMPARASSERO A LEGGERE "BENE" E SCRIVERE SOLAMENTE QUANDO SI HA COGNIZIONE DI CAUSA.

questo è il mio tipo di forum ideale....ciao ragazzi del forum *_*

QUOTO IN PIENO!!!!!!!! :asd: :asd: :asd: :asd: :asd: :asd:

cdimauro

01-11-2004, 05:39

Originariamente inviato da cionci
No...non hai capito... L'esempio è sempre quello di looking glasses... E' scopo delal VM far interagire l'applicazione Java con il SO ospitante....e qui siamo d'accordo, ma è compito di looking glasses interfacciare le altre applicazioni non Java con l'utente... e le operazioni dell'utente con il SO... Queste operazione non sono portabili in senso stretto, perchè fortemente dipendenti dal sistema operativo...
OK, adesso ho capito. :)
e dubito che queste funzionalità siano previste dalla VM... Quindi è impossibile scrivere codice Java per queste operazioni che sia sterttamente portabile, viste le differenza tra X e Windows...
Chiaramente una soluzione ci sarebbe...scrivere un layer in C++ o in C che fa da interfaccia...quindi dimostrerebbe che non è possibile scrivere l'intera applicazione in Java...
No, non è impossibile: "basterebbe" :asd: fare lo stesso lavoro due volte. ;)
Bisognerebbe scrivere in Java l'interfaccia fra le applicazioni e Looking glasses, tenendo conto del loro funzionamento. Praticamente l'operazione simmetrica a quella che si fa quando si effettua il porting della JVM su un sistema... ;)

In definitiva avremmo (sempre se non ho capito male :p):
applicazioni (native) <-> interfaccia Looking Glasses (Java) <-> sistema operativo.

Un bel lavoraccio, non c'è che dire. :D Immagino già la velocità dell'accrocco risultante... ;)

P.S. Non è un caso se ho messo la parola "acrocco": bisogna ben vedere in che modo sarebbe possibile piazzare un layer fra le applicazioni e Looking Glasses, in maniera trasparente. La vedo dura. Molto dura (mi sa che ci sarebbe da metter le mani sul s.o... ;))

cionci

01-11-2004, 13:14

Originariamente inviato da cdimauro
In definitiva avremmo (sempre se non ho capito male :p):
applicazioni (native) <-> interfaccia Looking Glasses (Java) <-> sistema operativo.

Un bel lavoraccio, non c'è che dire. :D Immagino già la velocità dell'accrocco risultante... ;)

Se ci pensi bene è proprio così che si comporta Looking Glasses...

Sei d'accordo che sia l'unico modo per rendere un'applicazione come Looking Glasses portabile semplicemente eseguendo lo stesso bytecode su due piattaforme diverse ?

In pratica bisognerebbe fare la stessa cosa che si farebbe con il C++ per rendere portabile il codice sorgente...ed è questa la conclusione a cui volevo arrivare...

La portabilità di un'applicazione come Loking Glasses scritta in Java è pari a quella della stessa applicazione scritta in C++ ;)

fek

01-11-2004, 14:11

Originariamente inviato da ZerOFraG
Mah, dipende. Ad oggi, dal punto di vista prestazionale puro, probabilmente no, perchè java è un linguaggio che esprime tutte le sua potenzialità quando utilizzato per applicazioni server-side.
Però dipende da quali sarebbero i target della commissione: probabilmente scritto in java costerebbe meno, si svilupperebbe molto più rapidamente e sarebbe molto più robusto. In c++ (non vedo altre alternative valide) si otterrebbero prestazioni migliori, ma costerebbe di più in termini di tempo e risorse e di mantenimento.
Senza contare che una volta scritto in java non si avrebbero problemi di porting.

Qui ti stai andando a infilare in un discorso davvero spinoso ;)

E' vero che linguaggi a piu' alto livello come Java e C#, offrono un ambiente di sviluppo che permette applicazioni mediamente piu' stabili e robuste, rispetto a linguaggio a livello piu' basso quali C/C++. Non sottovaluterei linguaggi ad livello come Eiffel con concetti come "design by contract".
Ma vale sempre il principio "There ain't anything like a free supper" ("Non esiste la zuppa gratuita"). Robustezza, stabilita', indipendenza dalla piattaforma non vengono gratis e si pagano in termini di prestazioni. Da qui non si scappa. Si puo' discutere se in un'applicazione quale un Desktop 3D sia piu' importante la robustezza e la stabilita', oppure sia piu' importante l'efficienza (sottointendo efficienza di esecuzione o anche di occupazione di memoria). E provero' a discuterne e dare la mia opinione a riguardo piu' in la': premetto che nel 99% dei casi io prediligo prima la robustezza e la stabilita'. Poi c'e' il restante 1%.

Da qui non si scappa: Java e' un linguaggio intrinsecamente piu' lento di C/C++, e' stato progettato cosi' per precisa scelta ed e' giustissimo che sia stato progettato cosi'. Esistono i JIT compilero, esistono gli HotSpot, per alleviare il problema, ma la velocita' esecutiva di un linguaggio nativo e ottimizzato per quegli scopi sara' sempre e comunque superiore: quando si prendono in considerazione, poi, tecniche quali il "profiling instrumented compiling" (in parole povere il codice viene compilato in base a dati che descrivono come il codice stesso verra' eseguito), la forbice si allarga ulteriormente.

Veniamo al problema, un Desktop 3D presuppone un qualche motore tridimensionale sul quale si appoggia. La domanda potrebbe essere riformulata in questo modo: sarebbe una scelta opportuna scrivere un motore tridimensionale in Java?.

No. Senza appello. E l'1% del quale parlavo prima. Un motore 3d e' un'applicazione real-time, io ho bisogno di sapere con precisione assoluta quando una risorsa e' creata e distrutta, non posso appoggiarmi ad un garbage collector, per quanto sia comodo e sia una scelta intelligente in moltissime altre situazioni. Java per scelta progettuale mi costringe al garbage collector. Inoltre, in un motore 3d ho bisogno del concetto di puntatore che linguaggi come Java e C# mi nascondono (aggiungo giustamente perche' i puntatori sono la fonte primaria di bug); la maggior parte delle ottimizzazioni si appoggiano alla possibilita' di manipolare buffer di memoria in maniera esplicita, buffer il cui comportamento temporale deve essere esplicito e prevedibile (Java non me lo assicura).

Inoltre non e' vero che con la potenza delle GPU in crescita, il motore 3d si limita a spedire geometria alla GPU che fa tutto il lavoro pesante. L'efficienza di un motore 3d dipende proprio da come la geometria e' spedita alla GPU, tanto e' vero che le prestazione della maggior parte dei giochi sono tutt'oggi limitate dalla CPU.

In sintesi: un Desktop 3D totalmente in Java secondo me non e' affatto una buona idea.
L'idea migliore, a mio avviso e mi trovo totalmente d'accordo con cionci su questo punto, sarebbe scrivere una parte del Desktop, quella a livello piu' basso, in C++, fornire un'interfaccia ad alto livello che astragga i concetti tridimensionali in entita' facilmente gestibili da un linguaggio ad alto livello (Java o C#), che poi garantisce un ambiente robusto e stabile a prezzo di una minore efficienza in una porzione di codice che comunque non e' critica per le prestazioni, perche' non rappresenta il collo di bottiglia.

Esempio. Il motore 3d mi mette a disposizioni primitive quali:
- Crea Oggetto 3D
- Visualizza Oggetto 3D
- Anima Oggetto 3D

Ad alto livello le operazioni sarebbero del tipo:
1) Crea Finestra come Oggetto 3D
2) Visualizza Finestra
3) ... operazioni
4) Chiudi Finestra

Creare una finestra 3D e' un'operazione eseguita relativamente di rado, non si creano 60 finestre al secondo ad esempio, e ci si puo' permettere una minore efficienza in questa operazione per guadagnare stabilita'. Spedire i dati geometrici della finestra alla scheda grafica va invece eseguito decine di volte al secondo e deve essere veloce. Questo per dare un'idea di che cosa intendo per operazioni frequenti che devono essere veloci e operazioni rare che possono essere ad alto livello.

Poi si puo' discutere sulla scelta del linguaggio ad alto livello, io, ad esempio, preferisco C# a Java, perche' mi e' piu' semplice interfacciargli classi C++ in ambiente Win32 dove per forza di cose programmo. Ma in altri ambiti Java puo' essere preferibile, dipende dalle esigenza, non voglio assolutamente scatenare una guerra di religione su questo punto.

Domandina un po' OT ma interessante: usciranno giochi .NET (C# e C++) in un futuro? Prima o poi credo di si', ma prima il framework deve essere parte integrante del sistema operativo perche' non ha senso chiedere al cliente di installare un modulo aggiuntivo per poter giocare, va contro il principio di semplicita' di utilizzo.
Sicuramente .NET sara' sempre piu' usato in futuro per i tool di sviluppo, che vedranno il motore 3d attraverso un wrapper .NET.
Scusate la piccola digressione :)

fek

01-11-2004, 14:19

Mi e' venuto in mente solo ora. Vorrei chiarire un punto. Chi ha seguito il mio scambio di opinioni con ilsensine riguardo all'efficienza del C++ rispetto al C, potrebbe obiettare che se seguissi la stessa linea di pensiero dovrei concludere che Java, essendo a piu' alto livello del C++ come il C++ lo e' rispetto al C, dovrebbe essere sempre preferibile e altrettanto efficienze.

Rispondo subito a questa possibile obiezione. Il C++ e' un superset del C, tutti i concetto che possono essere espressi in C possono essere espressi in C++ allo stesso modo o in maniera migliore. Java non e' un superset del C++ e non puo' esprimere alcuni concetti che il C++ puo' esprimere, quindi non tutto quello che puo' essere scritto in C++ puo' essere scritto in maniera altrettanto efficiente in Java. Al contrario tutto quello che puo' essere scritto in C puo' essere scritto in maniera altrettanto efficiente in C++.

ZerOFraG

02-11-2004, 12:08

Originariamente inviato da fek
Qui ti stai andando a infilare in un discorso davvero spinoso ;)

SNIP!

Quoto totalmente questo intervento, che condivido per la maggior parte.
Le uniche cose su cui non concordo sono dettagli e rimangono nell'ambito delle opinioni personali:

- C# non lo preferisco affatto a java per tanti motivi, primo tra i quali, che se in un mio progetto devo interfacciare classi C++, c'è qualcosa di sbagliato nell'architettura ;) Ma l'ambito di cui mi occupo è credo molto diverso dal tuo, quindi nessuna polemica :D

- java non è stato progettato lento per scelta. E' stato progettato per essere un linguaggio che non avesse bisogno di porting (e mille altre cose): da cui la scelta quasi obbligata per un linguaggio interpretato. Il resto sono conseguenze.

- che java sia un linguaggio attualmente più lento di un compilato in codice nativo, è indubbiamente vero. Che java ad oggi sia lento in assoluto, no.

- mi sfugge il motivo per cui si debba sapere quando una zona di memoria è stata effettivamente liberata, quando non si ha accesso diretto alla memoria: se la gestione non è sotto il mio controllo, non vedo perchè mai preoccuparmi di conoscerne lo stato. Non è che il GC di java butti via memoria in uso: libera solo quelle zone a cui non punta più alcun riferimento, per intenderci, se una variabile esce dal ciclo di vita, se impostata a null, etc. etc. Comunque qui ricadiamo nel discorso del C++ come rasoio: per queste cose (e parliamo di soprattutto di gestione manuale dell'accesso alla memoria e quindi dei puntatori) è palesemente meglio (o più veloce) di un linguaggio che media con uno strato di astrazione e gestione, su questo non ci piove. E la mia considerazione sulla scelta del C++ per lo sviluppo di un desktop 3D, deriva da questo e da un paio di altri motivi che tu stesso hai detto e che mi piace sottolineare:

Java non e' un superset del C++ e non puo' esprimere alcuni concetti che il C++ puo' esprimere, quindi non tutto quello che puo' essere scritto in C++ puo' essere scritto in maniera altrettanto efficiente in Java

Dirò di più: non tutto quello che può essere espresso in C++ può essere espresso in Java, a prescindere dall'efficienza.
Sarà per scelta progettuale votata alla sicurezza, sarà per quello che volete, ma la realtà dei fatti è questa.

Questo non vuol dire che non si possano tentare approcci alternativi o sperimentare soluzioni diverse.
Il problema posto da cioni è chiaramente irrisolvibile se non scrivendo un layer apposito tra le applicazioni e il desktop in java (conosco JNI ma non conosco un equivalente lato C/C++).

Ma è anche mal posto: anche per far girare applicazioni java su una piattaforma win32 ho bisogno di una VM.
Per questo dicevo che dipende da cosa si vuole ottenere.

Poi, per quanto riguarda il discorso della portabilità, mi spiace per chi non vuol capire, ma in java il problema non si pone neppure: anche nel caso descritto da cionci, la parte in java una volta compilata, rimarrebbe sempre la stessa. Punto. Senza doverla più ricompilare. Su tutte le VM. E' ben diverso che "scrivere codice portabile", il quale necessita comunque di una complilazione per poter essere eseguito.
Al limite si dovrebbe cambiare il layer, ma non mi sembra che si stia parlando di qualcosa scritto in java.
Sulla fattibilità del quale, tra l'altro, nutro forti dubbi.

Ma vi pongo una domanda su cui riflettere: le applicazioni scritte per KDE girano anche sotto Gnome e viceversa?

Banus

02-11-2004, 12:44

Originariamente inviato da ZerOFraG
Ma vi pongo una domanda su cui riflettere: le applicazioni scritte per KDE girano anche sotto Gnome e viceversa?
Dipende. Gnome si basa sulle librerie Gtk, KDE su Qt. Entrambe si appoggiano a loro volta su X.
X per quello che ne so offre alcune primitive abbastanza scarne per la gestione di finestre. Un'applicazione che si appoggia solo a queste può girare benissimo in entrambi i sistemi, e con il vantaggio di usare il look&feel del WM usato.

cdimauro

02-11-2004, 13:37

Originariamente inviato da cionci
Se ci pensi bene è proprio così che si comporta Looking Glasses...

Sei d'accordo che sia l'unico modo per rendere un'applicazione come Looking Glasses portabile semplicemente eseguendo lo stesso bytecode su due piattaforme diverse ?

In pratica bisognerebbe fare la stessa cosa che si farebbe con il C++ per rendere portabile il codice sorgente...ed è questa la conclusione a cui volevo arrivare...

La portabilità di un'applicazione come Loking Glasses scritta in Java è pari a quella della stessa applicazione scritta in C++ ;)
Esattamente. Concordo in toto. :)

cdimauro

02-11-2004, 13:45

Originariamente inviato da ZerOFraG
Poi, per quanto riguarda il discorso della portabilità, mi spiace per chi non vuol capire, ma in java il problema non si pone neppure: anche nel caso descritto da cionci, la parte in java una volta compilata, rimarrebbe sempre la stessa. Punto. Senza doverla più ricompilare. Su tutte le VM. E' ben diverso che "scrivere codice portabile", il quale necessita comunque di una complilazione per poter essere eseguito.
Mi spiace, ma non vedo grosse differenze. La tua applicazione può essere compilata in byecode una sola volta, ma non se in un sistema non è presente una VM che la possa eseguire, non te ne farai proprio nulla.
Viceversa, visto che normalmente su qualunque sistema esiste uno straccio di compilatore C (con GNU, ad esempio, posso compilare applicazioni tanto per Commodore64 quanto per un Cray MP), migliaia e migliaia di applicazioni ("scritte bene") potranno essere utilizzate, e gireranno molto velocemente.
In entrambi i casi, quindi, abbiamo bisogno di un "ambiente" disponibile: poco importa che sia la JVM o GNU con librerie QT o altro ancora, serve comunque "punto d'appoggio" per ottenere alla fine la possibilità di eseguire delle applicazioni.

C'è ben poco da capire: si tratta di una realtà di cui prendere atto.

cionci

02-11-2004, 14:19

Originariamente inviato da ZerOFraG
Poi, per quanto riguarda il discorso della portabilità, mi spiace per chi non vuol capire, ma in java il problema non si pone neppure: anche nel caso descritto da cionci, la parte in java una volta compilata, rimarrebbe sempre la stessa. Punto. Senza doverla più ricompilare. Su tutte le VM. E' ben diverso che "scrivere codice portabile", il quale necessita comunque di una complilazione per poter essere eseguito.
Al limite si dovrebbe cambiare il layer, ma non mi sembra che si stia parlando di qualcosa scritto in java.
Sulla fattibilità del quale, tra l'altro, nutro forti dubbi.
Ma a questo punto se dovessi riscrivere il layer (non in Java, ma in C++) la portabilità del programma scritto in Java sarebbe equivalente (a meno di una compilazione) a quella del programma scritto in C++, visto che anche in C++ dovresti solo riscrivere quello stesso layer...

E' un problema ricompilare ?!?!? Non mi sembra...

Forse mi sono perso qualcosa di Looking Glasses... Looking Glasses si interfaccia con X, ma facendo girare un'applicazione in GTK+ o QT avrebbe il look & feel originale ?!?!?

ZerOFraG

02-11-2004, 14:20

Originariamente inviato da cdimauro
Mi spiace, ma non vedo grosse differenze. La tua applicazione può essere compilata in byecode una sola volta, ma non se in un sistema non è presente una VM che la possa eseguire, non te ne farai proprio nulla.
Viceversa, visto che normalmente su qualunque sistema esiste uno straccio di compilatore C (con GNU, ad esempio, posso compilare applicazioni tanto per Commodore64 quanto per un Cray MP), migliaia e migliaia di applicazioni ("scritte bene") potranno essere utilizzate, e gireranno molto velocemente.
In entrambi i casi, quindi, abbiamo bisogno di un "ambiente" disponibile: poco importa che sia la JVM o GNU con librerie QT o altro ancora, serve comunque "punto d'appoggio" per ottenere alla fine la possibilità di eseguire delle applicazioni.

C'è ben poco da capire: si tratta di una realtà di cui prendere atto.

Credo che tu sia l'unico al mondo a vederla così.
Non che tu dica nulla di sbagliato (a parte forse: "visto che normalmente su qualunque sistema esiste uno straccio di compilatore C "), ma addirittura dire che in termini di portabilità è preferibile una applicazione scritta in C da ricompilare di volta in volta che una scritta in java, francamente mi sembra quantomeno azzardato.

E la realtà di cui prendere atto è forse un'altra...

Cmq, tutto ciò credo sia OT.

ZerOFraG

02-11-2004, 14:36

Originariamente inviato da cionci
Ma a questo punto se dovessi riscrivere il layer (non in Java, ma in C++) la portabilità del programma scritto in Java sarebbe equivalente (a meno di una compilazione) a quella del programma scritto in C++, visto che anche in C++ dovresti solo riscrivere quello stesso layer...

Mah, se ho ben capito quello che vuoi dire (ma ne dubito :p ) chiaramente il layer dovrebbe esporre una interfaccia unica verso le applicazioni.
Quindi sarebbe l'unico a dover essere distribuito per ogni ambiente.
Ma, ripeto nutro forti dubbi su un approccio del genere.

E' un problema ricompilare ?!?!? Non mi sembra...

La ricompilazione come atto in se no, magari tutto ciò che si porta dietro si (ambienti su cui ricompilare (tutti), distribuzione di diversi eseguibili, etc. etc.)

Ma poi, siamo sicuri che sia la portabilità il fulcro della questione?
Forse stiamo trascurando aspetti architetturali ben più importanti sollevati proprio dal tuo intervento: come sia possibile far girare applicazioni non java in un desktop scritto in java.

Forse mi sono perso qualcosa di Looking Glasses... Looking Glasses si interfaccia con X, ma facendo girare un'applicazione in GTK+ o QT avrebbe il look & feel originale ?!?!?

Non so risponderti con certezza, perchè non conosco a fondo Looking Glasses. La prossima settimana forse ho un po' di tempo per studiarmelo meglio, ma adesso sono oberato di impegni e soprattutto qui non ho i mezzi (leggi connessione) per muovermi con agilità. Prometto che non appena tornerò a casa e andrò a fondo sulla questione, posterò.

cionci

02-11-2004, 14:40

Originariamente inviato da ZerOFraG
Ma poi, siamo sicuri che sia la portabilità il fulcro della questione?
Forse stiamo trascurando aspetti architetturali ben più importanti sollevati proprio dal tuo intervento: come sia possibile far girare applicazioni non java in un desktop scritto in java.

Forse mi sono spiegato male, ma davo per scontato che lo facesse...ed il layer in questione avrebbe dovuto proprio fare questo... Fare da interfaccia fra SO ospite e Looking Glasses...

cdimauro

03-11-2004, 07:48

Originariamente inviato da ZerOFraG
Credo che tu sia l'unico al mondo a vederla così.
Fra noi due, sì. ;)
Non che tu dica nulla di sbagliato (a parte forse: "visto che normalmente su qualunque sistema esiste uno straccio di compilatore C "),
E cosa ci sarebbe di sbagliato in questo?
ma addirittura dire che in termini di portabilità è preferibile una applicazione scritta in C da ricompilare di volta in volta che una scritta in java, francamente mi sembra quantomeno azzardato.
E perché mai? Lo vedi tu un MAME scritto in Java? Un Apache? Un MySQL? Un Oracle? ecc. ecc.
Meglio fare un piccolo sforzo all'inizio, creando qualche file include in cui racchiudere tutto il codice o i dati non portabile, e ritrovarsi poi con un eseguibile per la piattaforma target che girerà con un'ottima velocità.
E la realtà di cui prendere atto è forse un'altra...
Quale? Java ha i suoi pro e i suoi contro, come pure la soluzione di compilare ogni volta i sorgenti per la piattaforma di destinazione. Si tratta sempre di vedere quali sono gli obiettivi che ci si pone e qual è la migliore strada per realizzarli.
Cmq, tutto ciò credo sia OT.
Ma è interessante, a detta anche di altri frequentatori del forum... :p

fek

03-11-2004, 09:36

Originariamente inviato da ZerOFraG
Quoto totalmente questo intervento, che condivido per la maggior parte.
Le uniche cose su cui non concordo sono dettagli e rimangono nell'ambito delle opinioni personali:

- C# non lo preferisco affatto a java per tanti motivi, primo tra i quali, che se in un mio progetto devo interfacciare classi C++, c'è qualcosa di sbagliato nell'architettura ;) Ma l'ambito di cui mi occupo è credo molto diverso dal tuo, quindi nessuna polemica :D

- java non è stato progettato lento per scelta. E' stato progettato per essere un linguaggio che non avesse bisogno di porting (e mille altre cose): da cui la scelta quasi obbligata per un linguaggio interpretato. Il resto sono conseguenze.

- che java sia un linguaggio attualmente più lento di un compilato in codice nativo, è indubbiamente vero. Che java ad oggi sia lento in assoluto, no.

Rispondo a questi dettagli uno per volta:

1) Se in un progetto devo interfacciare classi C++ a classi Java, c'e' sicuramente qualcosa di sbagliato nell'architettura: l'aver scelto Java :) A parte gli scherzi, proprio un Desktop 3D come questo e' una tipica applicazione dove parte del codice (anche minima) dovrebbe essere scritta in un linguaggio a piu' basso livello come il C++, perche' come ti ho descritto, il motore 3d che si interfaccia alla scheda grafica non puo' essere scritto in Java, non e' un linguaggio abbastanza espressivo per poter esprimere i concetti necessari ad un motore 3d con la necessaria efficienza. Questo e' un dato di fatto, non un'opinione. In questo ambito, scrivere l'intero Desktop 3D in Java e' una scelta senza dubbio sbagliata, scrivere le parti a basso livello in C++ dove e' necessario, e scrivere il resto ad alto livello in Java e' una scelta invece possibile che ha indubbi benefici; personalmente sceglierei C# per risolvere questo problema, per la facilita' di interfacciamento.

2) Qui forse non sono stato chiaro nella mia affermazione: Java e' stato progettato per essere un linguaggio ad alto livello per scelta, essere un linguaggio ad alto livello implica essere "piu' lento", e' una conseguenza immancabile che e' stata sicuramente prevista in fase di progettazione. Ma qui e' piu' un discorso filosofico di poca importanza.

- mi sfugge il motivo per cui si debba sapere quando una zona di memoria è stata effettivamente liberata, quando non si ha accesso diretto alla memoria: se la gestione non è sotto il mio controllo, non vedo perchè mai preoccuparmi di conoscerne lo stato. Non è che il GC di java butti via memoria in uso: libera solo quelle zone a cui non punta più alcun riferimento, per intenderci, se una variabile esce dal ciclo di vita, se impostata a null, etc. etc.

Non mi addentro nei problemi di sincronizzazione nell'uso e nel rilascio delle risorse presenti in un motore 3d, se non per accennare che certe risorse devono essere rilasciate strettamente prima di altre, cosa che non ho modo di forzare in Java se non con artifici che rendono l'architettura piu' involuta (andando contro ad uno dei principali motivi per usare un linguaggio a piu' alto livello, semplificare l'architettura).

Il GC non butta via ovviamente memoria in uso, il GC entra in funzione per definizione in maniera imprevedibile e questo comportamento non e' accettabile in un sistema in real time, dove le operazioni devono concludersi in un tempo deterministico.

Ti faccio un esempio: immagina che stia finendo di spedire la geometria di una scena alla GPU e mi appresto a sincronizzare la CPU e la GPU per il prossimo frame e per mantenere il frame rate costante so di avere a disposizione, per dire, 2 millisecondi prima della fine del frame. Immagina che il GC decida di entrare in gioco proprio in questo momento (teoricamente puo' farlo) e sai meglio di me che non e' deterministico quando finira', puo' impiegare meno di 2 millisecondi, puo' impiegarne di piu'. Se impiega piu' di 2 millisecondi (teoricamente puo' farlo), mi salta il frame, torna il controlla alla CPU che pensa di aspettare la fine del frame precedente e invece aspetta la fine del frame successivo, perdendo un intero frame, visibile in un "glitch" dell'animazione, ed e' un effetto particolarmente fastidioso in una qualunque applicazione 3d.
C'e' gia' il sistema operativo, Windows non e' un S.O. realtime, non e' possibile forzarlo a rilasciare il controllo in un tempo fisso, che decide di prendersi la CPU per un periodo indeterminato ed e' gia' faticoso controllare questo, non e' proprio il caso di crearsi ulteriori problemi con un garbage collector.

In sintesi, scrivere un motore 3d in Java porrebbe dei problemi tali, la cui soluzione richiederebbe un sistema piu' complesso. Inoltre, per definizione, un motore 3d che deve pilotare un hardware in maniera efficiente e' un'applicazione molto poco portabile, ulteriore motivo per il quale Java non e' una scelta intelligente.

Questo non vuol dire che non si possano tentare approcci alternativi o sperimentare soluzioni diverse.
Il problema posto da cioni è chiaramente irrisolvibile se non scrivendo un layer apposito tra le applicazioni e il desktop in java (conosco JNI ma non conosco un equivalente lato C/C++).

Si possono sempre tentare approcci alternativi, ma c'e' sempre qualcuno che vuole concludi il task ieri, e vuoi usare gli strumenti che ti aiutino, non cercare nuove soluzioni che magari non funzionano :)
A meno che non si sta facendo R&D per divertimento.

Poi, per quanto riguarda il discorso della portabilità, mi spiace per chi non vuol capire, ma in java il problema non si pone neppure: anche nel caso descritto da cionci, la parte in java una volta compilata, rimarrebbe sempre la stessa. Punto. Senza doverla più ricompilare. Su tutte le VM. E' ben diverso che "scrivere codice portabile", il quale necessita comunque di una complilazione per poter essere eseguito.
Al limite si dovrebbe cambiare il layer, ma non mi sembra che si stia parlando di qualcosa scritto in java.
Sulla fattibilità del quale, tra l'altro, nutro forti dubbi.

Su questo punto non sono molto aggiornato, ma i miei esperimenti con Java e svariate letture di post mortem di progetti in Java mi suggeriscono che il mito del "compili ed esegui ovunque" sia, per l'appunto, un mito. E' verissimo che Java aiuta enormemente a sviluppare applicazioni portabili, non credo che risolva tutti i problemi dovuti alle differenze architetturali: esempio di nuovo un motore 3d, non potrai mai pensare di scriverne uno in Java e lanciarlo cosi' com'e' su un'architettura completamente diversa.