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

[cdimauro]

Originariamente inviato da Tommo

Beh con uTorrent fai praticamente le stesse cose, ma quando sta acceso non te ne accorgi.
Per usare Azureus invece devo lasciare il pc

Li conosco entrambi, ma a livello di codice in comune non avranno praticamente niente: ecco perché non ha senso confrontarli.

[-Slash]

Originariamente inviato da Tommo

Beh con uTorrent fai praticamente le stesse cose, ma quando sta acceso non te ne accorgi.
Per usare Azureus invece devo lasciare il pc

E' esattamente quello a cui mi riferisco. Tutte e dico tutte le applicazioni java che ho provate sono lentissime.

ed in generale applicazioni in linguaggi non compilati, come python, risultano essere molto piu lente che programmi che fanno le stesse cose in linguaggi compilati. questa è la mia opinione...

per le gui mi riferivo in generale, ho letto in altri post sul forum quella cosa

[cdimauro]

"Casualmente" uso quasi sempre Python (da circa 3 anni), e a parte un po' di lentezza nel caricamento (la virtual machine deve partire per prima, e poi caricare i moduli dell'applicazione vera e propria), non mi sono mai lamentato della velocità d'esecuzione delle mie applicazioni.

[tomminno]

Originariamente inviato da cdimauro

Come avevo già detto, non puoi prendere a esempio programmi che esistono esclusivamente per un determinato linguaggio e generalizzare su quest'ultimo.

Bisogna prendere le STESSE applicazioni, che differiscono esclusivamente per il linguaggio di programmazione usato per implementarle.

Quanto alle agevolazioni di cui parli, un ambiente managed (generalmente) ti mette al riparo da segmentation fault / access violation, memory leak, doppia deallocazione della memoria, e qualche altra cosa: veri e propri incubi per chi programma con linguaggi non managed.

Diciamo che con i linguaggi managed metti un try catch e qualunque porcata tu possa fare nel mezzo sei sicuro che per lo meno finisci nel catch.
E' anche vero che ritrovarsi un'eccezione perchè fallisce la conversione del float 5,096 in uno short è qualcosa di frustrante.

In C++ sotto Windows sbattendoti con le SEH puoi trappare i segmentation fault, lo stack overflow è possibile trapparlo ma non avendo più spazio nello stack non hai modo di gestirlo.

OT: qualcuno conosce se esiste un equivalente Linux per le SEH?

La doppia deallocazione è un problema, ma generalmente sta scritto se la deallocazione è a carico del chiamante o meno (in C++ direi che non dovrebbe mai essere a carico del chiamante, oltretutto c'è modo di evitare il passaggio dei puntatori, vedi auto_ptr). E all'interno di una classe si spera che dopo la delete ci sia anche un'assegnazione a NULL del relativo puntatore.

Per i memory leak questi sono possibili in tutti i tipi di linguaggio sia managed che no.
Almeno in questo sono pari.

Secondo me l'enorme vantaggio dei linguaggi managed sul C++ è quello di fornire una vasta libreria tutto sommato uniforme in cui è possibile trovare tutto quello che serve, invece di ricorrere a librerie sempre diverse con interfacce differenti.

Buon 2008!

[tomminno]

Originariamente inviato da -Slash

per quanto riguarda i vantaggi a cui tu fai riferimento, avevo letto dell'estrema facilità nello scrivere interfacce, tramite codice o tramite tool con java, è vero?

Con le QT o le wxWidgets anche in C++ scrivere una GUI è facilissimo.

[cdimauro]

Originariamente inviato da tomminno

Diciamo che con i linguaggi managed metti un try catch e qualunque porcata tu possa fare nel mezzo sei sicuro che per lo meno finisci nel catch.
E' anche vero che ritrovarsi un'eccezione perchè fallisce la conversione del float 5,096 in uno short è qualcosa di frustrante.

In C++ sotto Windows sbattendoti con le SEH puoi trappare i segmentation fault, lo stack overflow è possibile trapparlo ma non avendo più spazio nello stack non hai modo di gestirlo.

OT: qualcuno conosce se esiste un equivalente Linux per le SEH?

La doppia deallocazione è un problema, ma generalmente sta scritto se la deallocazione è a carico del chiamante o meno (in C++ direi che non dovrebbe mai essere a carico del chiamante, oltretutto c'è modo di evitare il passaggio dei puntatori, vedi auto_ptr). E all'interno di una classe si spera che dopo la delete ci sia anche un'assegnazione a NULL del relativo puntatore.

Per i memory leak questi sono possibili in tutti i tipi di linguaggio sia managed che no.
Almeno in questo sono pari.

Secondo me l'enorme vantaggio dei linguaggi managed sul C++ è quello di fornire una vasta libreria tutto sommato uniforme in cui è possibile trovare tutto quello che serve, invece di ricorrere a librerie sempre diverse con interfacce differenti.

Buon 2008!

Sono tutte cose che i linguaggi managed risolvono "aggratis", però.

Per i memory leak non sono d'accordo: coi linguaggi managed (dotati di garbage collector) se un pezzo di memoria non risulta più usato / referenziato, prima o poi verrà deallocato.

La stessa cosa non si può dire per i linguaggi non managed (che non fanno uso di meccanismi GC): se dimentichi una free/delete, rimani con la memoria allocata fino alla morte dell'applicazione.

Auguri a tutti.

[tomminno]

Originariamente inviato da cdimauro

Li conosco entrambi, ma a livello di codice in comune non avranno praticamente niente: ecco perché non ha senso confrontarli.

Codice a comune per programmi scritti in linguaggi differenti non ce ne possono essere.

Come pensi di poter scrivere codice a comune tra C++ e Java?

Per essere comparabili non dovresti usare la STL del C++ che in Java non ha equivalente e viceversa per i generics. Ma se in Java si può fare benissimo a meno dei generics (che secondo me sono venuti fuori un pò malino a causa della retrocompatibilità del bytecode), togliere l'STL al C++ significa lavorare con il C con le classi: niente stream, string, vector, tr1...

Non potresti usare i puntatori del C++ perchè non hanno controparte in Java.

Non dovresti allocare niente sullo stack ma solo sulll'heap.

In Java per il problema del boxing e unboxing (assente in C++) che faresti useresti int o Integer? Ma in C++ Integer non esiste quindi creeresti una classe Integer per fare pari?

Insomma è impossibile scrivere codice comparabile di un certo interesse tra 2 linguaggi differenti.

[tomminno]

Originariamente inviato da cdimauro

Per i memory leak non sono d'accordo: coi linguaggi managed (dotati di garbage collector) se un pezzo di memoria non risulta più usato / referenziato, prima o poi verrà deallocato.

La stessa cosa non si può dire per i linguaggi non managed (che non fanno uso di meccanismi GC): se dimentichi una free/delete, rimani con la memoria allocata fino alla morte dell'applicazione.

Auguri a tutti.

Appunto il problema è che inavvertitamente potresti lasciare referenziato un oggetto che non dovrebbe più esserlo.

Qualche post fa è stato riportato un link a Mokabyte dove viene riportato un esempio di memory leak in Java: nell'esempio il pop su uno stack non impostava a null l'oggetto estratto, così che il GC si trova sempre referenziato l'oggetto e non lo elimina mai.
La dimenticanza equivalente in C++ sarebbe stata la mancata delete, ma che differenza c'è tra dimenticarsi elements[size] = null piuttosto che delete elements[size] ?
In entrambi i casi hai memory leak.

[jappilas]

Originariamente inviato da -Slash

E' esattamente quello a cui mi riferisco. Tutte e dico tutte le applicazioni java che ho provate sono lentissime.

anche Diamond Crush?

ed in generale applicazioni in linguaggi non compilati, come python, risultano essere molto piu lente che programmi che fanno le stesse cose in linguaggi compilati. questa è la mia opinione...

ma, senza offesa, è un' opinione che lascia un po' il tempo che trova, se confronti tra loro programmi scritti, oltre che in linguaggi diversi, da programmatori diversi, per librerie (toolkit) diverse, e basati su design con ogni probabilità diversi ... è come confrontare mele con pere, e non si può trarre conclusioni sull' efficienza relativa dei linguaggi in cui sono stati scritti..

imho, una misura già più attendibile dell' overhead del runtime di un linguaggio, si avrebbe applicando a codice preesistente (in, per dire, C++) le modifiche necessarie e sufficienti per renderlo valido sintatticamente e semanticamente (quindi funzionante) in quel linguaggio (o viceversa), senza alterarne struttura e algortmi di funzionamento - ovvero un language port ...
il codice di diamond crush ( java ) è a disposizione per ogni possibile uso, compresa, per chi volesse cimentarsi, una eventuale conversione in C++ ( a patto di aggiungere le deallocazioni degli oggetti e reimplementare strutture dati e meccanismi di introspection) - a questo punto, sarei perfino curioso di vedere un confronto quantitativo...

[sottovento]

Originariamente inviato da Unrue

Questa è bella.. L'assembly generato sarà uguale per quelle tre righe di codice che hai postato.. Ma prendi un programma da 10.000 righe di codice. Guarda guarda quanto sono uguali gli assembly generati..

Si, e' proprio bella.
Immagino che tu abbia preso un programma da 10000 righe di codice ed abbia fatto la verifica. Prego postare

[marco.r]

Originariamente inviato da tomminno

Appunto il problema è che inavvertitamente potresti lasciare referenziato un oggetto che non dovrebbe più esserlo.

Qualche post fa è stato riportato un link a Mokabyte dove viene riportato un esempio di memory leak in Java: nell'esempio il pop su uno stack non impostava a null l'oggetto estratto, così che il GC si trova sempre referenziato l'oggetto e non lo elimina mai.
La dimenticanza equivalente in C++ sarebbe stata la mancata delete, ma che differenza c'è tra dimenticarsi elements[size] = null piuttosto che delete elements[size] ?
In entrambi i casi hai memory leak.

C'e' una differenza importante. In un caso la memoria allocata e' persa "per sempre", mentre nell'altro c'e' ancora un riferimento, e quindi la memoria verra' prima o poi reclamata, solo piu' tardi di quando si vorrebbe. Ad esempio quando verra' aggiunto un nuovo oggetto sullo stack il puntatore verra' sovrascritto, e comunque la memoria verra' reclamata (eventualmente) una volta finito di usare lo stack.

[cdimauro]

Originariamente inviato da tomminno

Codice a comune per programmi scritti in linguaggi differenti non ce ne possono essere.

Come pensi di poter scrivere codice a comune tra C++ e Java?

Per essere comparabili non dovresti usare la STL del C++ che in Java non ha equivalente e viceversa per i generics. Ma se in Java si può fare benissimo a meno dei generics (che secondo me sono venuti fuori un pò malino a causa della retrocompatibilità del bytecode), togliere l'STL al C++ significa lavorare con il C con le classi: niente stream, string, vector, tr1...

Non potresti usare i puntatori del C++ perchè non hanno controparte in Java.

Non dovresti allocare niente sullo stack ma solo sulll'heap.

In Java per il problema del boxing e unboxing (assente in C++) che faresti useresti int o Integer? Ma in C++ Integer non esiste quindi creeresti una classe Integer per fare pari?

Insomma è impossibile scrivere codice comparabile di un certo interesse tra 2 linguaggi differenti.

I test che ha mostrato Tigershark rispecchiano la mia idea: le applicazioni sono esattamente le stesse, ma soltanto scritte con linguaggi diversi.

E' chiaro che di un un linguaggio sono libero di utilizzare qualunque costrutto, ed eventualmente libreria.

Quindi OK per l'STL per il C++, come pure per il framework standard di Java. Idem per i generics. Per i tipi di dati, userei gli scalari quando servono gli scalari, e i corrispettivi "boxed" (eventualmente generati automaticamente dal compilatore) quando servono invece degli oggetti.

La mia idea è che la struttura dei programmi dev'essere praticamente identica, fatta eccezione per i casi in cui, appunto, si può usare qualche funzione e/o oggetto di libreria o caratteristiche peculiari per implementare particolari parti di codice.

Questo se vogliamo fare dei confronti serii, in cui l'unica variabile diversa fra due applicazioni è, appunto, il linguaggio (e di esempi se ne trovano in giro) usato.

Sull'altro messaggio vedo che ha già scritto marco, di cui condivido il pensiero.

[sottovento]

Originariamente inviato da tomminno

La new del Java per lo meno richiama almeno anche la new di un Object.
Quindi il codice generato non può essere uguale.

Si, e' vero. Penso che ci sia un vantaggio a favore di Java.
Crea per esempio una pletora di piccoli oggetti, per esempio:

class MyTest
{
public:
  MyTest ()
  {
    a = 0;
    b = 0;
    buf = new char[1024];
    strcpy (buf, "");
  }

  MyTest (int a, int b)
  {
    this->a = a;
    this->b = b;
    buf = new char[1024];
    strcpy (buf, "");
  }

  MyTest (const MyTest &myTest)
  {
    printf ("Costruttore di copia chiamato\n");
    a = myTest.a;
    b = myTest.b;
    buf = new char[1024];
    strcpy (buf, myTest.buf);
  }

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

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

  void setText (char *text)
  {
    strcpy (buf, text);
  }

  const char *getText ()
  {
    return buf;
  }

private:
  int a;
  int b;
  char *buf;
};

Questa e' una classe con una dozzina di byte, implementabile sia in C++ sia in Java.
Dopo di che, scrivi nel main:

void allochiamo ()
{
  printf ("Alloco un po'...\n");
  time_t start = time (NULL);
  for (int i = 0; i < 1000000; i++)
  {
    MyTest *p = new MyTest;
    if (p)
      delete p;
  }
  time_t stop = time (NULL);
  printf ("Tempo di allocazione: %d\n", stop - start);
}

Scrivi lo stesso codice per Java, per esempio:

	static void allochiamo ()
	{
		long start = Calendar.getInstance().getTimeInMillis ();
		for (int i = 0; i < 100000000; i++)
		{
			MyTest mytest = new MyTest();
		}
		long stop = Calendar.getInstance().getTimeInMillis ();

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

Ho compilato la versione di C++ con Microsoft Visual Studio .NET 2003 Professional, mentre la versione Java e' stata compilata con jdk 1.5
Sul mio sistema Win XP, Java e' circa 100 volte piu' veloce.
Infatti puoi vedere dalle mie prove che il numero di zeri nel ciclo Java e' piu' grande, anche perche' sul mio sistema C++, con lo stesso numero di zeri, non arriva a completamento in un tempo decente (ore).
Dove sbaglio?
Soprattutto, nel caso abbia commesso un errore, che tipo di errore e'? L'ho creato apposta per far "vincere"Java o si tratta di una normalissima prassi di programmazione?
Perche' Java vince? Non dovrebbe perdere SEMPRE?

Originariamente inviato da tomminno

Stavamo parlando di codice generato per quel ciclo for, il GC non fa parte del programma quindi il codice generato è ancora una volta differente.

Esatto. Java e' quindi piu' ottimizzato in senso GLOBALE.
LOCALMENTE non riesce a battere C++, ma quando hai applicazioni da milioni di linee, le cose cambiano. Tanto piu' che le piattaforme a management di memoria (non solo Java) stanno vincendo sul mercato: mem leaks piu' difficili da produrre (ci vuole piu' entusiasmo), codice piu' robusto e possibilita' di fare ottimizzazioni a livello globale.

Originariamente inviato da tomminno

Spiegami dove verrebbero generate tutte le copie inutili, quando ormai tutti i compilatori traducono con un passaggio per riferimento tutti i metodi/funzioni che restituiscono copie di oggetti.

Riprendi l'esempio di prima:

MyTest getTest ()
{
  MyTest t;
  t.setA(5);
  t.setB(8);

  return t;
}

Spiegami come evitare questa copia.

Oppure:

void doSome1 (MyTest myTest)

Questa la potresti evitare scrivendo:

void doSome1 (const MyTest &myTest)

Pero'... se per caso usi i metodi di set() per risparmiare memoria, il tuo compilatore non compilera' un bel niente.
Come evitare? Dovrai fare una copia locale, che potremmo chiamare "copia volontaria".

Originariamente inviato da tomminno

Java su 1KB di RAM
Speigami quale OS ci girava.
Qualche riga di codice C per sistemi embedded l'ho scritta (ARM7 32KB) su questi sistemi non hai l'MMU, quindi non ci gira neanche Linux, e l'allocazione dinamica della memoria è un sogno.
Sarei curioso di sapere su quale sistema con 1KB di RAM hai visto girare Java.

Sorry, hai ragione. Era notizia riservata. Perdonami

[sottovento]

Dimenticavo. Spesso e' utile controllar wikipedia.
Beh, la versione italiana non mi piace, visto che da notizie contrastanti da quella inglese (non completamente, ma le informazioni sono diverse).

Leggendo infatti al link http://en.wikipedia.org/wiki/Compiler il paragrafo "Compiled versus interpreted languages" si legge una cosa, secondo me, importante:

Higher-level programming languages are generally divided for convenience into compiled languages and interpreted languages. However, there is rarely anything about a language that requires it to be exclusively compiled, or exclusively interpreted. The categorization usually reflects the most popular or widespread implementations of a language — for instance, BASIC is thought of as an interpreted language, and C a compiled one, despite the existence of BASIC compilers and C interpreters.

In a sense, all languages are interpreted, with "execution" being merely a special case of interpretation performed by transistors switching on a CPU. Modern trends toward just-in-time compilation and bytecode interpretation also blur the traditional categorizations.

In un certo senso, tutti i linguaggi sono intepretati poiche' girano tutti su una macchina virtuale. Cambia la macchina virtuale, ma sempre VM e'! Anche C++ non fa eccezione, come potrebbe, d'altronde?
Quanto e' efficiente la macchina virtuale? Si puo' migliorarla con un layer software in piu'?

Cosa ne pensate? E' questo, secondo voi, il motivo per cui i linguaggi "managed" vinceranno la sfida rispetto ai linguaggi tradizionali?

[dupa]

meglio un programma il 10% più veloce o un programma 10% più esente da errori?
a mio parere programmare in C++ porta più facilmente a commettere errori, rispetto a programmare in Java.

[-Slash]

Originariamente inviato da jappilas

anche Diamond Crush?

ma, senza offesa, è un' opinione che lascia un po' il tempo che trova, se confronti tra loro programmi scritti, oltre che in linguaggi diversi, da programmatori diversi, per librerie (toolkit) diverse, e basati su design con ogni probabilità diversi ... è come confrontare mele con pere, e non si può trarre conclusioni sull' efficienza relativa dei linguaggi in cui sono stati scritti..

imho, una misura già più attendibile dell' overhead del runtime di un linguaggio, si avrebbe applicando a codice preesistente (in, per dire, C++) le modifiche necessarie e sufficienti per renderlo valido sintatticamente e semanticamente (quindi funzionante) in quel linguaggio (o viceversa), senza alterarne struttura e algortmi di funzionamento - ovvero un language port ...
il codice di diamond crush ( java ) è a disposizione per ogni possibile uso, compresa, per chi volesse cimentarsi, una eventuale conversione in C++ ( a patto di aggiungere le deallocazioni degli oggetti e reimplementare strutture dati e meccanismi di introspection) - a questo punto, sarei perfino curioso di vedere un confronto quantitativo...

diamond crush mai provato

io sto dando una opinione da utente: tutti i programmi java che ho provato sono assolutamente lenti, molto piu degli equivalenti c e simili. poi potete dirmi che non ha senso confrontare vari programmi fatti da diversi programmatori, ma sinceramente mi sembra strano che prendo x programmi java e x programmi c e simili, e andando a confrontarli in ogni caso sono nettamente piu veloci quelli c...

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

[tomminno]

Dove sbagli non lo so (o meglio forse si, ho aggiunto il distruttore della classe MyTest altrimenti hai un bel memory leak ), ho creato al volo un progetto con Code::Blocks su linux Gcc 4.1.2 e il tempo di esecuzione del tuo codice è di 3 secondi con 10 milioni di allocazioni come nell'esempio Java.
Se non esegui la delete su buffer il sistema va in crisi perchè allochi 10GB di RAM.

Appena posso provo a fare lo stesso con Eclipse e ti dico il risultato.

[atragon]

Sia pure orientato su .Net mi pare interessante questo articolo:
http://msdn2.microsoft.com/it-it/lib...52(en-us).aspx

[tomminno]

Originariamente inviato da sottovento

MyTest getTest ()
{
  MyTest t;
  t.setA(5);
  t.setB(8);

  return t;
}

Spiegami come evitare questa copia.

E' il compilatore che lo fa al posto tuo.
Un qualunque compilatore tradice la tua funzione in:

void getTest (MyTest & tRet)
{
  MyTest t;
  t.setA(5);
  t.setB(8);

  tRet = t;
}

Oppure:

void doSome1 (MyTest myTest)

Questa la potresti evitare scrivendo:

void doSome1 (const MyTest &myTest)

Pero'... se per caso usi i metodi di set() per risparmiare memoria, il tuo compilatore non compilera' un bel niente.

Come evitare? Dovrai fare una copia locale, che potremmo chiamare "copia volontaria".

Esiste sempre la parola chiave mutable, da applicare alle variabili che non identificano strettamente la classe per cui possono essere modificate anche in presenza di riferimenti const.
Altrimenti se vuoi modificare l'oggetto la funzione corretta è:

void doSome1 (MyTest & myTest)

Come vedi nessuna copia di troppo

[sottovento]

Originariamente inviato da tomminno

Dove sbagli non lo so (o meglio forse si, ho aggiunto il distruttore della classe MyTest altrimenti hai un bel memory leak ), ho creato al volo un progetto con Code::Blocks su linux Gcc 4.1.2 e il tempo di esecuzione del tuo codice è di 3 secondi con 10 milioni di allocazioni come nell'esempio Java.
Se non esegui la delete su buffer il sistema va in crisi perchè allochi 10GB di RAM.

Appena posso provo a fare lo stesso con Eclipse e ti dico il risultato.

Si, mi ero accorto di non aver deallocato (ho fatto diverse prove prima di postare, poi ho copiato&incollato l'ultima).

Prestazioni di tutto rispetto, direi. 10 milioni di allocazioni in 3 secondi, praticamente 300 nanosecondi ad allocazione.
Sei proprio sicuro? Mi sembra una prestazione davvero esagerata!

Ne approfitto per augurarti Buon Anno, e per estendere l'augurio a tutti i frequentatori del forum.