Newsgroup: it.comp.lang.c++
Titolo: Le prestazioni.

Finalmente ho avuto un pò di tempo per fare alcuni confronti fra
compilatori c++ e non solo, nella lista dei confronti é compreso anche
il Visual Basic questo non per alimentare polemiche fra linguaggi
diversi ma solo per replicare ad un tizio che nel suo sito aveva
scritto che il Borland C++ era talmente lento da generare codice
peggiore rispetto a quello del Visual Basic: ora vedremo se quel tizio
aveva ragione.
Le prove sono state fatte utilizzando Borland C++ Builder 5
Professional update pack 1(basato sul compilatore borland c++ 5.5.1) ,
Visual C++ 6 SP4 e Visual Basic 6 SP4, con supporto delle eccezioni,
RTTI disattivata , niente ottimizzazioni per il BCB ed ottimizzazioni
di default per il VC++.
I test di confronto sono stati fatti solo con 3 routine semplici ma
abbastanza pesanti:
//PROVA SEI MILIONI ITERAZIONI RIPETUTE 10 VOLTE.
void routine()
{
	long x,y,z,a,u;
	y=z=a=0;
	for(u=1;u<=10;u++)
	{
		for(x=1;x<=6000000;x++)
		{
			y+=x;
			z+=x;
			a+=x;
		}
	}
}
//VERSIONE VB
Private Sub routine()
Dim x,y,z,a,u as long
for u=1 to 10
    for x=1 to 6000000
        y=y+x
        z=z+x
        a=a+x
    next
next
end sub
//PROVA RIEMPIMENTO E POI VISITAZIONE CON SCRITTURA DI UN VECTOR DI
10000 ELEMENTI.
void routine()
    {
    std::vector<int>prova(0);
    for(unsigned int x=0;x<10000;x++)prova.push_back(x);
    //unsigned commentato su vc++.
    for(/*unsigned*/ int x=0;x<10000;x++)std::cout<<x<<std::endl;
    }
//PROVA CONCATENAZIONE DI 10000 CARATTERI SENZA RESERVE.
void routine()
    {	
    std::string prova="";
    for(long x=0;x<100000;x++)prova+="a";
    }
//VERSIONE VB.
Private sub routine()
    Dim prova as String
    Dim x as Long
    prova=""
    for x=0 to 99999
        prova=prova+"a"
    next
end sub
//PROVA STRINGA CONCATENAZIONE DI 10000 CARATTERI CON RESERVE.
void routine()
    {	
    std::string prova="";
    prova.reserve(110000);
    for(long x=0;x<100000;x++)prova+="a";
    }
//PARTE ELABORAZIONE PRESTAZIONI IN MILLISECONDI.
#include<string>
#include<vector>
#include<iostream>
#include<ctime>    	
    int main()
	{
	clock_t start,end;
	start=clock();
	routine();
	end=clock();
                  std::cout<<"Tempo impiegato= "<<double(end-start)<<"
millisecondi\n";
	}    
    }
---------------
RISULTATI PROVE
---------------
600000 iterazioni.
(Visual Basic 6 sp4) 4457 millisecondi.
(Borland C++ Builder 5 up1) 150 millisecondi.
(Visual C++ 6 sp4) 150 millisecondi.
6000000 iterazioni.
(Visual Basic 6 sp4) 44624 millisecondi.
(Borland C++ Builder 5 up1) 1532 millisecondi.
(Visual C++ 6 sp4) 1542 millisecondi.
PROVA VECTOR DI 10000 INT CON RIEMPIMENTO,VISITAZIONE E SCRITTURA
DEGLI ELEMENTI.
(Borland C++ Builder 5 up1) 7531 millisecondi(media su 10 misurazioni)
(Visual C++ 6 sp4) 9000 millisecondi(media su 10 misurazioni)
CONCATENAZIONI STRINGHE CON 100000 CARATTERI SENZA RESERVE.
(qui arrivano i dolori)
(Borland C++ Builder 5 up1) 23224 millisecondi.
(Visual C++ 6 sp4) 3805 millisecondi.
(Visual Basic 6 sp4) 72434 millisecondi.
CONCATENAZIONI STRINGHE CON 100000 CARATTERI CON RESERVE.
(Borland C++ Builder 5 up1) 120 millisecondi(media su 10 misurazioni).
(Visual C++ 6 sp4) 190 millisecondi(media su 10 misurazioni).
CONCATENAZIONI STRINGHE CON 500000 CARATTERI CON RESERVE.
(Borland C++ Builder 5 up1) 600 millisecondi(media su 10 misurazioni).
(Visual C++ 6 sp4) 991 millisecondi(media su 10 misurazioni).
CONCATENAZIONI STRINGHE CON 1000000 CARATTERI CON RESERVE.
(Borland C++ Builder 5 up1) 1232 millisecondi(media su 10
misurazioni).
(Visual C++ 6 sp4) 2032 millisecondi(media su 10 misurazioni).
le prove confermano perfettamente ciò che avevo sospettato: il Borland
C++ regge alla perfezione il confronto con il Visual C++ risultando in
alcuni casi più veloce(seppur di poco). Un altro sospetto é
confermato, quello a riguardo dell' implementazione delle std::string
nel Borland C++ che in quanto a prestazioni fa piuttosto pena, anche
se in molti casi si può tranquillamente ricorrere all'uso di reserve()
che migliora decisamente le cose rendendo il codice più veloce di
quello generato dal Visual C++.
E' stata confermata un'altra cosa: ovvero che il codice generato dal
Visual Basic é mediamente 30 volte più lento di quello generato dal
Borland C++, e questo smentisce completamente le affermazioni di quel
tizio di cui parlavo prima.
Purtroppo non ho avuto tempo per fare le prove con il g++/djgpp, anche
se alcune prove fatte in passato mi fanno sospettare che dal punto di
vista delle prestazioni questo compilatore sia superiore alla
concorrenza.
Grazie per la cortese attenzione ed arrivederci..
Il Ghenio
-----
ZIO : Fun and games are over with. Anyone who dares
get in my way shall perish.
DIO ci salvi dagli ocx del Viral Basic.
-----

 quello generato dal Visual C++.
prova un po' con container tipo map, o con qualche algoritmo tipo sort, 
stable_sort, make_heap, etc, e ti accorgerai delle differenze

 ha scritto
[CUT]
Hai messo il Vc++ in release mode (e non debug) ???  (l'eseguibile deve
trovarsi nella cartella release e non debug).
Hai attivato le optimizations -> maximum speed ???
Fammi sapere,
Alex

 compilatori c++ e non solo, nella lista dei confronti é compreso anche
Alcune note (sono tutte IMHO):
C'e' differenza fra paragonare il compilatore e paragonare la libreria standard.
Si potrebbe obiettare che il produttore del compilatore sceglie con che libreria
fornirlo. Ma si puo' anche contro obiettare che una buona parte della libreria
(specificatamente le STL) si possono poi cambiare.
Per paragonare due (o piu') librerie le si dovrebbe compilare con lo stesso
compilatore e gli stessi settaggi di ottimizzazione. Meglio ancora compilarle
entrambe con due o tre compilatori diversi e con settaggi di ottimizzazione
diversi. Un paragone fra due librerie compilando il codice con due compilatori
diversi dice poco sulle librerie stesse.
Allo stesso modo per paragonare due (o piu') compilatori li si dovrebbe usare
con la stessa libreria (o fare a meno delle STL). Meglio ancora usarli con due o
piu' librerie diverse. Un paragone fra due compilatori usando due librerie
diverse dice poco sui compilatori stessi.
Infine paragonare due compilatori con "il settaggio di default" non ha senso. I
due parametri che possono essere interessanti per i compilatori sono la velocitą
di compilazione (tolti tutti i precompiled headers e cose simili) e la velocitą
del codice compilato. La velocitą di compilazione e' significativa solo se si
sviluppano sistemi molto grossi (dove una rebuild impiega parecchie ore su una
macchina veloce). Per progetti piccoli, ricompilare in 8 minuti o un 10 non
cambia. Inoltre quasi tutti i compilatori hanno una qualche facility per
precompilare gli header etc. In ogni caso: il test sulla velocitą di
compilazione va fatto in modalitą debug, zero ottimizzazione, con il massimo dei
simboli attivi (compreso eventuale browse database), partendo con codice gią
compilato, modificando alcuni sorgendi e facendo una build (non una rebuild
all). Questo e' il settaggio attivo nel 99% dei casi in cui si compila (e
pertanto quello che fa la differenza in termini di velocitą di compilazione). Il
test sulla velocitą dell'eseguibile generato va viceversa fatto in modalitą
release con il massimo possibile di ottimizzazioni attivate. Questo e' il
settaggio usato nel 99% dei casi in cui quello che conta e' compilare
l'eseguibile finale (soprattutto se la velocitą di esecuzione e' quella che
conta).
--
Andrea Ferro
---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info 
http://www.brainbench.com/transcript.jsp?pid=2522556

Fammi sapere,
Ho specificato che le ottimizzazioni erano disabilitate in tutt'e tre
i casi. Purtroppo non possiedo il VC++ a casa e neanche una versione
aggiornata del BCB, quindi al momento non posso fare altre prove.
Comunque lo scopo non era quello di mettere a confronto i due
compilatori, ma solo di capire se il BCB é davvero cosi' lento come
qualcuno dice. Se qualcun'altro ha effettuato delle prove con questo
compilatore é pregato di segnalarmelo.


Dim x,y,z,a,u as long
dichiara solo u come long, mentre le altre sono tutte variant, anche
se non fai l'errore che fanni in molti di usare l'integer (che molti
dimenticano essere a 16 bit)
Al 100% pero' se usi le impostazioni di default allora avrai compilato
il codice in pcode. Cosa cretina per questo genere di test.
Se ci tenevi potevi usare anche l'Eiffel GNU. C'e' una simpatica
opzione che ti genera codice che poi deve essere compilato con il GCC.
Sono certo che su codice cosi' semplice avresti trovato che Eiffel ha
prestazioni identiche alla versione C. Su codice reale pero' non ci
giurerei, malgrado il C.
Come gia' facevo io, devi attivare tutte le combinazioni delle
ottimizzazioni. Che per esempio nel VB sono piu' del solo compilare in
codice macchina (devi togliere anche il codice di controllo).
Nalla concatenazione di stringhe e' irrilevante, se non per curiosita'
personale, il confronto con il VB. Le stringhe del VB assomigliano
molto poco a quelle della libreria standard per come sono
implementate.
Ovviamente avresti dovuto anche usare una libreria comune tra i
compilatori C++, per esempio la STLPort (se ricordo bene la trovi su
www.stlport.org
 )
Se non possiedi il VC, puo' sempre confrontarlo con il GCC, LCC e i
demo vari di Kay, Intel (molto veloce) e tanti altri.
P.S. 1
Io non sono "tizio". Ho un nome. 
Papero per la precisione
P.S. 2
Con risultati cosi' diversi dai miei non ti e' venuto in mente di
scaricare i miei test e provarli sul tuo computer? O i miei risultati
erano confermati, oppure erano smentiti, o se preferisci c'era
qualcosa che non quadrava con i tuoi test, oppure io avevo preso un
abbaglio. I tutte e due i casi la cosa era di interesse.
-- 
Tieni per te il Papero giusto se vuoi la mia email
Sito Papero 1 -> 
http://utenti.tripod.it/papero
Sito Papero 2 -> 
http://user.7host.com/papero/

 abbaglio. I tutte e due i casi la cosa era di interesse.
[CUT]
