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

[tomminno]

Originariamente inviato da sottovento

Quello che dicevo e' che C++ non puo' fare alcuna assunzione sulla validita' della variabile FUORI dalla messageGot (), pertanto in coda non avra' altra scelta che mettere un COPIA dell'oggetto, o un puntatore alla COPIA dell'oggetto, altrimenti il rischio e' quello di processare della fuffa.

Java non ha questo problema.

Ma se non ne fai una copia locale qualcuno dall'esterno potrebbe modificare il contenuto del messaggio che hai messo in coda perchè ha un riferimento all'oggetto.
A me hanno sempre detto che è un comportamento da evitare, una classe dovrebbe avere il pieno controllo delle variabili che utilizza, se vuoi modificare una variabile devi passare per i metodi set, ma se dall'esterno qualcuno tiene il riferimento all'oggetto può modificarlo senza passare dal set.

Usi la copia o violi l'incapsulamento?

Per quanto riguarda processare fuffa, il C++ risolve utilizzando auto_ptr. Se qualcuno ti passa un auto_ptr sai per certo che ti lascia l'ownership del puntatore, altrimenti devi supporre che non lo deallocherai salvo specifiche opposte (generalmente questi problemi nascono interfacciandosi con librerie in C).

Questo e' sufficiente a far pendere l'ago delle prestazioni dalla parte di Java? Well, dipende da quanto e' pesante le copie che C++ e' obbligato a fare mentre Java puo' evitare.

Ripeto con gli smart pointer queste copie in più si possono evitare già da subito senza attendere gli rvalue reference e la move semantics del futuro standard (che promette di risolvere la questione definitivamente).

Sono convinto che ci sono dei casi (e non proprio particolari) in cui queste equazioni si invertono. E sono convinto che in futuro le cose cambieranno ancora...

Io aspetto di provare il nuovo C++

[cionci]

Scusate...ma Java come si comporta in un caso del genere...ora mi create confusione
Io passo per riferimento la classe Telegram, ma se io mi devo prendere la stringa e modificarla devo assolutamente farmi una copia...sia per come è definita una string in Java, sia per evitare qualcun altro mi modifichi l'oggetto dall'esterno...no ?

Poi il fatto che si facciano queste copie in più non significa assolutamente che Java sia più lento del C++...abbiamo visto come anche su una cosa banale (il bubblesort che ho postato qualche pagina fa) il C++ possa essere anche più veloce di Java di 4-5 volte...credo che questo vantaggio possa far entrare ampiamente qualche copia in più fatta nel passaggio dei parametri e nella gestione delle classi...

[sottovento]

Originariamente inviato da cionci

Scusate...ma Java come si comporta in un caso del genere...ora mi create confusione
Io passo per riferimento la classe Telegram, ma se io mi devo prendere la stringa e modificarla devo assolutamente farmi una copia...sia per come è definita una string in Java, sia per evitare qualcuno altro mi modifichi l'oggetto dall'esterno...no ?

In Java risolveresti (elegantemente) il problema allocando un nuovo oggetto ogni volta che ricevi un telegramma. Semplice, elegante, efficiente e non viola l'incapsulamento.
Purtroppo non e' cosi' facile in C++, occorre sempre trovare delle "scorciatoie" che non sempre funzionano, e decidono di non funzionare alle 3 del mattino, costringendo sottovento ad alzarsi, spostare la famiglia che gli dorme sopra, e correre per 30 miglia a risolvere il problema

auto_ptr e compagnia bella non mi sembra si possano applicare in questi casi, quanto meno io non ce lo vedo proprio...

[cionci]

Originariamente inviato da sottovento

In Java risolveresti (elegantemente) il problema allocando un nuovo oggetto ogni volta che ricevi un telegramma. Semplice, elegante, efficiente e non viola l'incapsulamento.
Purtroppo non e' cosi' facile in C++, occorre sempre trovare delle "scorciatoie" che non sempre funzionano, e decidono di non funzionare alle 3 del mattino, costringendo sottovento ad alzarsi, spostare la famiglia che gli dorme sopra, e correre per 30 miglia a risolvere il problema

auto_ptr e compagnia bella non mi sembra si possano applicare in questi casi, quanto meno io non ce lo vedo proprio...

Se in Java devi quindi creare un nuovo oggetto per ogni copia del messaggio che consegni ad un destinatario...allora sei nella stessa situazione della copia
In C++ ti mantieni un solo messaggio locale al dispatcher e lo deallochi o automaticamente (variabile locale o auto_ptr) o con la delete quando lo hai consegnato a tutti i client registrati.

Sei esattamente nella stessa situazione...ne una copia in più ne una in meno

[marco.r]

Originariamente inviato da sottovento

Quello che dicevo e' che C++ non puo' fare alcuna assunzione sulla validita' della variabile FUORI dalla messageGot (), pertanto in coda non avra' altra scelta che mettere un COPIA dell'oggetto, o un puntatore alla COPIA dell'oggetto, altrimenti il rischio e' quello di processare della fuffa.

Quel che stavo dicendo io e' che se il programma e' stato strutturato in un certo modo le assunzioni le puoi fare. E se non puoi ci sono gli smart_pointer.
Questo non toglie che la copia possa essere una soluzione piu' comoda, ma non e' l'unica.

come non sono convinto dell'equazione
- C++ = efficiente
- Java = inefficiente

Non ne sono convinto neanche io, ma adesso stiamo parlando di altro

[tomminno]

Originariamente inviato da sottovento

In Java risolveresti (elegantemente) il problema allocando un nuovo oggetto ogni volta che ricevi un telegramma. Semplice, elegante, efficiente e non viola l'incapsulamento.
Purtroppo non e' cosi' facile in C++, occorre sempre trovare delle "scorciatoie" che non sempre funzionano, e decidono di non funzionare alle 3 del mattino, costringendo sottovento ad alzarsi, spostare la famiglia che gli dorme sopra, e correre per 30 miglia a risolvere il problema

auto_ptr e compagnia bella non mi sembra si possano applicare in questi casi, quanto meno io non ce lo vedo proprio...

Ricevi un telegramma e allochi un nuovo telegramma copia del precedente.
Questo non significa per caso fare una copia dell'oggetto?

[marco.r]

Originariamente inviato da tomminno

La copia locale è sempre buona cosa, se devi riusare la variabile in altre parti della classe.

Diciamo che e' cattiva cosa cosa riutilizzare la variabile per altre cose...
non farlo e ti risparmi possibili rogne.

[tomminno]

Originariamente inviato da marco.r

Diciamo che e' cattiva cosa cosa riutilizzare la variabile per altre cose...
non farlo e ti risparmi possibili rogne.

Se sei in un metodo set cavolo vorrai riusarla quella variabile o no?

[cdimauro]

Originariamente inviato da marco.r

E' una questione che mi incuriosisce da un po' e non ho mai avuto una risposta chiara: cosa si intende per linguaggio Managed ? Mi risulta che il termine sia stato coniato da Microsoft per indicare quei linguaggi che girano all'interno della framework .NET, ma vedo che e' spesso usato in contesti piu' generali. Ma allora che caratteristiche deve avere ? Avere un GC ? (Ma allora anche il C++ potrebbe esserlo), girare in una VM (quindi sarebbe da escludere Java compilato con gcj) ? Altro ?

A parte l'esplicito riferimento alla CLR e all'IL, mi ritrovo esattamente in questa definizione: http://blogs.msdn.com/brada/archive/.../09/48925.aspx

Quindi ci rientrano linguaggi come Java, C#, Python, Ruby, ecc., dove l'esecuzione avviene attraverso una VM che è dotata ANCHE di GC (nei casi in cui serva) e che "diriga" l'esecuzione del codice aggiungendo eventuali controlli necessari per impedire l'esecuzione di azioni dannose e/o non previste.

Originariamente inviato da marco.r

Ok, quando leggo "stesso programma" io capisco anche medesima implementazione , questione di capirsi.

Certamente: meglio rimuovere le ambiguità.

In questo caso allora non ha molto senso star li' a destreggiarsi in loop ciclopici... decidiamo un task un po' piu' complesso e vediamo come va a finire C++ vs. Java vs. resto del mondo.

Potremmo provare a convertire Diamond Crash in C++ e vedere come viene, come suggeriva Marco.

Sempre che abbia senso. Il web e' pieno di confronti simili.
Che nella maggior parte dei casi hanno poco senso visto che spesso dettano anche come debbano essere scritti i programmi (vedi ad esempio il famoso shootout) e allora tanto vale.

Questi confronti vanno presi sempre con le pinze.

Possono essere un'utile "metrica" per vedere il comportamento di specifiche piattaforme su specifici pezzi di codice, ma giusto per farsi un'idea.

Non conosco nello specifico i "dettami" che si devono seguire per implementare i programmi, ma leggendo quella pagina non mi pare che vi siano imposizioni su come debba essere scritto il codice.
A cosa ti riferisci di preciso?

[RaouL_BennetH]

Originariamente inviato da cdimauro

Potremmo provare a convertire Diamond Crash in C++ e vedere come viene, come suggeriva Marco.

Perdonami Cesare!!

Ma sottintendi che riscrivendo Diamond in C++ si tramuterà in un cicloopico Crash ?

Scusate l'ot

[fek]

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

Ho creato un mostro. E francamente un po' mi dispiace pure

[fek]

Originariamente inviato da Tommo

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

Spiegami come si fa! Spiegami come si fa! Diventiamo ricchissimi!

[sottovento]

Originariamente inviato da tomminno

Ricevi un telegramma e allochi un nuovo telegramma copia del precedente.
Questo non significa per caso fare una copia dell'oggetto?

No dai, non e' una copia del precedente. Ricevo un telegramma (potrebbe essere una sequenza di byte) ed in entrambi i linguaggi devo creare un nuovo oggetto.
In generale il costruttore si prendera' in carico delle eventuali decodifiche (che devono essere fatte una sola volta, in partenza).

[cdimauro]

Originariamente inviato da RaouL_BennetH

Perdonami Cesare!!

Ma sottintendi che riscrivendo Diamond in C++ si tramuterà in un cicloopico Crash ?

Scusate l'ot

ARGH!!! Mica è la prima volta che confondo delle vocali...

Figurati che una volta ho pronunciato "drag en drop" (proprio così) e i miei amici che erano vicini si sono ribaltati dalle risate.

[pietro84]

Originariamente inviato da 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++?

io mi sono occupato di visione artificiale. secondo me il linguaggio più adatto è ANSI C .
lascia stare i linguaggi ad oggetti.

[tomminno]

Originariamente inviato da pietro84

io mi sono occupato di visione artificiale. secondo me il linguaggio più adatto è ANSI C .
lascia stare i linguaggi ad oggetti.

Realizzare una GUI in puro C secondo me è da masochisti.
Mai avuto a che fare con le Win32 o le GTK?
Evidentemente no, altrimenti non avresti fatto un'affermazione simile.

[marco.r]

Originariamente inviato da tomminno

Se sei in un metodo set cavolo vorrai riusarla quella variabile o no?

Usare e riusare sono due cose distinte (e cosi' ho esaurito il mio bonus settimanale di pedanteria ).
Se tu invece intendevi usare la variabile (per lo scopo per il quale e' stato chiamato il metodo) il discorso e' un po' diverso, ma per certi versi abbastanza semplice. Tenersi una copia di una istanza o un puntatore/riferimento dovrebbe dipendere semplicemente dal fatto che dal punto di vista logico l'oggetto a cui ci si riferisce sia lo stesso o un altro.
Voglio che chi elabora la coda possa modificare l'oggetto che mi e' stato passato o, al contrario, vedere le modifiche che ha effettuato qualcun altro ? Mi tengo il puntatore.
Voglio che il risultato dell'elaborazione sia un qualcosa di distinto dal suo input ? Me lo copio e poi lo modifico.
E' comunque una cosa che va al di la' del linguaggio, e che quindi vale tanto in C++ quanto in Java. A dire il vero in C++ ho un'arma in piu': se il chiamante vuole essere sicuro che l'oggetto non venga modificato posso passarlo come const, ed evitare che il chiamato adotti la prima soluzione.

[tomminno]

Originariamente inviato da marco.r

Usare e riusare sono due cose distinte (e cosi' ho esaurito il mio bonus settimanale di pedanteria ).
Se tu invece intendevi usare la variabile (per lo scopo per il quale e' stato chiamato il metodo) il discorso e' un po' diverso, ma per certi versi abbastanza semplice. Tenersi una copia di una istanza o un puntatore/riferimento dovrebbe dipendere semplicemente dal fatto che dal punto di vista logico l'oggetto a cui ci si riferisce sia lo stesso o un altro.

Il mio discorso si concretizzava in particolare sui metodi set, visto che qualcuno ti passa un riferimento esterno, controlli se il riferimento contiene valori accettabili e infine lo copi su una variabile della classe per poterlo riusare in altre parti della classe stessa, ovunque sia necessaria. Era questo il senso del mio "riusare", non certo nel senso di riutilizzo di variabili per scopi differenti.

Voglio che chi elabora la coda possa modificare l'oggetto che mi e' stato passato o, al contrario, vedere le modifiche che ha effettuato qualcun altro ? Mi tengo il puntatore.

Il C++ in questo non aiuta visto che i riferimenti devono sempre esistere, una variabile di classe che sia un riferimento deve essere inizializzata nella lista di inizializzazione e quindi in generale di scarsa utilità.
Il C++ in questi casi obbliga ad usare i puntatori.

A dire il vero in C++ ho un'arma in piu': se il chiamante vuole essere sicuro che l'oggetto non venga modificato posso passarlo come const, ed evitare che il chiamato adotti la prima soluzione.

const_cast e passa la paura.
Purtroppo il C++ non garantisce niente, in quanto potresti volutamente togliere il const a qualunque cosa.
Infatti a causa di questo in linea teorica sarebbe sempre bene passare copie di variabili locali.
Io sinceramente me ne sono sempre fregato di potenziali terroristi del codice e restituisco sempre riferimenti const.

[a2000.1]

Originariamente inviato da tomminno

Realizzare una GUI in puro C secondo me è da masochisti.
Mai avuto a che fare con le Win32 o le GTK?
Evidentemente no, altrimenti non avresti fatto un'affermazione simile.

[marco.r]

Originariamente inviato da tomminno

Il mio discorso si concretizzava in particolare sui metodi set, visto che qualcuno ti passa un riferimento esterno, controlli se il riferimento contiene valori accettabili e infine lo copi su una variabile della classe per poterlo riusare in altre parti della classe stessa, ovunque sia necessaria. Era questo il senso del mio "riusare", non certo nel senso di riutilizzo di variabili per scopi differenti.

Certo se vuoi usarlo cosi' devi fai la copia, ma in che modo questo e' differente in C++ da Java (ricordo che il discorso iniziale era che il C++ obbligherebbe a fare piu' copie) ?

Il C++ in questo non aiuta visto che i riferimenti devono sempre esistere, una variabile di classe che sia un riferimento deve essere inizializzata nella lista di inizializzazione e quindi in generale di scarsa utilità.
Il C++ in questi casi obbliga ad usare i puntatori.

Perdonami, ma non ho capito cosa intendi dire con questo...

const_cast e passa la paura.
Purtroppo il C++ non garantisce niente, in quanto potresti volutamente togliere il const a qualunque cosa.
Infatti a causa di questo in linea teorica sarebbe sempre bene passare copie di variabili locali.
Io sinceramente me ne sono sempre fregato di potenziali terroristi del codice e restituisco sempre riferimenti const.

E' difficile che una persona aggiunga un const_cast per sbaglio, per cui si evitano tutti i casi in cui si va a modificare involontariamente un oggetto.
Era questo a cui mi riferivo, e non e' una cosa da poco. Il problema di chi opera con malizia e' tutto un altro paio di maniche, ma anche piu' circoscritto, visto che di solito e' legato a chi scrive codice che deve essere utilizzato da terze parti (ad esempio una libreria).