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

[Unrue]

Originariamente inviato da cionci

Perché la comunicazione fra i thread avviene attraverso la memoria Infatti thread appartenenti allo stesso processo vedono la stessa memoria...
Ovviamente se i processori distinti sui quali girano non hanno memoria condivisa allora non possono comunicare

Ok, allora guarda gua

http://charm.cs.uiuc.edu/manuals/htm...++/manual.html

Questa è Charm++ un'altra libreria spesso usata con i supercomputers che fa un pesante uso di threads. Leggendo il manuale, almeno per adesso, non ho visto relazioni con il message passing. Allora come fanno i threads a comunicare tra loro ?

[^TiGeRShArK^]

Originariamente inviato da Unrue

Pensandoci meglio non sono mica più così sicuro che la memoria nel nodo sia condivisa. Probabilmente dipende dal supercompuer in questione. Ora però mi fai venire una curiosità: perchè i threads non possono operare con architetture a memoria distribuita?

Ogni thread va elaborato da un processore fisico/logico...
Se fai girare thread diversi in macchine che non condividono la stessa memoria (come ad esempio ogni macchina componente il cluster) allora devi ovviamente usare dei meccanismi di comunicazioni per scambiare i dati elaborati, siano essi meccanismi di messagge passing o ad esempio work units similari a quelle del folding@home (che, sinceramente, non ho idea su cosa siano basate).
Su una macchina a memoria condivisa invece non hai alcuna necessità di scambiare i dati dato che i thread hanno completamente a disposizione tutta la memoria della macchina, al massimo potranno avere prestazioni un pò inferiori nel caso in cui i dati da elaborare si trovino nei moduli di memoria direttamente connessi agli altri processori, e quindi le latenze sarebbero + elevate (ovviamente tralasciando il distinguo tra bus point-to-point, come l'HT o bus condiviso, quale il classico FSB, e la presenza di dati modificati nella cache di un processore che ancora devono essere scritti nella memoria RAM).

[Unrue]

Originariamente inviato da ^TiGeRShArK^

Su una macchina a memoria condivisa invece non hai alcuna necessità di scambiare i dati dato che i thread hanno completamente a disposizione tutta la memoria della macchina, al massimo potranno avere prestazioni un pò inferiori nel caso in cui i dati da elaborare si trovino nei moduli di memoria direttamente connessi agli altri processori, e quindi le latenze sarebbero + elevate (ovviamente tralasciando il distinguo tra bus point-to-point, come l'HT o bus condiviso, quale il classico FSB, e la presenza di dati modificati nella cache di un processore che ancora devono essere scritti nella memoria RAM).

Okk, mi torna

[sottovento]

Originariamente inviato da cionci

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

Qui ti voglio!
Specificata cosi', ogni programmatore Java sa gia quel che fare, e sa che telegram e' valido per ogni tipo di elaborazione che gli salta in mente.

Ma... e' lo stesso per il programmatore C++? Assolutamente no!
Telegram potrebbe essere una variabile locale, nel metodo di chiamata del dispatcher, giusto?

Come fai a saperlo? Se non te lo dice qualcuno, NON LO PUOI SAPERE.

A questo punto, aggiungo un tassello: ho ricevuto questo telegramma e lo devo, ovviamente, elaborare.
L'elaborazione e' affidata ad un altro thread, per motivi di efficienza. Devo quindi fare una push dell'oggetto in una coda, il thread lo prelevera' e lo elaborera'.
Sei costretto, in C++, a fare una copia!
Altrimenti, potrebbe essere che sei efficiente ma, sorry, vai in crash

Java ovviamente non fara' alcuna copia, tirera' dritto e saremo tutti sicuri che funziona correttamente. In C++ non potrai essere sicuro, ed avrai anche paura di generare dei leak!

[cionci]

Originariamente inviato da sottovento

Qui ti voglio!
Specificata cosi', ogni programmatore Java sa gia quel che fare, e sa che telegram e' valido per ogni tipo di elaborazione che gli salta in mente.

Ma... e' lo stesso per il programmatore C++? Assolutamente no!
Telegram potrebbe essere una variabile locale, nel metodo di chiamata del dispatcher, giusto?

Come fai a saperlo? Se non te lo dice qualcuno, NON LO PUOI SAPERE.

Non ho capito Fammi un'esempio...

Originariamente inviato da sottovento

A questo punto, aggiungo un tassello: ho ricevuto questo telegramma e lo devo, ovviamente, elaborare.
L'elaborazione e' affidata ad un altro thread, per motivi di efficienza. Devo quindi fare una push dell'oggetto in una coda, il thread lo prelevera' e lo elaborera'.
Sei costretto, in C++, a fare una copia!
Altrimenti, potrebbe essere che sei efficiente ma, sorry, vai in crash

Java ovviamente non fara' alcuna copia, tirera' dritto e saremo tutti sicuri che funziona correttamente. In C++ non potrai essere sicuro, ed avrai anche paura di generare dei leak!

Certo...ma questo dovrebbe giustificare prestazioni migliori da parte di Java ?
Comunque stai ricadendo nuovamente sul garbage collector...se io uso un garbage collector in C++ posso copiare quanti riferimenti voglio

[sottovento]

Originariamente inviato da cionci

Non ho capito Fammi un'esempio...

In generale, quando si implementano queste architetture in C++ (beh, sono delle callback) i metodi sono del tipo:

void messageGot (Telegram *telegram);

oppure, come hai scritto:

void messageGot (Telegram &telegram);

Domanda: qual e' la durata della vita di questo oggetto?
Questo oggetto e' stato allocato per me: lo devo deallocare?
Se non lo devo deallocare, chi lo dealloca?
L'oggetto e' ancora valido al termine della MIA esecuzione? In pratica, come ho scritto nell'esempio che seguiva, posso scrivere:
coda.push (telegram)
oppure e' meglio infilarci una copia?

Originariamente inviato da cionci

Certo...ma questo dovrebbe giustificare prestazioni migliori da parte di Java ?
Comunque stai ricadendo nuovamente sul garbage collector...se io uso un garbage collector in C++ posso copiare quanti riferimenti voglio

Certo, e' ovvio che vado ad insistere proprio li', perche' e' quello che puo' fare la differenza, e la puo' fare senza che io ne sappia niente.
Esistono del garbage collector per C++ ma sono limitati, poiche' in C++ esiste un'algebra dei puntatori. Cmq se ci metti un garbage collector, allora siamo nel gruppo dei linguaggi "managed"

[OT]Cionci: se pubblico un OT mi censuri? Certe volte ci sono notizie che vanno condivise [/OT]

[cionci]

Originariamente inviato da sottovento

In generale, quando si implementano queste architetture in C++ (beh, sono delle callback) i metodi sono del tipo:

void messageGot (Telegram *telegram);

oppure, come hai scritto:

void messageGot (Telegram &telegram);

Domanda: qual e' la durata della vita di questo oggetto?
Questo oggetto e' stato allocato per me: lo devo deallocare?
Se non lo devo deallocare, chi lo dealloca?
L'oggetto e' ancora valido al termine della MIA esecuzione? In pratica, come ho scritto nell'esempio che seguiva, posso scrivere:
coda.push (telegram)
oppure e' meglio infilarci una copia?

In generale l'oggetto passato per riferimento non lo deve deallocare nessuno...sicuramente non dentro messageGot...
Con il puntatore dipende dall'architettura che scegli di implementare.

Certo, e' ovvio che vado ad insistere proprio li', perche' e' quello che puo' fare la differenza, e la puo' fare senza che io ne sappia niente.
Esistono del garbage collector per C++ ma sono limitati, poiche' in C++ esiste un'algebra dei puntatori. Cmq se ci metti un garbage collector, allora siamo nel gruppo dei linguaggi "managed"

No, è sempre C++...se il Garbage Collector si può implementare in C++ perché diventerebbe Managed ?

[OT]Cionci: se pubblico un OT mi censuri? Certe volte ci sono notizie che vanno condivise [/OT]

Non credo

[tomminno]

Originariamente inviato da sottovento

In generale, quando si implementano queste architetture in C++ (beh, sono delle callback) i metodi sono del tipo:

void messageGot (Telegram *telegram);

oppure, come hai scritto:

void messageGot (Telegram &telegram);

Domanda: qual e' la durata della vita di questo oggetto?

Sicuramente almeno fino all'uscita di messageGot.
Se vuoi usarlo fuori dal metodo devi farne una copia in una variabile locale.

Cosa che in realtà dovrebbe essere bene fare altrimenti qualcuno dall'esterno della classe potrebbe modificare il contenuto di una variabile magari privata.
Sai che bell'incapsulamento.

Questo oggetto e' stato allocato per me: lo devo deallocare?
Se non lo devo deallocare, chi lo dealloca?

Essendo un riferimento non deve nemmeno passarti per la mente di deallocarlo

L'oggetto e' ancora valido al termine della MIA esecuzione? In pratica, come ho scritto nell'esempio che seguiva, posso scrivere:
coda.push (telegram)
oppure e' meglio infilarci una copia?

generalmente è meglio mettere puntatori nei contenitori STL.
Con il codice:

coda.push (telegram);

metti nel contenitore una copia dell'oggetto telegram.

Certo, e' ovvio che vado ad insistere proprio li', perche' e' quello che puo' fare la differenza, e la puo' fare senza che io ne sappia niente.
Esistono del garbage collector per C++ ma sono limitati, poiche' in C++ esiste un'algebra dei puntatori.

"Che cavolo stai dicendo Willy?"
I puntatori hanno tutti la stessa dimensione 32 o 64 bit a seconda dell'architettura, l'unica eccezione è per i puntatori a metodo che a seconda del compilatore possono arrivare ad occupare anche a 20 byte.

[tomminno]

Originariamente inviato da cionci

In generale l'oggetto passato per riferimento non lo deve deallocare nessuno...sicuramente non dentro messageGot...

Un riferimento dovrebbe essere deallocato esclusivamente dal compilatore.
Penso che non ci sia cosa peggiore in C++ che passare il riferimento di qualcosa allocato dinamicamente.
Quello si che può portare ad errori a runtime difficilmente comprensibili.

[cionci]

Originariamente inviato da tomminno

Un riferimento dovrebbe essere deallocato esclusivamente dal compilatore.
Penso che non ci sia cosa peggiore in C++ che passare il riferimento di qualcosa allocato dinamicamente.
Quello si che può portare ad errori a runtime difficilmente comprensibili.

Chiaro...ma volevo sottolineare che c'è la possibilità di farlo Infatti ho scritto che generalmente non lo deve deallocare nessuno...

[marco.r]

Originariamente inviato da cionci

No, è sempre C++...se il Garbage Collector si può implementare in C++ perché diventerebbe Managed ?

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 ?

[marco.r]

Originariamente inviato da tomminno

Un riferimento dovrebbe essere deallocato esclusivamente dal compilatore.
Penso che non ci sia cosa peggiore in C++ che passare il riferimento di qualcosa allocato dinamicamente.
Quello si che può portare ad errori a runtime difficilmente comprensibili.

Perche' ? I riferimenti rendono piu' chiara l'ownership dell'oggetto che deve essere allocato e (in generale) deallocato dal chiamante.
Ovvio che se vado a prendermi i puntatori di tali oggetti spesso vuol dire che sono in cerca di rogne...

[sottovento]

Originariamente inviato da cionci

In generale l'oggetto passato per riferimento non lo deve deallocare nessuno...sicuramente non dentro messageGot...
Con il puntatore dipende dall'architettura che scegli di implementare.

Si, il puntatore probabilmente viene deallocato alla fine delle chiamate alle callback. Non hai grandi scelte, in una architettura simile (la piu' diffusa).
Ergo: dovrai copiare i tuoi dati per evitare che ti spariscano da sotto il naso. No other chances!

Originariamente inviato da cionci

No, è sempre C++...se il Garbage Collector si può implementare in C++ perché diventerebbe Managed ?

Perche' ero convinto che Managed si riferisse al fatto che qualcuno fa il management della memoria per me. Se non e' cosi', allora non ho proprio la minima idea di cosa sia Managed

Originariamente inviato da cionci

Non credo

Ti riferisci al fatto che non mi censuri o che certe notizie non vadano condivise?

[sottovento]

Originariamente inviato da tomminno

Sicuramente almeno fino all'uscita di messageGot.
Se vuoi usarlo fuori dal metodo devi farne una copia in una variabile locale.

Esatto. E' proprio sulla copia che sto insistendo

Originariamente inviato da tomminno

Cosa che in realtà dovrebbe essere bene fare altrimenti qualcuno dall'esterno della classe potrebbe modificare il contenuto di una variabile magari privata.
Sai che bell'incapsulamento.



Essendo un riferimento non deve nemmeno passarti per la mente di deallocarlo

Perfetto! Ma... se e' un puntatore? Ne fai la copia comunque, no?

Originariamente inviato da tomminno

generalmente è meglio mettere puntatori nei contenitori STL.
Con il codice:

coda.push (telegram);

metti nel contenitore una copia dell'oggetto telegram.

Beh, diciamo che ci siamo capiti

Originariamente inviato da tomminno

"Che cavolo stai dicendo Willy?"
I puntatori hanno tutti la stessa dimensione 32 o 64 bit a seconda dell'architettura, l'unica eccezione è per i puntatori a metodo che a seconda del compilatore possono arrivare ad occupare anche a 20 byte.

Il cavolo che sto dicendo e' che i puntatori, in C++ hanno operazioni non solo di assegnamento ma anche di somma, sottrazione, ...
Queste operazioni non ti permetteranno ti tener conto di tutti i puntatori che fanno riferimento allo stesso oggetto, in modo da deallocarlo automaticamente quando nessuno lo punta piu'. (i famosi "smart pointer" che usi quando programmi usando COM).
E' un problema ben noto...

[marco.r]

Originariamente inviato da cdimauro

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/showpo...&postcount=152

Ok, quando leggo "stesso programma" io capisco anche medesima implementazione , questione di capirsi.
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.
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.

[sottovento]

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 ?

Mi associo. Credevo anch'io che si riferisse solo al fatto che qualcuno si prende cura della mia memoria, ma ora non sono piu' sicuro di nulla.

[sottovento]

Originariamente inviato da marco.r

Ok, quando leggo "stesso programma" io capisco anche medesima implementazione , questione di capirsi.
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.
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.

Fantastico! Ovviamente hai [hanno] ragione.

[marco.r]

Originariamente inviato da sottovento

Perfetto! Ma... se e' un puntatore? Ne fai la copia comunque, no?

Dipende che policy hai stabilito per la gestione della memoria.
Se ci si gestisce la memoria da se' bisogna farlo con criterio, per cui quando chiami quel metodo dovresti gia' sapere se la proprieta' di quella memoria e' del chiamato, del chiamante e in tal caso se per una quantita' di tempo sufficiente a garantirne l'uso da parte del chiamato. Ovvio che se ogni metodo fa caso a parte si diventa matti...

[sottovento]

Originariamente inviato da marco.r

Dipende che policy hai stabilito per la gestione della memoria.
Se ci si gestisce la memoria da se' bisogna farlo con criterio, per cui quando chiami quel metodo dovresti gia' sapere se la proprieta' di quella memoria e' del chiamato, del chiamante e in tal caso se per una quantita' di tempo sufficiente a garantirne l'uso da parte del chiamato. Ovvio che se ogni metodo fa caso a parte si diventa matti...

Forse non ci siamo capiti. Quello che volevo dire e' che:
1 - c'e' un "dispatcher" che riceve dei telegrammi da dove vuole lui;
2 - se qualcuno ne vuole copia, implementa una interfaccia (o una funzione virtuale in C++) e si registra. Quando un nuovo telegramma arriva, viene automaticamente chiamata la messageGot() (e' sempre un esempio);
3 - la messageGot() deve elaborare il telegramma. Supponendo che debba fare diverse operazioni, si sia deciso di affidare le medesime ad un altro thread.

Quindi la messageGot() sara' piu' o meno cosi':

void messageGot (Telegram *telegram)  oppure
void messageGot (Telegram &telegram)
{
  // Metti in coda per elaborare
  taskQueue.push (telegram);
}

E' una soluzione ampiamente usata.

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.

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.

Scusami se non ho capito bene quello che intendevi dire.
Cmq quello che voglio andare a sfatare e' l'assunto:
- compilato = efficiente
- interpretato = inefficiente

Non ne sono per niente convinto, come non sono convinto dell'equazione
- C++ = efficiente
- Java = inefficiente

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

[tomminno]

Originariamente inviato da sottovento

Esatto. E' proprio sulla copia che sto insistendo

La copia locale è sempre buona cosa, se devi riusare la variabile in altre parti della classe. Perchè significa che nessuno dall'esterno possa modificarne il contenuto a tua insaputa. Se condividi il riferimento con altre classi questo presupposto cade.

Perfetto! Ma... se e' un puntatore? Ne fai la copia comunque, no?

Per questo motivo è meglio passare il riferimento.
Se qualcuno ti passa un puntatore e te lo copi solo come puntatore e chi te lo ha passato decide di deallocarlo sei nei guai.
Stesso discorso per il chiamante che potrebbe vedersi deallocato il puntatore dal chiamato a sua insaputa.
Generalmente nelle classi si include il costruttore di copia che prende in ingresso un riferimento const, io almeno non ho mai scritto la versione di copia per puntatori, magari sono poco previdente

Il cavolo che sto dicendo e' che i puntatori, in C++ hanno operazioni non solo di assegnamento ma anche di somma, sottrazione, ...
Queste operazioni non ti permetteranno ti tener conto di tutti i puntatori che fanno riferimento allo stesso oggetto, in modo da deallocarlo automaticamente quando nessuno lo punta piu'. (i famosi "smart pointer" che usi quando programmi usando COM).
E' un problema ben noto...

Sarà anche un problema ben noto, ma auto_ptr funziona da più di 10 anni e ci sono gli smart pointer di boost (e del nuovo standard) che non hanno di questi problemi.
Mai usato COM potrebbe essere un problema suo