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

[Barbalbero]

Sul web i pareri sono discordi e contrastanti, sebbene tutti ammettano che C++ sia più performante di java. Alcuni però sostengono che le prestazioni siano simili. Voi che ne dite?
Parlando ad esempio di software di visione artificiale, credete sia conveniente l'utilizzo di java (comodo per via delle libererie disponibili) o è meglio utilizzare il C++?

[subvertigo]

La filosofia di Java è chi va piano va sano e va lontano.

Tutto in Java è fatto per essere il più lento e pesante possibile :D .

Se hai mezzi/conoscenze per usare il C++ vai sicuro su quello...

[Barbalbero]

La mia filosofia è che se i mezzi o le conoscenze mancano, si è sempre in tempo ad acquisirle :cool:

[^TiGeRShArK^]

La filosofia di Java è chi va piano va sano e va lontano.

Tutto in Java è fatto per essere il più lento e pesante possibile :D .

Se hai mezzi/conoscenze per usare il C++ vai sicuro su quello...

:asd:
guarda che è già da un paio di anni che è stato introdotto il JIT.
Java ha prestazioni paragonabili al C++ oggi come oggi.
Già un paio di volte avevo postato dei bench con sciencemark e con non ricordo quale altro software in cui si vedeva che mediamente, in quell'ambito, le prestazioni di java erano circa il 95% di quelle del C++.

[subvertigo]

:asd:
guarda che è già da un paio di anni che è stato introdotto il JIT.
Java ha prestazioni paragonabili al C++ oggi come oggi.
Già un paio di volte avevo postato dei bench con sciencemark e con non ricordo quale altro software in cui si vedeva che mediamente, in quell'ambito, le prestazioni di java erano circa il 95% di quelle del C++.

Ok sono banalotto al 100%.... ma dimmi... secondo te si riuscirebbe a fare in Java un Utorrent da 100 Kb di codice oggetto, velocissimo e con pochissima occupazione di risorse?

Già il fatto di usare una VM è di per sè più pesante...

[^TiGeRShArK^]

Ok sono banalotto al 100%.... ma dimmi... secondo te si riuscirebbe a fare in Java un Utorrent da 100 Kb di codice oggetto, velocissimo e con pochissima occupazione di risorse?

Già il fatto di usare una VM è di per sè più pesante...
:mbe:
cioè tu misuri le performance in base al tempo di avvio di un'applicazione o in base alla memoria occupata dalla VM? :mbe:
guarda..
io le performance, nel mio ambito, tendo a valutarle in base alla velocità di servizio a regime e, sinceramente, in un'epoca in cui 2 GB di ram costano 50 euro, che la VM in partenza mi occupi 20 MB sinceramente non mi pare uno scandalo.
L'importante è che le prestazioni siano paragonabili al C++ SENZA gli sbattimenti assurdi di quel linguaggio.

[mad_hhatter]

Ok sono banalotto al 100%.... ma dimmi... secondo te si riuscirebbe a fare in Java un Utorrent da 100 Kb di codice oggetto, velocissimo e con pochissima occupazione di risorse?

Già il fatto di usare una VM è di per sè più pesante...

ma parliamo di dimensione del codice oggetto o di velocita' dello stesso? mettiamoci d'accordo...

i benefici di java sono ben altri, non ti pare?

[stdecden]

:mbe:
cioè tu misuri le performance in base al tempo di avvio di un'applicazione o in base alla memoria occupata dalla VM? :mbe:
guarda..
io le performance, nel mio ambito, tendo a valutarle in base alla velocità di servizio a regime e, sinceramente, in un'epoca in cui 2 GB di ram costano 50 euro, che la VM in partenza mi occupi 20 MB sinceramente non mi pare uno scandalo.
L'importante è che le prestazioni siano paragonabili al C++ SENZA gli sbattimenti assurdi di quel linguaggio.

É una cosa che non capiró mai...

I linguaggi diventano sempre piú lenti e pesanti, mentre i computer diventano sempre piú potenti...

Secondo me non ha senso creare linguaggi cosí pesanti e non sfruttare al massimo le capacitá della macchina.

P.S. Sto parlando in particolare dei linguaggi .NET, con java non ho tanta esperienza, ma credo sia la stessa cosa

[^TiGeRShArK^]

http://www.shudo.net/jit/perf/SciMark-P4.png
http://www.shudo.net/jit/perf/Linpack-1000-P4.png

[^TiGeRShArK^]

É una cosa che non capiró mai...

I linguaggi diventano sempre piú lenti e pesanti, mentre i computer diventano sempre piú potenti...

Secondo me non ha senso creare linguaggi cosí pesanti e non sfruttare al massimo le capacitá della macchina.

P.S. Sto parlando in particolare dei linguaggi .NET, con java non ho tanta esperienza, ma credo sia la stessa cosa

:mbe:
veramente + un programma è ad alto livello + è facile concentrarsi sul problema, magari avendo a disposizione + tempo per trovare algoritmi migliori per risolverlo.
Se invece ci si dovesse concentrare a tracciare un maledetto segmentation fault o qualche memory leak apparentemente impossibile si otterrebbero programmi di qualità + scadente (o per le features che non sono state implementate per carenza di tempo o per i bug ancora presenti)

[sottovento]

Ciao,
volevo aggiungere il mio parere: la vita non e' riconducibile ad un benchmark :)
Il tuo programma sara' piuttosto lungo, con una parte piuttosto critica e (molte) altre parti meno critiche, ma comunque necessitanti di un certo grado di prestazioni.

Probabilmente in queste parti (circa l'80% del codice) troverai la conferma di quello che sto per dirti (sperando di non far partire un flame gigantesco): Java avra' prestazioni addirittura superiori al C/C++!
Ho avuto la possibilita' di vedere la stessa applicazione codificata nei due linguaggi e verificare, (non senza incredulita') questa affermazione.

Com'e' possibile? Semplice: nei benchmark pui codificare lo stesso algoritmo di test in entrambi i linguaggi, con una codifica che e' pressoche simile. In questo caso, spesso (non sempre e non cosi' frequentemente come si crede), C++ ha prestazioni superiori (i.e. e' piu' veloce, stiamo parlando di questo, no?).

Nella programmazione di una applicazione "vera", spesso lo stesso algoritmo deve essere codificato nei due linguaggi in due maniere diverse.
Il risultato e' che spesso, per evitare crash/leaks/... in C++ e' necessario ricorrere alle COPIE di oggetti, mentre in Java queste copie semplicemente non sono necessarie. La copia costa, in termini di memoria e di velocita' di esecuzione, e costa piu' della compilazione JIT (che avviene peraltro una sola volta).
Addirittura (esperienza personale) i programmatori non si accorgono nemmeno di aver fatto una copia poiche' essa e' implicita nel passaggio di argomenti, ritorno di funzioni, ....

Questo fa decadere le prestazioni drammaticamente.
Queste copie sono evitabili? Non sempre, e non sempre in modo "pulito".
Java non ha questi problemi. Ovviamente dovra' deallocare la memoria non piu' in uso, ma puo' usare trucchi basati su "economia di scala", per esempio, deallocando blocchi di oggetti contigui od usando un qualsiasi altro algoritmo.
E' questo un notevole vantaggio di cui C++ non puo' godere.

Esistono poi parecchi altri problemi relativi alle prestazioni, in un programma reale. Java li affronta mediamente meglio, e fa sicuramente meglio di un programmatore medio C++.

Il mio suggerimento e': scrivi tutto in Java. Ci saranno poi delle parti (saranno meno del 10%) che potranno essere ottimizzate cambiando linguaggio.
Potrai riscrivere queste parti in C++ (meglio in C) e chiamarle direttamente dall'ambiente Java, cercando cosi' di ottimizzare i benefici.

[morskott]

Ciao,
volevo aggiungere il mio parere: la vita non e' riconducibile ad un benchmark :)
Il tuo programma sara' piuttosto lungo, con una parte piuttosto critica e (molte) altre parti meno critiche, ma comunque necessitanti di un certo grado di prestazioni.

Probabilmente in queste parti (circa l'80% del codice) troverai la conferma di quello che sto per dirti (sperando di non far partire un flame gigantesco): Java avra' prestazioni addirittura superiori al C/C++!
Ho avuto la possibilita' di vedere la stessa applicazione codificata nei due linguaggi e verificare, (non senza incredulita') questa affermazione.

Com'e' possibile? Semplice: nei benchmark pui codificare lo stesso algoritmo di test in entrambi i linguaggi, con una codifica che e' pressoche simile. In questo caso, spesso (non sempre e non cosi' frequentemente come si crede), C++ ha prestazioni superiori (i.e. e' piu' veloce, stiamo parlando di questo, no?).

Nella programmazione di una applicazione "vera", spesso lo stesso algoritmo deve essere codificato nei due linguaggi in due maniere diverse.
Il risultato e' che spesso, per evitare crash/leaks/... in C++ e' necessario ricorrere alle COPIE di oggetti, mentre in Java queste copie semplicemente non sono necessarie. La copia costa, in termini di memoria e di velocita' di esecuzione, e costa piu' della compilazione JIT (che avviene peraltro una sola volta).
Addirittura (esperienza personale) i programmatori non si accorgono nemmeno di aver fatto una copia poiche' essa e' implicita nel passaggio di argomenti, ritorno di funzioni, ....

Questo fa decadere le prestazioni drammaticamente.
Queste copie sono evitabili? Non sempre, e non sempre in modo "pulito".
Java non ha questi problemi. Ovviamente dovra' deallocare la memoria non piu' in uso, ma puo' usare trucchi basati su "economia di scala", per esempio, deallocando blocchi di oggetti contigui od usando un qualsiasi altro algoritmo.
E' questo un notevole vantaggio di cui C++ non puo' godere.

Esistono poi parecchi altri problemi relativi alle prestazioni, in un programma reale. Java li affronta mediamente meglio, e fa sicuramente meglio di un programmatore medio C++.

Il mio suggerimento e': scrivi tutto in Java. Ci saranno poi delle parti (saranno meno del 10%) che potranno essere ottimizzate cambiando linguaggio.
Potrai riscrivere queste parti in C++ (meglio in C) e chiamarle direttamente dall'ambiente Java, cercando cosi' di ottimizzare i benefici.

Dipende pure dall'ambito di utilizzo, un controllore di un nocciolo di una centrale nucleare col cavolo che lo programmerei in Java, ma diciamo che nelle altre situazioni (leggermente piu normali) il così tanto overhead di java in pratica non ce se ne accorge nemmeno, sempre che esista (come sottovento ha sottolineato).
Per utilizzi un po a metà tra il normale e lo strict real time farei la parte critica in C/C++ e lo chiamerei da java tramite JNI (spero di aver azzeccato la sigla).

[71104]

La filosofia di Java è chi va piano va sano e va lontano.

Tutto in Java è fatto per essere il più lento e pesante possibile :D .

Se hai mezzi/conoscenze per usare il C++ vai sicuro su quello...

guarda, tante volte non lo sapessi Jake è più veloce di Quake :asd:

[71104]

Già il fatto di usare una VM è di per sè più pesante...

:mbe:
cioè tu misuri le performance in base al tempo di avvio di un'applicazione o in base alla memoria occupata dalla VM? :mbe:

infatti non ha senso; la memoria occupata dal materiale specifico della virtual machine è in gran parte condivisa da tutti i processi che vi si appoggiano, quindi all'aumentare del numero di processi Java che girano contemporaneamente l'overhead rappresentato dalla JVM tende a scomparire. ma questa è solo la motivazione più stupida per la quale l'overhead della JVM non può assolutamente controbilanciare negativamente gli enormi benefici del programmare in una piattaforma managed piuttosto che in C++.

[71104]

ma parliamo di dimensione del codice oggetto o di velocita' dello stesso? mettiamoci d'accordo...

i benefici di java sono ben altri, non ti pare? anche perché come dimensioni del... "codice oggetto" vince sicuramente Java; in genere gli eseguibili nativi sono molto più grossi dei .class o dei .jar (questi ultimi poi sono pure compressi).

[^TiGeRShArK^]

Dipende pure dall'ambito di utilizzo, un controllore di un nocciolo di una centrale nucleare col cavolo che lo programmerei in Java, ma diciamo che nelle altre situazioni (leggermente piu normali) il così tanto overhead di java in pratica non ce se ne accorge nemmeno, sempre che esista (come sottovento ha sottolineato).
Per utilizzi un po a metà tra il normale e lo strict real time farei la parte critica in C/C++ e lo chiamerei da java tramite JNI (spero di aver azzeccato la sigla).
solo se serve..
l'ottimizzazione del codice se effettuata senza alcun dato preciso di profiling, e, in caso non sia strettamente necessaria, porta sempre ad un peggioramento del codice rendendolo meno leggibile e + soggetto ai bug.
Io di solito scrivo in Java (o python o ruby o C# o quello che capita) e finora non ho mai avuto necessita di ottimizzare i miei programmi dato che la velocità di esecuzione è generalmente ottimale.
In caso fosse strettamente necessaria, la prima fase di ottimizzazione da fare SEMPRE, è quella di utilizzare un algoritmo + performante.
Con un semplice cambio di algoritmo si possono averee vantaggi MOLTO + drastici rispetto all'uso dello stesso algoritmo con JNI.
In caso ancora non fosse sufficiente cercherei di ottimizzare il tutto nello stesso linguaggio utilizzato, e, solo come soluzione estrema, ottimizzerei l'1% critico di codice con un linguaggio compilato staticamente.

[71104]

I linguaggi diventano sempre piú lenti e pesanti, ma dove...

Secondo me non ha senso creare linguaggi cosí pesanti e non sfruttare al massimo le capacitá della macchina. e allora esci dal luogo comune, quello è ovvio che non ha senso.

[71104]

Dipende pure dall'ambito di utilizzo, un controllore di un nocciolo di una centrale nucleare col cavolo che lo programmerei in Java, ma diciamo che nelle altre situazioni (leggermente piu normali) il così tanto overhead di java in pratica non ce se ne accorge nemmeno, sempre che esista (come sottovento ha sottolineato).
Per utilizzi un po a metà tra il normale e lo strict real time farei la parte critica in C/C++ e lo chiamerei da java tramite JNI (spero di aver azzeccato la sigla).
praticamente stai dicendo che il codice critico (cioè diciamo quello che deve funzionare a tutti i costi) tu non lo affideresti mai ad una virtual machine, ma preferisci scrivertelo da solo. teoricamente hai ragione dal momento che la Sun non si assume responsabilità per danni che la tecnologia Java può provocare alle persone, all'ambiente, ecc. ecc. :D ma nella pratica lasciati dire che nello scrivere il tuo codice critico sbaglierai con probabilità molto maggiore di quanto potrebbe mai sbagliare la JVM, semplicemente perché la JVM è un prodotto software molto maturo.

[71104]

solo come soluzione estrema, ottimizzerei l'1% critico di codice con un linguaggio compilato staticamente. io veramente a quel punto proporrei l'acquisizione di hardware migliore... seriamente, per un 1% ti stai ad ammazzare rendendo i tuoi sorgenti incomprensibili e per nulla manutenibili, aumentando a dismisura i costi futuri di riutilizzo di quel codice? :D
e secondo te un 1% di performance in più non lo puoi guadagnare migliorando l'hardware? perché cavolo deve essere il programmatore a farsi un didietro così a scrivere software? tantopiù che siamo a Natale :D

[^TiGeRShArK^]

io veramente a quel punto proporrei l'acquisizione di hardware migliore... seriamente, per un 1% ti stai ad ammazzare rendendo i tuoi sorgenti incomprensibili e per nulla manutenibili, aumentando a dismisura i costi futuri di riutilizzo di quel codice? :D
e secondo te un 1% di performance in più non lo puoi guadagnare migliorando l'hardware? perché cavolo deve essere il programmatore a farsi un didietro così a scrivere software? tantopiù che siamo a Natale :D
infatti l'ho citata appositamente come ultimissima scelta giusto per evitare l'impalamento e la crocifissione in sala mensa :D

[Tommo]

Mah, secondo me Java effettivamente è più lento del C++ in molti casi...
Azureus mi impalla il pc ancora oggi, e prendeva il 60% del mio P4. Alcune demo fatte da me rallentavano paurosamente appena comparivano più di 10 forme o finestrelle...
Poi certo l'operatore ++ funziona altrettanto veloce :D
Sinceramente non so come fanno questi test a dare il Java veloce come il C++, quando nella "vita reale" questo è falso: i programmi Java sono sempre poco reattivi se non proprio inutilmente pesanti...

io veramente a quel punto proporrei l'acquisizione di hardware migliore... seriamente, per un 1% ti stai ad ammazzare rendendo i tuoi sorgenti incomprensibili e per nulla manutenibili, aumentando a dismisura i costi futuri di riutilizzo di quel codice? :D
e secondo te un 1% di performance in più non lo puoi guadagnare migliorando l'hardware? perché cavolo deve essere il programmatore a farsi un didietro così a scrivere software? tantopiù che siamo a Natale :D

Un 1% qua, un 1% la... e così nel 2007 i quad core sono utilizzati di m***a, e per far girare word2007 su Vista serve un Core2Duo e 2gb di ram. :muro:
E a giudicare dalla tua firma non ti dovrebbe piacere proprio questo andazzo... guarda che Linux non lo hanno MAI sviluppato pensando in questa maniera.
Per favore, non fare più sto ragionamento... mi pare un ragionamento da idraulico pagato a ore + che da programmer serio.
"Facciamo le cagate, tanto paga l'user"... :rolleyes:

[kk3z]

Il programmatore java va avanti di presupposti: tanto tutti hanno 1 giga di memoria, tanto costa poco 1 giga di ram, tanto tutti hanno la virtual machine, tanto se non ce l'hanno devono scaricare solo 20 mb, tanto tutti hanno l'adsl...

[franksisca]

Mah, secondo me Java effettivamente è più lento del C++ in molti casi...
Azureus mi impalla il pc ancora oggi, e prendeva il 60% del mio P4. Alcune demo fatte da me rallentavano paurosamente appena comparivano più di 10 forme o finestrelle...
Poi certo l'operatore ++ funziona altrettanto veloce :D
Sinceramente non so come fanno questi test a dare il Java veloce come il C++, quando nella "vita reale" questo è falso: i programmi Java sono sempre poco reattivi se non proprio inutilmente pesanti...
Un 1% qua, un 1% la... e così nel 2007 i quad core sono utilizzati di m***a, e per far girare word2007 su Vista serve un Core2Duo e 2gb di ram. :muro:
E a giudicare dalla tua firma non ti dovrebbe piacere proprio questo andazzo... guarda che Linux non lo hanno MAI sviluppato pensando in questa maniera.
Per favore, non fare più sto ragionamento... mi pare un ragionamento da idraulico pagato a ore + che da programmer serio.
"Facciamo le cagate, tanto paga l'user"... :rolleyes:
pensa che a me azureus sul muletto(P2 450) va benissimo.....

Non è assolutamente vero che i programmi java sono poco reattivi.

Comunque ricordate che si parla di programmi compilati con JIT......ne avete mai usato 1???
Il programmatore java va avanti di presupposti: tanto tutti hanno 1 giga di memoria, tanto costa poco 1 giga di ram, tanto tutti hanno la virtual machine, tanto se non ce l'hanno devono scaricare solo 20 mb, tanto tutti hanno l'adsl...

ma guarda che non è vero, in java esistono i thread(non solo in java)....se sai cosa sono capirai che la tua affermazione è insensata;)

[sottovento]

Il programmatore java va avanti di presupposti: tanto tutti hanno 1 giga di memoria, tanto costa poco 1 giga di ram, tanto tutti hanno la virtual machine, tanto se non ce l'hanno devono scaricare solo 20 mb, tanto tutti hanno l'adsl...

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.

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

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?

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 i bug sono piu' frequentemente localizzati nella parte di interfaccia, realizzata con altri linguaggi (normalmente C o assembler).

[^TiGeRShArK^]

Mah, secondo me Java effettivamente è più lento del C++ in molti casi...
Azureus mi impalla il pc ancora oggi, e prendeva il 60% del mio P4. Alcune demo fatte da me rallentavano paurosamente appena comparivano più di 10 forme o finestrelle...
Poi certo l'operatore ++ funziona altrettanto veloce :D
Sinceramente non so come fanno questi test a dare il Java veloce come il C++, quando nella "vita reale" questo è falso: i programmi Java sono sempre poco reattivi se non proprio inutilmente pesanti...
:mbe:
sbaglio o hai citato solo applicazioni grafiche? :mbe:
cmq con l'update N, di prossima uscita, anche questo problema teoricamente dovrebbe essere risolto dato che le swing sotto windows useranno di default l'accelerazione direct x anzichè quella open gl finora utilizzata.
E cmq..
tanto a reattività Eclipse e Netbeans non mi sembra proprio che abbiano niente da invidiare ad un'applicazione nativa, anche con la release attuale della JRE.

[^TiGeRShArK^]

Un 1% qua, un 1% la... e così nel 2007 i quad core sono utilizzati di m***a, e per far girare word2007 su Vista serve un Core2Duo e 2gb di ram. :muro:
E a giudicare dalla tua firma non ti dovrebbe piacere proprio questo andazzo... guarda che Linux non lo hanno MAI sviluppato pensando in questa maniera.
Per favore, non fare più sto ragionamento... mi pare un ragionamento da idraulico pagato a ore + che da programmer serio.
"Facciamo le cagate, tanto paga l'user"... :rolleyes:
si vabbè..
e secondo te anzichè impiegare il tempo per fare un software FUNZIONANTE, bisognerebbe impiegarlo per guadagnare un 1% (scarso) di prestazioni che all'atto pratico sarebbe inutile perdendoci in leggibilità del codice e a umentando la possibilità di introdurre bug? :rolleyes:
Le ottimizzazioni vanno fatte solo ed esclusivamente se un accurato profiling del codice mostra effettivamente un problema prestazionale nell'esecuzione del codice.
E, per inciso, dato che MOLTI sembrano dimenticarlo, solitamente il 90% delle perdite di performance si trovano nell'1% critico del codice.
Per cui ottimizzare TUTTO il codice, oltre che essere una perdita di tempo che non porta a benefici prestazionali evidenti, è un metodo SICURO per introdurre bug e per perdere tempo che potrebbe essere meglio utilizzato per introdurre nuove features (che, a mio modesto parere, sono + utili dei bug :p)

[^TiGeRShArK^]

Il programmatore java va avanti di presupposti: tanto tutti hanno 1 giga di memoria, tanto costa poco 1 giga di ram, tanto tutti hanno la virtual machine, tanto se non ce l'hanno devono scaricare solo 20 mb, tanto tutti hanno l'adsl...
:rolleyes:
tu invece vai avanti per luoghi comuni :rolleyes:
7.1 MB è la dimensione della nuova JRE per windows tanto per inciso.
e, tanto per continuare, l'ENORME occupazione di memoria che secondo te dovrebbe avere, si traduce con 6.8 MB di RAM occupata per la VM alla partenza.
complimenti per la disinformazione gratuita :rolleyes:

[^TiGeRShArK^]

Il programmatore java va avanti di presupposti: tanto tutti hanno 1 giga di memoria, tanto costa poco 1 giga di ram, tanto tutti hanno la virtual machine, tanto se non ce l'hanno devono scaricare solo 20 mb, tanto tutti hanno l'adsl...
oddio.. :muro:
solo ora ho notato la tua sign..
Non mi venire a dire che tu programmi in PHP e critichi Java?!?!? :muro:

[Tommo]

:mbe:
sbaglio o hai citato solo applicazioni grafiche? :mbe:
cmq con l'update N, di prossima uscita, anche questo problema teoricamente dovrebbe essere risolto dato che le swing sotto windows useranno di default l'accelerazione direct x anzichè quella open gl finora utilizzata.
E cmq..
tanto a reattività Eclipse e Netbeans non mi sembra proprio che abbiano niente da invidiare ad un'applicazione nativa, anche con la release attuale della JRE.
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 :rolleyes:


si vabbè..
e secondo te anzichè impiegare il tempo per fare un software FUNZIONANTE, bisognerebbe impiegarlo per guadagnare un 1% (scarso) di prestazioni che all'atto pratico sarebbe inutile perdendoci in leggibilità del codice e a umentando la possibilità di introdurre bug? :rolleyes:
Le ottimizzazioni vanno fatte solo ed esclusivamente se un accurato profiling del codice mostra effettivamente un problema prestazionale nell'esecuzione del codice.
E, per inciso, dato che MOLTI sembrano dimenticarlo, solitamente il 90% delle perdite di performance si trovano nell'1% critico del codice.
Per cui ottimizzare TUTTO il codice, oltre che essere una perdita di tempo che non porta a benefici prestazionali evidenti, è un metodo SICURO per introdurre bug e per perdere tempo che potrebbe essere meglio utilizzato per introdurre nuove features (che, a mio modesto parere, sono + utili dei bug :p)

Eh no... se sei bravo tu lo fai SIA veloce SIA funzionante... troppo comodo così :D
E poi posso capire se fosse l'1%... ma in Vista a forza di .NET si è perso un 40% buono... era forse il caso di correggere qualcuno di quei quaranta 1% di perdita "insignificante"?

Il problema fondamentale è che magari il java fosse solo l'1% più lento del C++... il 90% delle applicazioni di tutti i giorni (che guarda caso sono grafiche) stentano ancora parecchio.
Mi sono ricordato ora di un programma java per fare schemi UML talmente poco reattivo e veloce che mi ha fatto passare a paint :rolleyes:

Ci sarà un motivo se java è ancora usato in ambiente desktop solo sperimentalmente no?

[^TiGeRShArK^]

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 :rolleyes:

A parte che la velocità di un'applicazione NON si misura dal tempo di avvio, e questa è una cosa che davo ormai per scontato dato che è la misura PEGGIORE delle performance di un'applicazione (per inciso facendo partire la VM Java in modalità server ci mette PIU' tempo a partire ma i programmi girano + velocemente), cmq anche Visual Studio 2008 non mi pare quella grande scheggia all'avvio, eh... :rolleyes:

Eh no... se sei bravo tu lo fai SIA veloce SIA funzionante... troppo comodo così :D

mai lavorato in qualche progetto SERIO? :rolleyes:
secondo te il requirement qual'è?
arrivare alla scadenza con un'applicazione completa per un decimo che però va il 10% più veloce o completare totalmente l'applicazione rispettando i requisiti di performance? :rolleyes:

Il problema fondamentale è che magari il java fosse solo l'1% più lento del C++... il 90% delle applicazioni di tutti i giorni (che guarda caso sono grafiche) stentano ancora parecchio.
Mi sono ricordato ora di un programma java per fare schemi UML talmente poco reattivo e veloce che mi ha fatto passare a paint :rolleyes:

Ci sarà un motivo se java è ancora usato in ambiente desktop solo sperimentalmente no?
ci sarà un motivo se netbeans funziona egregiamente quanto a reattività? :rolleyes:
non sarà che *forse* il programma che hai provato era scritto con i piedi?
Il linguaggio di programmazione aiuta a scrivere codice pulito e funzionante..
Ma se non si rispettano le guidelines e si fa overengineering a manetta ecco che risultati si hanno.
L'overengineering, al pari dell'ottimizzazione NON NECESSARIA, è assolutamente DANNOSO per dei programmi scritti bene.

[marco.r]

Ma se non si rispettano le guidelines e si fa overengineering a manetta ecco che risultati si hanno.
L'overengineering, al pari dell'ottimizzazione NON NECESSARIA, è assolutamente DANNOSO per dei programmi scritti bene.

Mi sembra un difetto piuttosto diffuso nella comunita' Java, perlomeno rispetto a quelle di molti altri linguaggi. Forse proprio da li' la sensazione di maggior lentezza che molti rilevano.

Per 71104:
dovresti migliorare la qualita' della bitmap in sign. Io sono tarato, ma la prima volta ho letto "Against-TOPA" :mbe: :stordita: :p

[71104]

Mah, secondo me Java effettivamente è più lento del C++ in molti casi... "secondo me" in informatica non esiste

Sinceramente non so come fanno questi test a dare il Java veloce come il C++, quando nella "vita reale" questo è falso: i programmi Java sono sempre poco reattivi se non proprio inutilmente pesanti... a me non sembra proprio... tutta sta pesantezza mi sa più di luogo comune che altro, e ovviamente sto parlando da persona che usa molto spesso programmi Java (Eclipse in primis). ora sarà che sono il solito fortunello a cui tutto quanto funziona sempre bene*, ma io quando apro un menu in Eclipse quello si apre all'istante; quando clicco un pulsante quello comincia subito a fare quello che deve fare; per non parlare di quant'è veloce il completamento automatico del codice; e via dicendo.

*mi succede sempre così anche nel dibattito Windows vs. Linux, nel quale naturalmente io mi schiero a favore di Windows: sono l'unico della terra a cui Windows non crasha mai, che non deve mai formattare, che non si è mai beccato un virus, ecc. ecc. :asd:

che ci posso fare, sono fortunato :rolleyes:


Un 1% qua, un 1% la... e così nel 2007 i quad core sono utilizzati di m***a, e per far girare word2007 su Vista serve un Core2Duo e 2gb di ram. :muro: ho la nausea da frasi fatte

E a giudicare dalla tua firma non ti dovrebbe piacere proprio questo andazzo... e a giudicare da questa tua affermazione tu non hai capito un tubo della mia firma. la mia firma non lotta contro la trascurata ottimizzazione del software, bensì contro il Trusted Computing e i brevetti software. inoltre nella lotta contro il Trusted Computing io prendo una posizione particolare: poiché secondo me boicottare l'hardware (come i Core2) è troppo difficile visto che prima o poi verrà il momento in cui non esisterà più hardware non-TC, allora io sono a favore del boicottaggio del software. la mia firma questo non lo spiega, offre solo qualche link che costituisce per chi ancora non sa delle ottime fonti di informazione (Wikipiedia l'ho data per scontata).

guarda che Linux non lo hanno MAI sviluppato pensando in questa maniera. AAAAAAA MBE' ALLORA :sofico: :sofico: :sofico:

Per favore, non fare più sto ragionamento... mi pare un ragionamento da idraulico pagato a ore + che da programmer serio.
"Facciamo le cagate, tanto paga l'user"... :rolleyes: quanto ci godrò quando verrà il giorno che qualcuno non ti comprerà il tuo software perché qualcun altro l'ha già sviluppato prima di te perché facendolo in una piattaforma managed c'ha messo un decimo del tempo :asd:

[71104]

Per 71104:
dovresti migliorare la qualita' della bitmap in sign. Io sono tarato, ma la prima volta ho letto "Against-TOPA" :mbe: :stordita: :p me l'hanno detto anche su un altro forum :stordita:
ma non le ho realizzate io quelle immagini ^^
le ho prese da qua: http://www.againsttcpa.com/tcpa-banner.html

[banryu79]

*mi succede sempre così anche nel dibattito Windows vs. Linux, nel quale naturalmente io mi schiero a favore di Windows: sono l'unico della terra a cui Windows non crasha mai, che non deve mai formattare, che non si è mai beccato un virus, ecc. ecc. :asd:

che ci posso fare, sono fortunato :rolleyes:


Siamo in due allora. Mai usato Linux, quindi non dico una virgola dato che non lo conosco.

Ma sono un utente Windows, navigo in rete e tutto.
In 12 anni di utilizzo di pc vari con diversi software, giochi, IDE per sviluppo, navigazione in rete ecc... il peggio che mi è capitato è stato qualche crash sotto Win ME.

Con Win XP per esempio, mai avuto problemi fin'ora. Tutto bene anche con Windows 2000.

Botta di culo coi fiocchi anche per me allora :sofico:


Quoto anche l'affermazione di sottovento circa il fatto che Java (OAK alle origini) era nato per sistemi real time e embedded, nelle nuove tecnologie (nuove per l'epoca, si parla del 1990-91) ad esempio gli elettrodomestici di nuova generazione.

Se qualcuno ha la vaga idea di cosa significhi e quanto immmensamente importante sia l'affidabilità richiesta al software per elettrodomestici può immaginare lo spirito che doveva guidare coloro che hanno partorito Java.
(si parla di sistemi real time)


Per fare della critica costruttiva bisognerebbe sempre portare dei fatti che supportino le proprie affermazioni, non ha molto senso dire "secondo me" e basta.
Altrimenti, appunto, sono affermazioni che riguardano "solo te"

[subvertigo]

Allora secondo me la discussione è andata su un binario flamesco sbagliato...

Sul fatto che il Java introduca uno strato di astrazione ulteriore, e alcuni meccanismi come il garbage collector, più qualche API e middleware non al top dell'efficienza, penso che possiamo più o meno tutti concordare. Perciò questo riduce de facto l'efficienza rispetto ad un programma C++ che faccia la stessa identica cosa. Per questo avevo risposto di getto che "come prestazioni pure" è meglio il C++.

Nel senso dell'efficacia invece concordo con tutti quelli che fino ad ora hanno così bene difeso la piattaforma Java. E' sicuramente tra le più efficaci e promettente per il futuro (insieme alle altre tecnologie similari).

[sottovento]

Allora secondo me la discussione è andata su un binario flamesco sbagliato...

Sul fatto che il Java introduca uno strato di astrazione ulteriore, e alcuni meccanismi come il garbage collector, più qualche API e middleware non al top dell'efficienza, penso che possiamo più o meno tutti concordare. Perciò questo riduce de facto l'efficienza rispetto ad un programma C++ che faccia la stessa identica cosa. Per questo avevo risposto di getto che "come prestazioni pure" è meglio il C++.

Nel senso dell'efficacia invece concordo con tutti quelli che fino ad ora hanno così bene difeso la piattaforma Java. E' sicuramente tra le più efficaci e promettente per il futuro (insieme alle altre tecnologie similari).

Non era questo il senso del mio intervento.
Tutto quello che e' stato introdotto (i meccanismi che hai elencato) ritengo NON vadano ad inficiare le performance.
Per intenderci, il tuo ciclo "stretto", rimarra' tale anche in Java. Non c'e' motivo (apparente, a me conosciuto) che possa degradare le prestazioni.
Troverai un degrado delle prestazioni in operazioni che generalmente sono fuori dal tuo ciclo stretto, vale a dire le allocazioni, ...
Ma... non penso che qualcuno (a meno di applicazioni veramente particolari) se ne possa accorgere.
In compenso, avrai un netto miglioramento delle prestazioni in altre parti, piu' importanti, del programma.
Esempio: devi usare STL in C++? Che so, un container? Le STL sono estremamente ottimizzate, ma dovrai inserirci un oggetto che abbia un ciclo di vita compatibile con la sua memorizzazione nel container. In parole povere, dovrai gestire oggetti allocati dinamicamente, dovrai ricordarti di deallocarli, ...
Oppure, come fanno tutti, andrai di copia. E le performances saranno a favore di Java.

Le piattaforme managed stanno prendendo il sopravvento (detto da sottovento e' tutto un programma :D). Non e' solo perche' e' piu' facile scrivere programmi robusti, ma ne hai anche un vantaggio in prestazioni nei "casi medi".
Non e' difficile prevedere che in futuro sara' sempre meglio...

[Barbalbero]

Beh... io devo aggiungere una cosa... Sul mio portatile aspire 1650, quando è in modalità risparmio energetico, netbeans è fastidiosamente lento(scopro ora che è programmato in java)... eclipse ora che ci penso è circa uguale.... Mentre quando il processore è in modalità massima prestazione, va tutto ok.

[Tommo]

"secondo me" in informatica non esiste

a me non sembra proprio... tutta sta pesantezza mi sa più di luogo comune che altro, e ovviamente sto parlando da persona che usa molto spesso programmi Java (Eclipse in primis). ora sarà che sono il solito fortunello a cui tutto quanto funziona sempre bene*, ma io quando apro un menu in Eclipse quello si apre all'istante; quando clicco un pulsante quello comincia subito a fare quello che deve fare; per non parlare di quant'è veloce il completamento automatico del codice; e via dicendo.

*mi succede sempre così anche nel dibattito Windows vs. Linux, nel quale naturalmente io mi schiero a favore di Windows: sono l'unico della terra a cui Windows non crasha mai, che non deve mai formattare, che non si è mai beccato un virus, ecc. ecc. :asd:

che ci posso fare, sono fortunato :rolleyes:



Beh ho messo il "secondo me" perchè il mio parere è contrario ai tests, ma su 3 pc che ho provato i programmi java sono tangibilmente più lenti di quelli normali.
Sarà che sono fatti male, ma allora sarà una cattiva abitudine dei programmatori Java.
Forse è anche che Java non è lento di per se, ma purtroppo se uno nella sua vita usa solo quello non si renderà conto di molti problemi prestazionali, che sono evidenti solo se si programma in C/C++.



ho la nausea da frasi fatte


Non sono frasi fatte, io stesso uso Vista + Office2007, e li reputo ottimi, ma posso fare questo solo perchè ho un pc buono comprato da poco... sono lentissimi su pc vecchi, tanto che la gente torna a farsi mettere XP sui pc scassoni.
Frasi sentite in coda in un negozio di informatica:
"Sto pc è nuovo, ma parte lentissimo, non si accende nulla, ci mette anni a fare le cose... ma io non ci ho messo nulla!"
"Beh ha Vista?"
"Si"
"E' normale."
:D


e a giudicare da questa tua affermazione tu non hai capito un tubo della mia firma. la mia firma non lotta contro la trascurata ottimizzazione del software, bensì contro il Trusted Computing e i brevetti software. inoltre nella lotta contro il Trusted Computing io prendo una posizione particolare: poiché secondo me boicottare l'hardware (come i Core2) è troppo difficile visto che prima o poi verrà il momento in cui non esisterà più hardware non-TC, allora io sono a favore del boicottaggio del software. la mia firma questo non lo spiega, offre solo qualche link che costituisce per chi ancora non sa delle ottime fonti di informazione (Wikipiedia l'ho data per scontata).

Si si conosco il problema, ho letto anche i link... ho detto quello perchè di solito Contro Vista, TCP e M$ = Linuxaro.
Sinceramente non avrei mai sospettato che ti trovassi bene con win :D


quanto ci godrò quando verrà il giorno che qualcuno non ti comprerà il tuo software perché qualcun altro l'ha già sviluppato prima di te perché facendolo in una piattaforma managed c'ha messo un decimo del tempo :asd:
Poi quando esce il mio tutti passano a quello perchè LORO ci mettono un decimo del tempo a lavorarci :rolleyes:

[71104]

Siamo in due allora. Mai usato Linux, quindi non dico una virgola dato che non lo conosco.

Ma sono un utente Windows, navigo in rete e tutto.
In 12 anni di utilizzo di pc vari con diversi software, giochi, IDE per sviluppo, navigazione in rete ecc... il peggio che mi è capitato è stato qualche crash sotto Win ME.

Con Win XP per esempio, mai avuto problemi fin'ora. Tutto bene anche con Windows 2000.

Botta di culo coi fiocchi anche per me allora :sofico: chiariamo un attimo però, a onor del vero a me Windows 95 e Windows 98 mi si impallavano sempre :D
per non parlare della mia esperienza con Windows ME... l'ho tenuto installato complessivamente solo per poche ore :asd: all'avvio voleva per forza farmi sorbire la sua scrausissima presentazione, che la prima volta si è anche bloccata miseramente (e quindi sono stato costretto a sorbirmela due volte).

Windows 2000 è stata una svolta: non mi pareva vero che un sistema operativo potesse non bloccarsi mai :eek: eppure oh, quello mica si bloccava eh... e così piano piano iniziai ad apprendere le meraviglie di quello che era chiamato il kernel NT.

fine OT :p

Per fare della critica costruttiva bisognerebbe sempre portare dei fatti che supportino le proprie affermazioni, non ha molto senso dire "secondo me" e basta.
Altrimenti, appunto, sono affermazioni che riguardano "solo te" e magari pure sbagliate

[71104]

Beh... io devo aggiungere una cosa... Sul mio portatile aspire 1650, quando è in modalità risparmio energetico, netbeans è fastidiosamente lento(scopro ora che è programmato in java)... eclipse ora che ci penso è circa uguale.... Mentre quando il processore è in modalità massima prestazione, va tutto ok. e i programmi nativi?

[Barbalbero]

se con "programmi nativi" (perdona l'ignoranza) intendi i normali programmi per windows, sì, vanno leggermente più lenti, ma in netbeans e hattrick organizer (anche questo scritto in java) la differenza si nota parecchio, specialmente nelle combo box e nel refresh della finestra. Addirittura in netbeans 5.0 quando si scrive il codice c'è un delay di circa un decimo di secondo (o roba simile) tra quando pigi una lettera e quando essa compare sul monitor.

[atragon]

Solo per curiosità, visto che si parla di linguaggi: c'è qualche cosa che non vi piace di Java? Io l'ho mollato dal lontano 2000 per cui non faccio testo ma leggendo questo 3D mi pare quasi IL linguaggio definitivo....per cui, escludendo che lo sia, mi piacerebbe sapere su cosa può migliorare a parer vostro, chi sa mai che lo riprenda in mano.
Un'altra curiosità. Qualcuno ha provato il linguaggio D?
Saluti.

[franksisca]

Solo per curiosità, visto che si parla di linguaggi: c'è qualche cosa che non vi piace di Java? Io l'ho mollato dal lontano 2000 per cui non faccio testo ma leggendo questo 3D mi pare quasi IL linguaggio definitivo....per cui, escludendo che lo sia, mi piacerebbe sapere su cosa può migliorare a parer vostro, chi sa mai che lo riprenda in mano.
Un'altra curiosità. Qualcuno ha provato il linguaggio D?
Saluti.

io credo che l'aspetto da migliorare sia Swing, credo che sia quello che rende "pesante" una applicazione java.


Per D no, mai usato(sentito si)

[71104]

Beh ho messo il "secondo me" perchè il mio parere è contrario ai tests, ma su 3 pc che ho provato i programmi java sono tangibilmente più lenti di quelli normali. secondo me invece no; e mo come la mettiamo?

Sarà che sono fatti male, ma allora sarà una cattiva abitudine dei programmatori Java. sarà che stiamo campando ipotesi all'aria senza dati reali e riproducibili

Forse è anche che Java non è lento di per se, ma purtroppo se uno nella sua vita usa solo quello non si renderà conto di molti problemi prestazionali, che sono evidenti solo se si programma in C/C++. perché se esiste un problema secondo te uno se ne deve "rendere conto"? è un concetto di apprendimento tipico da chi ha costruito la sua scarna cultura informatica a forza di tutorials uno più scrauso dell'altro trovati qua e là in internet (magari quelle ciofeche di html.it :asd: ).
normalmente se esiste un problema e si deve poter assumere che una certa persona lo sappia risolvere allora quella persona deve averci studiato in maniera mirata (intendo tipo coi libri, sai, coi tomi da centinaia di pagine, non con le paginette scrause di tutorials online) altrimenti si sta facendo l'assunzione sbagliata.

Non sono frasi fatte, sono campate in aria perché non ci sono dati reali e riproducibili.

io stesso uso Vista + Office2007, e li reputo ottimi, ma posso fare questo solo perchè ho un pc buono comprato da poco... sono lentissimi su pc vecchi, tanto che la gente torna a farsi mettere XP sui pc scassoni.
Frasi sentite in coda in un negozio di informatica:
"Sto pc è nuovo, ma parte lentissimo, non si accende nulla, ci mette anni a fare le cose... ma io non ci ho messo nulla!"
"Beh ha Vista?"
"Si"
"E' normale."
:D è successa la stessa cosa ad un mio amico, solo che non era normale: Vista ci metteva tanto a partire per colpa di un driver programmato di merda.
sul portatile di un altro amico invece ci sono installati Vista ed XP in dual boot; Vista parte molto prima di XP. e tutto questo non c'entra una mazza con Java.

ho detto quello perchè di solito Contro Vista, TCP e M$ = Linuxaro. 1) non sono "contro Microsoft"
2) Linux è stato il primo sistema operativo ad offrire supporto a certe features del Trusted Computing

Sinceramente non avrei mai sospettato che ti trovassi bene con win :D XP :O

Poi quando esce il mio tutti passano a quello perchè LORO ci mettono un decimo del tempo a lavorarci :rolleyes: basta crederci :asd:

[71104]

Solo per curiosità, visto che si parla di linguaggi: c'è qualche cosa che non vi piace di Java? Io l'ho mollato dal lontano 2000 per cui non faccio testo ma leggendo questo 3D mi pare quasi IL linguaggio definitivo....per cui, escludendo che lo sia, mi piacerebbe sapere su cosa può migliorare a parer vostro, chi sa mai che lo riprenda in mano. secondo me dovrebbe essere più semplice. sostanzialmente sono due le cose di Java 6 che non mi piacciono:

1) la possibilità di istanziare classi create così a muzzo nel codice, just-in-time (scusate ma non so come si chiamano :D esempio sotto per capire meglio)

class Asd
{
public abstract void lol();

public void rofl()
{
Asd asd = new Asd()
{
public void lol()
{
}

};

asd.lol();
}

}


2) il fatto che i riferimenti possano assumere il valore null.

[franksisca]

1) la possibilità di istanziare classi create così a muzzo nel codice, just-in-time (scusate ma non so come si chiamano :D esempio sotto per capire meglio)


innerclass (se non erro), invece io credo che se non se ne abusa siano "utili" ;)

[banryu79]

Se non erro le "Inner Class" e le "Anonymous Inner Class" sono una tecnica utile per l'implementazione di interfacce grafiche (adirittura mi pare che il loro utilizzo faccia pure parte di determinati design pattern).

Io non le butterei via :D

[kk3z]

:rolleyes:
tu invece vai avanti per luoghi comuni :rolleyes:
7.1 MB è la dimensione della nuova JRE per windows tanto per inciso.
e, tanto per continuare, l'ENORME occupazione di memoria che secondo te dovrebbe avere, si traduce con 6.8 MB di RAM occupata per la VM alla partenza.
complimenti per la disinformazione gratuita :rolleyes:

30 mb di partenza, 50 appena apro un programma. Che poi questo programma vada lento, va bene, può essere colpa del programmatore.

E sì, programmo in php ma non ho installato nè apache nè php.

[^TiGeRShArK^]

Beh... io devo aggiungere una cosa... Sul mio portatile aspire 1650, quando è in modalità risparmio energetico, netbeans è fastidiosamente lento(scopro ora che è programmato in java)... eclipse ora che ci penso è circa uguale.... Mentre quando il processore è in modalità massima prestazione, va tutto ok.
In TILAB usavo Eclipse su un PIII 800 e 384 MB con il *progettino* a cui lavoravo di circa 35K LOCs e tutti gli altri progetti collegati (circa 350K LOCs).
E non mi pare che ci si potesse lamentare considerando al macchina che avevo a disposizione.
A Roma invece utilizzavo due Workspace separati dato che le linee di codice per progetto erano intorno al milione... ma lì avevo quanto meno 1 GB di RAM per fortuna :p

[^TiGeRShArK^]

Beh ho messo il "secondo me" perchè il mio parere è contrario ai tests, ma su 3 pc che ho provato i programmi java sono tangibilmente più lenti di quelli normali.
Sarà che sono fatti male, ma allora sarà una cattiva abitudine dei programmatori Java.
Forse è anche che Java non è lento di per se, ma purtroppo se uno nella sua vita usa solo quello non si renderà conto di molti problemi prestazionali, che sono evidenti solo se si programma in C/C++.
:mbe:
veramente ho iniziato a programmare in BASIC, quindi sono passato a C + assembly (dato che ai tempi in cui internet non esisteva per superare i 640X480 a 16 colori bisognava accedere alle routine del BIOS per attivare la modalità VESA della scheda video), quindi C++, Visula Basic, Java Script, Java, Python, Ruby, C#, ASP.Net, PHP, JSP, STRUTS.. e probabilmente sto ancora dimenticando qualcosa... e, sinceramente, JAva per il 95% delle applicazioni non ha nulla da invidiare a C++.
E' ovvio che ci sono casi in cui è meglio utilizzare altri linguaggi, ma un linguaggio di programmazione non è altro che uno strumento, quindi a seconda di quello che si deve fare occorre scegliere lo strumento + adatto.
Java, generalmente, è di gran lunga preferibile a C++, sia a livello di facilità di scrittura del codice, che a livello di performance, dato che il codice della VM è MOLTO + ottimizzato di quanto in media un programmatore possa ottimizzare.

[^TiGeRShArK^]

Solo per curiosità, visto che si parla di linguaggi: c'è qualche cosa che non vi piace di Java? Io l'ho mollato dal lontano 2000 per cui non faccio testo ma leggendo questo 3D mi pare quasi IL linguaggio definitivo....per cui, escludendo che lo sia, mi piacerebbe sapere su cosa può migliorare a parer vostro, chi sa mai che lo riprenda in mano.
Un'altra curiosità. Qualcuno ha provato il linguaggio D?
Saluti.
Ora, come ho detto, a breve dovrà uscire l'update N che migliora ulteriormente le performance dell'interfaccia grafica sotto windows utilizzando di defualt la pipeline direct x anzichè quella open gl.
Per inciso GROSSI passi avanti nell'ottimizzazione dell'interrfaccia grafica sono stati fatti a partire da Java 5 e continuando con la versione attuale di Java 6, dato che molti componenti sono stati riscritti accelerati totalmente in hardware, e quindi le performance sono aumentate notevolmente.
Certo che se uno utilizza ancora Java 5, o peggio java 1.4.2 e precedenti, ci credo che vedrà le applicazioni grafiche andare una chiavica :mbe:

[^TiGeRShArK^]

secondo me dovrebbe essere più semplice. sostanzialmente sono due le cose di Java 6 che non mi piacciono:

1) la possibilità di istanziare classi create così a muzzo nel codice, just-in-time (scusate ma non so come si chiamano :D esempio sotto per capire meglio)

2) il fatto che i riferimenti possano assumere il valore null.
1) Inner-classes :stordita:
2) Perchè i riferimenti non potrebbero assuemere valore null? :mbe:

[^TiGeRShArK^]

30 mb di partenza, 50 appena apro un programma. Che poi questo programma vada lento, va bene, può essere colpa del programmatore.

E sì, programmo in php ma non ho installato nè apache nè php.

vuoi che ti posto gli screenshot se non ti fidi?
Ho provato ieri e ho segnato esattamente i valori di memoria fisica utilizzati per un programma che ciclava a vuoto, quindi dovrebbero coincidere presumibilmente con i valori di memoria occupati dalla sola VM.

[sottovento]

Solo per curiosità, visto che si parla di linguaggi: c'è qualche cosa che non vi piace di Java? Io l'ho mollato dal lontano 2000 per cui non faccio testo ma leggendo questo 3D mi pare quasi IL linguaggio definitivo....per cui, escludendo che lo sia, mi piacerebbe sapere su cosa può migliorare a parer vostro, chi sa mai che lo riprenda in mano.
Un'altra curiosità. Qualcuno ha provato il linguaggio D?
Saluti.

Per fortuna non esiste il linguaggio perfetto. Ci aveva provato l'IBM con il PL/1. Vi ricordate? Diceva che avrebbe fatto sparire qualsiasi altro linguaggio, invece e' morto lui...

Quello che non mi piace di Java e' praticamente quello che non mi piace dei linguaggi orientati agli oggetti.
Anche l'informatica (meglio, la programmazione) ha le sue "mode". Si e' passati attraverso parecchie di queste mode nel corso della pur breve storia dell'Informatica.
La programmazione ad oggetti e' ovviamente qualcosa di piu' di una moda, visto che e' stata ampiamente adottata. Ma... siamo sicuri che porti effettivamente i benefici promessi, oppure e' stata sopravvalutata?
Io non ne sono molto sicuro, anche se programmo ad oggetti (o meglio, devo sbadilare codice ad oggetti scritto da altri) tutto il giorno.

Per esempio:
- si dice che la programmazione ad oggetti e' piu' naturale. Poi pero' sono tutti partiti dalla programmazione procedurale. Forse perche' siamo vecchi?
Beh, puo' essere, ma anche le nuove leve sembra partano dalla programmazione procedurale. Allora forse questo assunto non e' proprio vero, se fosse piu' semplice e naturale partirei proprio da li' e non da una cosa piu' difficile;

- si dice che basta conoscere la parte pubblica dell'oggetto per poterlo usare correttamente. Non mi sento neanche di fare un controesempio.
La verita' e' che se scrivi un oggetto che e' "intuibile" (per esempio un oggetto String oppure Complex) allora ne hai dei benefici e sai gia' come usarlo senza nemmeno consultare il manuale.
Se un oggetto si chiama ModelMWithAdaptionOnPressureButNotOnSpeed che deriva da ModelWithGenericAdaptation che deriva da ModelWithAdaptationSupport (magari con costruttore privato, lo devi creare usando una classe Factory), non hai introdotto alcun beneficio, anzi dovrai controllare il codice (sparso su parecchi file) per capire da dove si comincia.
Si puo' obiettare che questo e' vero per tutti gli stili di programmazione.
Si, ovviamente e' cosi', ma la programmazione ad oggetti "spinge" molto di piu' in questa direzione. Soprattutti i nuovi arrivati, tendono ad identificare la programmazione ad oggetti con l'ereditarieta' e ti spalmano le varie funzioni su una pletora di classi, spesso inutilmente.

- Se non si modifica la parte pubblica dell'oggetto, una nuova versione di un oggetto puo' sostituire la precedente senza nemmeno ricompilare il programma "ospite". Semplicemente falso;

- Gestione della memoria: la programmazione ad oggetti introduce grossi problemi di gestione della memoria. Si ha un grosso numero di piccoli oggetti, con conseguente frammentazione. I vari sistemi di garbage collection piuttosto che memory management servono soprattutto per far fronte a questo.

- Classe di problemi che si possono risolvere. Essendo Java/C++ linguaggi "General purpose" ci si aspetta che possano risolvere qualsiasi problema di programmazione, ed in effetti vengono usati in praticamente tutti i campi.
Pero'... non sono sempre i migliori, e spesso sono i meno "intuibili". I detrattori di queste tecnologie (si, esistono :D) fanno sempre l'esempio di una formula matematica. Per i linguaggi procedurali la formula e':
a = (b * c) + e + f
Per i linguaggi ad oggetti la stessa formula e':
a = ((b.math.times(c)).math.plus(e)).math.plus(f)
Ovviamente portano all'eccesso il discorso, nessuno mi impedisce di implementare la prima versione. Ma il succo del discorso e' chiaro.

Concludendo: secondo me Java e' un ottimo linguaggio. Non e' perfetto e per fortuna non esistera' mai il linguaggio perfetto.
Le tecnologie attuali sono legate alla programmazione orientata agli oggetti e Java e' un ottimo rappresentante.
Queste tecnologie hanno portato grandi vantaggi, ma spesso (almeno secondo il mio umile parere) molti non sono tali, e nel futuro mi auguro che si possano trovare dei paradigmi di programmazione piu' semplici, efficienti e naturali...

[atragon]

Per fortuna non esiste il linguaggio perfetto. Ci aveva provato l'IBM con il PL/1. Vi ricordate? Diceva che avrebbe fatto sparire qualsiasi altro linguaggio, invece e' morto lui...

Quello che non mi piace di Java e' praticamente quello che non mi piace dei linguaggi orientati agli oggetti.
Anche l'informatica (meglio, la programmazione) ha le sue "mode". Si e' passati attraverso parecchie di queste mode nel corso della pur breve storia dell'Informatica.
La programmazione ad oggetti e' ovviamente qualcosa di piu' di una moda, visto che e' stata ampiamente adottata. Ma... siamo sicuri che porti effettivamente i benefici promessi, oppure e' stata sopravvalutata?
Io non ne sono molto sicuro, anche se programmo ad oggetti (o meglio, devo sbadilare codice ad oggetti scritto da altri) tutto il giorno.

Per esempio:
- si dice che la programmazione ad oggetti e' piu' naturale. Poi pero' sono tutti partiti dalla programmazione procedurale. Forse perche' siamo vecchi?
Beh, puo' essere, ma anche le nuove leve sembra partano dalla programmazione procedurale. Allora forse questo assunto non e' proprio vero, se fosse piu' semplice e naturale partirei proprio da li' e non da una cosa piu' difficile;

- si dice che basta conoscere la parte pubblica dell'oggetto per poterlo usare correttamente. Non mi sento neanche di fare un controesempio.
La verita' e' che se scrivi un oggetto che e' "intuibile" (per esempio un oggetto String oppure Complex) allora ne hai dei benefici e sai gia' come usarlo senza nemmeno consultare il manuale.
Se un oggetto si chiama ModelMWithAdaptionOnPressureButNotOnSpeed che deriva da ModelWithGenericAdaptation che deriva da ModelWithAdaptationSupport (magari con costruttore privato, lo devi creare usando una classe Factory), non hai introdotto alcun beneficio, anzi dovrai controllare il codice (sparso su parecchi file) per capire da dove si comincia.
Si puo' obiettare che questo e' vero per tutti gli stili di programmazione.
Si, ovviamente e' cosi', ma la programmazione ad oggetti "spinge" molto di piu' in questa direzione. Soprattutti i nuovi arrivati, tendono ad identificare la programmazione ad oggetti con l'ereditarieta' e ti spalmano le varie funzioni su una pletora di classi, spesso inutilmente.

- Se non si modifica la parte pubblica dell'oggetto, una nuova versione di un oggetto puo' sostituire la precedente senza nemmeno ricompilare il programma "ospite". Semplicemente falso;

- Gestione della memoria: la programmazione ad oggetti introduce grossi problemi di gestione della memoria. Si ha un grosso numero di piccoli oggetti, con conseguente frammentazione. I vari sistemi di garbage collection piuttosto che memory management servono soprattutto per far fronte a questo.

- Classe di problemi che si possono risolvere. Essendo Java/C++ linguaggi "General purpose" ci si aspetta che possano risolvere qualsiasi problema di programmazione, ed in effetti vengono usati in praticamente tutti i campi.
Pero'... non sono sempre i migliori, e spesso sono i meno "intuibili". I detrattori di queste tecnologie (si, esistono :D) fanno sempre l'esempio di una formula matematica. Per i linguaggi procedurali la formula e':
a = (b * c) + e + f
Per i linguaggi ad oggetti la stessa formula e':
a = ((b.math.times(c)).math.plus(e)).math.plus(f)
Ovviamente portano all'eccesso il discorso, nessuno mi impedisce di implementare la prima versione. Ma il succo del discorso e' chiaro.

Concludendo: secondo me Java e' un ottimo linguaggio. Non e' perfetto e per fortuna non esistera' mai il linguaggio perfetto.
Le tecnologie attuali sono legate alla programmazione orientata agli oggetti e Java e' un ottimo rappresentante.
Queste tecnologie hanno portato grandi vantaggi, ma spesso (almeno secondo il mio umile parere) molti non sono tali, e nel futuro mi auguro che si possano trovare dei paradigmi di programmazione piu' semplici, efficienti e naturali...

Ottima analisi. Secondo alcuni nel prossimo futuro andranno di moda linguaggi che possano abbracciare facilmente più paradigmi. F# ad esempio oppure lo stesso Ruby sarebbero indicati in questo senso ma personalmente non li conosco a sufficienza.

[marko.fatto]

Ottima analisi. Secondo alcuni nel prossimo futuro andranno di moda linguaggi che possano abbracciare facilmente più paradigmi. F# ad esempio oppure lo stesso Ruby sarebbero indicati in questo senso ma personalmente non li conosco a sufficienza.

nuovo linguaggio?*

comunque per il resto quoto


edit:*niente... trovato :eek:

[71104]

1) Inner-classes :stordita: quelle mi sa che sono un'altra cosa:

class Asd
{
public class Lol
{
}
}


2) Perchè i riferimenti non potrebbero assuemere valore null? :mbe: pensa che bello un mondo dove non esistono puntatori nulli *__*

prima abbiamo detto addio ai segmentation faults, con questo diremmo addio anche alle NullPointerExceptions

[shinya]

pensa che bello un mondo dove non esistono puntatori nulli *__*

prima abbiamo detto addio ai segmentation faults, con questo diremmo addio anche alle NullPointerExceptions


...per dare il benvenuto ai memory leaks probabilmente.
Vedi [Bloch - Effective Java, Capitolo 2 - Item 5]

Mokabyte non mi piace, ma questo articolo più o meno riassume l'idea...
http://www2.mokabyte.it/cms/article.run?articleId=i_8CY-DYX-HUL-UGO_7f000001_11024688_5b5a367a

[marco.r]

1) Inner-classes :stordita:
2) Perchè i riferimenti non potrebbero assuemere valore null? :mbe:
Per lo stesso motivo per cui non puo' assumerne 2. Si tratta di un riferimento ad un oggetto, ne' piu', ne meno. Il null e' un artificio che poteva andare bene in C, in Java forse non e' proprio il massimo.

[marco.r]

...per dare il benvenuto ai memory leaks probabilmente.
Vedi [Bloch - Effective Java, Capitolo 2 - Item 5]

Mokabyte non mi piace, ma questo articolo più o meno riassume l'idea...
http://www2.mokabyte.it/cms/article.run?articleId=i_8CY-DYX-HUL-UGO_7f000001_11024688_5b5a367a

Il fatto che i puntatori a null vengano utilizzati per questo scopo non vuol dire che sia l'unico modo per farlo, o che questo giustifichi la possibilita' di avere un puntatore nullo in qualsiasi situazione.

[marco.r]

secondo me dovrebbe essere più semplice. sostanzialmente sono due le cose di Java 6 che non mi piacciono:

1) la possibilità di istanziare classi create così a muzzo nel codice, just-in-time (scusate ma non so come si chiamano :D esempio sotto per capire meglio)

Penso si chiamino classi anonime (ma non ne sono sicuro).
Immagino siano state introdotte principalmente per sopperire alla mancanza delle closure in Java.

[^TiGeRShArK^]

Penso si chiamino classi anonime (ma non ne sono sicuro).
Immagino siano state introdotte principalmente per sopperire alla mancanza delle closure in Java.

infatti quella che ha postato lui mi pareva una anoynomous inner class.. ma dice di no.. :stordita:

[^TiGeRShArK^]

Per lo stesso motivo per cui non puo' assumerne 2. Si tratta di un riferimento ad un oggetto, ne' piu', ne meno. Il null e' un artificio che poteva andare bene in C, in Java forse non e' proprio il massimo.
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? :mbe:

[theClimber]

In altri linguaggi (ad esempio smalltalk), esiste esplicitamente un oggetto nullo.

Le implicazione su come viene implementato l'oggetto nullo hanno ripercussioni su tutto l'ambiente. Le due alternative principali sono se l'oggetto nullo deve generare errori, o se deve consumare in modo silente i messaggi.
Smalltalk ed objective-C hanno fatto scelte diverse:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/17785


La gestione dll'oggetto nullo che esegue le chiamate senza generare errori è specifico design pattern (a livello applicativo). Vantaggio principale del pattern è la semplificazione del codice che non ha più bisogno di molte validazioni e controlli:
http://en.wikipedia.org/wiki/Null_Object_pattern

Probabilmente la scelta di Java risente del fatto storico di dover supportare dispositivi embedded, richiedendo così un implementazione "semplice" e più di basso livello.

[cdimauro]

e a giudicare da questa tua affermazione tu non hai capito un tubo della mia firma. la mia firma non lotta contro la trascurata ottimizzazione del software, bensì contro il Trusted Computing e i brevetti software. inoltre nella lotta contro il Trusted Computing io prendo una posizione particolare: poiché secondo me boicottare l'hardware (come i Core2) è troppo difficile visto che prima o poi verrà il momento in cui non esisterà più hardware non-TC, allora io sono a favore del boicottaggio del software. la mia firma questo non lo spiega, offre solo qualche link che costituisce per chi ancora non sa delle ottime fonti di informazione (Wikipiedia l'ho data per scontata).
Ne avevamo già parlato, ma visto che in questo thread si parla di luoghi comuni e ne riporti anche tu, ti ripropongo il link alla discussione su Trusted Computing et similia: http://www.hwupgrade.it/forum/showthread.php?t=1011111 ;)

Ah, dimenticavo: su Wikipedia può scriverci chiunque, ma anche altri siti che "trattano" l'argomento (come quelli che hai in firma) non sono esenti da immane assurdità che hanno riportato.
Per maggiori informazioni, vale sempre il link che ho postato sopra.

Per il resto non ha il benché minimo senso andare a confrontare applicazioni totalmente diverse, come ad esempio Azureus e uTorrent, o tirare fuori un'applicazione che non ha un ESATTO corrispondente con un altro linguaggio (es: Eclipse, NetBeans, Poseidon, ecc.; gli esempi si sono sprecati).

Ha senso invece riportare confronti sulle MEDESIME applicazioni, come ha fatto "TigerShark": il codice fa ESATTAMENTE la stessa cosa, ma l'UNICA differenza è il linguaggio usato.

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? :mbe:
Ne parlammo tempo addietro (e lo stesso marco scrisse dei messaggi molto interessanti in merito), ma non sono riuscito a trovare il link.

Comunque basta che per ogni classe esista una particolare istanza da usare per indicare un oggetto "nullo".
Se ho una classe Frutto che mi restituisce come istanze Banana, Pera, Mela, ecc., per indicare l'assenza di un frutto restituirà "NessunFrutto" (il valore "nullo" predefinito della classe).

Il vantaggio è che in questo modo il compilatore può generare SEMPRE codice efficiente, perché ha la sicurezza che non incontrerà mai nessun "NULL", ma sempre istanze concrete di ogni particolare classe con cui lavoriamo.

A noi programmatori non interessa né ci è necessario sapere se un'istanza è banalmente e genericamente "nulla": è sufficiente sapere che un'istanza di una particolare classe ha un "valore nullo" (per quella precisa classe).

Non so se mi sono spiegato, ma eventualmente marco chiarirà meglio il concetto se ne avrà voglia. :p

P.S. Sono in ferie fino al 6: se riesci a contattare Jocchan fammi sapere che ci vediamo uno di questi giorni, se possibile (anche di giorno, non c'è problema); al limite vediamoci noi due, se lui non può.

[franksisca]

mi permetto di dire la mia (del tutto personale):

Il fatto di avere la possibilità di mettere a null un oggetto secondo me è un vantaggio per i già citati esempi...
Comunque basta che per ogni classe esista una particolare istanza da usare per indicare un oggetto "nullo".
infatti basta il null....uguale per tutti, senza bisogno di andare a leggere le documentazioni......

credo che si abbia anche uno spreco di memoria minore non facendolo puntare ad un oggetto concreto.....


in pratica volevo solo dire che secondo me il "null" non è un "problema" di java, ma è una scelta filosofica.....

il tutto IMHO :D

[Re_Kotc]

dopo essermi letto tutto il flame che avete sollevato (e dopo aver capito circa un 20% di quello che c'era scritto :D) posso dare la mia modesta (e forse idiota) opinione di programmatore alle prime armi?
Ho programmato qualche tempo fa un programmino "scolastico" per il calcolo dei primi 5000 numeri primi, forse non sarà la versione più ottimizzata che esista per fare questo (anzi sicuramente XD) , però posso dire che calcolando con il mio orologio a lancette (LOL) il tempo di esecuzione dello stesso codice in C++ e JAVA su un vecchio Pentium III 700mhz con Ubuntu Gutsy, ho rilevato che mentre in Java ci volevano quasi 40 secondi in C++ ci si limitava a 13...ora avendo fatto la prova più volte io programmatore inesperto cosa posso pensare??..

Senza nessuna polemica e senza alzare polveroni :)

[Unrue]

Indipendentemente dal fatto che Java sia meglio di C++ od il contrario ( a me piacciono entrambi :) ) Java, ha l'innegabile overhead di dover fare due compilazioni: una in bytecode e l'altra in assembler. C++ no, la fa direttamente in assembler. E per quanto piccolo sia questo passaggio, non sarà mai eliminabile, in quanto insito nella natura dei linguaggi interpretati. Tutto sta nell'analizzare quanto, nella nostra applicazione, questo passaggio comporta o meno dei rallentamenti. Quindi in ogni applicazione, fatta bene o male, Java parte con un leggero svantaggio.

Detto questo, spesso il codice Java è più elegante e pulito( ovviamente dipende molto anche dal programmatore) quindi spesso si può accettare un maggior tempo di esecuzione a fronte di una maggiore chiarezza del codice.

Io che lavoro spesso con applicazioni parallele che operano su decine di processori, posso dirvi che Java è visto come la peste in questi campi. C++ un pò meno, non a caso ci sono molte librerie parallele scritte in C++( ad esempio Charm++) . In questo campo, dove si cerca la massima velocità di esecuzione possibile, prevalgono C e Fortran perchè sono ritenuti più veloci di tutti. Attenzione, non dico migliori sotto tutti i punti di vista, ma solo sotto quello della velocità di esecuzione. Questi due linguaggi infatti, hanno poche astrazioni che facilitano sì la programmazione, ma che rallentano l'esecuzione del programma. In questo campo, la portabilità di Java non serve assolutamente a nulla. Anzi, molto spesso tali applicazioni sono ottimizzate per la macchina in questione.

[71104]

...per dare il benvenuto ai memory leaks probabilmente.
Vedi [Bloch - Effective Java, Capitolo 2 - Item 5] non ce l'ho, ma non vedo perché il non poter usare null darebbe origine ai memory leaks.

Mokabyte non mi piace, ma questo articolo più o meno riassume l'idea...
http://www2.mokabyte.it/cms/article.run?articleId=i_8CY-DYX-HUL-UGO_7f000001_11024688_5b5a367a quel sito si vede una schifezza indecente sia su IE7 che su FF, mi rifiuto di leggerlo (e peccato perché sembrava interessante).

[71104]

Indipendentemente dal fatto che Java sia meglio di C++ od il contrario ( a me piacciono entrambi :) ) Java, ha l'innegabile overhead di dover fare due compilazioni: una in bytecode e l'altra in assembler. C++ no,la fa direttamente in assembler.E per quanto piccolo sia questo passaggio, non sarà mai eliminabile, in quanto insito nella natura dei linguaggi interpretati. Tutto sta nell'analizzare quanto, nella nostra applicazione, questo passaggio comporta o meno dei rallentamenti. Quindi in ogni applicazione, fatta bene o male, Java parte con un leggero svantaggio. si ma una volta che una classe è stata compilata poi resta là e gira con velocità nativa; questo overhead è presente per ciascuna classe solamente al caricamento, ma quando il programma è stato caricato tutto gira veloce come un programma C++.

[tomminno]

:mbe:
veramente + un programma è ad alto livello + è facile concentrarsi sul problema, magari avendo a disposizione + tempo per trovare algoritmi migliori per risolverlo.
Se invece ci si dovesse concentrare a tracciare un maledetto segmentation fault o qualche memory leak apparentemente impossibile si otterrebbero programmi di qualità + scadente (o per le features che non sono state implementate per carenza di tempo o per i bug ancora presenti)

Come se i memory leak in java non fossero possibili.
A volte anche trovare dei riferimenti circolari che impediscono la deallocazione degli oggetti non è così immediato.
Io non sono risucito a trovarne in un programma C# che per inviare delle stringhe via seriale (usando 2 classi) arriva ad occupare 70MB di RAM per circa 2MB di dati inviati. Avesse avuto dei memory leak in C++ si sarebbe fermato ad occupare 2MB più del necessario, al massimo 4 visto che le classi coinvolte erano 2.

[cdimauro]

mi permetto di dire la mia (del tutto personale):

Il fatto di avere la possibilità di mettere a null un oggetto secondo me è un vantaggio per i già citati esempi...

infatti basta il null....uguale per tutti, senza bisogno di andare a leggere le documentazioni......

credo che si abbia anche uno spreco di memoria minore non facendolo puntare ad un oggetto concreto.....


in pratica volevo solo dire che secondo me il "null" non è un "problema" di java, ma è una scelta filosofica.....

il tutto IMHO :D
theClimber aveva postato un link illuminante in merito, che spiega molto meglio il concetto che avevo esposto e più semplicemente: http://en.wikipedia.org/wiki/Null_Object_pattern ;)

Per quanto riguarda lo "spreco" di spazio, servirebbe un oggetto "null" per ogni classe, e francamente non mi pare eccessiva come richiesta.

[71104]

Le due alternative principali sono se l'oggetto nullo deve generare errori, o se deve consumare in modo silente i messaggi.
sono molto ignorante in ingegneria del software ma che un null object generi eccezioni mi sembra una cavolata visto che è la stessa cosa che fa in Java un riferimento nullo, e a quel punto tanto vale...
la cosa ideale per me sarebbe un linguaggio dove di default i null object di ciascuna classe hanno metodi vuoti, e opzionalmente questi metodi possono essere overriddati e il programmatore può scriverci quello che vuole (anche lanciare un'eccezione se vuole). l'unico problema è per i metodi che devono ritornare qualcosa; quelli dovrebbero essere overriddati per forza a meno che non si stabiliscano valori di default da ritornare: falso per i booleani, 0 per gli interi, null object per le classi, e così via.

[Unrue]

si ma una volta che una classe è stata compilata poi resta là e gira con velocità nativa; questo overhead è presente per ciascuna classe solamente al caricamento, ma quando il programma è stato caricato tutto gira veloce come un programma C++.

Infatti ho puntualizzato che è un piccolo svantaggio :) Non che pregiudica tutto il tempo di esecuzione.

[71104]

altra cosa che non mi piace di Java, anche se è una fesseria: detesto il nome NullPointerException :D
i riferimenti di Java hanno poco a che vedere coi puntatori.

[cdimauro]

dopo essermi letto tutto il flame che avete sollevato (e dopo aver capito circa un 20% di quello che c'era scritto :D) posso dare la mia modesta (e forse idiota) opinione di programmatore alle prime armi?
Ho programmato qualche tempo fa un programmino "scolastico" per il calcolo dei primi 5000 numeri primi, forse non sarà la versione più ottimizzata che esista per fare questo (anzi sicuramente XD) , però posso dire che calcolando con il mio orologio a lancette (LOL) il tempo di esecuzione dello stesso codice in C++ e JAVA su un vecchio Pentium III 700mhz con Ubuntu Gutsy, ho rilevato che mentre in Java ci volevano quasi 40 secondi in C++ ci si limitava a 13...ora avendo fatto la prova più volte io programmatore inesperto cosa posso pensare??..

Senza nessuna polemica e senza alzare polveroni :)
Una rondine non fa primavera... ;)

[cdimauro]

Come se i memory leak in java non fossero possibili.
A volte anche trovare dei riferimenti circolari che impediscono la deallocazione degli oggetti non è così immediato.
Io non sono risucito a trovarne in un programma C# che per inviare delle stringhe via seriale (usando 2 classi) arriva ad occupare 70MB di RAM per circa 2MB di dati inviati. Avesse avuto dei memory leak in C++ si sarebbe fermato ad occupare 2MB più del necessario, al massimo 4 visto che le classi coinvolte erano 2.
Eccessiva occupazione di memoria e memory leak mi sembra siano due cose completamente diverse... ;)

[cdimauro]

sono molto ignorante in ingegneria del software ma che un null object generi eccezioni mi sembra una cavolata visto che è la stessa cosa che fa in Java un riferimento nullo, e a quel punto tanto vale...
la cosa ideale per me sarebbe un linguaggio dove di default i null object di ciascuna classe hanno metodi vuoti, e opzionalmente questi metodi possono essere overriddati e il programmatore può scriverci quello che vuole (anche lanciare un'eccezione se vuole). l'unico problema è per i metodi che devono ritornare qualcosa; quelli dovrebbero essere overriddati per forza a meno che non si stabiliscano valori di default da ritornare: falso per i booleani, 0 per gli interi, null object per le classi, e così via.
Il vantaggio è che i null object possono, ma non devono essere obbligati a generare eccezioni.

E' chiaro che tutto dipende da come si vuole siano gestiti questi casi particolari...

[tomminno]

io veramente a quel punto proporrei l'acquisizione di hardware migliore... seriamente, per un 1% ti stai ad ammazzare rendendo i tuoi sorgenti incomprensibili e per nulla manutenibili, aumentando a dismisura i costi futuri di riutilizzo di quel codice? :D
e secondo te un 1% di performance in più non lo puoi guadagnare migliorando l'hardware? perché cavolo deve essere il programmatore a farsi un didietro così a scrivere software? tantopiù che siamo a Natale :D

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?

Per esperienza professionale mi riferisco principalmente al C#, dove codice realizzato con tutti i crismi per la versione 1.1 non è per niente riusabile con la versione 2.0.
E scommetto che quelli pensati per il 2.0 non saranno adattabili alle specifiche di programmazione del 3.5.

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 :D

[tomminno]

ma dove...


Nel mondo reale.
Non tutti la fuori hanno i dual core, più spesso la gente lavora con computer con 512-256 MB di RAM e si lamenta che i programmi sono lenti.
Non puoi rispondergli "Guarda che 1GB di ram costa 50Euro", visto che memorie così vecchie non le trovi facilmente.
Il C# su macchine del genere è assolutamente inadatto, visto che si prende 25MB solo per una stupidissima interfaccia con una textbox multiline e 3 pulsanti che non fanno assolutamente niente.

Per uscire leggermente dall'ambito desktop, vogliamo paragonare la velocità di un sito in PHP rispetto ad uno ASP.NET?
A parte che le pagine ASP.NET sono piene di schifezze inserite gratuitamente da ASP stesso che rendono il download decisamente più pesante, il carico di lavoro del server è decisamente più elevato.
La cosa si nota decisamente se il "server" è un P4 con 1GB di ram che deve tenere in piedi 3 siti e un centro servizi.


e allora esci dal luogo comune, quello è ovvio che non ha senso.

Avendo realizzato diversi programmi in C++ e C# e avendo usato diversi programmi in Java la mia impressione da utilizzatore è che C# e Java siano notevolmente più lenti, la motivazione che posso portare è che occupano molte più risorse, specialmente memoria, per fare le stesse cose.
Magari lo sviluppatore ci ha messo 1 ora per realizzarli, ma poi io utilizzatore perdo 1 ora di tempo per usarli ogni volta, nell'attesa che il programma reagisca ai comandi.
Su tutte le macchine che ho avuto sotto mano la JVM si prende sempre i suoi 60MB, l'avvio dei programmi java mi è sempre sembrato mostruosamente lento, magari per il JIT, però poi l'esecuzione stessa del programma non era fulminea.

Con questo niente a che ridire con la struttura del linguaggio Java.

[tomminno]

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]

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 :D solo? io qua ancora riesco a compilare i famosi applet demo di Java, il mitico MoleculeViewer :asd: e quella roba credo proprio che abbia più di 10 anni.

[tomminno]

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 :rolleyes:


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]

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

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]

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]

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? :mbe:
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]

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]

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]

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]

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]

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

[cionci]

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]

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

[cdimauro]

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]

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.

[cionci]

Perché? :confused:
Tanto per fare un esempio nelle simulazioni matematiche e fisiche e nelle applicazioni per microcontrollori. Nelle simulazioni in particolare si ottimizza il più possibile perché più tempo si risparmia e più soldi si risparmia (per il supercomputer intendo). Nei microcontrollori più tempo si risparmia e più autonomia si acquista (vedi reti di sensori).
In questi ambiti applicativi l'ottimizzazione non ha mai fine.

[Unrue]

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

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

Allora abbiamo filosofie di programmazione diverse :D

[cdimauro]

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.
Se capita, ci si rimette mano. ;)

Beh, la mia non è filosofia ma, considerato il poco a tempo disposizione e le tante cose che ho da fare, soltanto pragmatismo. :p

[cdimauro]

Tanto per fare un esempio nelle simulazioni matematiche e fisiche e nelle applicazioni per microcontrollori. Nelle simulazioni in particolare si ottimizza il più possibile perché più tempo si risparmia e più soldi si risparmia (per il supercomputer intendo). Nei microcontrollori più tempo si risparmia e più autonomia si acquista (vedi reti di sensori).
In questi ambiti applicativi l'ottimizzazione non ha mai fine.
Certamente, e concordo.

[sottovento]

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.

No, non lo dimentico. Ripeto: non e' difficile trovare casi in cui Java e' piu' veloce.
Usi una macchina virtuale estremamente simile a quella reale, ed ha ben poco overhead, che puo' essere benissimo superato da altre comuni inefficienti in un programma reale.


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.

Assolutamente si:
- se ci metti delle new, dovrai solo registrare quella memoria, operazione semplicissima;
- quando GC andra' a deallocare, lo fara' meglio di te. (economie di scala).
- il ciclo di vita degli oggetti obblighera' C++ a fare una marea di copie inutili, che saranno sicuramente evitate in programmazione Java;





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.
L'ho anche visto girare su 1k di RAM

[cionci]

No, non lo dimentico. Ripeto: non e' difficile trovare casi in cui Java e' piu' veloce.
Usi una macchina virtuale estremamente simile a quella reale, ed ha ben poco overhead, che puo' essere benissimo superato da altre comuni inefficienti in un programma reale.

Il codice macchina della VM è intrinsecamente più lento del codice macchina del sistema ospite visto che deve essere interpretato. L'unico modo che ha un VM di arrivare alle prestazioni di un programma compilato è usare un compilatore JIT...altrimenti nisba, non c'è proprio storia.

[cdimauro]

Col vantaggio, però, di poter adattare meglio il codice generato a seconda del contesto dell'esecuzione. ;)

Cosa impossibile da realizzare per un programma C/C++, che è compilato staticamente una sola volta e col compilatore che ha fatto a priori delle assunzioni.

Infatti se esce una nuova architettura le applicazioni Java (.NET, ecc.) non devono essere toccate di una virgola: è sufficiente aggiornare la VM per utilizzarla.

La "morte" del codice binario, invece, è la compilazione statica che lega il codice mani e piedi all'architettura target...

[cionci]

Va bene, ma non c'entra niente con le prestazioni.

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

Il codice, in sostanza, viene "adattato" in base alle condizioni rilevate in tempo reale.

Altra cosa, un compilatore "classico" che ha emesso il "miglior codice" (secondo lui) staticamente per una certa architettura (ma possiamo considerare anche n architetture, con code path diversi selezionati a runtime; come ad esempio avviene coi compilatori Intel da un po' di tempo a questa parte, ma soltanto per le sue architetture) ha fatto il suo lavoro e amen: il codice è quello e non si tocca.

Se arriva una nuova architettura che ha bisogno di ottimizzazioni specifiche, si deve ricompilare nuovamente (es: passando da P3 a P4 le ottimizzazioni sono cambiate anche radicalmente, e il vecchio codice pensato per i primi non gira bene su questi ultimi).

Coi linguaggi che fanno uso di VM, invece, entrambi i problemi sono risolti brillantemente aggiornando soltanto la VM (e il primo problema NON è risolvibile da un compilatore "classico").

[Unrue]

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.

Il codice, in sostanza, viene "adattato" in base alle condizioni rilevate in tempo reale.



Scusa ma quali sarebbero queste condizioni che il compilatore JIT rileva ? Inoltre, più un codice lo puoi legare all'architettura più va veloce, in quanto puoi sfruttare tutto al meglio (cache, registri particolari del processore, ecc ecc). Un compilatore JIT non credo che faccia questo a runtime, non credo proprio, come può farlo? Andrebbe contro il concetto stesso di portabilità. Sono queste le cose che danno una bella spinta all'applicazione. Spesso e volentieri la portabilità di Java in programmi che girano su PC non serve a nulla. A parte programmi di grosse dimensioni, non vedo questa grande fatica a dover ricompilare un programma.

[cionci]

In teoria il profiling a runtime potrebbe tranquillamente farlo, gli basterebbe generare codice diverso al successivo ingresso in quella parte di codice. Ma quanto costa fare un profiling a runtime ? La Java VM lo fa ? Io credo proprio di no.

[Unrue]

Appunto :) Bisogna vedere se il gioco vale la candela. Ad esempio, io potrei impostare un ciclo for in modo che abbia meno cache miss possibili. MA questo proprio perchè so che tipo di cache ho sotto. Con Java è molto più incasinato fare questo, anzi, non lo puoi proprio fare se il programma è pensato per girare su diverse piattaforme. Sicuramente si troverà una cache differente e quindi tutto il lavoro svolto sul ciclo for andrebbe buttato via.

Secondo me, se prendiamo un programma Java , quanto buono che sia, mai e poi mai avrà le stesse prestazioni di un codice scritto in C, C++ che sfrutta appieno l'hardware. Non c'è compilatore JIT che tenga per questo. Il rovescio della medaglia è ovviamente che se cambio architettura devo ricompilare ma, come ho detto prima,.. è davvero questa grande fatica ricompilare ??

[cionci]

Però lo potrebbe fare la prima volta che genera il codice JIT...e già sarebbe un ottimo compromesso...potrebbe generare un codice diverso per ogni CPU...certo un profiling a runtime sarebbe veramente troppo costoso imho.

[Unrue]

Però lo potrebbe fare la prima volta che genera il codice JIT...e già sarebbe un ottimo compromesso...potrebbe generare un codice diverso per ogni CPU...certo un profiling a runtime sarebbe veramente troppo costoso imho.

Ma lo fa realmente? E' un'opzione attivabile? Oppure nemmeno si sono posti il problema ? :) Perchè se non è possibile farlo, C++, in fatto di prestazioni vince alla stragrande ( prima di scatenare polemiche ripeto : mi riferisco a programmi adattati all'hardware che c'è sotto, non in generale)

[cdimauro]

Ecco qui http://arstechnica.com/reviews/1q00/dynamo/dynamo-1.html un articolo che tratta la questione JIT, profiling & generazione dinamica di codice.

Per il resto e rispondendo a Unrue, non di tutti i programmi è disponibile il sorgente e quindi è possibile ricompilare.

Va da sé che il progetto Dinamo di HP dimostra che è possibile prendere un eseguibile già compilato e trattarlo alla stregua del bytecode di Java et similia, quindi tirando fuori nuovo codice in base alle condizioni rilevate a runtime.

Non è il concetto di codice eseguibile che si scontra con quello di bytecode, ma qui il problema è più generale e riguarda la presenza di una VM (ormai spesso dotata di compilatore JIT) che si pone da "intermediario" fra il "codice oggetto" e la macchina che dovrà fisicamente eseguirlo.

Questo concetto lo si può tranquillamente allargare prendendo codice oggetto compilato per una certa architettura e ricompilandolo al volo per farlo girare su un'altra anche completamente diversa. ;)

Ultima cosa: non so se la JVM applica quanto ho esposto. Questo ce lo potrebbe dire PGI-Bis, che ha smanettato sui suoi sorgenti. :p

[Unrue]

Per il resto e rispondendo a Unrue, non di tutti i programmi è disponibile il sorgente e quindi è possibile ricompilare.


Questo è un altro discorso, che si allaccia all'Open Source. Ma si andrebbe fuori tema.


Questo concetto lo si può tranquillamente allargare prendendo codice oggetto compilato per una certa architettura e ricompilandolo al volo per farlo girare su un'altra anche completamente diversa. ;)


Va bene, ma quanto costa farlo? C++ lo fa in fase di compilazione, Java a runtime.

[cdimauro]

Leggiti il link che ho passato prima. ;)

[jappilas]

Scusa ma quali sarebbero queste condizioni che il compilatore JIT rileva ? ad esempio i code path effettivamente attraversati in base alle condizioni di runtime (in presenza di branch condizionati ) - se nel mio codice vi fosse, per dire, una catena di if del tipo
if ( variabile == valore1)
<istruzioni>
else if (variabile == valore2)
<istruzioni>
<...>il primo controllo condizionale verrebbe eseguito anche quando variabile è uguale a valore2; e se durante l' esecuzione del programma fosse la seconda condizione verificata con più frequenza, e quindi preso il relativo branch, avrei una inefficienza (che con un compilatore statico non si avrebbe modo di rilevare se non con un profiling del codice compilato)
Inoltre, più un codice lo puoi legare all'architettura più va veloce, in quanto puoi sfruttare tutto al meglio (cache, registri particolari del processore, ecc ecc).questo dipende dalle capacità del programmatore di ottimizzare il codice (assembly, perchè per sfruttare direttamente eventuali registri particolari a cui ti riferisci l' uso di linguaggi di più alto livello sarebbe praticamente fuori discussione) a mano e a mente
Un compilatore JIT non credo che faccia questo a runtime, non credo proprio, come può farlo? Andrebbe contro il concetto stesso di portabilità.anche scrivere codice ad alta ottimizzazione non sarebbe esattamente il massimo della portabilità ( tieni conto che per sfruttare al 100% la macchina, come dicevi, dovresti usare istruzioni che alcuni processori supportano e altri no, tenere conto che ogni famiglia di cpu ( anche all' interno della stessa isa x86) ha una differente topologia (line size, associatività...) per la cache l2...

in sostanza credo che non si tratterebbe di una mera ricompilazione, ma di una riscrittura delle parti sensibili del tuo codice ...
Però lo potrebbe fare la prima volta che genera il codice JIT...e già sarebbe un ottimo compromesso...potrebbe generare un codice diverso per ogni CPU...certo un profiling a runtime sarebbe veramente troppo costoso imho.ma esiste almeno un compilatore (LLVM) che ha l' analisi e trasformazione del codice, potenzialmente per tutta la durata del suo ciclo di vita, tra i suoi obiettivi primari
Leggiti il link che ho passato prima. ;)a cui aggiungerei questo http://www.usenix.org/publications/library/proceedings/usenix-nt97/full_papers/chernoff/chernoff.pdf :D

[cdimauro]

Con la complessità dei processori attuali non è il caso di usare nemmeno l'assembly: molto meglio affidarsi a ottimi compilatori di linguaggi ad alto livello, che possono tenere conto delle innumerevoli variabili in gioco. ;)

P.S. Grazie per il link. :)

[Unrue]

ad esempio i code path effettivamente attraversati in base alle condizioni di runtime (in presenza di branch condizionati ) - se nel mio codice vi fosse, per dire, una catena di if del tipo
if ( variabile == valore1)
<istruzioni>
else if (variabile == valore2)
<istruzioni>
<...>il primo controllo condizionale verrebbe eseguito anche quando variabile è uguale a valore2; e se durante l' esecuzione del programma fosse la seconda condizione verificata con più frequenza, e quindi preso il relativo branch, avrei una inefficienza (che con un compilatore statico non si avrebbe modo di rilevare se non con un profiling del codice compilato)


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

questo dipende dalle capacità del programmatore di ottimizzare il codice (assembly, perchè per sfruttare direttamente eventuali registri particolari a cui ti riferisci l' uso di linguaggi di più alto livello sarebbe praticamente fuori discussione) a mano e a mente

Non è necessario scendere fino all'assembly per fare le ottimizzazioni che dicevo sopra. Basta un buon profiler ed un pò di pazienza :) Inoltre spesso e volentieri, per abilitare particolari registri, è sufficiente impostare un flag specifico in fare di compilazione e ci pensa poi il compilatore a smistare il flusso di programma su quei registri.

[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 :confused:
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]

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

[atragon]

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

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]

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]

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è?? :mbe: 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.



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 ..:p Continua a valere il mio discorso. Che, almeno per adesso, un programma C++ ottimizzato con l'hardware è più veloce di un analogo Java

[Unrue]

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..:muro: 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]

E perchè?? :mbe: 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 ..:p 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]

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.


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]

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]

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_predictionso 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 :O
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 :O

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]

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 :D

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/showpost.php?p=20319449&postcount=65
Confrontare applicazioni diverse, come Azureus e uTorrent, non ha senso. ;)

[Tommo]

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 :D

[cdimauro]

Beh con uTorrent fai praticamente le stesse cose, ma quando sta acceso non te ne accorgi.
Per usare Azureus invece devo lasciare il pc :D
Li conosco entrambi, ma a livello di codice in comune non avranno praticamente niente: ecco perché non ha senso confrontarli.

[-Slash]

Beh con uTorrent fai praticamente le stesse cose, ma quando sta acceso non te ne accorgi.
Per usare Azureus invece devo lasciare il pc :D
E' esattamente quello a cui mi riferisco. Tutte e dico tutte le applicazioni java che ho provate sono lentissime.

ed in generale applicazioni in linguaggi non compilati, come python, risultano essere molto piu lente che programmi che fanno le stesse cose in linguaggi compilati. questa è la mia opinione...

per le gui mi riferivo in generale, ho letto in altri post sul forum quella cosa

[cdimauro]

"Casualmente" uso quasi sempre Python (da circa 3 anni), e a parte un po' di lentezza nel caricamento (la virtual machine deve partire per prima, e poi caricare i moduli dell'applicazione vera e propria), non mi sono mai lamentato della velocità d'esecuzione delle mie applicazioni. ;)

[tomminno]

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.

Diciamo che con i linguaggi managed metti un try catch e qualunque porcata tu possa fare nel mezzo sei sicuro che per lo meno finisci nel catch.
E' anche vero che ritrovarsi un'eccezione perchè fallisce la conversione del float 5,096 in uno short è qualcosa di frustrante.

In C++ sotto Windows sbattendoti con le SEH puoi trappare i segmentation fault, lo stack overflow è possibile trapparlo ma non avendo più spazio nello stack non hai modo di gestirlo.

OT: qualcuno conosce se esiste un equivalente Linux per le SEH?

La doppia deallocazione è un problema, ma generalmente sta scritto se la deallocazione è a carico del chiamante o meno (in C++ direi che non dovrebbe mai essere a carico del chiamante, oltretutto c'è modo di evitare il passaggio dei puntatori, vedi auto_ptr). E all'interno di una classe si spera che dopo la delete ci sia anche un'assegnazione a NULL del relativo puntatore.

Per i memory leak questi sono possibili in tutti i tipi di linguaggio sia managed che no.
Almeno in questo sono pari.

Secondo me l'enorme vantaggio dei linguaggi managed sul C++ è quello di fornire una vasta libreria tutto sommato uniforme in cui è possibile trovare tutto quello che serve, invece di ricorrere a librerie sempre diverse con interfacce differenti.

Buon 2008!

[tomminno]

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?

Con le QT o le wxWidgets anche in C++ scrivere una GUI è facilissimo.

[cdimauro]

Diciamo che con i linguaggi managed metti un try catch e qualunque porcata tu possa fare nel mezzo sei sicuro che per lo meno finisci nel catch.
E' anche vero che ritrovarsi un'eccezione perchè fallisce la conversione del float 5,096 in uno short è qualcosa di frustrante.

In C++ sotto Windows sbattendoti con le SEH puoi trappare i segmentation fault, lo stack overflow è possibile trapparlo ma non avendo più spazio nello stack non hai modo di gestirlo.

OT: qualcuno conosce se esiste un equivalente Linux per le SEH?

La doppia deallocazione è un problema, ma generalmente sta scritto se la deallocazione è a carico del chiamante o meno (in C++ direi che non dovrebbe mai essere a carico del chiamante, oltretutto c'è modo di evitare il passaggio dei puntatori, vedi auto_ptr). E all'interno di una classe si spera che dopo la delete ci sia anche un'assegnazione a NULL del relativo puntatore.

Per i memory leak questi sono possibili in tutti i tipi di linguaggio sia managed che no.
Almeno in questo sono pari.

Secondo me l'enorme vantaggio dei linguaggi managed sul C++ è quello di fornire una vasta libreria tutto sommato uniforme in cui è possibile trovare tutto quello che serve, invece di ricorrere a librerie sempre diverse con interfacce differenti.

Buon 2008!
Sono tutte cose che i linguaggi managed risolvono "aggratis", però. ;)

Per i memory leak non sono d'accordo: coi linguaggi managed (dotati di garbage collector) se un pezzo di memoria non risulta più usato / referenziato, prima o poi verrà deallocato.

La stessa cosa non si può dire per i linguaggi non managed (che non fanno uso di meccanismi GC): se dimentichi una free/delete, rimani con la memoria allocata fino alla morte dell'applicazione. ;)

Auguri a tutti. :)

[tomminno]

Li conosco entrambi, ma a livello di codice in comune non avranno praticamente niente: ecco perché non ha senso confrontarli.

Codice a comune per programmi scritti in linguaggi differenti non ce ne possono essere.

Come pensi di poter scrivere codice a comune tra C++ e Java?

Per essere comparabili non dovresti usare la STL del C++ che in Java non ha equivalente e viceversa per i generics. Ma se in Java si può fare benissimo a meno dei generics (che secondo me sono venuti fuori un pò malino a causa della retrocompatibilità del bytecode), togliere l'STL al C++ significa lavorare con il C con le classi: niente stream, string, vector, tr1...

Non potresti usare i puntatori del C++ perchè non hanno controparte in Java.

Non dovresti allocare niente sullo stack ma solo sulll'heap.

In Java per il problema del boxing e unboxing (assente in C++) che faresti useresti int o Integer? Ma in C++ Integer non esiste quindi creeresti una classe Integer per fare pari?

Insomma è impossibile scrivere codice comparabile di un certo interesse tra 2 linguaggi differenti.

[tomminno]

Per i memory leak non sono d'accordo: coi linguaggi managed (dotati di garbage collector) se un pezzo di memoria non risulta più usato / referenziato, prima o poi verrà deallocato.

La stessa cosa non si può dire per i linguaggi non managed (che non fanno uso di meccanismi GC): se dimentichi una free/delete, rimani con la memoria allocata fino alla morte dell'applicazione. ;)

Auguri a tutti. :)

Appunto il problema è che inavvertitamente potresti lasciare referenziato un oggetto che non dovrebbe più esserlo.

Qualche post fa è stato riportato un link a Mokabyte dove viene riportato un esempio di memory leak in Java: nell'esempio il pop su uno stack non impostava a null l'oggetto estratto, così che il GC si trova sempre referenziato l'oggetto e non lo elimina mai.
La dimenticanza equivalente in C++ sarebbe stata la mancata delete, ma che differenza c'è tra dimenticarsi elements[size] = null piuttosto che delete elements[size] ?
In entrambi i casi hai memory leak.

[jappilas]

E' esattamente quello a cui mi riferisco. Tutte e dico tutte le applicazioni java che ho provate sono lentissime.anche Diamond Crush? ;)

ed in generale applicazioni in linguaggi non compilati, come python, risultano essere molto piu lente che programmi che fanno le stesse cose in linguaggi compilati. questa è la mia opinione...ma, senza offesa, è un' opinione che lascia un po' il tempo che trova, se confronti tra loro programmi scritti, oltre che in linguaggi diversi, da programmatori diversi, per librerie (toolkit) diverse, e basati su design con ogni probabilità diversi ... è come confrontare mele con pere, e non si può trarre conclusioni sull' efficienza relativa dei linguaggi in cui sono stati scritti.. ;)

imho, una misura già più attendibile dell' overhead del runtime di un linguaggio, si avrebbe applicando a codice preesistente (in, per dire, C++) le modifiche necessarie e sufficienti per renderlo valido sintatticamente e semanticamente (quindi funzionante) in quel linguaggio (o viceversa), senza alterarne struttura e algortmi di funzionamento - ovvero un language port ...
il codice di diamond crush ( java ) è a disposizione per ogni possibile uso, compresa, per chi volesse cimentarsi, una eventuale conversione in C++ ( a patto di aggiungere le deallocazioni degli oggetti e reimplementare strutture dati e meccanismi di introspection) - a questo punto, sarei perfino curioso di vedere un confronto quantitativo...

[sottovento]

Questa è bella..:muro: 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..

Si, e' proprio bella.
Immagino che tu abbia preso un programma da 10000 righe di codice ed abbia fatto la verifica. Prego postare

[marco.r]

Appunto il problema è che inavvertitamente potresti lasciare referenziato un oggetto che non dovrebbe più esserlo.

Qualche post fa è stato riportato un link a Mokabyte dove viene riportato un esempio di memory leak in Java: nell'esempio il pop su uno stack non impostava a null l'oggetto estratto, così che il GC si trova sempre referenziato l'oggetto e non lo elimina mai.
La dimenticanza equivalente in C++ sarebbe stata la mancata delete, ma che differenza c'è tra dimenticarsi elements[size] = null piuttosto che delete elements[size] ?
In entrambi i casi hai memory leak.
C'e' una differenza importante. In un caso la memoria allocata e' persa "per sempre", mentre nell'altro c'e' ancora un riferimento, e quindi la memoria verra' prima o poi reclamata, solo piu' tardi di quando si vorrebbe. Ad esempio quando verra' aggiunto un nuovo oggetto sullo stack il puntatore verra' sovrascritto, e comunque la memoria verra' reclamata (eventualmente) una volta finito di usare lo stack.

[cdimauro]

Codice a comune per programmi scritti in linguaggi differenti non ce ne possono essere.

Come pensi di poter scrivere codice a comune tra C++ e Java?

Per essere comparabili non dovresti usare la STL del C++ che in Java non ha equivalente e viceversa per i generics. Ma se in Java si può fare benissimo a meno dei generics (che secondo me sono venuti fuori un pò malino a causa della retrocompatibilità del bytecode), togliere l'STL al C++ significa lavorare con il C con le classi: niente stream, string, vector, tr1...

Non potresti usare i puntatori del C++ perchè non hanno controparte in Java.

Non dovresti allocare niente sullo stack ma solo sulll'heap.

In Java per il problema del boxing e unboxing (assente in C++) che faresti useresti int o Integer? Ma in C++ Integer non esiste quindi creeresti una classe Integer per fare pari?

Insomma è impossibile scrivere codice comparabile di un certo interesse tra 2 linguaggi differenti.
I test che ha mostrato Tigershark rispecchiano la mia idea: le applicazioni sono esattamente le stesse, ma soltanto scritte con linguaggi diversi.

E' chiaro che di un un linguaggio sono libero di utilizzare qualunque costrutto, ed eventualmente libreria.

Quindi OK per l'STL per il C++, come pure per il framework standard di Java. Idem per i generics. Per i tipi di dati, userei gli scalari quando servono gli scalari, e i corrispettivi "boxed" (eventualmente generati automaticamente dal compilatore) quando servono invece degli oggetti.

La mia idea è che la struttura dei programmi dev'essere praticamente identica, fatta eccezione per i casi in cui, appunto, si può usare qualche funzione e/o oggetto di libreria o caratteristiche peculiari per implementare particolari parti di codice.

Questo se vogliamo fare dei confronti serii, in cui l'unica variabile diversa fra due applicazioni è, appunto, il linguaggio (e di esempi se ne trovano in giro) usato. ;)

Sull'altro messaggio vedo che ha già scritto marco, di cui condivido il pensiero.

[sottovento]

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

Si, e' vero. Penso che ci sia un vantaggio a favore di Java.
Crea per esempio una pletora di piccoli oggetti, per esempio:


class MyTest
{
public:
MyTest ()
{
a = 0;
b = 0;
buf = new char[1024];
strcpy (buf, "");
}

MyTest (int a, int b)
{
this->a = a;
this->b = b;
buf = new char[1024];
strcpy (buf, "");
}

MyTest (const MyTest &myTest)
{
printf ("Costruttore di copia chiamato\n");
a = myTest.a;
b = myTest.b;
buf = new char[1024];
strcpy (buf, myTest.buf);
}

void setA (int a)
{
this->a = a;
}

void setB (int b)
{
this->b = b;
}

void setText (char *text)
{
strcpy (buf, text);
}

const char *getText ()
{
return buf;
}

private:
int a;
int b;
char *buf;
};

Questa e' una classe con una dozzina di byte, implementabile sia in C++ sia in Java.
Dopo di che, scrivi nel main:


void allochiamo ()
{
printf ("Alloco un po'...\n");
time_t start = time (NULL);
for (int i = 0; i < 1000000; i++)
{
MyTest *p = new MyTest;
if (p)
delete p;
}
time_t stop = time (NULL);
printf ("Tempo di allocazione: %d\n", stop - start);
}

Scrivi lo stesso codice per Java, per esempio:


static void allochiamo ()
{
long start = Calendar.getInstance().getTimeInMillis ();
for (int i = 0; i < 100000000; i++)
{
MyTest mytest = new MyTest();
}
long stop = Calendar.getInstance().getTimeInMillis ();

System.out.println ("Time: " + ((stop - start)));
}

Ho compilato la versione di C++ con Microsoft Visual Studio .NET 2003 Professional, mentre la versione Java e' stata compilata con jdk 1.5
Sul mio sistema Win XP, Java e' circa 100 volte piu' veloce.
Infatti puoi vedere dalle mie prove che il numero di zeri nel ciclo Java e' piu' grande, anche perche' sul mio sistema C++, con lo stesso numero di zeri, non arriva a completamento in un tempo decente (ore).
Dove sbaglio?
Soprattutto, nel caso abbia commesso un errore, che tipo di errore e'? L'ho creato apposta per far "vincere"Java o si tratta di una normalissima prassi di programmazione?
Perche' Java vince? Non dovrebbe perdere SEMPRE?


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

Esatto. Java e' quindi piu' ottimizzato in senso GLOBALE.
LOCALMENTE non riesce a battere C++, ma quando hai applicazioni da milioni di linee, le cose cambiano. Tanto piu' che le piattaforme a management di memoria (non solo Java) stanno vincendo sul mercato: mem leaks piu' difficili da produrre (ci vuole piu' entusiasmo), codice piu' robusto e possibilita' di fare ottimizzazioni a livello globale.



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.

Riprendi l'esempio di prima:


MyTest getTest ()
{
MyTest t;
t.setA(5);
t.setB(8);

return t;
}

Spiegami come evitare questa copia.

Oppure:

void doSome1 (MyTest myTest)

Questa la potresti evitare scrivendo:

void doSome1 (const MyTest &myTest)

Pero'... se per caso usi i metodi di set() per risparmiare memoria, il tuo compilatore non compilera' un bel niente.
Come evitare? Dovrai fare una copia locale, che potremmo chiamare "copia volontaria".


Java su 1KB di RAM :confused:
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.
Sorry, hai ragione. Era notizia riservata. Perdonami

[sottovento]

Dimenticavo. Spesso e' utile controllar wikipedia.
Beh, la versione italiana non mi piace, visto che da notizie contrastanti da quella inglese :D (non completamente, ma le informazioni sono diverse).

Leggendo infatti al link http://en.wikipedia.org/wiki/Compiler il paragrafo "Compiled versus interpreted languages" si legge una cosa, secondo me, importante:


Higher-level programming languages are generally divided for convenience into compiled languages and interpreted languages. However, there is rarely anything about a language that requires it to be exclusively compiled, or exclusively interpreted. The categorization usually reflects the most popular or widespread implementations of a language — for instance, BASIC is thought of as an interpreted language, and C a compiled one, despite the existence of BASIC compilers and C interpreters.

In a sense, all languages are interpreted, with "execution" being merely a special case of interpretation performed by transistors switching on a CPU. Modern trends toward just-in-time compilation and bytecode interpretation also blur the traditional categorizations.


In un certo senso, tutti i linguaggi sono intepretati poiche' girano tutti su una macchina virtuale. Cambia la macchina virtuale, ma sempre VM e'! Anche C++ non fa eccezione, come potrebbe, d'altronde?
Quanto e' efficiente la macchina virtuale? Si puo' migliorarla con un layer software in piu'?

Cosa ne pensate? E' questo, secondo voi, il motivo per cui i linguaggi "managed" vinceranno la sfida rispetto ai linguaggi tradizionali?

[dupa]

meglio un programma il 10% più veloce o un programma 10% più esente da errori?
a mio parere programmare in C++ porta più facilmente a commettere errori, rispetto a programmare in Java.

[-Slash]

anche Diamond Crush? ;)

ma, senza offesa, è un' opinione che lascia un po' il tempo che trova, se confronti tra loro programmi scritti, oltre che in linguaggi diversi, da programmatori diversi, per librerie (toolkit) diverse, e basati su design con ogni probabilità diversi ... è come confrontare mele con pere, e non si può trarre conclusioni sull' efficienza relativa dei linguaggi in cui sono stati scritti.. ;)

imho, una misura già più attendibile dell' overhead del runtime di un linguaggio, si avrebbe applicando a codice preesistente (in, per dire, C++) le modifiche necessarie e sufficienti per renderlo valido sintatticamente e semanticamente (quindi funzionante) in quel linguaggio (o viceversa), senza alterarne struttura e algortmi di funzionamento - ovvero un language port ...
il codice di diamond crush ( java ) è a disposizione per ogni possibile uso, compresa, per chi volesse cimentarsi, una eventuale conversione in C++ ( a patto di aggiungere le deallocazioni degli oggetti e reimplementare strutture dati e meccanismi di introspection) - a questo punto, sarei perfino curioso di vedere un confronto quantitativo...
diamond crush mai provato

io sto dando una opinione da utente: tutti i programmi java che ho provato sono assolutamente lenti, molto piu degli equivalenti c e simili. poi potete dirmi che non ha senso confrontare vari programmi fatti da diversi programmatori, ma sinceramente mi sembra strano che prendo x programmi java e x programmi c e simili, e andando a confrontarli in ogni caso sono nettamente piu veloci quelli c...

Non ho assolutamente nulla contro java, solo che mi vengono in mente una caterva di esempi di programmi lentissimi in questo linguaggio e che per uno o un'altro motivo devo anche usare spesso: eclipse, che da solo si prende 300 mb di ram e all'uni sui computer un pochino datati è piu che inutilizzabile, maple che sul mio computer con 1 gb di ram e core duo fatica a caricare le finestre :confused: azureus che lo trovo semplicemente inutilizzabile, e potrei dirne altri...

programmi cosi affamati di risorse per quello che fanno in c++ sinceramente non mi vengono in mente...

[tomminno]

Dove sbagli non lo so (o meglio forse si, ho aggiunto il distruttore della classe MyTest altrimenti hai un bel memory leak :D ), ho creato al volo un progetto con Code::Blocks su linux Gcc 4.1.2 e il tempo di esecuzione del tuo codice è di 3 secondi con 10 milioni di allocazioni come nell'esempio Java.
Se non esegui la delete su buffer il sistema va in crisi perchè allochi 10GB di RAM.

Appena posso provo a fare lo stesso con Eclipse e ti dico il risultato.

[atragon]

Sia pure orientato su .Net mi pare interessante questo articolo:
http://msdn2.microsoft.com/it-it/library/ms973852(en-us).aspx

[tomminno]

MyTest getTest ()
{
MyTest t;
t.setA(5);
t.setB(8);

return t;
}

Spiegami come evitare questa copia.


E' il compilatore che lo fa al posto tuo.
Un qualunque compilatore tradice la tua funzione in:

void getTest (MyTest & tRet)
{
MyTest t;
t.setA(5);
t.setB(8);

tRet = t;
}



Oppure:

void doSome1 (MyTest myTest)

Questa la potresti evitare scrivendo:

void doSome1 (const MyTest &myTest)

Pero'... se per caso usi i metodi di set() per risparmiare memoria, il tuo compilatore non compilera' un bel niente.

Come evitare? Dovrai fare una copia locale, che potremmo chiamare "copia volontaria".


Esiste sempre la parola chiave mutable, da applicare alle variabili che non identificano strettamente la classe per cui possono essere modificate anche in presenza di riferimenti const.
Altrimenti se vuoi modificare l'oggetto la funzione corretta è:

void doSome1 (MyTest & myTest)


Come vedi nessuna copia di troppo

[sottovento]

Dove sbagli non lo so (o meglio forse si, ho aggiunto il distruttore della classe MyTest altrimenti hai un bel memory leak :D ), ho creato al volo un progetto con Code::Blocks su linux Gcc 4.1.2 e il tempo di esecuzione del tuo codice è di 3 secondi con 10 milioni di allocazioni come nell'esempio Java.
Se non esegui la delete su buffer il sistema va in crisi perchè allochi 10GB di RAM.

Appena posso provo a fare lo stesso con Eclipse e ti dico il risultato.

Si, mi ero accorto di non aver deallocato (ho fatto diverse prove prima di postare, poi ho copiato&incollato l'ultima).

Prestazioni di tutto rispetto, direi. 10 milioni di allocazioni in 3 secondi, praticamente 300 nanosecondi ad allocazione.
Sei proprio sicuro? Mi sembra una prestazione davvero esagerata!

Ne approfitto per augurarti Buon Anno, e per estendere l'augurio a tutti i frequentatori del forum.

[jappilas]

Dimenticavo. Spesso e' utile controllar wikipedia.
Beh, la versione italiana non mi piace, visto che da notizie contrastanti da quella inglese :D (non completamente, ma le informazioni sono diverse).no no, in certi casi le voci sono completamente diverse, e quel che è peggio, a volte riportano evidenti castronerie solo per non voler (o non saper) postare una traduzione diretta della voce inglese originale (solitamente scritta cum grano salis, almeno per quanto concerne l' informatica) - quella sull' Hyperthreading (http://it.wikipedia.org/wiki/Hyper-Threading) è un esempio lampante :muro:
Leggendo infatti al link http://en.wikipedia.org/wiki/Compiler il paragrafo "Compiled versus interpreted languages" si legge una cosa, secondo me, importante:<...>
In un certo senso, tutti i linguaggi sono intepretati poiche' girano tutti su una macchina virtuale. importante, e tanto più vera, soprattutto se si tiene conto che:
da una parte, esistono chip che eseguono nativamente bytecode Java (in cui quindi il BC java diventa parte dell' instruction set - ad esempio ARM con estensione Jazelle )
dall'altra, nei moderni processori, anche l' assembly della ISA pubblica è disaccoppiato dal set delle istruzioni effettivamente eseguite dalle unità interne della cpu, da un livello di traduzione - in questo senso l' instruction decoder agirebbe come virtual machine di basso livello...
Cosa ne pensate? E' questo, secondo voi, il motivo per cui i linguaggi "managed" vinceranno la sfida rispetto ai linguaggi tradizionali?che i linguaggi managed vincano o meno, dipenderà dal livello di rapidità e di immunità agli errori dei programmatori, che consentiranno di raggiungere nello sviluppo di una soluzione, e da quanto questi due aspetti controbilanceranno il runtime overhead, in ambiti ora esclusivamente coperti dallo sviluppo in linguaggio compilato
se però si considera che dei runtime per managed code sono già entrati a livello kernel nei sistemi operativi attuali (come parti di infrastrutture tese a uniformare la driver base e facilitare lo sviluppo di nuovi driver) e che per l' aggiornamento del C++ in programma per il 2009, si prevede l' introduzione nello standard di una garbage collection, l' impressione è che il managed code sia quello che vuole il mercato...

[sottovento]

Tutto


Non volevo ricopiare tutto il tuo post, per cui lo quoto tutto cosi' :D

[jappilas]

Non volevo ricopiare tutto il tuo post, per cui lo quoto tutto cosi' :D;):D

diamond crush mai provatoprovalo, secondo me non ti deluderà ;)
<...>: eclipse, che da solo si prende 300 mb di ram e all'uni sui computer un pochino datati è piu che inutilizzabile, maple che sul mio computer con 1 gb di ram e core duo fatica a caricare le finestre :confused: azureus che lo trovo semplicemente inutilizzabile, e potrei dirne altri...non ho usato maple (solo matlab, e non mi pare fosse Java :stordita: ), uso Eclipse su un p4 con 512 MB di ram - oggettivamente è pesante, più pesante di , per dire, Code:Blocks
ma rispetto a quest' ultimo ha un' architettura diversa (è strutturato in una moltitudine di plugin che vengono caricati all' avvio dell' sdk) e a runtime sembra fare molte più operazioni "dietro le quinte": l' input dell' utente sembra essere monitorato costantemente da un thread in background per tenere aggiornato il database degli import, gli Outlines e per la creazione delle liste contestuali, di hints mirati alla correzione degli errori sintattici in sospeso, di refactoring possibili sul metodo selezionato in un dato momento, e dei membri di classe accessibili con l' operatore di scopes...
credo che ciò contribuisca al suo essere memory e cpu - intensive... :O

[tomminno]

Si, mi ero accorto di non aver deallocato (ho fatto diverse prove prima di postare, poi ho copiato&incollato l'ultima).

Prestazioni di tutto rispetto, direi. 10 milioni di allocazioni in 3 secondi, praticamente 300 nanosecondi ad allocazione.
Sei proprio sicuro? Mi sembra una prestazione davvero esagerata!

Ne approfitto per augurarti Buon Anno, e per estendere l'augurio a tutti i frequentatori del forum.

Compilato in debug, mi risulta che l'esecuzione vari tra 3.4 e 3.6 secondi.
Con un milione di cicli il tempo di esecuzione è di 0.37 secondi.
Tra l'altro vedo che in release con l'opzione O2 non cambia praticamente niente.
Non escludo pesanti ottimizzazioni del loop unrolling del gcc.

Ho provato anche ad usare un pò di C++ invece del C, usando una variabile string e assegnando la stringa vuota. Risultato 1,5 secondi per 10 milioni di cicli.

Con Java 1.6.0.3 usando la classe String ottengo 1,8 secondi, mentre eseguendo la new di un array di char pari a 1024 il tempo di esecuzione è 143,797 secondi.

Se le differenze sono pressochè nulle usando le rispettive classi String, con una sequenza enorme di allocazioni la differenza è parecchio marcata.
Non vedo possibili ottimizzazioni della JVM messe in pratica.

Domani riprovo con XP.

Sarebbe interessante riportare i benchmark ottenuti con questo piccolo test.
I test li ho eseguiti su un notebook Core 2 Duo T5300 1,7GHz, 2GB RAM, Fedora 8.

nel mio caso stravince il c++.

[-Slash]

;):D

provalo, secondo me non ti deluderà ;)
non ho usato maple (solo matlab, e non mi pare fosse Java :stordita: ), uso Eclipse su un p4 con 512 MB di ram - oggettivamente è pesante, più pesante di , per dire, Code:Blocks
ma rispetto a quest' ultimo ha un' architettura diversa (è strutturato in una moltitudine di plugin che vengono caricati all' avvio dell' sdk) e a runtime sembra fare molte più operazioni "dietro le quinte": l' input dell' utente sembra essere monitorato costantemente da un thread in background per tenere aggiornato il database degli import, gli Outlines e per la creazione delle liste contestuali, di hints mirati alla correzione degli errori sintattici in sospeso, di refactoring possibili sul metodo selezionato in un dato momento, e dei membri di classe accessibili con l' operatore di scopes...
credo che ciò contribuisca al suo essere memory e cpu - intensive... :O
anche code::blocks ha una architettura a plugin, e di default ha piu plugin caricati di eclipse(ad esempio wxsmith)

[tomminno]

anche code::blocks ha una architettura a plugin, e di default ha piu plugin caricati di eclipse(ad esempio wxsmith)

Eclipse però è un progetto ben più grande e maturo di Code::Blocks, il quale non è che abbia poi molti plugin.
Eclipse lo puoi confrontare con Visual Studio, Code::Blocks no, sebbene sotto tanti aspetto CB funzioni molto meglio di VS per il C++.

[-Slash]

Eclipse però è un progetto ben più grande e maturo di Code::Blocks, il quale non è che abbia poi molti plugin.
Eclipse lo puoi confrontare con Visual Studio, Code::Blocks no, sebbene sotto tanti aspetto CB funzioni molto meglio di VS per il C++.
Ma io parlo di velocità del programma... Eclipse di default non ha nessun plugin, a parte quello per team syncronising se non erro

Code::Blocks di default ne ha qualcuno in piu, compreso wxsmith che è bello pesante come plugin, però come velocità non c'è proprio paragone :D

comunque io sinceramente mi trovo molto meglio con CB che con eclipse cdt, difatti all'uni consigliano eclipse ed io me ne frego altamente ed utilizzo CB :asd:

[sottovento]

Compilato in debug, mi risulta che l'esecuzione vari tra 3.4 e 3.6 secondi.
Con un milione di cicli il tempo di esecuzione è di 0.37 secondi.
Tra l'altro vedo che in release con l'opzione O2 non cambia praticamente niente.
Non escludo pesanti ottimizzazioni del loop unrolling del gcc.

Ho provato anche ad usare un pò di C++ invece del C, usando una variabile string e assegnando la stringa vuota. Risultato 1,5 secondi per 10 milioni di cicli.

Con Java 1.6.0.3 usando la classe String ottengo 1,8 secondi, mentre eseguendo la new di un array di char pari a 1024 il tempo di esecuzione è 143,797 secondi.

Se le differenze sono pressochè nulle usando le rispettive classi String, con una sequenza enorme di allocazioni la differenza è parecchio marcata.
Non vedo possibili ottimizzazioni della JVM messe in pratica.

Domani riprovo con XP.

Sarebbe interessante riportare i benchmark ottenuti con questo piccolo test.
I test li ho eseguiti su un notebook Core 2 Duo T5300 1,7GHz, 2GB RAM, Fedora 8.

nel mio caso stravince il c++.

E' piu' che interessante, anche perche' mi hai fatto venire il dubbio ed ho rifatto le operazioni, ottenendo ancora la vittoria di Java.

Ho usato un notebook 1,7GHz, 1GB RAM Win XP SP2.
Ho fatto 100 milioni di cicli, avendo tempi in proporzione piu' che doppi dei tuoi (per java, c++ e' molto piu' lento). Fra l'altro, usando Java 1.5 e Visual Studio .NET, che sembra essere uno dei migliori.

Sulle stringhe hai ottenuto 1,5 contro 1,8... beh, devo dire che sono sorpreso in ogni caso dalla velocita', in entrambi i casi. Eppure hai un computer che non e' poi cosi' piu' performante del mio... :)

A proposito, che tempi hai su 100 milioni di cicli? E, avendo tempo, su 1 miliardo? Le differenze dovrebbero accentuarsi, giusto?
Oppure potrebbe succedere qualcos'altro, visto che la tua memoria e' doppia della mia :D

[tomminno]

E' piu' che interessante, anche perche' mi hai fatto venire il dubbio ed ho rifatto le operazioni, ottenendo ancora la vittoria di Java.

Ho usato un notebook 1,7GHz, 1GB RAM Win XP SP2.
Ho fatto 100 milioni di cicli, avendo tempi in proporzione piu' che doppi dei tuoi (per java, c++ e' molto piu' lento). Fra l'altro, usando Java 1.5 e Visual Studio .NET, che sembra essere uno dei migliori.


Ma con Java che tempi ottieni?
Perchè a me per fare 10 milioni di cicli ci ha messo più di 147 secondi contro i 3.5 del C++.
Non so se possa essere un problema della JVM Sun su linux.

Per quanto riguarda il C++ non ho dubbi che il vantaggio sia il compilatore :D


A proposito, che tempi hai su 100 milioni di cicli? E, avendo tempo, su 1 miliardo? Le differenze dovrebbero accentuarsi, giusto?
Oppure potrebbe succedere qualcos'altro, visto che la tua memoria e' doppia della mia :D

Domani provo a ripetere i test e ad eseguirli anche su XP con VS2005.

[sottovento]

Ma con Java che tempi ottieni?
Perchè a me per fare 10 milioni di cicli ci ha messo più di 147 secondi contro i 3.5 del C++.

:confused: Esattamente il contrario del mio test!
Per 100 milioni di cicli, ci metto 52 secondi, mentre C++ (compilato in modalita' release) piu' del doppio.


Fra l'altro, aumentando il numero di cicli, si vede che la velocita' su C++ diminuisce progressivamente.

Non so se possa essere un problema della JVM Sun su linux.

Per quanto riguarda il C++ non ho dubbi che il vantaggio sia il compilatore :D



Domani provo a ripetere i test e ad eseguirli anche su XP con VS2005.

Sono davvero confuso. Oltretutto ho usato 1.5 che non e' nemmeno l'ultima versione di jdk.

In ogni caso, prendendo le prestazioni che hai segnalato prima sulle stringhe, (in cui Java e' piu' lento), risulta piu' lento di circa il 7%...

[cionci]

Per le altre cose, l'avevo scritto: http://www.hwupgrade.it/forum/showpost.php?p=20319449&postcount=65
Confrontare applicazioni diverse, come Azureus e uTorrent, non ha senso. ;)
Però sarebbe interessante confrontare Azureus in bytecode e Azureus compilato con GCJ...

[cdimauro]

Sicuramente. :)

[cionci]

sottovento...posta il sorgente anche di Java, almeno evitiamo dubbi dovuti all'implementazione. L'avevi messo il distruttore con la delete[] nella versione C++, vero ?

[cionci]

O il mio compilatore è molto intelligente o la mia macchina è molto veloce :asd:

Alloco un po'...
Tempo di allocazione: 0

Versione C++ :eek:

Edit:

$ time ./MyTest
Alloco un po'...
Tempo di allocazione: 0

real 0m0.154s
user 0m0.148s
sys 0m0.000s

[cionci]

sottovento, mi sa che non hai scelto proprio l'esempio migliore ;)

$ time java -classpath . mytest/Main
Alloco un po'...
Time: 63.06

real 1m3.177s
user 1m2.908s
sys 0m0.500s

$ time ./MyTest
Alloco un po'...
Tempo di allocazione: 11

real 0m11.373s
user 0m11.369s
sys 0m0.000s

[^TiGeRShArK^]

Indipendentemente dal fatto che Java sia meglio di C++ od il contrario ( a me piacciono entrambi :) ) Java, ha l'innegabile overhead di dover fare due compilazioni: una in bytecode e l'altra in assembler. C++ no, la fa direttamente in assembler. E per quanto piccolo sia questo passaggio, non sarà mai eliminabile, in quanto insito nella natura dei linguaggi interpretati. Tutto sta nell'analizzare quanto, nella nostra applicazione, questo passaggio comporta o meno dei rallentamenti. Quindi in ogni applicazione, fatta bene o male, Java parte con un leggero svantaggio.

A volte questo può essere un vantaggio dato che il JIT compila con ottimizzazioni diverse il codice a seconda dei vari path che vengono seguiti al run-time mentre in C++ il codice è sempre compilato staticamente.

Detto questo, spesso il codice Java è più elegante e pulito( ovviamente dipende molto anche dal programmatore) quindi spesso si può accettare un maggior tempo di esecuzione a fronte di una maggiore chiarezza del codice.

Io che lavoro spesso con applicazioni parallele che operano su decine di processori, posso dirvi che Java è visto come la peste in questi campi. C++ un pò meno, non a caso ci sono molte librerie parallele scritte in C++( ad esempio Charm++) . In questo campo, dove si cerca la massima velocità di esecuzione possibile, prevalgono C e Fortran perchè sono ritenuti più veloci di tutti.

Il tempo sprecato per ottimizzare la velocità di esecuzione in C può essere imho usato MOLTO + proficuamente ottimizzando l'algoritmo, che dovrebbe essere praticamente l'unica ottimizzazione da fare dato che tutte le altre portano invariabilmente a una complicazione del codice e va fatta solo ed esclusivamente se vi sono requisiti strettissimi a riguardo.
Inoltre già dalla version 5 di Java c'è tutto il package java.util.concurrent che semplifica notevolmente la gestione di applicaizioni parallele.
Il supporto base al parallelismo invece credo ci sia fin da java 1.0 :fagiano:

[^TiGeRShArK^]

Come se i memory leak in java non fossero possibili.
A volte anche trovare dei riferimenti circolari che impediscono la deallocazione degli oggetti non è così immediato.
Io non sono risucito a trovarne in un programma C# che per inviare delle stringhe via seriale (usando 2 classi) arriva ad occupare 70MB di RAM per circa 2MB di dati inviati. Avesse avuto dei memory leak in C++ si sarebbe fermato ad occupare 2MB più del necessario, al massimo 4 visto che le classi coinvolte erano 2.

E' MOLTO + difficile avere dei memory leaks in java.
A me sinceramente è capitato solo una volta e il problema si presentava solo in modalità concorrente per un bug del caiser che non riceveva mai tutti i messaggi di un'agente e quindi la coda dei messaggi cresceva indefinitamente.
E sinceramente mi sfugge perchè in C++ il memory leak ti avrebbe preso solo 2 MB in +..
Io credo invece che in quella situazione il problema sarebbe stato se possibile ancora + grave.

[^TiGeRShArK^]

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.
In C# non ho idea, ma in JAVA il garbage collector di solito viene eseguito solo quando si raggiunge la dimensione predefinita massima assegnata per l'heap space tramite l'opzione -Xmx da riga di comando.
In quel modo l'applicazione non verrà rallentata in alcun modo dal garbage collector fino a che non sia effettivamente necessario.

[Unrue]

Si, e' proprio bella.
Immagino che tu abbia preso un programma da 10000 righe di codice ed abbia fatto la verifica. Prego postare

Quindi secondo te gli assembly generati sono uguali?? Ma via su, se vuoi te lo posto un assembly di un programma da 10.000 righe di codice.. Cambia il linguaggio, cambiano i compilatori, cambiano le librerie.. Dimmi come fa l'assembly generato ad essere lo stesso :mbe:

[Unrue]

Il supporto base al parallelismo invece credo ci sia fin da java 1.0 :fagiano:

Io per parallelismo intendevo applicazioni che girano su più processori, non intendevo con i thread. Nel senso che te hai un'applicazione seriale e modifichi l'algoritmo in modo che ogni processore esegue una porzione e poi comunicano tra loro i risultati intermedi. Ad esempio, con le librerie MPI. Dove è il supporto di Java ad applicazioni di questo tipo? Che sono quelle che girano nei supercomputers per simulazioni scientifiche per intendersi. C'è una libreria che sfrutta i threads, ma guarda caso è scritta in C++, e si chiama Charm++

In campi come la simulazione su supercomputers, dove la velocità è fondamentale, Java non è presente. Ma guarda un pò ..

[Unrue]

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 :O
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 :O

ps: tanti auguri :)

Auguri anche a te !Mi fa piacere che conosci bene la branch-prediction :) La tua analisi è molto interessante, è chiaro che C/C++ staticamente non possono ottimizzare i cache-miss, ma se lo fai a mano puoi è come. Ovviamente è più lungo , dispendioso e richiede una buona esperienza. Se Java fa questo a runtime ben venga, anche se non credo, altrimenti ci sarebbero differenze prestazionali davvero notevoli. Nel' articolo Dinamo postato prima si parla di un 20% in più, non è che sia chissà cosa. Trall'altro, come si spiegano allora quei grafici postati all'inizio in cui si vede Java che è sempre sotto a C++ anche se di poco?Fa il profiling a runtime e ciò nonostante va peggio di C++? C'è qualcosa che non torna..

Inoltre cari javisti spiegatemi una cosa :) Come mai , spesso e volentieri quando si crea una GUi in Java, è necessario usare due thread,uno per gestire l'interfaccia, l'altro per il resto del codice, in quanto uno solo non ce la fa a gestire tutto quanto, soprattutto il refresh?Come mai in C++ questo non succede? :) Forse perchè l'analogo programma in C++ è un pò più leggero ? Mah.. misteri.

[franksisca]

Inoltre cari javisti spiegatemi una cosa :) Come mai , spesso e volentieri quando si crea una GUi in Java, è necessario usare due thread,uno per gestire l'interfaccia, l'altro per il resto del codice, in quanto uno solo non ce la fa a mandare tutto quanto?Come mai in C++ questo non succede? :) Forse perchè l'analogo programma in C++ è un pò più leggero ? Mah.. misteri.

e questo dove l'hai sentita???

io faccio fare tutto in un (ovviametne seguendo patter specifici)...è acnhe vero che io non faccio applicazioni grosse.....semplici programmini(per ora).

comunque credo che da dati pratici la discussione si stia spostando su "ideologie".

io credo che il tutto si possa riassumere così:

C++ è più performate se lo sai scrivere a dovere, ma se conosci java e non devi per "forza di cose" usare c++, allora java è ottimo anche a livello prestazionale.


ho sbagliato con la sintesi??

[Unrue]

L'ho sentita e sperimentata più volte di persona :) Non è un mistero questa cosa dei refresh. Spiegatemela su, perchè sinceramente non l'ho mai capita :)

[franksisca]

L'ho sentita e sperimentata più volte di persona :) Non è un mistero questa cosa dei refresh. Spiegatemela su, perchè sinceramente non l'ho mai capita :)

allora, una cosa è che si sceglie di farlo in questo modo, un'altra è che si è costretti.

s si sceglie, chiedilo a chi lo fà, non a me.

io ti posso dire che secondo me può essere una scelta furba per alleggerire il sistema(usando i thread lo stesso spazio di memoria).


poi, ripeto, ognuno la pensa come vuole.

[^TiGeRShArK^]

In teoria il profiling a runtime potrebbe tranquillamente farlo, gli basterebbe generare codice diverso al successivo ingresso in quella parte di codice. Ma quanto costa fare un profiling a runtime ? La Java VM lo fa ? Io credo proprio di no.

Adaptive optimization

Adaptive optimization is a technique in computer science that performs dynamic recompilation of portions of a program based on the current execution profile. With a simple implementation, an adaptive optimizer may simply make a trade-off between Just-in-time compilation and interpreting instructions. At another level, adaptive optimization may take advantage of local data conditions to optimize away branches and to use inline expansion to decrease context switching.


Register allocation improvements

Prior to Java 6, allocation of registers was very primitive in the "client" virtual machine (they did not live across blocks), which was a problem in architectures which did not have a lot of registers available, such as x86 for example. If there are no more registers available for an operation, the compiler must copy from register to memory (or memory to register), which takes time (registers are typically much faster to access). However the "server" virtual machine used a color-graph allocator and did not suffer from this problem.

An optimization of register allocation was introduced in this version: [7]; it was then possible to use the same registers across blocks (when applicable), reducing accesses to the memory. This led to a reported performance gain of approximately 60% in some benchmarks. [8]

In this example, the same register could be used for result, and the doSomethingElse method.

public int doSomething() {
int result = 1;
for (int i = 0; i < 10000; i++) {
result = result + doSomethingElse(i * 20);
}
return result;
}
private int doSomethingElse(int value) {
return value * 10;
}


non è un un full-profiling al runtime, cmq il codice viene dinamicamente adattato in base alle condizioni attuali.

[Unrue]

allora, una cosa è che si sceglie di farlo in questo modo, un'altra è che si è costretti.

s si sceglie, chiedilo a chi lo fà, non a me.

io ti posso dire che secondo me può essere una scelta furba per alleggerire il sistema(usando i thread lo stesso spazio di memoria).


poi, ripeto, ognuno la pensa come vuole.

Anche secondo me è una scelta furba, solo che spesso e volentieri sono costretto a farlo perchè sennò l'applicazione non fa il refresh, se non alla fine!! Ora,non sono un mostro nella programmazione di grafica in Java, ma questa cosa l'ho sentita spesso in giro. In C++ non mi è mai capitato. Oh, qualcosa vorrà dire.

[^TiGeRShArK^]

Appunto :) Bisogna vedere se il gioco vale la candela. Ad esempio, io potrei impostare un ciclo for in modo che abbia meno cache miss possibili. MA questo proprio perchè so che tipo di cache ho sotto. Con Java è molto più incasinato fare questo, anzi, non lo puoi proprio fare se il programma è pensato per girare su diverse piattaforme. Sicuramente si troverà una cache differente e quindi tutto il lavoro svolto sul ciclo for andrebbe buttato via.

Secondo me, se prendiamo un programma Java , quanto buono che sia, mai e poi mai avrà le stesse prestazioni di un codice scritto in C, C++ che sfrutta appieno l'hardware. Non c'è compilatore JIT che tenga per questo. Il rovescio della medaglia è ovviamente che se cambio architettura devo ricompilare ma, come ho detto prima,.. è davvero questa grande fatica ricompilare ??
:mbe:
questo mi spieghi come fai a farlo sinceramente :mbe:
Lo puoi fare sicuramente in architetture come il Cell in cui decidi tu quali dati caricare nella memoria locale delle SPE, ma in un'architettura di tipo x86 non hai alcun controllo sulla cache (e vorrei ben dire!) e quindi qualsiasi supposizione vai a fare, a meno che il tuo programma non sia un piccolo kernel dedicato che faccia solo quell'operazione, non è valida dato che varia al variare delle condizioni in cui si trova il processore.

[Unrue]

:mbe:
questo mi spieghi come fai a farlo sinceramente :mbe:
Lo puoi fare sicuramente in architetture come il Cell in cui decidi tu quali dati caricare nella memoria locale delle SPE, ma in un'architettura di tipo x86 non hai alcun controllo sulla cache (e vorrei ben dire!) e quindi qualsiasi supposizione vai a fare, a meno che il tuo programma non sia un piccolo kernel dedicato che faccia solo quell'operazione, non è valida dato che varia al variare delle condizioni in cui si trova il processore.

Controlli la cache nel senso che adatti il ciclo alla cache stessa, in modo da avere meno cache miss possibili ,non nel senso che te gli dici cosa caricare (cosa credo impossibile):)

Io personalmente non ho mai fatto ottimizzazioni a livello di cache, però conosco persone che lo fanno, quindi è possibilissimo :)

[sottovento]

sottovento, mi sa che non hai scelto proprio l'esempio migliore ;)

$ time java -classpath . mytest/Main
Alloco un po'...
Time: 63.06

real 1m3.177s
user 1m2.908s
sys 0m0.500s

$ time ./MyTest
Alloco un po'...
Tempo di allocazione: 11

real 0m11.373s
user 0m11.369s
sys 0m0.000s

Well, a questo punto siete in due contro uno :D
Devo quindi pensare che il problema stia dalla mia parte, anche se ho fatto esperimenti parecchie volte prima di postare, onde evitare brutte figure.

Avevo anche messo la delete[]. Cmq penso sia inutile postare anche il codice Java, visto che e' proprio uguale. Devo capire come mai ho queste prestazioni.

Non per fare il cocciuto, ma resto ancora convinto di quanto scritto prima: Java (come altre piattaforme managed) hanno la possibilita' di fare ottimizzazioni a livello globale, certamente ad un livello piu' alto di quanto possa fare C++.
Ovviamente con C++ si puo' fare tutto quello che fa Java, naturalmente scrivendolo da zero...

[^TiGeRShArK^]

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
Sono due discorsi diversi.
La branch prediction del processore usa delle euristiche che vanno bene nel circa il 95% dei casi nelle architetture moderne, ma il caso proposto da jappilas mi pare proprio uno di quei casi in cui tale tecnica non funziona correttamente, portando ad uno stallo della pipeline in caso di errore di predizione.

[tomminno]

E sinceramente mi sfugge perchè in C++ il memory leak ti avrebbe preso solo 2 MB in +..
Io credo invece che in quella situazione il problema sarebbe stato se possibile ancora + grave.

Perchè le 2 classi in totale inviano su seriale tanti pacchetti da 100 byte per un totale di circa 2MB di dati, più una serie di eventi per monitorare lo stato di invio, ma questi si scambiano degli interi.
Se in C++ facessi tante "new char [100]" dimenticandomi la delete avrei un memory leak di 2MB, invece il programma C# che già di per se parte con 25MB arriva alla fine del'operazione ad occupare 70MB che non vengono mai rilasciati.
Insomma non saranno memory leak ma 70MB per inviare 4 cavolate in seriale mi sembrano una esagerazione.

[jappilas]

Auguri anche a te !Mi fa piacere che conosci bene la branch-prediction :) La tua analisi è molto interessante, è chiaro che C/C++ staticamente non possono ottimizzare i cache-miss, ma se lo fai a mano puoi è come. certo
qualsiasi cosa è fattibile avendo a disposizione risorse sufficienti, nel senso di tempo e capacità del programmatore impiegato, e tenendo conto che molto probabilmente l' ottimizzazione spinta renderà il codice meno leggibile e più difficilmente manutenibile (il che si rifletterà in un aumento dei costi della soluzione a lungo termine) - il punto è: considerando ciò, ne vale la pena?
in certi casi può effettivamente valere la pena, ma negli altri risulterà più conveniente scrivere codice più pulito e leggibile che altamente ottimizzato, e affidarsi a strumenti di ottimizzazione dinamica ...
Nel' articolo Dinamo postato prima si parla di un 20% in più, non è che sia chissà cosa. sì ma cosiderando che Dinamo traduceva (o meglio, "trasformava" ottimizzando, a run time) codice macchina PA8000 (generato da un compilatore che, si può ragionevolmente pensare, vi avesse applicato le ottimizzazioni di cui era capace) in altro codice macchina PA8000, un incremento di prestazioni del 20% è imho tutt' altro che trascurabile (proprio perchè frutto di ottimizzazioni sull' AST del programma intero, che il compilatore originale non aveva modo di applicare) ;)
Come mai , spesso e volentieri quando si crea una GUi in Java, è necessario usare due thread,uno per gestire l'interfaccia, l'altro per il resto del codice, in quanto uno solo non ce la fa a gestire tutto quanto, soprattutto il refresh?Come mai in C++ questo non succede? :) Forse perchè l'analogo programma in C++ è un pò più leggero ? Mah.. misteri.veramente, AFAIK, la presenza di almeno due thread sarebbe una caratteristica inerente alla realizzazione di applicazioni GUI- based, quindi interattive
con un solo thread, un' applicazione interattiva consisterebbe in un loop in cui si effettuerebbe un polling degli eventi in ingresso e un aggiornamento della struttura dati interna e della presentazione visuale in base a questi eventi - in occasione dell' invocazione di una system call sincrona o dell' ingresso in una lunga routine di calcolo, l' intera applicazione smetterebbe di rispondere all' input dell' utente fino alla terminazione di queste
per questo motivo è prassi comune per applicazioni di un certa complessità creare thread separati per ridurre la "modalità" dell' interfaccia, ma questo "ad alto livello" è indipendente dal linguaggio ... il meccanismo con cui ciò viene implementato, e il modo di impiegarlo invece possono variare ampiamente rispetto al linguaggio, ad estensioni del linguaggio (ad esempio openMP), o al toolkit grafico (già considerando il C++ esistono *se non ricordo male* toolkit in cui un thread nascosto è creato internamente all' inizializzazione della libreria, e altri in cui la gestione dei messaggi e degli eventi gui è thread-safe, quindi viene supportato un event/message loop per_thread, quindi è possibile adottare un design più scalabile per la propria applicazione )

[Unrue]

Sono due discorsi diversi.
La branch prediction del processore usa delle euristiche che vanno bene nel circa il 95% dei casi nelle architetture moderne, ma il caso proposto da jappilas mi pare proprio uno di quei casi in cui tale tecnica non funziona correttamente, portando ad uno stallo della pipeline in caso di errore di predizione.

Quindi? Io stavo puntualizzando il fatto che la branch-prediction non c'entra nulla con il linguaggio di programmazione usato.

[^TiGeRShArK^]

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 ..:p Continua a valere il mio discorso. Che, almeno per adesso, un programma C++ ottimizzato con l'hardware è più veloce di un analogo Java
teoricamente si.
Nelle applicazioni REALI tali differenze sono, a parte casi particolari, negligibili dato che in un sistema reale non è solo il tuo programma a girare ma gira una quantità enorme di servizi e il tuo programma, compilato staticamente, non potrà sapere a priori quale tipo di ottimizzazione darà i risultati migliori.

Un'altra tecnica implementata nella JVM a partire da Java 6 è la seguente:

In programming language compiler optimization theory, escape analysis is a method for determining the dynamic scope of pointers. It is related to pointer analysis and shape analysis.

When a variable (or an object) is allocated in a subroutine, a pointer to the variable can escape to other threads of execution, or to calling subroutines. If a subroutine allocates an object and returns a pointer to it, the object can be accessed from undetermined places in the program — the pointer has "escaped". Pointers can also escape if they are stored in global variables or other data structures that, in turn, escape the current procedure.

Escape analysis determines all the places where a pointer can be stored and whether the lifetime of the pointer can be proven to be restricted only to the current procedure and/or thread.

Optimizations

A compiler can use the results of escape analysis as basis for optimizations:

* Converting heap allocations to stack allocations. If an object is allocated in a subroutine, and a pointer to the object never escapes, the object may be a candidate for stack allocation instead of heap allocation.

* Synchronization elision. If an object is found to be accessible from one thread only, operations on the object can be performed without synchronization.

* Breaking up objects or scalar replacement. An object may be found to be accessed in ways that do not require the object to exist as a sequential memory structure. This may allow parts (or all) of the object to be stored in CPU registers instead of in memory.

In pratica, nonostante non sia un full profiling, questa tecnica, porta notevoli vantaggi nei casi succitati.
La cosa interessante da notare è che *corregge* anche degli eventuali errori di un programmatore.
Se un oggetto o un blocco di codice è dichiarato synchronized, ma viene utilizzato solo all'interno di un unico thread in fase di esecuzione, allora le operazioni lì definite vengono eseguite senza sincronizzazione.

[sottovento]

Conci/Tommino
Sto cercando di capire se e dove sbaglio. Vorrei provare (se possibile) ad avere una base comune.
E' possbile x voi rifare l'esperimento con le due sole variabili a,b? (i.e. eliminare tutto cio' che riguarda buf).

Sul mio computer, questo determina un bel vantaggio di Java. Sarebbe bello vedere gli stessi risultati da un'altra parte, visto che comincio a sentirmi solo :(

Ripeto mia configurazione: Win XP SP2 1.7 GHz 1Mb RAM

[Unrue]

Se un oggetto o un blocco di codice è dichiarato synchronized, ma viene utilizzato solo all'interno di un unico thread in fase di esecuzione, allora le operazioni lì definite vengono eseguite senza sincronizzazione.

Nessuno nega che Java faccia tante ottimizzazioni carine a runtime, ma come si spiega allora che, nonostante C++ non le faccia, le prestazioni nel grafico che tu hai postato all'inizio sono pressappoco uguali ?:)

[cionci]

Inoltre cari javisti spiegatemi una cosa :) Come mai , spesso e volentieri quando si crea una GUi in Java, è necessario usare due thread,uno per gestire l'interfaccia, l'altro per il resto del codice, in quanto uno solo non ce la fa a gestire tutto quanto, soprattutto il refresh?Come mai in C++ questo non succede? :) Forse perchè l'analogo programma in C++ è un pò più leggero ? Mah.. misteri.
Succede anche in C++, con le MFC ad esempio...e quei framework che non te lo fanno vedere hanno comunque un thread dedicato a gestire la GUI ;)

[^TiGeRShArK^]

Appunto il problema è che inavvertitamente potresti lasciare referenziato un oggetto che non dovrebbe più esserlo.

Qualche post fa è stato riportato un link a Mokabyte dove viene riportato un esempio di memory leak in Java: nell'esempio il pop su uno stack non impostava a null l'oggetto estratto, così che il GC si trova sempre referenziato l'oggetto e non lo elimina mai.
La dimenticanza equivalente in C++ sarebbe stata la mancata delete, ma che differenza c'è tra dimenticarsi elements[size] = null piuttosto che delete elements[size] ?
In entrambi i casi hai memory leak.
sono due cose ESTREMAMENTE diverse.
Un oggetto, quando non viene + utilizzato, allora viene automaticamente deallocato.
Gli unici problemi in Java ci possono essere quando tra i campi di una classe ci sono strutture aventi la funzione di repository di dati o di cache.
In quel caso, mio pare anche *ovvio* che debbano essere implementati dei meccanismi per gestire correttamente la cache o per rimuovere i dati non + necessari.
Quindi non c'entra niente fare elements[size] = null (che tra l'altro non è neanche semanticamente corretto perchè al + dovrebbe essere elements = null :mbe: ), dato che si suppone che in un'array di dimensione fissa si abbia abbastanza memoria da garantire la memorizzazione di ogni oggetto dell'array, ma il vero problema è fare il [I]remove dalle varie collections.
Tra l'altro, se non erro, mi pare che sia anche sconsigliato porre a null un oggetto dato che si complica inutilmente il codice e si incasina di + il lavoro del GC.

[cionci]

Sul mio computer, questo determina un bel vantaggio di Java. Sarebbe bello vedere gli stessi risultati da un'altra parte, visto che comincio a sentirmi solo :(

Ripeto mia configurazione: Win XP SP2 1.7 GHz 1Mb RAM
Posta i sorgenti C++ e quelli Java...
Almeno partiamo davvero da una base comune ;)
In ogni caso gcc 4.1.3 su Linux e Java 1.6. Il sistema è un Core 2 Duo a 3.2 Ghz.

[shinya]

Controlli la cache nel senso che adatti il ciclo alla cache stessa, in modo da avere meno cache miss possibili ,non nel senso che te gli dici cosa caricare (cosa credo impossibile):)

Io personalmente non ho mai fatto ottimizzazioni a livello di cache, però conosco persone che lo fanno, quindi è possibilissimo :)


Colgo la palla al balzo per insinuarmi nella discussione, e a proposito di gestione della cache faccio notare che esiste un paper a riguardo.

paper: http://citeseer.ist.psu.edu/prokop99cacheobliviou.html
wikipedia: http://en.wikipedia.org/wiki/Cache-oblivious_algorithm

Avvertimento: il paper è di quelli da mal di testa!

edit: c'è anche un paper più umano (sembra)... http://www.dunkel.dk/thesis/

[^TiGeRShArK^]

Non ho assolutamente nulla contro java, solo che mi vengono in mente una caterva di esempi di programmi lentissimi in questo linguaggio e che per uno o un'altro motivo devo anche usare spesso: eclipse, che da solo si prende 300 mb di ram e all'uni sui computer un pochino datati è piu che inutilizzabile, maple che sul mio computer con 1 gb di ram e core duo fatica a caricare le finestre :confused: azureus che lo trovo semplicemente inutilizzabile, e potrei dirne altri...

programmi cosi affamati di risorse per quello che fanno in c++ sinceramente non mi vengono in mente...
assolutamente falso.
Ho appena fatto partire eclipse ed ecco in allegato i risultati.
circa 84 MB.
E come ho detto prima l'ho anche usato tranquillamente con progetti da circa 1 Milione di LOCs e avevo problemi (ovviamente) solo in fase di compilazione.

[^TiGeRShArK^]

Ma io parlo di velocità del programma... Eclipse di default non ha nessun plugin, a parte quello per team syncronising se non erro

Code::Blocks di default ne ha qualcuno in piu, compreso wxsmith che è bello pesante come plugin, però come velocità non c'è proprio paragone :D

comunque io sinceramente mi trovo molto meglio con CB che con eclipse cdt, difatti all'uni consigliano eclipse ed io me ne frego altamente ed utilizzo CB :asd:
Ma anche no.
Elipse europa versione classic ha di default:
Eclipse CVS client, Eclipse CVS client resources, Eclipse Java Development Tools, Eclipse JDT plug-in Developer Resources, Eclipse PDE Plug.in Developer Resources, Eclipse RCP, Eclipse RCP Plug-in developer resources, Eclipse plug.in development environment.
...Sinceramente non sembrano proprio pochi.
L'unico da te citato è il client CVS x il team synchronize :fagiano:

[Unrue]

Succede anche in C++, con le MFC ad esempio...e quei framework che non te lo fanno vedere hanno comunque un thread dedicato a gestire la GUI ;)

Non lo sapevo.Comunque se hanno un thread di suo che gestisce l'interfaccia, allora vuol dire che questa cosa è gestita meglio di Java. A meno che le ultime versioni non hanno sopperito a questo.

[cionci]

Non lo sapevo.Comunque se hanno un thread di suo che gestisce l'interfaccia, allora vuol dire che questa cosa è gestita meglio di Java.
C'è anche chi non lo ha...come MFC...è semplicemente una scelta progettuale, non è meglio o peggio. In un linguaggio come Java in cui è facilissimo creare thread e gestirli anche io avrei usato una realizzazione come quella attuale.

[^TiGeRShArK^]

In campi come la simulazione su supercomputers, dove la velocità è fondamentale, Java non è presente. Ma guarda un pò ..
Questo è un caso *erstremamente* particolare e, tra l'altro, è l'UNICO caso possibile in cui sai a priori cosa girerà cul tuo processore e potrai utilizzare esattamente le ottimizzazioni migliori.
Praticamente è tutto fuorchè un caso reale :p
Comunque non ho capito che intendi con "applicazioni che girano su + processori".
I thread servono esattamente per quello scopo.
Ogni thread può essere instradato ad un processore fisico (o logico) e venire eseguito in parallelo.
Per quanto riguarda il riassemblamento dei rislutati ci sono una miriade di tecniche diverse.
La più semplice è la comune barriera che permetti di fissare un "checkpoint" in cui si attende l'arrivo dei risultati intermedi dei vari thread che possono quindi essere reinterpretati correttamente.
Introdotta a aprtire da java 5 insieme a tutte le altre strutture ad alto livello per la gestione dei thread.

[sottovento]

Posta i sorgenti C++ e quelli Java...
Almeno partiamo davvero da una base comune ;)
In ogni caso gcc 4.1.3 su Linux e Java 1.6. Il sistema è un Core 2 Duo a 3.2 Ghz.

Sorry, e' il giorno delle figure di tacchino ;)
Cmq non mi sembra che ci possano essere grandi differenze.

Java:

import java.lang.*;
import java.util.*;

class MyTest
{
private int a;
private int b;

public MyTest ()
{
a = 0;
b = 0;
}

public MyTest (int a, int b)
{
this.a = a;
this.b = b;
}

public void setA (int a)
{
this.a = a;
}

public void setB (int b)
{
this.b = b;
}
};

class Alloc
{
public static void main (String[] args)
{
allochiamo ();
}

static void allochiamo ()
{
System.out.println ("Allochiamo un po'...");
long start = Calendar.getInstance().getTimeInMillis ();
for (int i = 0; i < 100000000; i++)
{
MyTest mytest = new MyTest();
}
long stop = Calendar.getInstance().getTimeInMillis ();
System.out.println ("Fine allocazione");

System.out.println ("Time: " + ((stop - start)));
}
}


C++:

class MyTest
{
public:
MyTest ()
{
a = 0;
b = 0;
}

MyTest (int a, int b)
{
this->a = a;
this->b = b;
}

MyTest (const MyTest &myTest)
{
printf ("Costruttore di copia chiamato\n");
a = myTest.a;
b = myTest.b;
}

void setA (int a)
{
this->a = a;
}

void setB (int b)
{
this->b = b;
}

private:
int a;
int b;
};

void allochiamo ()
{
for (int i = 0; i < 100000000; i++)
{
MyTest *p = new MyTest;
if (p)
delete p;
// printf ("%c%d", 13, i);
}
}

int main (int argc, char *argv[])
{
try
{
printf ("Alloco un po'...\n");
time_t start = time (NULL);
allochiamo ();
time_t stop = time (NULL);
printf ("Tempo di allocazione: %d\n", stop - start);
}
catch (...)
{
printf ("Exception!\n");
}
return 0;

[Unrue]

Questo è un caso *erstremamente* particolare e, tra l'altro, è l'UNICO caso possibile in cui sai a priori cosa girerà cul tuo processore e potrai utilizzare esattamente le ottimizzazioni migliori.
Praticamente è tutto fuorchè un caso reale :p

Era solo per dire un campo in cui serve velocità pura ed appunto Java non è presente. Anche se sono casi particolari, servono per capire le potenzialità dei linguaggi.


Comunque non ho capito che intendi con "applicazioni che girano su + processori".


Dai un'occhiata ad MPI:
http://www.mpi-forum.org/

[^TiGeRShArK^]

Auguri anche a te !Mi fa piacere che conosci bene la branch-prediction :) La tua analisi è molto interessante, è chiaro che C/C++ staticamente non possono ottimizzare i cache-miss, ma se lo fai a mano puoi è come. Ovviamente è più lungo , dispendioso e richiede una buona esperienza.

Non puoi in alcun modo farlo a mano a meno che non giri solo ed esclusivamente il tuo codice su quella macchina.

Se Java fa questo a runtime ben venga, anche se non credo, altrimenti ci sarebbero differenze prestazionali davvero notevoli. Nel' articolo Dinamo postato prima si parla di un 20% in più, non è che sia chissà cosa. Trall'altro, come si spiegano allora quei grafici postati all'inizio in cui si vede Java che è sempre sotto a C++ anche se di poco?

Non sempre.
Se noti bene ci sono uno o due test in cui java è sopra.

Inoltre cari javisti spiegatemi una cosa :) Come mai , spesso e volentieri quando si crea una GUi in Java, è necessario usare due thread,uno per gestire l'interfaccia, l'altro per il resto del codice, in quanto uno solo non ce la fa a gestire tutto quanto, soprattutto il refresh?Come mai in C++ questo non succede? :) Forse perchè l'analogo programma in C++ è un pò più leggero ? Mah.. misteri.
:mbe:
Hai idea di come viene implementato un sottosistema grafico event-driven quale swing? :mbe:
In caso in cui la tua applicazione fa operazioni di durata che è possibile assumere atomica allora *potresti* utilizare l'Event Dispatcher Thread stesso per far girare interamente la tua applicazione.
Nella vita reale però questo non deve MAI essere fatto dato che se per caso qualcosa non va a buon fine e la tua operazione che avrebbe dovuto essere atomica risulta essere + lenta allora l'EDT rimane bloccato nel tuo metodo e non può fare quello per cui è stato progettato: dispatchare eventi.
Quindi sinceramente mi sfugge la tua obiezione.
E' proprio il risultato di una ben precisa scelta architetturale il fatto che occorre utilizzare un thread diverso dall'Event Dispatcher Thread per non fare andare in stallo l'interfaccia grafica.
Altrimenti spiegami come faresti in C++ a far girare in un unico thread la tua applicazione con metodi bloccanti e il dispatching degli eventi dell'interfaccia grafica :mbe:

[shinya]

Non puoi in alcun modo farlo a mano a meno che non giri solo ed esclusivamente il tuo codice su quella macchina.

Io non sarei cosi categorico... i link che ho postato pare proprio non esserseli fumati nessuno.

Cmq, da wikipedia (Cache-oblivious algorithm):
"In computing, a cache-oblivious algorithm is an algorithm designed to exploit the CPU cache without having the size of the cache (or the length of the cache lines, etcetera) as an explicit parameter. An optimal cache-oblivious algorithm is a cache-oblivious algorithm that exploits the cache optimally (in an asymptotic sense, ignoring constant factors). Thus, a cache oblivious algorithm is designed to perform well, without modification, on multiple machines with different cache sizes, or for a memory hierarchy with different levels of cache having different sizes."

Ci sono tutte delle ricerche su questi argomenti (che ho linkato).

[tomminno]

Non lo sapevo.Comunque se hanno un thread di suo che gestisce l'interfaccia, allora vuol dire che questa cosa è gestita meglio di Java. A meno che le ultime versioni non hanno sopperito a questo.

No l'utlizzo di almeno 2 thread è indispensabile.
Che io sappia nessuna interfaccia grafica di serie ha controlli thread safe (non lo sono C#,MFC,wxWidgets,QT e mi sembra anche Java). Quindi a meno di non bloccare completamente l'interfaccia in attesa dell'esecuzione di un comando (mai usato VB?) devi passare il tutto ad un altro thread che poi dovrà sincronizzarsi con quello dell'interfaccia al momento di ritornare il risultato dell'esecuzione.

[cionci]

sottovento: è più veloce quello Java, ma mi sembra che tu abbia trovato un caso un po' limite ;) Praticamente il programma non fa niente :D

[^TiGeRShArK^]

Controlli la cache nel senso che adatti il ciclo alla cache stessa, in modo da avere meno cache miss possibili ,non nel senso che te gli dici cosa caricare (cosa credo impossibile):)

Io personalmente non ho mai fatto ottimizzazioni a livello di cache, però conosco persone che lo fanno, quindi è possibilissimo :)
Può essere fatto solo in determinate applicazioni in cui è presente una forte località dei dati, e, soprattutto, se in background non girano altri servizi che riempiono la cache con i loro dati...

[^TiGeRShArK^]

Perchè le 2 classi in totale inviano su seriale tanti pacchetti da 100 byte per un totale di circa 2MB di dati, più una serie di eventi per monitorare lo stato di invio, ma questi si scambiano degli interi.
Se in C++ facessi tante "new char [100]" dimenticandomi la delete avrei un memory leak di 2MB, invece il programma C# che già di per se parte con 25MB arriva alla fine del'operazione ad occupare 70MB che non vengono mai rilasciati.
Insomma non saranno memory leak ma 70MB per inviare 4 cavolate in seriale mi sembrano una esagerazione.
In java basta settare l'opzione Xmx ad un livello inferiore, se necessario e ci pensa il GC a liberare la memoria automaticamente non appena arriva alla soglia che gli hai settato.

[^TiGeRShArK^]

Quindi? Io stavo puntualizzando il fatto che la branch-prediction non c'entra nulla con il linguaggio di programmazione usato.
mi riquoto.. :p

At another level, adaptive optimization may take advantage of local data conditions to optimize away branches and to use inline expansion to decrease context switching.

.. a sentire wikipedia sembrerebbe che le ottimizzazioni al runtime del JIT migliorino i branch nel codice.

[^TiGeRShArK^]

Nessuno nega che Java faccia tante ottimizzazioni carine a runtime, ma come si spiega allora che, nonostante C++ non le faccia, le prestazioni nel grafico che tu hai postato all'inizio sono pressappoco uguali ?:)
:mbe:
Forse col fatto che il memory manager di Java gestisce in maniera trasparente la memoria?
Forse col fatto che il Garbage Collector rende immediato l'uso di oggetti senza preoccuparsi di distruttori o di porre l'oggetto a null?
E' ovvio che tutti i vantaggi di java si debbano pagare in qualche misura a livello prestazionale, ma, a dispetto di quanto dite voi, nella maggioranza dei casi il gioco non vale la candela, ovvero per la misera % che potrà essere guadagnata a livello prestazionale in C++ si avrà un incremento molto sensibile dei costi di produzione.

[^TiGeRShArK^]

Era solo per dire un campo in cui serve velocità pura ed appunto Java non è presente. Anche se sono casi particolari, servono per capire le potenzialità dei linguaggi.



Dai un'occhiata ad MPI:
http://www.mpi-forum.org/
E che c'azzecca il Message Passing con la gestione di + processori? :mbe:
Il Message Passing è utilizzato, ma non solo, per la comunicazione nei cluster server.
Esso se non erro viene utilizzato anche in qualche SO per la comunicazione tra i thread.
Ma alla fine è solo un protocollo per lo scambio di dati, non ha nulla a che vedere con l'elaborazione parallela vera e propria :mbe:

[^TiGeRShArK^]

Io non sarei cosi categorico... i link che ho postato pare proprio non esserseli fumati nessuno.

Cmq, da wikipedia (Cache-oblivious algorithm):
"In computing, a cache-oblivious algorithm is an algorithm designed to exploit the CPU cache without having the size of the cache (or the length of the cache lines, etcetera) as an explicit parameter. An optimal cache-oblivious algorithm is a cache-oblivious algorithm that exploits the cache optimally (in an asymptotic sense, ignoring constant factors). Thus, a cache oblivious algorithm is designed to perform well, without modification, on multiple machines with different cache sizes, or for a memory hierarchy with different levels of cache having different sizes."

Ci sono tutte delle ricerche su questi argomenti (che ho linkato).

ancora non ero arrivato a quei links :p
Comunque quelli rappresentano appunto una categoria ben definita di problemi, e in quel caso non si ottimizza per una determinata dimensione di cache ma si suddivide (a quanto ho capito) ricorsivamente il problema in modo che si abbia una dimensione dell'operazione tanto piccola che possa entrare in cache.
Quindi, in questo modo, l'ottimizzazione vale per qualsiasi linguaggio utilizzato, dal Python al Java fino al C++... o sbaglio? ;)

[cionci]

assolutamente falso.
Ho appena fatto partire eclipse ed ecco in allegato i risultati.
circa 84 MB.
E come ho detto prima l'ho anche usato tranquillamente con progetti da circa 1 Milione di LOCs e avevo problemi (ovviamente) solo in fase di compilazione.
A me 318 MB su Ubuntu :confused:
Controlla direttamente la memoria occupata...non vorrei che le DLL non te le contasse

[^TiGeRShArK^]

A me 318 MB su Ubuntu :confused:
Controlla direttamente la memoria occupata...non vorrei che le DLL non te le contasse
:mbe:
ora sono con fedora 8 e non posso riavviare..
Comunque 318 MB su ubuntu mi pare tantino :stordita:
84 MB dovrebbe essere la memoria RAM fisica occupata.

[cionci]

Ci sta anche che non sia il pacchetto minimale...è quello che ti installa con Synaptic...

[^TiGeRShArK^]

Ci sta anche che non sia il pacchetto minimale...è quello che ti installa con Synaptic...

..io in windows ho la versione classic che comprende tutti i plugin elencati prima per lo sviluppo java, RCP, e PDE.. :stordita:

[Unrue]

E che c'azzecca il Message Passing con la gestione di + processori? :mbe:
Il Message Passing è utilizzato, ma non solo, per la comunicazione nei cluster server.
Esso se non erro viene utilizzato anche in qualche SO per la comunicazione tra i thread.
Ma alla fine è solo un protocollo per lo scambio di dati, non ha nulla a che vedere con l'elaborazione parallela vera e propria :mbe:

:mbe: :mbe: :mbe:
Perdonami ma.... hai letto bene a cosa serve quella libreria? Venire a dire che MPi con l'elaborazione parallela non c'entra nulla, quando la stragrande maggioranza di applicazioni parallele la usa, mi pare che sia una grossissima fesseria :D Gli algoritmi seriali genralmente sono parallelizzati proprio con quella libreria...

[sottovento]

sottovento: è più veloce quello Java, ma mi sembra che tu abbia trovato un caso un po' limite ;) Praticamente il programma non fa niente :D

Per prima cosa: grazie! Cominciavo a sentirmi un marziano, pensavo di vedere cose che non esistono :rolleyes:

Seconda cosa: il caso non e' proprio limite. E' solo l'inizio. Se ci metti altro codice dentro, java prendera' il volo rispetto a C++.

Pensa, per esempio, all'architettura MVC: Java sara' nettamente piu' veloce.
Analogamente, architetture basate su sistemi di notifica (i.e. i listener): java sara' ancora piu' veloce.
E cosi' via.
Purtroppo tirare in piedi un esempio di questo genere, richiede molto piu' tempo....

Beh, ti ringrazio ancora.

[marco.r]

assolutamente falso.
Ho appena fatto partire eclipse ed ecco in allegato i risultati.
circa 84 MB.
E come ho detto prima l'ho anche usato tranquillamente con progetti da circa 1 Milione di LOCs e avevo problemi (ovviamente) solo in fase di compilazione.
Anche a me sotto linux succhia molta memoria, diciamo attorno ai 150 appena partito per poi andare attorno ai 200-250 durante il lavoro. Devo dire pero' che io lo uso per il C++, il cui plugin lascia alquanto a desiderare, visto che oltre a fare molte cose malino, non di rado mi lancia qualche errore strano, come quello allegato :stordita: (molto esplicativi soprattutto i dettagli :D )

[marco.r]

Li conosco entrambi, ma a livello di codice in comune non avranno praticamente niente: ecco perché non ha senso confrontarli.
Ma non ha neanche senso confrontare due programmi scritti allo stesso modo, perche linguaggi diversi hanno modi diversi di essere programmati "al meglio". Piuttosto meglio confrontare due programmi che producano lo stesso output.

[cionci]

Sottovento: è molto probabile che il codice che hai postato con il compilatore JIT si risolva in un "non codice"...nel senso che dopo il primo run si accorga che non ci sono side effect e che il codice assembly nativo sia in effetti nullo ;)

Non mi risulta che qualsiasi cosa tu ci metta dentro vada più veloce Java...ad esempio con una cosa stupida:

class MyTest {

ArrayList<Integer> v;

public MyTest() {
v = new ArrayList<Integer>();
for(int i = 100; i > 0; i--)
{
for(int k = 0; k < 5; k++)
{
v.add(k * i);
}
}
}

public void sort() {
for(int i = 0; i < v.size(); i++)
for(int j = 0; j < v.size(); j++)
{
if(v.get(i) > v.get(j))
{
Integer temp = v.get(i);
v.set(i, v.get(j));
v.set(j, temp);
}
}
}
};


static void allochiamo ()
{
System.out.println ("Allochiamo un po'...");
long start = Calendar.getInstance().getTimeInMillis ();
for (int i = 0; i < 10000; i++)
{
MyTest mytest = new MyTest();
mytest.sort();
}
long stop = Calendar.getInstance().getTimeInMillis ();
System.out.println ("Fine allocazione");

System.out.println ("Time: " + ((stop - start)));
}

PS: lo so che si possono limitare gli indici del bubblesort.

Con Java 20 secondi...in C++ 5 secondi (con ottimizzazione O2)

[cionci]

Anche a me sotto linux succhia molta memoria, diciamo attorno ai 150 appena partito per poi andare attorno ai 200-250 durante il lavoro.
A me 170 MB appena partito...318 MB appena apri un nuovo progetto vuoto...

[variabilepippo]

è più veloce quello Java


Mi sembra il minimo, nella versione C++ ci sono 100000000 di allocazioni E di deallocazioni, mentre nella versione Java si attende l'intervento del GC una tantum. Non mi sembra un confronto equo... :rolleyes:

Con i benchmark si può dimostrare tutto ed il contrario di tutto:

The Java Faster than C++ Original Benchmark (http://kano.net/javabench/)
The Java (not really) faster than C++ (http://bruscy.multicon.pl/pages/przemek/java_not_really_faster_than_cpp.html)
'The Java Faster than C++' Benchmark Revisited (http://www.freewebs.com/godaves/javabench_revisited/)
Why Java is slow (http://www.jelovic.com/articles/why_java_is_slow.htm)

http://bruscy.multicon.pl/pages/przemek/files/plots/160u1-43x/java_vs_cpp_stacked.png


Total execution time for C++: 73.30 seconds
Total execution time for Java Server VM: 204.01 seconds
Total execution time for Java Client VM: 249.83 seconds


NB. Preferisco le piattaforme managed al C++ perché consentono di sviluppare prodotti migliori in tempi minori, ma è difficile ottenere con esse le prestazioni del codice nativo ottimizzato da programmatori esperti.


The Benchmarks

Perversely, the only area [* *] in which Java can be as fast as C++ is a typical benchmark. If you need to calculate Nth Fibonacci number or run Linpack, there is no reason why Java cannot be as fast as C++. As long as all the computation stays in one class and uses only primitive data types like int and double, the Java compiler is on equal footing with the C++ compiler.
The Real World

The moment you start using objects in your program, Java looses the potential for optimization. This section lists some of the reasons why.

[* *] Se ci si riferisce alla serie di benchmark sintetizzati dal grafico neanche in questa area Java riesce ad eccellere.

[sottovento]

Mi sembra il minimo, nella versione C++ ci sono 100000000 di allocazioni E di deallocazioni, mentre nella versione Java si attende l'intervento del GC una tantum. Non mi sembra un confronto equo... :rolleyes:

Si, e' esattamente dove si vuole andare a parare.
E' da un po' di post che scrivo che e' per questo motivo che si puo' affermare che prima o poi le piattaforme managed saranno piu' performanti... C++ ed affini ti permettono una ottimizzazione LOCALE, i managed sembrano (parere personale) andare verso una ottimizzazione GLOBALE.


Con i benchmark si può dimostrare tutto ed il contrario di tutto:

:D Vero :D
Nel caso non lo dimostrino, puoi sempre interpretare i risultati :D
Ad ogni modo, mi faccio sempre un po' di test. Penso di essere uno pratico, quindi mi fido dei test MIEI, fatto per il problema che vado a risolvere.


NB. Preferisco le piattaforme managed al C++ perché consentono di sviluppare prodotti migliori in tempi minori, ma è difficile ottenere con esse le prestazioni del codice nativo ottimizzato da programmatori esperti.

...

[* *] Se ci si riferisce alla serie di benchmark sintetizzati dal grafico neanche in questa area Java riesce ad eccellere.

Dopo tutta questa discussione (in cui ho difeso a spada tratta le prestazioni di Java) sara' difficile credermi, ma preferisco il C/C++, essenzialmente perche' mi da da vivere da circa 20 anni :)

Questo pero' non toglie che le cose si stanno muovendo: dal mio punto di vista e' evidente dove si sta andando, e perche'.
Secondo me non e' solo un problema di sviluppo di software migliore ed in tempi piu' rapidi.
Non si e' mai veramente risolto il problema delle prestazioni dei linguaggi ad oggetti, dove vengono creati tanti oggetti di pochi byte ciascuno, causando problemi di frammentazione...
GC e' la naturale soluzione. Meglio deallocare in un botto, no? Le prestazioni ne guadagnano.

[cionci]

GC e' la naturale soluzione. Meglio deallocare in un botto, no? Le prestazioni ne guadagnano.
Niente vieta di usare il garbage collector anche per il C++ ;)
Anzi il C++ ha nella libreria standard diversa roba adatta per creare un garbage collector...

[sottovento]

Niente vieta di usare il garbage collector anche per il C++ ;)

Of course! Ovviamente lo potremmo usare anche per l'assembler :)

Ma tutto questo mi porta ad una domanda: non dormi mai? :D Io sono ancora al lavoro, ma tu... :D

[TTYman]

E' curioso come tanti argomenti trattati a favore dell'uno o dell'altro linguaggio ancora non abbiano portato a conclusioni nette, probabilmente perche' non ce ne sono, allo stato attuale.
La mia esperienza lavorativa, ormai oltre 15 anni di programmazione, mi ha portato a questa conclusione:

Java cerca di ovviare alle problematiche maturate con il C++, durante l'evoluzione dell'informatica e delle esigenze dei software in genere; in special modo nell'uso dei puntatori e dei riferimenti, nelle allocazioni e nelle deallocazioni, i principali problemi di sviluppo che prendevano poi molto tempo nel cercare soluzioni ai bug; con la diffusione di internet a livello mondiale, c'e' stata la maggiore necessita' di programmi orientati al paradigma client-server: java nasce proprio per questo, eliminare i problemi di sviluppo del c++ ed aggiungere funzionalita' per ambienti di rete.

La velocita' di esecuzione iniziava a non essere la prima necessita' di sviluppo, perche' l'hardware cresceva a dismisura come potenza, e i programmi di conseguenza, senza particolari accorgimenti software.
Questa prassi pero' di non ottimizzare il codice, o meglio, di non realizzare software a regola d'arte, ha portato a quello che alcuni hanno definito come 40% in meno di prestazioni di Microsoft Vista rispetto a XP, mantenendo lo stesso hardware, dato che Vista e' fortemente basato su .Net Framework, la Virtual Machine di Microsoft concorrenziale a quella di Sun.
Quindi usare una macchina virtuale implica un degrado di prestazioni rispetto al non usarla, a parita' di hardware. Questo e' assodato da applicazioni "reali".
Ma perche'?

Semplicemente perche' ad oggi le macchine virtuali non implementano quello che molti paper che sono stati riferiti iniziano a definire come "necessita'" per la pluralita' dei sistemi hardware: l'astrazione dall'hardware. Ma e' proprio necessaria questa astrazione? Si se si considerano dal punto di vista della cache locale associata alla cpu (AMD, Intel, Transmeta etc tutti con cache e metodi di accesso differenti), che e' vitale per la velocita' di esecuzione dei software (Vista e' compatibile si con x86, ma sono tutti diversi tra di loro a livello di cache e non solo...). In secondo luogo perche' non hanno la possibilita' di accedere in modo semplice alle sempre maggiori necessita' di interfacciamento esterno (ognuno con implementazioni troppo proprietarie per la portabilita' nel reparto palm computing o mobile per esempio... altro che standard...)

La direzione intrapresa e' di realizzare un compilatore in tempo reale (o ricompilatore dinamico) integrato nella VM e/o Sistema Operativo che ottimizza il codice, frammentandolo e riorganizzandolo, con tecniche di morphig etc., per l'architettura e la cache "rilevata" durante l'esecuzione. Chi riuscira' ad implementare questo prima degli altri e in modo semplice, l'avra' vinta (tra Sun e Microsoft intendo con le loro Virtual Machines). Per adesso i compilatori C/C++ realizzano questo staticamente perche' sono stati progettari per farlo :O, basti pensare al gcc e quali/quante piattaforme supporta, mentre la macchina virtuale java/.net ancora no. Quindi e' questo il motivo della superiore velocita' dei programmi C/C++ nativi.

Progetti che hanno applicato la ricompilazione dinamica hanno dimostrato che sono super efficienti, e la microsoft lo sa, non per altro ha tra i suoi sviluppatori alcuni guru "conosciuti" nell'ambiente dell'emulazione...
No, io non lavoro per la Microsoft... beh ancora no :Prrr: e sinceramente non credo possa mai succedere... Tux Rulez !

TTY

[cdimauro]

Ma non ha neanche senso confrontare due programmi scritti allo stesso modo, perche linguaggi diversi hanno modi diversi di essere programmati "al meglio". Piuttosto meglio confrontare due programmi che producano lo stesso output.
Sì, ma devono essere gli STESSI programmi: stesse identiche funzionalità.

E' chiaro che poi, in base al linguaggio, posso utilizzare costrutti e librerie a disposizione. Ne parlo meglio qui: http://www.hwupgrade.it/forum/showpost.php?p=20347372&postcount=152 ;)

[cdimauro]

Questa prassi pero' di non ottimizzare il codice, o meglio, di non realizzare software a regola d'arte, ha portato a quello che alcuni hanno definito come 40% in meno di prestazioni di Microsoft Vista rispetto a XP, mantenendo lo stesso hardware, dato che Vista e' fortemente basato su .Net Framework, la Virtual Machine di Microsoft concorrenziale a quella di Sun.
Stai confrontando due programmi MOOOLTO diversi: Vista e XP non sono ESATTAMENTE la stessa cosa, e il primo offre MOLTE più funzionalità rispetto al secondo.

[cionci]

Stai confrontando due programmi MOOOLTO diversi: Vista e XP non sono ESATTAMENTE la stessa cosa, e il primo offre MOLTE più funzionalità rispetto al secondo.
Funzionalità completamente nuove solo dal punto di Vista della grafica (e che per questo avrebbero dovuto pesare interamente sulla scheda grafica)...per il resto sono state tutte "riscritture" di cose che esistevano già in XP (non che ci sia solo la veste grafica diversa, ma le altre feature sono appunto adattamenti di feature già esistenti e mi sembra strano che occupino così tante risorse)...
Se poi vuoi fare riferimento a ReadyDrive, ReadyBoost e compagnia...sono tutte tecnologie che avrebbero dovuto rendere il sistema più veloce ;)

[cionci]

Ma tutto questo mi porta ad una domanda: non dormi mai? :D Io sono ancora al lavoro, ma tu... :D
Mi stavo divertendo a scrivere un garbage collector :asd:

[tomminno]

Per prima cosa: grazie! Cominciavo a sentirmi un marziano, pensavo di vedere cose che non esistono :rolleyes:

Seconda cosa: il caso non e' proprio limite. E' solo l'inizio. Se ci metti altro codice dentro, java prendera' il volo rispetto a C++.

Pensa, per esempio, all'architettura MVC: Java sara' nettamente piu' veloce.
Analogamente, architetture basate su sistemi di notifica (i.e. i listener): java sara' ancora piu' veloce.
E cosi' via.
Purtroppo tirare in piedi un esempio di questo genere, richiede molto piu' tempo....

Beh, ti ringrazio ancora.

In realtà se ci metti la new come in origine il tempo di esecuzione di Java cresce esponenzialmente quello C++ no.
Prova a rimettere la new di un array di 1024 char e poi ne riparliamo.

[tomminno]

Mi sembra il minimo, nella versione C++ ci sono 100000000 di allocazioni E di deallocazioni, mentre nella versione Java si attende l'intervento del GC una tantum. Non mi sembra un confronto equo... :rolleyes:


In realtà questo accade in quanto il runtime vede che quel codice non fa niente e non lo esegue, prova a scrivere un codice che faccia qualcosa e vedrai i tempi di esecuzione, tra l'altro anche nei test che hai riportato è chiaro come la creazione di un oggetto in Java sia molto più lenta che in C++


NB. Preferisco le piattaforme managed al C++ perché consentono di sviluppare prodotti migliori in tempi minori, ma è difficile ottenere con esse le prestazioni del codice nativo ottimizzato da programmatori esperti.


Secondo me il vero vantaggio delle piattaforme managed è la libreria unifrome e praticamente omnicomprensiva (però prova ad uscire dal seminato e la produttività crolla improvvisamente).
In C++ devi fare riferimento alle librerie specifiche ognuna con la propria interfaccia, i linguaggi managed ti forniscono una libreria con interfaccia uniforme e soprattutto già fatta.
Pensa se effettivamente il C++ non sarebbe ben più produttivo se oltre alla libreria standard avesse anche una libreria estesa equivalente come funzionalità a quella di Java o del .NET.

[cdimauro]

Funzionalità completamente nuove solo dal punto di Vista della grafica (e che per questo avrebbero dovuto pesare interamente sulla scheda grafica)...per il resto sono state tutte "riscritture" di cose che esistevano già in XP (non che ci sia solo la veste grafica diversa, ma le altre feature sono appunto adattamenti di feature già esistenti e mi sembra strano che occupino così tante risorse)...
Se poi vuoi fare riferimento a ReadyDrive, ReadyBoost e compagnia...sono tutte tecnologie che avrebbero dovuto rendere il sistema più veloce ;)
No, le modifiche di Vista sono molto più profonde.

Quella dell'interfaccia grafica "carina" è soltanto uno degli aspetti citati, e tra l'altro ampiamente sottovalutato vista la portata dei cambiamenti (ricordiamoci che Metro e SilverLight sono soltanto delle banali applicazioni del nuovo sottosistema grafico completamente strutturato).

ReadyDrive e ReadyBoost, poi, funzionano benissimo e accelerano anche di molto il caricamento: basta provarle.

Comunque l'elenco delle modifiche di Vista è impressionante e si tratta, oltre di una sostanziale riscrittura, di nuove funzionalità non presenti su XP. ;)

[cdimauro]

Secondo me il vero vantaggio delle piattaforme managed è la libreria unifrome e praticamente omnicomprensiva (però prova ad uscire dal seminato e la produttività crolla improvvisamente).
In C++ devi fare riferimento alle librerie specifiche ognuna con la propria interfaccia, i linguaggi managed ti forniscono una libreria con interfaccia uniforme e soprattutto già fatta.
Pensa se effettivamente il C++ non sarebbe ben più produttivo se oltre alla libreria standard avesse anche una libreria estesa equivalente come funzionalità a quella di Java o del .NET.
La produttività non dipende soltanto dalle librerie a corredo, ma anche dalle caratteristiche del linguaggio stesso, che permettono di velocizzare la stesura e/o il mantenimento del codice.

Ecco perché ormai preferisco sviluppare quasi esclusivamente in Python. :p

[tomminno]

La produttività non dipende soltanto dalle librerie a corredo, ma anche dalle caratteristiche del linguaggio stesso, che permettono di velocizzare la stesura e/o il mantenimento del codice.

Ecco perché ormai preferisco sviluppare quasi esclusivamente in Python. :p

Sarà ma con C# a me risulta veloce sviluppare codice non perchè non esplicito la delete (anche perchè poi devo sbattermi con using, finally e robetta simile), ma perchè se ho a che fare con SQLServer, MySQL, Sqlite adotto esattamente lo stesso codice, perchè c'è una interfaccia comune. In C++ devo ricorrere alle rispettive interfacce native che chiaramente sono agli antipodi e ogni volta mi devo studiare le nuove funzionalità.
In compenso se devo realizzare una comunicazione seriale con C# 1.1 ci metto molto di più che a farlo con il C++, perchè nel caso del vecchio C# devo andare a manina a wrappare sua orripilanza Win32, mentre in C++ uso wxCTB e mi ritrovo pure codice multipiattaforma. Con il 2.0 invece il tempo di sviluppo è praticamente alla pari (con leggero vantaggio per il C++ in caso di dati binari, visto che in tal caso c'è da lottare con le conversioni del C#).
Il vantaggio sta sempre nel fatto che qualcun altro ha fatto del lavoro che io evito di fare e nel caso di C# e Java questo lavoro svolto da altri è decisamente consistente.

[cdimauro]

Sull'uso delle librerie nulla da dire: è chiaro che velocizzano.

Infatti avevo scritto che la produttività dipende ANCHE dal linguaggio. ;)

[^TiGeRShArK^]

:mbe: :mbe: :mbe:
Perdonami ma.... hai letto bene a cosa serve quella libreria? Venire a dire che MPi con l'elaborazione parallela non c'entra nulla, quando la stragrande maggioranza di applicazioni parallele la usa, mi pare che sia una grossissima fesseria :D Gli algoritmi seriali genralmente sono parallelizzati proprio con quella libreria...
si che ho letto.
E spiegami cosa avrei detto di sbagliato.
Quella libreria è utilizzata per la gestione di cluster di computer, tu parlavi genericamente di software parallelizzabile, che invece è gestito tranquillamente mediante multi-threading.
Inoltre il message passing non è utilizzato solo ed esclusivamente in quel campo ma, tanto per fare un esempio che dovrebbe essere familiare un pò a tutti noi, SOAP e la OOP sono basati sul message passing.

[sottovento]

In realtà se ci metti la new come in origine il tempo di esecuzione di Java cresce esponenzialmente quello C++ no.
Prova a rimettere la new di un array di 1024 char e poi ne riparliamo.

Beh, esponenzialmente proprio no. Sul fatto che in queste condizioni C++ abbia dei vantaggi, e' innegabile.

Il trucco sta nel "tarpargli le ali" :)
Scherzi a parte: considera che gia' un semplicissimo esempio ha mostrato che ci sono dei casi in cui Java ha prestazioni superiori a C++.
Questa frase sembrava un'eresia, sembrava che sempre e comunque C++ dovesse essere superiore. Invece non e' cosi', e penso che ormai sia chiaro questo concetto.

Quando C++ e' superiore? Quando Java e' superiore?
Occorrerebbe tantissimo tempo per investigare, ma scommetto che i progettisti di Java avevano questo concetto bene in mente. Nel caso non l'avessero acquisito bene, cmq ci sta pensando la Microsoft (e' impossibile che la cosa sia sfuggita anche a loro).

Secondo me (senza poter provare, e' solo un parere), si possono costruire esempi partendo dal "tarpare le ali" (detto da un pilota .. :D ).

ESEMPIO (tutto da provare, beninteso): stai realizzando un sistema di scambio messaggi.
Nell'architettura prevedi che in caso di ricezione di un messaggio, esso sia reindirizzato ai listener che si sono registrati per averlo. E' una architettura realizzata migliaia di volte, niente di particolare.

I notri programmi, dunque, scriveranno:

MyListener listener;

telegramDispatcher.addListener (listener);


MyListener avra' quindi un metodo del tipo
(Java)

void messageGot (Telegram telegram);


(c++)

void messageGot (Telegram *telegram);


Per quanto riguarda Java, questa specifica e' piu' che sufficiente (ovviamente, sto costruendo un esempio proprio per questo :D).

Ma... per C++? Come siamo messi a livello sia di correttezza, sia di efficienza?

Se avessi scritto

void messageGot (Telegram telegram);


sarei stato sicuro che telegram e' una copia, pertanto la cosa e' inefficiente (quanto inefficiente? Arbitrariamente, lo posso rendere sufficientemente inefficiente fino a far vincere Java :D).

Ho invece scritto usando i puntatori per evitare la copia.
Si, ma... siamo sicuri che abbiamo eliminato tutti i nostri problemi?

Direi a naso che questa classe di problemi vedra' ancora vincere Java...

[sottovento]

Mi stavo divertendo a scrivere un garbage collector :asd:

:D

[cionci]

Ho invece scritto usando i puntatori per evitare la copia.
Si, ma... siamo sicuri che abbiamo eliminato tutti i nostri problemi?

Direi a naso che questa classe di problemi vedra' ancora vincere Java...
Non credo assolutamente ;)
Praticamente nel 90% dei casi i passaggi si fanno per riferimento o per puntatore...se lo fai per copia sei un masichista ;)

void messageGot (Telegram &telegram);

Prima sei andato a sfruttare una caso (tante classi piccole) in cui il C++ era svantaggiato perché deallocavi subito, tra l'altro a mano...
Con una politica di deallocazione più furba il C++ sarebbe tornato nuovamente in testa,,,

[Unrue]

si che ho letto.
E spiegami cosa avrei detto di sbagliato.
Quella libreria è utilizzata per la gestione di cluster di computer, tu parlavi genericamente di software parallelizzabile, che invece è gestito tranquillamente mediante multi-threading.
Inoltre il message passing non è utilizzato solo ed esclusivamente in quel campo ma, tanto per fare un esempio che dovrebbe essere familiare un pò a tutti noi, SOAP e la OOP sono basati sul message passing.

Ho paura che noi due abbiamo concetti diversi di "elaborazione parallela" :D

Non so, spiegami come fai con i thread Java a gestire un algoritmo parallelo che gira su 128 processori ad esempio. Se non usi una libreria apposita, come fai a mappare ogni thread su un processore?

Il veri algoritmi paralleli sono quelli nati per girare su più processori. Con il multi-threading te simuli questo comportamento, ma in realtà i programmi sotto girano sempre in maniera sequenziale se hai a disposizione un solo processore fisico.. Se ne hai più di uno già il discorso cambia e si può parlare di parallelizzazione.

[cionci]

Non so, spiegami come fai con i thread Java a gestire un algoritmo parallelo che gira su 128 processori ad esempio. Se non usi una libreria apposita, come fai a mappare ogni thread su un processore?
Imho ha ragione ^TiGeRShArK^. I thread sono per definizione uno strumento per l'elaborazione parallela. I thread vengono associati ai processori secondo l'algoritmo di schedulazione del sistema operativo ospite. Molte volte si può influire sull'algoritmo settando manualmente su quale CPU deve girare il thread.

I problema è che i thread sono fatti per le architetture a memoria condivisa...al contrario i super computer non lo sono...per questo il message passing viene in aiuto ;)

[variabilepippo]

Senza considerare che, come sottolineato da ^TiGeRShArK, il Message Passing non è utilizzato/utilizzabile soltanto per implementare sistemi di elaborazione parallela, dunque non sussiste una relazione biunivoca tra MPI ed elaborazione parallela... :rolleyes:

[Unrue]

Senza considerare che, come sottolineato da ^TiGeRShArK, il Message Passing non è utilizzato/utilizzabile soltanto per implementare sistemi di elaborazione parallela, dunque non sussiste una relazione biunivoca tra MPI ed elaborazione parallela... :rolleyes:

Non mi pare di averlo mai detto :mbe: