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

[marco.r]

Originariamente inviato da 71104

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

Originariamente inviato da marco.r

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

[^TiGeRShArK^]

Originariamente inviato da marco.r

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?

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

Originariamente inviato da 71104

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.

Originariamente inviato da ^TiGeRShArK^

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

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

Originariamente inviato da cdimauor

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

[Re_Kotc]

dopo essermi letto tutto il flame che avete sollevato (e dopo aver capito circa un 20% di quello che c'era scritto ) 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]

Originariamente inviato da shinya

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

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

[71104]

Originariamente inviato da 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.

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]

Originariamente inviato da ^TiGeRShArK^

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]

Originariamente inviato da 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...

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

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]

Originariamente inviato da theClimber

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]

Originariamente inviato da 71104

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
i riferimenti di Java hanno poco a che vedere coi puntatori.

[cdimauro]

Originariamente inviato da Re_Kotc

dopo essermi letto tutto il flame che avete sollevato (e dopo aver capito circa un 20% di quello che c'era scritto ) 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]

Originariamente inviato da tomminno

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]

Originariamente inviato da 71104

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]

Originariamente inviato da 71104

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

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

[tomminno]

Originariamente inviato da 71104

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.