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

[^TiGeRShArK^]

Originariamente inviato da -Slash

Non ho assolutamente nulla contro java, solo che mi vengono in mente una caterva di esempi di programmi lentissimi in questo linguaggio e che per uno o un'altro motivo devo anche usare spesso: eclipse, che da solo si prende 300 mb di ram e all'uni sui computer un pochino datati è piu che inutilizzabile, maple che sul mio computer con 1 gb di ram e core duo fatica a caricare le finestre azureus che lo trovo semplicemente inutilizzabile, e potrei dirne altri...

programmi cosi affamati di risorse per quello che fanno in c++ sinceramente non mi vengono in mente...

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.

[^TiGeRShArK^]

Originariamente inviato da -Slash

Ma io parlo di velocità del programma... Eclipse di default non ha nessun plugin, a parte quello per team syncronising se non erro

Code::Blocks di default ne ha qualcuno in piu, compreso wxsmith che è bello pesante come plugin, però come velocità non c'è proprio paragone

comunque io sinceramente mi trovo molto meglio con CB che con eclipse cdt, difatti all'uni consigliano eclipse ed io me ne frego altamente ed utilizzo CB

Ma anche no.
Elipse europa versione classic ha di default:
Eclipse CVS client, Eclipse CVS client resources, Eclipse Java Development Tools, Eclipse JDT plug-in Developer Resources, Eclipse PDE Plug.in Developer Resources, Eclipse RCP, Eclipse RCP Plug-in developer resources, Eclipse plug.in development environment.
...Sinceramente non sembrano proprio pochi.
L'unico da te citato è il client CVS x il team synchronize

[Unrue]

Originariamente inviato da cionci

Succede anche in C++, con le MFC ad esempio...e quei framework che non te lo fanno vedere hanno comunque un thread dedicato a gestire la GUI

Non lo sapevo.Comunque se hanno un thread di suo che gestisce l'interfaccia, allora vuol dire che questa cosa è gestita meglio di Java. A meno che le ultime versioni non hanno sopperito a questo.

[cionci]

Originariamente inviato da Unrue

Non lo sapevo.Comunque se hanno un thread di suo che gestisce l'interfaccia, allora vuol dire che questa cosa è gestita meglio di Java.

C'è anche chi non lo ha...come MFC...è semplicemente una scelta progettuale, non è meglio o peggio. In un linguaggio come Java in cui è facilissimo creare thread e gestirli anche io avrei usato una realizzazione come quella attuale.

[^TiGeRShArK^]

Originariamente inviato da Unrue

In campi come la simulazione su supercomputers, dove la velocità è fondamentale, Java non è presente. Ma guarda un pò ..

Questo è un caso *erstremamente* particolare e, tra l'altro, è l'UNICO caso possibile in cui sai a priori cosa girerà cul tuo processore e potrai utilizzare esattamente le ottimizzazioni migliori.
Praticamente è tutto fuorchè un caso reale
Comunque non ho capito che intendi con "applicazioni che girano su + processori".
I thread servono esattamente per quello scopo.
Ogni thread può essere instradato ad un processore fisico (o logico) e venire eseguito in parallelo.
Per quanto riguarda il riassemblamento dei rislutati ci sono una miriade di tecniche diverse.
La più semplice è la comune barriera che permetti di fissare un "checkpoint" in cui si attende l'arrivo dei risultati intermedi dei vari thread che possono quindi essere reinterpretati correttamente.
Introdotta a aprtire da java 5 insieme a tutte le altre strutture ad alto livello per la gestione dei thread.

[sottovento]

Originariamente inviato da cionci

Posta i sorgenti C++ e quelli Java...
Almeno partiamo davvero da una base comune
In ogni caso gcc 4.1.3 su Linux e Java 1.6. Il sistema è un Core 2 Duo a 3.2 Ghz.

Sorry, e' il giorno delle figure di tacchino
Cmq non mi sembra che ci possano essere grandi differenze.

Java:

import java.lang.*;
import java.util.*;

class MyTest
{
  private int a;
  private int b;

  public MyTest ()
  {
    a = 0;
    b = 0;
  }

  public MyTest (int a, int b)
  {
    this.a = a;
    this.b = b;
  }

  public void setA (int a)
  {
    this.a = a;
  }

  public void setB (int b)
  {
    this.b = b;
  }
};

class Alloc
{
	public static void main (String[] args)
	{
		allochiamo ();
	}

	static void allochiamo ()
	{
		System.out.println ("Allochiamo un po'...");
		long start = Calendar.getInstance().getTimeInMillis ();
		for (int i = 0; i < 100000000; i++)
		{
			MyTest mytest = new MyTest();
		}
		long stop = Calendar.getInstance().getTimeInMillis ();
		System.out.println ("Fine allocazione");

		System.out.println ("Time: " + ((stop - start)));
	}
}

C++:

class MyTest
{
public:
  MyTest ()
  {
    a = 0;
    b = 0;
  }

  MyTest (int a, int b)
  {
    this->a = a;
    this->b = b;
  }

  MyTest (const MyTest &myTest)
  {
    printf ("Costruttore di copia chiamato\n");
    a = myTest.a;
    b = myTest.b;
  }

  void setA (int a)
  {
    this->a = a;
  }

  void setB (int b)
  {
    this->b = b;
  }

private:
  int a;
  int b;
};

void allochiamo ()
{
  for (int i = 0; i < 100000000; i++)
  {
    MyTest *p = new MyTest;
    if (p)
      delete p;
//    printf ("%c%d", 13, i);
  }
}

int main (int argc, char *argv[])
{
  try
  {
    printf ("Alloco un po'...\n");
    time_t start = time (NULL);
    allochiamo ();
    time_t stop = time (NULL);
    printf ("Tempo di allocazione: %d\n", stop - start);
  }
  catch (...)
  {
    printf ("Exception!\n");
  }
 return 0;

[Unrue]

Originariamente inviato da ^TiGeRShArK^

Questo è un caso *erstremamente* particolare e, tra l'altro, è l'UNICO caso possibile in cui sai a priori cosa girerà cul tuo processore e potrai utilizzare esattamente le ottimizzazioni migliori.
Praticamente è tutto fuorchè un caso reale

Era solo per dire un campo in cui serve velocità pura ed appunto Java non è presente. Anche se sono casi particolari, servono per capire le potenzialità dei linguaggi.

Originariamente inviato da ^TiGeRShArK^

Comunque non ho capito che intendi con "applicazioni che girano su + processori".

Dai un'occhiata ad MPI:
http://www.mpi-forum.org/

[^TiGeRShArK^]

Originariamente inviato da Unrue

Auguri anche a te !Mi fa piacere che conosci bene la branch-prediction La tua analisi è molto interessante, è chiaro che C/C++ staticamente non possono ottimizzare i cache-miss, ma se lo fai a mano puoi è come. Ovviamente è più lungo , dispendioso e richiede una buona esperienza.

Non puoi in alcun modo farlo a mano a meno che non giri solo ed esclusivamente il tuo codice su quella macchina.

Se Java fa questo a runtime ben venga, anche se non credo, altrimenti ci sarebbero differenze prestazionali davvero notevoli. Nel' articolo Dinamo postato prima si parla di un 20% in più, non è che sia chissà cosa. Trall'altro, come si spiegano allora quei grafici postati all'inizio in cui si vede Java che è sempre sotto a C++ anche se di poco?

Non sempre.
Se noti bene ci sono uno o due test in cui java è sopra.

Inoltre cari javisti spiegatemi una cosa Come mai , spesso e volentieri quando si crea una GUi in Java, è necessario usare due thread,uno per gestire l'interfaccia, l'altro per il resto del codice, in quanto uno solo non ce la fa a gestire tutto quanto, soprattutto il refresh?Come mai in C++ questo non succede? Forse perchè l'analogo programma in C++ è un pò più leggero ? Mah.. misteri.

Hai idea di come viene implementato un sottosistema grafico event-driven quale swing?
In caso in cui la tua applicazione fa operazioni di durata che è possibile assumere atomica allora *potresti* utilizare l'Event Dispatcher Thread stesso per far girare interamente la tua applicazione.
Nella vita reale però questo non deve MAI essere fatto dato che se per caso qualcosa non va a buon fine e la tua operazione che avrebbe dovuto essere atomica risulta essere + lenta allora l'EDT rimane bloccato nel tuo metodo e non può fare quello per cui è stato progettato: dispatchare eventi.
Quindi sinceramente mi sfugge la tua obiezione.
E' proprio il risultato di una ben precisa scelta architetturale il fatto che occorre utilizzare un thread diverso dall'Event Dispatcher Thread per non fare andare in stallo l'interfaccia grafica.
Altrimenti spiegami come faresti in C++ a far girare in un unico thread la tua applicazione con metodi bloccanti e il dispatching degli eventi dell'interfaccia grafica

[shinya]

Originariamente inviato da ^TiGeRShArK^

Non puoi in alcun modo farlo a mano a meno che non giri solo ed esclusivamente il tuo codice su quella macchina.

Io non sarei cosi categorico... i link che ho postato pare proprio non esserseli fumati nessuno.

Cmq, da wikipedia (Cache-oblivious algorithm):
"In computing, a cache-oblivious algorithm is an algorithm designed to exploit the CPU cache without having the size of the cache (or the length of the cache lines, etcetera) as an explicit parameter. An optimal cache-oblivious algorithm is a cache-oblivious algorithm that exploits the cache optimally (in an asymptotic sense, ignoring constant factors). Thus, a cache oblivious algorithm is designed to perform well, without modification, on multiple machines with different cache sizes, or for a memory hierarchy with different levels of cache having different sizes."

Ci sono tutte delle ricerche su questi argomenti (che ho linkato).

[tomminno]

Originariamente inviato da Unrue

Non lo sapevo.Comunque se hanno un thread di suo che gestisce l'interfaccia, allora vuol dire che questa cosa è gestita meglio di Java. A meno che le ultime versioni non hanno sopperito a questo.

No l'utlizzo di almeno 2 thread è indispensabile.
Che io sappia nessuna interfaccia grafica di serie ha controlli thread safe (non lo sono C#,MFC,wxWidgets,QT e mi sembra anche Java). Quindi a meno di non bloccare completamente l'interfaccia in attesa dell'esecuzione di un comando (mai usato VB?) devi passare il tutto ad un altro thread che poi dovrà sincronizzarsi con quello dell'interfaccia al momento di ritornare il risultato dell'esecuzione.

[cionci]

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

[^TiGeRShArK^]

Originariamente inviato da Unrue

Controlli la cache nel senso che adatti il ciclo alla cache stessa, in modo da avere meno cache miss possibili ,non nel senso che te gli dici cosa caricare (cosa credo impossibile)

Io personalmente non ho mai fatto ottimizzazioni a livello di cache, però conosco persone che lo fanno, quindi è possibilissimo

Può essere fatto solo in determinate applicazioni in cui è presente una forte località dei dati, e, soprattutto, se in background non girano altri servizi che riempiono la cache con i loro dati...

[^TiGeRShArK^]

Originariamente inviato da tomminno

Perchè le 2 classi in totale inviano su seriale tanti pacchetti da 100 byte per un totale di circa 2MB di dati, più una serie di eventi per monitorare lo stato di invio, ma questi si scambiano degli interi.
Se in C++ facessi tante "new char [100]" dimenticandomi la delete avrei un memory leak di 2MB, invece il programma C# che già di per se parte con 25MB arriva alla fine del'operazione ad occupare 70MB che non vengono mai rilasciati.
Insomma non saranno memory leak ma 70MB per inviare 4 cavolate in seriale mi sembrano una esagerazione.

In java basta settare l'opzione Xmx ad un livello inferiore, se necessario e ci pensa il GC a liberare la memoria automaticamente non appena arriva alla soglia che gli hai settato.

[^TiGeRShArK^]

Originariamente inviato da Unrue

Quindi? Io stavo puntualizzando il fatto che la branch-prediction non c'entra nulla con il linguaggio di programmazione usato.

mi riquoto..

At another level, adaptive optimization may take advantage of local data conditions to optimize away branches and to use inline expansion to decrease context switching.

.. a sentire wikipedia sembrerebbe che le ottimizzazioni al runtime del JIT migliorino i branch nel codice.

[^TiGeRShArK^]

Originariamente inviato da Unrue

Nessuno nega che Java faccia tante ottimizzazioni carine a runtime, ma come si spiega allora che, nonostante C++ non le faccia, le prestazioni nel grafico che tu hai postato all'inizio sono pressappoco uguali ?

Forse col fatto che il memory manager di Java gestisce in maniera trasparente la memoria?
Forse col fatto che il Garbage Collector rende immediato l'uso di oggetti senza preoccuparsi di distruttori o di porre l'oggetto a null?
E' ovvio che tutti i vantaggi di java si debbano pagare in qualche misura a livello prestazionale, ma, a dispetto di quanto dite voi, nella maggioranza dei casi il gioco non vale la candela, ovvero per la misera % che potrà essere guadagnata a livello prestazionale in C++ si avrà un incremento molto sensibile dei costi di produzione.

[^TiGeRShArK^]

Originariamente inviato da Unrue

Era solo per dire un campo in cui serve velocità pura ed appunto Java non è presente. Anche se sono casi particolari, servono per capire le potenzialità dei linguaggi.



Dai un'occhiata ad MPI:
http://www.mpi-forum.org/

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

[^TiGeRShArK^]

Originariamente inviato da shinya

Io non sarei cosi categorico... i link che ho postato pare proprio non esserseli fumati nessuno.

Cmq, da wikipedia (Cache-oblivious algorithm):
"In computing, a cache-oblivious algorithm is an algorithm designed to exploit the CPU cache without having the size of the cache (or the length of the cache lines, etcetera) as an explicit parameter. An optimal cache-oblivious algorithm is a cache-oblivious algorithm that exploits the cache optimally (in an asymptotic sense, ignoring constant factors). Thus, a cache oblivious algorithm is designed to perform well, without modification, on multiple machines with different cache sizes, or for a memory hierarchy with different levels of cache having different sizes."

Ci sono tutte delle ricerche su questi argomenti (che ho linkato).

ancora non ero arrivato a quei links
Comunque quelli rappresentano appunto una categoria ben definita di problemi, e in quel caso non si ottimizza per una determinata dimensione di cache ma si suddivide (a quanto ho capito) ricorsivamente il problema in modo che si abbia una dimensione dell'operazione tanto piccola che possa entrare in cache.
Quindi, in questo modo, l'ottimizzazione vale per qualsiasi linguaggio utilizzato, dal Python al Java fino al C++... o sbaglio?

[cionci]

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.

A me 318 MB su Ubuntu
Controlla direttamente la memoria occupata...non vorrei che le DLL non te le contasse

[^TiGeRShArK^]

Originariamente inviato da cionci

A me 318 MB su Ubuntu
Controlla direttamente la memoria occupata...non vorrei che le DLL non te le contasse

ora sono con fedora 8 e non posso riavviare..
Comunque 318 MB su ubuntu mi pare tantino
84 MB dovrebbe essere la memoria RAM fisica occupata.

[cionci]

Ci sta anche che non sia il pacchetto minimale...è quello che ti installa con Synaptic...