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

[tomminno]

Originariamente inviato da cdimauro

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.

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

Originariamente inviato da Unrue

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

Originariamente inviato da tomminno

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

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

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

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]

Originariamente inviato da cionci

Mi stavo divertendo a scrivere un garbage collector

[cionci]

Originariamente inviato da sottovento

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]

Originariamente inviato da ^TiGeRShArK^

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"

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]

Originariamente inviato da Unrue

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

[Unrue]

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

Non mi pare di averlo mai detto

[cionci]

Originariamente inviato da Unrue

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

Anche per il message passing puoi fare lo stesso discorso...

[Unrue]

Originariamente inviato da cionci

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

MM, questo non mi torna molto. MPi di per sè crea e gestisce un thread che vive su ogni processore. Addirittura, se usi un'altra libreria parallela che è Charm++, usi i cosiddetti "chare", che altro non sono che thread sui vari processori, ed in quel caso puoi avenre anche diversi su di uno

[variabilepippo]

Non mi pare di averlo mai detto

All'affermazione corretta di TigerShark:

E che c'azzecca il Message Passing con la gestione di + processori?
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

hai risposto con

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 Gli algoritmi seriali genralmente sono parallelizzati proprio con quella libreria...

MPI è un'interfaccia utilizzabile *ANCHE* per implementare sistemi di calcolo distribuito (un concetto diverso rispetto ad "elaborazione parallela"), ma non esiste un nesso biunivoco tra "elaborazione parallela" e MPI (come ribadito da più fonti). Infatti il message passing viene impiegato anche nei microkernel, nell'IPC ed in tanti altri casi DIVERSI dal calcolo distribuito.

[Unrue]

Dire che una libreria è usata principalmente per quello scopo è bel diverso dal dire che c'è una relazione biunivoca tra la libreria e lo scopo stesso.. Il che equivarrebbe a dire che la libreria in questione è stata costruita SOLO per quello. Cosa che non ho mai affermato. Mi pare che si stia cercando il cosiddetto pelo nell'uovo..

E' poi che MPI sia usato principalmente per il calcolo distribuito è un dato di fatto, non vedo cosa tu abbia da obbiettare..

[cionci]

Originariamente inviato da Unrue

MM, questo non mi torna molto. MPi di per sè crea e gestisce un thread che vive su ogni processore.

Certo un thread locale a quel processore, ma che non può comunicare con un altro thread locale ad un altro processore perché l'architettura dei supercomputer non è a memoria condivisa

[cionci]

Originariamente inviato da variabilepippo

ed in tanti altri casi DIVERSI dal calcolo distribuito.

Sì, infatti viene usato per implementare l'IPC nei sistemi operativi distribuiti...oppure come primitiva di comunicazione nei cluster.

[Unrue]

Originariamente inviato da cionci

Certo un thread locale a quel processore, ma che non può comunicare con un altro thread locale ad un altro processore perché l'architettura dei supercomputer non è a memoria condivisa

Continua a non tornarmi. In un singolo nodo di un supercomputers, possono esserci ad esempio 8 processori. Ebbene, la memoria globale del supercomputer non è condivisa ok, ma quella del nodo si. Quindi in teoria potrei usare thread per fare comunicazioni intranodo. Forse il message passing si attiva quando è richiesta la comunicazione tra nodi diversi?

[cionci]

Originariamente inviato da Unrue

Continua a non tornarmi. In un singolo nodo di un supercomputers, possono esserci ad esempio 8 processori.

Non è detto, i processori vettoriali operano praticamente sempre su memoria non condivisa che io sappia.
Se sono processori x86 o Risc tradizionali allora sì.

Originariamente inviato da Unrue

Ebbene, la memoria globale del supercomputer non è condivisa ok, ma quella del nodo si. Quindi in teoria potrei usare thread per fare comunicazioni intranodo. Forse il message passing si attiva quando è richiesta la comunicazione tra nodi diversi?

Se la memoria del nodo è condivisa potresti usarla per la comunicazione fra i thread, ma probabilmente non si usa per mantenere una certa uniformità in modo da non dover trattare diversamente thread locali tra loro e thread remoti.

[Unrue]

Originariamente inviato da cionci

Non è detto, i processori vettoriali operano praticamente sempre su memoria non condivisa che io sappia.
Se sono processori x86 o Risc tradizionali allora sì.

Se la memoria del nodo è condivisa potresti usarla per la comunicazione fra i thread, ma probabilmente non si usa per mantenere una certa uniformità in modo da non dover trattare diversamente thread locali tra loro e thread remoti.

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?

[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