Looking Glass: desktop 3D da Sun

[fek]

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]

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

- 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]

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]

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]

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]

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]

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]

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

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]

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

[fek]

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

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