JAVA più lento del C++. Ma quanto?

[tomminno]

Originariamente inviato da sottovento

Anche il compilatore Java ha questa opzione: la attiviamo e possiamo quindi fare una comparazione del codice generato.
Siamo tutti d'accordo che Java genera per una macchina virtuale, la quale pero' non e' stata progettata "campata per aria" ma e' molto simile alle architetture esistenti (i.e. c'e' praticamente una traduzione "uno a uno").

Dimentichi che dietro c'è una VM che esegue insieme al tuo programma, un Garbage collector che agisce dietro le quinte, tutta l'ereditarietà con tutti i suoi costrutti per la sincronizzazione che si ti ritrovi gratis, ma ce li hai anche se non ti servono.

Ti accorgerai che il codice e' simile, praticamente identico.

Assolutamente no.
Se nel ciclo for ci metti delle new (e delle delete nell'equivalente C++) il codice dell'applicazione java avrà una new che comporta decisamente più operazioni per via della struttura ad oggetti propria di Java e l'assenza totale del codice di deallocazione che non è a carico del programma, ma di una entità terza: il GC.

In altre parole: dato quel codice, non puoi sapere il linguaggio di partenza.
Con questi presupposti, per quale motivo Java deve essere piu' lento? Forse perche' ad un programmatore "Java only" non piace essere veloce e quindi e' bene inserire delle istruzioni inutili?
Cosa effettivamente rende Java piu' lento, in questo caso?

Sembrera' strano ma Java non e' nato per il web, bensi' per particolari applicazioni real time. Questo perche' la JVM e' facilmente implementabile su tutti i processori ed occupa poco.
Il suo uso garantiva di portare gli algoritmi (generalmente di controllo) da un processore ad un altro, salvando un sacco di lavoro. Lavoro, nota, non tanto di codifica quanto di test. Nel caso che questo processore sia destinato ad un dispositivo di elettronica di consumo (si dice cosi...) un bug nel software ha un impatto economico notevole.

Infatti Java è proliferato in tutti altri ambiti, non è mai diventato il linguaggio dei tostapane come pensato originariamente.

E se anche è stato inserito nello standard Blue Ray, bisogna anche ricordarsi che serve l'accompagnamento di ben 256MB di RAM.

[71104]

Originariamente inviato da tomminno

E che senso ha invece sbattersi per fare un codice manutenibile, versatile e riusabile quando poi la struttura del linguaggio cambia ogni 2 anni e rende automanticamente il tuo codice obsoleto e per niente riusabile?

se il codice vecchio continua a compilare non vedo il problema. Java è molto retrocompatibile.

Per lo meno il C++ con tutti i suoi difetti è uno standard ISO, e in quanto tale mantiene i suoi difetti per almeno una decina d'anni

solo? io qua ancora riesco a compilare i famosi applet demo di Java, il mitico MoleculeViewer e quella roba credo proprio che abbia più di 10 anni.

[tomminno]

Originariamente inviato da Tommo

Beh devo dire che Netbeans è piuttosto veloce... ma ci mette sempre multipli del tempo che ci mette VC++ ad avviarsi, nonostante faccia molta meno roba.
Un ipotetico Word2007 fatto in Java sarebbe più pesante di Crysis mi sa

Probabilmente anche il nuovo Word fa ampio uso di .NET.
Ma il Visual Studio 200X è scritto in .NET infatti anche lui è leggero come una piuma, poi qualcuno mi deve spiegare cosa cavolo viene caricato in memoria e mai scaricato se l'occupazione cresce proporzionalmente al tempo di utilizzo anche se si cambia progetto.
Magari non ha memory leak ma l'effetto è lo stesso.

[cdimauro]

Ma soprattutto si continua a parlare di consumo di risorse quando il tema in oggetto era la VELOCITA' DI ESECUZIONE.

Pur con tutto il garbage collector che funziona dietro le quinte e il compilatore JIT, mi sembra che i risultati siano notevoli per Java rispetto al C++.

[tomminno]

Originariamente inviato da ^TiGeRShArK^

1) Inner-classes
2) Perchè i riferimenti non potrebbero assuemere valore null?

Infatti se i riferimenti non possono assumere il valore null, come in C++, diventano praticamente inusabili come in C++.

[cdimauro]

Potrebbero anche assumere, come valore, il riferimento all'"oggetto null" della classe, come abbiamo discusso prima.

[cdimauro]

Originariamente inviato da tomminno

Probabilmente anche il nuovo Word fa ampio uso di .NET.
Ma il Visual Studio 200X è scritto in .NET infatti anche lui è leggero come una piuma, poi qualcuno mi deve spiegare cosa cavolo viene caricato in memoria e mai scaricato se l'occupazione cresce proporzionalmente al tempo di utilizzo anche se si cambia progetto.
Magari non ha memory leak ma l'effetto è lo stesso.

No, perché un memory leak non lo puoi recuperare, mentre la memoria allocata da un'applicazione managed la libererà il garbage collector quando lo riterrà opportuno, oppure se verrà forzato a farlo.

[marco.r]

Originariamente inviato da ^TiGeRShArK^

si e fin qui ci siamo..
ma se non esistesse il null, un oggetto non inizializato a cosa punterebbe?
Ad un oggetto con tutti i field inizializzati al valore di default?
Ad un oggetto completamente vuoto che occupa lo spazio necessario (con eventuali collections e arrays vuoti ovviamente)?
Per me se un oggetto non è inizializzato non dovrebbe avere un riferimento, quindi, ad occhio un riferimento nullo mi pare che faccia esattamente questo.. o sbaglio?

L'idea e' che in generale non si dovrebbero avere oggetti inizializzati. E nei casi in questo effettivamente occorra, allora si potrebbe utilizzare un tipo diverso, diciamo Maybe<T> al posto del solo T, che lanci un'eccezione quando l'oggetto non c'e'.
Un difetto di questa soluzione e' che hai una doppia indirezione, a naso risolvibile con l'uso di tagged pointers.
Piu' rognoso il fatto che in questo modo sei obbligato a costruire gli oggetti tutti in una botta, visto che in Java non puoi chiamare funzioni/metodi in piu' riprese, e il linguaggio non offre, per quel che ne conosco io perlomeno, strumenti sufficientemente snelli per simularne il comportamento.

[tomminno]

Originariamente inviato da cdimauro

Eccessiva occupazione di memoria e memory leak mi sembra siano due cose completamente diverse...

Io sono convinto che quella occupazione di memoria sia dovuta a memory leak nel programma dovuta alla presenza di qualche riferimento circolare non identificato, visto che quella memoria non viene mai più rilasciata dal GC.
Il problema è che nessuno è riuscito a capire dove stesse il problema.

[tomminno]

Originariamente inviato da cdimauro

No, perché un memory leak non lo puoi recuperare, mentre la memoria allocata da un'applicazione managed la libererà il garbage collector quando lo riterrà opportuno, oppure se verrà forzato a farlo.

Se nei fatti quella memoria non viene mai rilasciata è esattamente equivalente ad un memory leak.
Se dopo un ora che sto sviluppando un progetto C# l'IDE mi occupa 150MB e passo ad un progetto C++ quei 150MB non cambiano di una virgola.
Se invece parto direttamente con il progetto C++ l'occupazione di memoria generalmente non va oltre gli 80MB.
Cosa porta il GC a non deallocare tutta quella ram?
Si tratta di progetti profondamente differenti per cui tutto l'eventuale caching dei dati non è riusabile e quindi dovrebbe essere deallocato.
Siccome questo non accade è perfettamente analogo ad un memory leak, visto che non recupererai mai quella memoria fino alla chiusura dell'IDE.

[marco.r]

Originariamente inviato da tomminno

Se nei fatti quella memoria non viene mai rilasciata è esattamente equivalente ad un memory leak.
Se dopo un ora che sto sviluppando un progetto C# l'IDE mi occupa 150MB e passo ad un progetto C++ quei 150MB non cambiano di una virgola.
Se invece parto direttamente con il progetto C++ l'occupazione di memoria generalmente non va oltre gli 80MB.
Cosa porta il GC a non deallocare tutta quella ram?
Si tratta di progetti profondamente differenti per cui tutto l'eventuale caching dei dati non è riusabile e quindi dovrebbe essere deallocato.
Siccome questo non accade è perfettamente analogo ad un memory leak, visto che non recupererai mai quella memoria fino alla chiusura dell'IDE.

Un riferimento circolare non dovrebbe costituire un problema per un garbage collector come quello del C#. Piu' facile che semplicemente rimanga un riferimento ai dati vecchi in quelli nuovi oppure che delle risorse (non necessariamente memoria) che devono venire rilasciate esplicitamente non lo siano. O che per qualche forma cache abbiano usato dei puntatori normali invece che dei weak pointers.

[cionci]

Imho state mettendo di mezzo troppo spesso il GC e i memory leak...per realizzare un GC in C++ con un reference count ci vogliono 10 minuti. Inoltre il C++ ha degli strumenti chiamati smart pointer (come auto_ptr definito nella std library) che vengono in aiuto ai programmatori sfaticati...
Il problema è sempre il solito...sono in pochi a programmare in vero C++...ma c'è sempre il retaggio del C che fa in modo che i programmatori si complichino la vita da soli.

Quindi tornando alle prestazioni: un compilatore JIT ha esattamente le stesse potenzialità di generare un codice altrettanto efficiente di quello di un compilatore tradizionale...quindi a parte il primo run (che può essere o meno interpretato), le velocità si equivalgono. Su codice ripetitivo è chiaro che l'impatto che può avere il primo run va sempre più assottigliandosi.
L'unica differenza è che sul codice C++ è più facile fare fine tuning e magari tirare fuori qualche punto percentuale in più di prestazioni.
L'impatto della VM sulla quantità di memoria usata complessivamente è importante, chiaramente questo può essere o meno un parametro indicativo, dipende dal tipo di applicazione e da dove deve girare.

[Unrue]

Secondo me, la velocità di un programma, più che dal linguaggio dipende da come si imposta il codice. Se è impostato bene, senza inutili sprechi di risorse, state tranquilli che l'applicazione gira veloce. Ormai quasi tutti i linguaggi hanno ottime prestazioni, altrimenti non li userebbe nessuno. Molti programmatori si fermano con lo sviluppo quando l'applicazione gira. Ma non basta, il fatto che giri è solo il primo passo. Successivamente ci dovrebbe essere un'accurato profiling per capire dove e come si può velocizzare il codice. Quanti fanno il profiling del codice? Ben pochi direi..

Vi faccio un esempio stupido: nell'applicazione che sto sviluppando adesso sto effettuando il profiling. Ebbene, con mio grandissimo stupore, ho notato che c'era una funzione che occupava il 70 % del tempo totale!! Sapevo che occupava tempo, ma non pensavo così tanto. Allora ho preso tale funzione, l'ho ottimizzata a dovere ed adesso il codice vola Tale funzione adesso ne occupa solo il 35%

Se mi fermavo con lo sviluppo al fatto che girasse, non immagino quanti calcoli avrei fatto fare alla CPU inutilmente !

[shinya]

Originariamente inviato da 71104

non ce l'ho, ma non vedo perché il non poter usare null darebbe origine ai memory leaks.

quel sito si vede una schifezza indecente sia su IE7 che su FF, mi rifiuto di leggerlo (e peccato perché sembrava interessante).

http://safari.oreilly.com/0201310058/ch02lev1sec5

E' uno stralcio del capitolo del libro di Bloch...manca la parte rivisitata del codice, dove impone a null l'elemento liberato dall'array nel metodo 'pop'.
Cmq c'è un pochino di spiegazione e si dovrebbe capire...

A me non fa tanto incazzare che esistano NullPointerException...mi fa incazzare che ci siano una serie di eccezioni non "gestite" in java...tipo questa, o ArrayIndexBlaBlaBla... cioè sono errori o no?? Se sono errori devi killare il programma nel modo più vistoso possibile... come se ci fosse un assert(false).

E invece certe cose si scoprono inevitabilmente quando si va in produzione, si guarda il log e si scoprono i NullPointerException che prima ti erano sfuggiti perchè il programma "tanto andava".

Ecco, il concetto di unchecked exception non mi piace per niente...

@cionci:
Grazie per aver ricordato auto_ptr! Non li vedo mai usare da nessuno sfortunatamente. C++ dev'essere un linguaggio cosi vasto che nessuno ha ancora cominciato ad usarlo...

[cdimauro]

Originariamente inviato da Unrue

Secondo me, la velocità di un programma, più che dal linguaggio dipende da come si imposta il codice. Se è impostato bene, senza inutili sprechi di risorse, state tranquilli che l'applicazione gira veloce. Ormai quasi tutti i linguaggi hanno ottime prestazioni, altrimenti non li userebbe nessuno. Molti programmatori si fermano con lo sviluppo quando l'applicazione gira. Ma non basta, il fatto che giri è solo il primo passo. Successivamente ci dovrebbe essere un'accurato profiling per capire dove e come si può velocizzare il codice. Quanti fanno il profiling del codice? Ben pochi direi..

Vi faccio un esempio stupido: nell'applicazione che sto sviluppando adesso sto effettuando il profiling. Ebbene, con mio grandissimo stupore, ho notato che c'era una funzione che occupava il 70 % del tempo totale!! Sapevo che occupava tempo, ma non pensavo così tanto. Allora ho preso tale funzione, l'ho ottimizzata a dovere ed adesso il codice vola Tale funzione adesso ne occupa solo il 35%

Se mi fermavo con lo sviluppo al fatto che girasse, non immagino quanti calcoli avrei fatto fare alla CPU inutilmente !

Ho fatto profiling e ottimizzazione del codice per buona parte della mia vita, ma adesso per lo più ho smesso.

Se un'applicazione funziona e la sua velocità d'esecuzione è soddisfacente, non la tocco più.

Ormai m'interessa risolvere problemi, non trovare una soluzione per forza di cose "ottimale".

[cionci]

Originariamente inviato da cdimauro

Se un'applicazione funziona e la sua velocità d'esecuzione è soddisfacente, non la tocco più.

Concordo...se le prestazioni sono sufficienti non ha senso ottimizzare, certo in certi ambiti applicativi questa "filosofia" non è applicabile...

[Unrue]

Beh, questo è ovvio. Non ha senso perdere un mese per cercare di migliorare le prestazioni di 1 %. Ma difficilmente un'applicazione gira a dovere fin da subito. Ma comunque almeno un profiling lo farei. Giusto per avere un'idea. Magari il codice per una stupidaggine perde un sacco di tempo, e allora perchè non correggerla?

[cdimauro]

Originariamente inviato da cionci

Concordo...se le prestazioni sono sufficienti non ha senso ottimizzare, certo in certi ambiti applicativi questa "filosofia" non è applicabile...

Perché?

[cdimauro]

Originariamente inviato da Unrue

Beh, questo è ovvio. Non ha senso perdere un mese per cercare di migliorare le prestazioni di 1 %. Ma difficilmente un'applicazione gira a dovere fin da subito. Ma comunque almeno un profiling lo farei. Giusto per avere un'idea. Magari il codice per una stupidaggine perde un sacco di tempo, e allora perchè non correggerla?

Perché se è comunque soddisfacente mi va bene così.

Il tempo risparmiato preferisco spenderlo su altri progetti oppure per aggiornarmi...

[Unrue]

Originariamente inviato da cionci

Concordo...se le prestazioni sono sufficienti non ha senso ottimizzare, certo in certi ambiti applicativi questa "filosofia" non è applicabile...

Però spesso non è mica facile dire se le prestazioni sono sufficienti. E magari il codice sembra girare veloce, e poi sotto determinate condizioni va lentissimo. Può capitare.