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

[^TiGeRShArK^]

Originariamente inviato da cionci

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

[Unrue]

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

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

[sottovento]

Originariamente inviato da cionci

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

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

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]

Originariamente inviato da ^TiGeRShArK^

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 (molto esplicativi soprattutto i dettagli )

[marco.r]

Originariamente inviato da cdimauro

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]

Originariamente inviato da marco.r

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

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

The Java Faster than C++ Original Benchmark
The Java (not really) faster than C++
'The Java Faster than C++' Benchmark Revisited
Why Java is slow[*]

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]

Originariamente inviato da variabilepippo

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

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.

Originariamente inviato da variabilepippo

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

Vero
Nel caso non lo dimostrino, puoi sempre interpretare i risultati
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.

Originariamente inviato da variabilepippo

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]

Originariamente inviato da sottovento

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]

Originariamente inviato da cionci

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? Io sono ancora al lavoro, ma tu...

[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 , 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 e sinceramente non credo possa mai succedere... Tux Rulez !

TTY

[cdimauro]

Originariamente inviato da marco.r

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

[cdimauro]

Originariamente inviato da TTYman

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]

Originariamente inviato da cdimauro

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]

Originariamente inviato da sottovento

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

Mi stavo divertendo a scrivere un garbage collector

[tomminno]

Originariamente inviato da sottovento

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

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]

Originariamente inviato da variabilepippo

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

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]

Originariamente inviato da cionci

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]

Originariamente inviato da tomminno

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.