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

[tomminno]

Assolutamente si:
- se ci metti delle new, dovrai solo registrare quella memoria, operazione semplicissima;

La new del Java per lo meno richiama almeno anche la new di un Object.
Quindi il codice generato non può essere uguale.

- quando GC andra' a deallocare, lo fara' meglio di te. (economie di scala).

Stavamo parlando di codice generato per quel ciclo for, il GC non fa parte del programma quindi il codice generato è ancora una volta differente.

- il ciclo di vita degli oggetti obblighera' C++ a fare una marea di copie inutili, che saranno sicuramente evitate in programmazione Java;

Spiegami dove verrebbero generate tutte le copie inutili, quando ormai tutti i compilatori traducono con un passaggio per riferimento tutti i metodi/funzioni che restituiscono copie di oggetti.

L'ho anche visto girare su 1k di RAM

Java su 1KB di RAM
Speigami quale OS ci girava.
Qualche riga di codice C per sistemi embedded l'ho scritta (ARM7 32KB) su questi sistemi non hai l'MMU, quindi non ci gira neanche Linux, e l'allocazione dinamica della memoria è un sogno.
Sarei curioso di sapere su quale sistema con 1KB di RAM hai visto girare Java.

[tomminno]

Originariamente inviato da cdimauro

Invece sì e il motivo è semplice: il compilatore JIT può intervenire sul codice "emesso" se si rende conto che è possibile migliorarlo in base ai dati di profilazione raccolti a runtime, generando del nuovo codice che ne tenga conto.

Naturalmente la profilazione del codice avviene a costo 0.
Non viene eseguita alcuna istruzione di CPU per profilare il codice vero?

Prima si dice che la JVM ha un peso 0, poi che esegue un profiling accuratissimo che ottimizza il codice macchina generato dinamicamente senza nessun sovraccarico sul sistema.

[cdimauro]

Facciamo una cosa: quotami chi e dove si sarebbe detto ciò che hai scritto...

[atragon]

Originariamente inviato da cdimauro

Facciamo una cosa: quotami chi e dove si sarebbe detto ciò che hai scritto...

Forse Tommino ha, un po' platealmente, espresso un dubbio che ha colpito anche me leggendo il tuo intervento. Hai detto una cosa estremamente interessante ma forse usando una sintetizzazione eccessiva. Il "rendersi conto" è naturale per gli umani ma parlando di un software questo dovrebbe (uso il condizionale perchè non so se ciò accade ed eventualmente come) basarsi su una precisa parametrizzazione che comporta anche una sorta memoria storica (i dati raccolti a run-time) tra l'altro con una certezza quasi assoluta (se errasse ad interpretare i dati che riceve potrebbe profilare il software al peggio anzichè al meglio). Inoltre questo lavoro costa risorse, anche se così a occhio non mi pare un fattore assolutamente critico ma importante si. Non so, così divagando è un meccanismo che, se presente andrebbe conosciuto meglio. Inoltre anche "i JIT" in ambito .Net fanno lo stesso?

[cdimauro]

Non conosco i dettagli dell'implementazione delle VM di Java e .NET, per cui non posso risponderti.

Per il resto, è chiaro che la profilazione ha un costo: questo mi pare che nessuno qui l'abbia mai detto.
Se leggi nel link su Dynamo che ho postato, ne parlano molto meglio.

I risultati a cui sono giunti le ricerche di HP è che lo stesso codice compilato (quindi nemmeno in forma di bytecode: era proprio codice macchina PA-RISC), ma eseguito da Dynamo che ne analizzava l'esecuzione risultava mediamente più veloce grazie alla profilazione che permetteva man mano di tirare fuori codice più efficiente.

Tra l'altro faccio notare che i processori moderni (già dai tempi del Pentium) hanno molti registri di sistema appositamente dedicati alla raccolta di informazioni sull'esecuzione.
Queste sono a costo zero come calcolo, fatta eccezione per la loro lettura e interpretazione ovviamente.

[atragon]

Ok, grazie per le precisazioni.

[Unrue]

Originariamente inviato da cdimauro

Tra l'altro faccio notare che i processori moderni (già dai tempi del Pentium) hanno molti registri di sistema appositamente dedicati alla raccolta di informazioni sull'esecuzione.
Queste sono a costo zero come calcolo, fatta eccezione per la loro lettura e interpretazione ovviamente.

Questo però non dipende certo dal linguaggio che stiamo usando. Lo stesso discorso della predizione dei salti cui ho parlato prima.

Trall'altro non ho ancora capito se la JVM applica le tecniche menzionate in quell'articolo. Perchè se non le applica, allora ha poco senso parlare di codice ottimizzato con l'hardware per Java..

[cdimauro]

Non dipende dal linguaggio usato? No, ma infatti dipende dal fatto che si faccia uso di una VM o meno, a prescindere dal linguaggio usato, appunto (in teoria potrei avere codice C++ compilato in bytecode e poi eseguito da una VM).

L'avevo scritto: non è una "guerra" fra codice compilato e codice in bytecode, ma fra chi usa una VM o no.

Come detto già in precedenza, non conosco i dettagli della JVM, per cui non ti posso rispondere...

[Unrue]

Originariamente inviato da cdimauro

Non dipende dal linguaggio usato? No, ma infatti dipende dal fatto che si faccia uso di una VM o meno, a prescindere dal linguaggio usato, appunto (in teoria potrei avere codice C++ compilato in bytecode e poi eseguito da una VM).

E perchè?? Se tali tecniche sono implementate direttamente nel processore non si attivano certo con o senza la VM. Non vedo il collegamento tra le due cose.

Originariamente inviato da cdimauro

Come detto già in precedenza, non conosco i dettagli della JVM, per cui non ti posso rispondere...

Ma scusami tanto.. quando ho parlato di codice C++ ottimizzato per l'hardware, mi hai linkato quell'articolo Dinamo( molto interessante trall'altro). E poi si scopre che molto probabilmente Java non adotta quelle tecniche? Ma allora .. Continua a valere il mio discorso. Che, almeno per adesso, un programma C++ ottimizzato con l'hardware è più veloce di un analogo Java

[Unrue]

Originariamente inviato da sottovento

Puo' essere, ma ci sono i programmatori java/C++ e magari anche di qualche altro linguaggio.

Supponi di avere un codice di questo genere:

for (int i = 0; i < 100; i++)
{
   // Fai qualcosa qui
}

Il compilatore C++ lo tradurra' in codice macchina. Quasi ogni compilatore ha l'opzione (di solito -s) di mostrare la traduzione in linguaggio assembly.
Possiamo quindi attivare questa opzione e vedere il codice generato.


Ti accorgerai che il codice e' simile, praticamente identico.
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?

Questa è bella.. L'assembly generato sarà uguale per quelle tre righe di codice che hai postato.. Ma prendi un programma da 10.000 righe di codice. Guarda guarda quanto sono uguali gli assembly generati..

[cdimauro]

Originariamente inviato da Unrue

E perchè?? Se tali tecniche sono implementate direttamente nel processore non si attivano certo con o senza la VM. Non vedo il collegamento tra le due cose.

Semplice: se un programma è compilato che se ne fa di quelle informazioni? Nulla: il codice è stato generato staticamente e amen.

Mentre una VM può farne uso per generare codice in base a esse.

Ma scusami tanto.. quando ho parlato di codice C++ ottimizzato per l'hardware, mi hai linkato quell'articolo Dinamo( molto interessante trall'altro). E poi si scopre che molto probabilmente Java non adotta quelle tecniche?

Ho detto che non conosco i dettagli della JVM, non che non le adotti.

Ma allora .. Continua a valere il mio discorso. Che, almeno per adesso, un programma C++ ottimizzato con l'hardware è più veloce di un analogo Java

Vedi sopra.

[Unrue]

Originariamente inviato da cdimauro

Semplice: se un programma è compilato che se ne fa di quelle informazioni? Nulla: il codice è stato generato staticamente e amen.

Ti prendo il branch -predictor come esempio,in quanto menzionato prima. Non è che lui si attiva o meno in base al fatto che hai o no la VM. Continuo a non capire il tuo discorso. Gli arriva del codice assembly e lui predice i salti. Non gli e ne importa nulla da dove venga questo codice, se da C++, Java o Cobol.

Originariamente inviato da cdimauro

Ho detto che non conosco i dettagli della JVM, non che non le adotti.

Vedi sopra.

Mi informerò. Certo però, se mi posti un link in un thread dove si parla di velocità tra C++ e Java, abbi l'accortezza di verificare se Java adotta quelle tecniche Altrimenti è aria fritta. Anche io potrei citarti centinaia di articoli in cui si migliora l'assembly generato. Ma se C++ non le usa, che li cito a fare?

Bye bye e buon anno

[cdimauro]

Originariamente inviato da Unrue

Ti prendo il branch -predictor come esempio,in quanto menzionato prima. Non è che lui si attiva o meno in base al fatto che hai o no la VM. Continuo a non capire il tuo discorso. Gli arriva del codice assembly e lui predice i salti. Non gli e ne importa nulla da dove venga questo codice, se da C++, Java o Cobol.

Non ci siamo capiti: mi riferivo alle informazioni disponibili a runtime che puoi recuperare dagli appositi registri di sistema.

La logica di branch prediction non c'entra nulla.

Mi informerò. Certo però, se mi posti un link in un thread dove si parla di velocità tra C++ e Java, abbi l'accortezza di verificare se Java adotta quelle tecniche Altrimenti è aria fritta. Anche io potrei citarti centinaia di articoli in cui si migliora l'assembly generato. Ma se C++ non le usa, che li cito a fare?

Perdonami: era una discussione a 360° e quello di cui stiamo parlando sarà anche aria fritta (da verificare) ma è utile a capire le differenze di fondo che ci stanno fra l'esecuzione di codice nativo "direttamente" e quello di codice che passa da una VM.

Bye bye e buon anno

Altrettanto.

[jappilas]

Originariamente inviato da Unrue

Questo non è vero perchè ci sono circuiti di branch-prediction nel processore, che evitano proprio questo. E non c'entra nulla con il linguaggio che si sta usando.

E visto che vi piace snocciolare link, ve ne snocciolo uno anch'io :

http://en.wikipedia.org/wiki/Branch_prediction

so cos'è la brach prediction
ma quelle che avevo in mente prima (chiedo scusa, nella fretta ho formulato il post precedente in modo poco chiaro ) erano non tanto penalità da branch misprediction, ma cache miss
se il blocco di codice coperto dalla prima condizione (non verificata) è lungo, quello seguente, non essendo "locale" al primo, resterà escluso dal prefetch in cache della prima istruzione di test e di quelle attigue - al che entrarvi comporterà un cache miss ( questo anche se il processore eseguisse il branch corretto nella totalità dei casi, cioè se il branch predictor avesse un ' accuratezza del 100%, cosa che anche con i predittori attuali a tabelle multiple, non avviene - la precisione si attesta sul 97% - motivo per cui su certi processori l' instruction scheduling interno avviene in modo ottimistico, ignorando il responso della BP per, eventualmente e successivamente, ripetere il flusso di esecuzione corretto, dal branch in avanti ... certo, si potrebbe obiettare che su quegli stessi processori la L1I allinea le micro-ops sulle cache lines, sequenziando direttamente un flusso di esecuzione che copre i salti condizionati, quindi un' ottimizzazione di questo tipo potrebbe avere valenza relativa, però... )
se la seconda condizione è quella più frequentemente verificata ( cosa che un compilatore C/C++ statico che non inferisce sulla condizioni di runtime, non ha modo di sapere a priori ), e se l' intera sequenza è racchiusa in un loop, quel loop sarà tipicamente inefficiente
ed è qui che può assumere rilevanza il profiling od anche un compilatore JIT che ottimizzi l' ordine dei blocchi di codice, che è quello che intendevo prima ( e per cui LLVM è nato, anche se LLVM è interessante per tutta una serie di altri aspetti - oltre a poter essere usato come compilatore statico a mo' di alternativa all' ottimizzatore di GCC ...)
ma in effetti si comincia a divagare... LLVM di suo avrebbe le potenzialità per portare notevoli benefici su più fronti, un sistema JIT su altri ( non necessariamente e non solo in relazione con la portabilità o con il profiling delle applicazioni), mentre il thread verteva su java

ps: tanti auguri

[dupa]

ma la branch prediction nn appare in caso di pipeline di cpu? che c'entra con java e c++?

ciao

[-Slash]

Dal basso della mia poca esperienza di programmazione posso dire che tutti i programmi che ho provato scritti in java sono di una lentezza a dir poco esasperante. Un esempio direi Maple, che ho installato da poco, e crasha una volta si e l'altra anche, ma anche eclipse, che è di una lentezza esasperante se non si ha un sistema con almeno 512 mb di ram, a differenza che ne so di un code::blocks che funziona ovunque. In generale programmi con funzionalità equivalenti funzionano meglio se scritti in c++ che se scritti in java.

Questo dettato dalla mia normale esperienza di utilizzatore diciamo medio-avanzato di computer. Per quanto riguarda la programmazione io studio c++ per l'università e la sintassi mi piace molto. D'altro canto ho dato un occhio a java e non posso dire la stessa cosa.

Poi però ho letto diverse opinioni riguardo la relativa semplicità rispetto a c++ per quanto riguarda alcune operazioni che invece nel linguaggio di Stroutsap risultano piu complesse, quindi sto seriamente considerando la possibilità di iniziare ad imparare un altro linguaggio. Volevo quindi chiedervi: a che agevolazioni vi riferite?

[cdimauro]

Come avevo già detto, non puoi prendere a esempio programmi che esistono esclusivamente per un determinato linguaggio e generalizzare su quest'ultimo.

Bisogna prendere le STESSE applicazioni, che differiscono esclusivamente per il linguaggio di programmazione usato per implementarle.

Quanto alle agevolazioni di cui parli, un ambiente managed (generalmente) ti mette al riparo da segmentation fault / access violation, memory leak, doppia deallocazione della memoria, e qualche altra cosa: veri e propri incubi per chi programma con linguaggi non managed.

[-Slash]

Originariamente inviato da cdimauro

Come avevo già detto, non puoi prendere a esempio programmi che esistono esclusivamente per un determinato linguaggio e generalizzare su quest'ultimo.

Bisogna prendere le STESSE applicazioni, che differiscono esclusivamente per il linguaggio di programmazione usato per implementarle.

Quanto alle agevolazioni di cui parli, un ambiente managed (generalmente) ti mette al riparo da segmentation fault / access violation, memory leak, doppia deallocazione della memoria, e qualche altra cosa: veri e propri incubi per chi programma con linguaggi non managed.

Quello che intendo io è che confronando programmi molto simili che svolgono le stesse funzioni, lo stesso programma scritto in c++ funziona mediamente molto meglio secondo me.

Un altro esempio che posso farti è azureus per esempio: ha piu o meno le stesse possibilità di un programma di torrent avanzato, ma è a dir poco pachidermico. Forse proprio la facilità di cui parli fa si che programmatori diciamo non molto capaci facciano programmi anche piu complessi delle loro possibilità, non so che dirti, perchè se devo dire un programma scritto in java che mi soddisfi per velocità non te ne so dire neanche uno

per quanto riguarda i vantaggi a cui tu fai riferimento, avevo letto dell'estrema facilità nello scrivere interfacce, tramite codice o tramite tool con java, è vero?

[cdimauro]

Personalmente mi trovo decisamente meglio con Delphi, che IMHO ancora oggi è imbattibile nella scrittura di applicazioni dotate di GUI.

I vantaggi a cui mi riferivo non hanno a che fare con la creazione di applicazioni dotate di GUI: si tratta di concetti "generali", applicabili a qualunque tipo di codice.

Per le altre cose, l'avevo scritto: http://www.hwupgrade.it/forum/showpo...9&postcount=65
Confrontare applicazioni diverse, come Azureus e uTorrent, non ha senso.

[Tommo]

Originariamente inviato da cdimauro

Confrontare applicazioni diverse, come Azureus e uTorrent, non ha senso.

Beh con uTorrent fai praticamente le stesse cose, ma quando sta acceso non te ne accorgi.
Per usare Azureus invece devo lasciare il pc