Newsgroup: it.comp.lang.visual-basic
Titolo: Incredulo: VB6 vs C++

Salve,
per una mia particolare applicazione audio scritta in VB6 ho la necessità di 
ottimizzare alcuni calcoli.
L'idea è stata quella di utilizzare delle DLL scritte in C++ da richiamare 
da VB6. Prima di fare questo ho fatto un test dai risultati incredibili:
Ho fatto una DLL in C++ con VC6 e l'ho compilata, ecco il codice:
double _stdcall Somma()
{
    double k;
    double ris;
    ris = 0;
    k = 0;
 for (long i=1; i < 10000000; i++)
{
  k = k + 0.0000001;
  ris = ris + sin(k)/2 + cos(k)/2;
}
    return ris;
}
La funzione calcola la somma di dieci milioni di seni e coseni della 
variabile k.
La stessa funzione l'ho fatta in VB facendogli eseguire gli stessi calcoli:
Dim b as integer
Dim k as double
Dim ris as double
k = 0
ris = 0
for b = 1 to 10000000
 k = k  + 0.0000001
 ris = ris + sin(k)/2 + cos(k)/2
next b
I due processi danno lo stesso risultato, avviamente, ma sono rimasto 
incredulo difronte l'evidenza che VB6 è due volte piu veloce!!!!!! (Vb 2.3 
Secondi, C++ 4.8 Secondi)
Come diavolo è possibile, dove sbaglio?? Ai guru l'ardua sentenza.
Emiliano. 

 La stessa funzione l'ho fatta in VB facendogli eseguire gli stessi calcoli:
la differenza di performance mi pare strana, se riscontrata su 
compilati (privi di opzioni specifiche o cmq con ottimizzazioni 
molto diverse), anche considerato l'onere di chiamata a funzione 
esterna (nella DLL), dato che cmq viene chiamata solo una volta 
e ha persino un solo valore di ritorno e zero parametri, per cui 
l'overhead è limitato.
Per sicurezza (lo so, la domanda è idiota), hai misurato le 
performance a runtime "libero" o da dentro un debugger ? Nel 
caso del debugger potrebbe esserci molto più lavoro dietro le 
quinte (per gestire magari possibili backtrack nello stack) 
quando la chiamata è esterna al modulo, ivi incluso il tempo di 
caricamento della DLL se tu non l'hai già caricata in memoria.
L'avevi caricata, vero ? O la chiamata a funzione è il primo 
riferimento effettivo alla DLL esterna ? In tal caso esegui il 
confronto di performance nelle chiamate dalla seconda in poi, 
oppure esegui il preload in qualche modo (se è automatico, 
ignora queste precisazioni).
Per il resto, rimango sorpreso. Intendiamoci, non mi aspettavo 
grosse differenze di velocità né in un senso né nell'altro, 
visto che l'impatto della sintassi di alto livello su una 
routine che usa semplici calcoli double non richiede chissà 
quali sforzi di ottimizzazione e, d'altra parte, il calcolo 
floating point, che si mangia il 9x,xx % del tempo macchina 
della tua funzione, viene di fatto delegato a librerie 
precompilate sia nel caso del C++ sia del VB. Si presume che 
entrambe le librerie siano già molto ottimizzate e poco diverse 
come efficienza. L'unica differenza potrebbe essere che so, che 
la libreria matematica di VB ha inserito codice orientato a 
qualche processore di classe superiore mentre nella DLL C++ è 
stato linkato codice più ampiamente portabile ma meno performante.
Son tutte ipotesi, lo so, ma del resto non c'è strane magie in 
sottofondo e, a pari condizioni effettive, il tuo codice 
dovrebbe girare in modo molto simile.
Una qualche differenza di performance la potresti riscontrare 
con oggetti dati di maggiore complessità, come vettori, mappe, 
liste, alberi, code, stack etc, nel qual caso un codice C++ ben 
scritto o meglio ancora l'uso della STL, sicuramente produce 
efficienza maggiore. In generale non ci si deve aspettare 
miracoli quando il linguaggio essenzialmente delega a librerie 
già ottimizzate (come nel caso di funzioni grafiche di oggetti 
esterni, in cui l'onere di chiamata è minimale rispetto ai tempi 
di calcolo interno).
ciao
Soviet_Mario


Io sono incredulo,
significa che oggi come oggi è possibile utilizzare visual basic anche per 
applicazioni orientate alle performance.
Ero sicuro che il C++ avrebbe prodotto risultati eclatanti, mi aspettavo 
almeno un fattore 3X e invece con enorme piacere sono costretto a constatare 
che un'effetto riverbero calcolato in C++ è piu lento di uno calcolato 
direttamente in VB.
La Dll C è una dll dinamica richiamata da VB con un Declare sub, credo che i 
tempi necessari per effettuare il passaggio dei parametri e per il ritonro 
del risultato siano assolutamente trascurabili, visto che la routine C 
inpiega circa 5 secondi per effettuare quei calcoli.
Resto in attesa di eventuali avvisi da parte vostra di qualche invisibile 
errore o dimenticanza non essendo, io, un programmatore C.
Emiliano.


 essendo, io, un programmatore C.
Ma hai provato a riscrivere il codice seguendo le indicazioni di 
soviet_mario? E che risultati hai ottenuto?
Per la cronaca le funzioni matematiche in VB sono prestanti 
"praticamente" quanto quelle in C++. A maggior ragione non dovresti 
riscontrare differenze cosi' ampie sui tempi di esecuzione. Ci hai 
detto tutto?
Lokar
-- 
Sito Comune: 
http://www.it-lang-vb.net/
Manifesto: 
http://www.it-lang-vb.net/docs/Manifesto.txt
Statuto: 
http://www.it-lang-vb.net/docs/Statuto.txt

 direttamente in VB.
prima ancora di entrare nel merito del codice C++, sarebbe bene accertare
come sono stati misurati i tempi, quante prove sono state fatte, se c'era
la possibilita` che qualche altra applicazione possa aver rubato tempo di
cpu (
p.es
. e` partita una scansione antivirus), ecc.
-- 
ciao, hal

Stessi risultati, i tempi rimangono sempre quelli, VB 2X.
Forse devo impostare qualche opzioni nel compilatore del C++ (io uso VC++)
Emiliano.


Secondo me è tutto "sotto controllo",
la misura del tempo di esecuzione avviene con il timer di sistema, VB 
memorizza il timer, avvia il ciclo, effettua la differenza tra il tempo di 
avvio e quello finale, banalissimo.
Questa cosa la fa per entrambi i clici, quello eseguito in VB (2.3 secondi) 
e quello eseguito dal C++ (4.5 Seconci). Se faccio 20 prove a distanza di 
tempo ottengo sempre il medesimo risultato, le temporizzazioni possono 
cambiare di 1/2%.
Non credo ci sia nulla di anamolo, forse dobbiamo entrare nel merito del 
codice C++ :))
Emiliano.


 Forse devo impostare qualche opzioni nel compilatore del C++ (io uso VC++)
quali opzioni usi adesso?
la dll carica qualche libreria aggiuntiva che ne possa rallentare la
esecuzione?
ad esempio, se in vb forzi preventivamente il  caricamento della dll
con LoadLibrary, i tempi cambiano?
-- 
ciao, hal

 con LoadLibrary, i tempi cambiano?
Dove l'hai preso sto LoadLibrary? Mai sentito. ;)
Facciamo sta prova, come si usa?
Emiliano. 

 codice C++ :))
ho perso la struttura del thread, rispondo qui forse a sproposito
non ti resta che capire in che misura la libreria di calcolo 
(math) del C++ è ottimizzata per il tuo processore e quanto lo è 
la corrispettiva libreria di VB.
Se tutte le altre variabili già citate da molti (io non avevo 
pensato ad antivirus, ad es, perché ritenevo che se uno si mette 
a "profilare" le performance, come minimo cerca di mettersi in 
un identico ambiente e non disturbato da altri processi) sono 
state escluse, rimane la possibile differente qualità (e grado 
di aggiornamento) delle librerie di appoggio.
Il codice C++ era scritto in modo adeguato, salvo le lievissime 
migliorie che avevo suggerito, peraltro poco influenti. L'unica 
differenza può rimanere il fatto che una libreria sia meglio 
adatta a supportare al 100 % il tuo hardware mentre l'altra sia 
magari più portabile e meno spinta sulle istruzioni più recenti.
Non resta che questa variabile .... ripeto, non credo 
all'ipotesi arcana della magia di VB. Inoltre il codice scritto 
era tanto semplice che praticamente ogni compilatore può 
gestirlo al meglio.
10 anni fa usavo per dei calcoli l'accesso diretto al 
coprocessore matematico waitek, con variabili long double ad 80 
bit di precisione, e tenevo praticamente tutte le variabili 
nello stack interno del preprocessore, salvo trasferirle in ram 
a calcoli finiti. Il tempo di calcolo era circa il 30-35 % a 
quelle dell'allora libreria di calcolo del Borland C (versione 
soft) e del 70 % (versione hardware). Ma se provavo a eseguire i 
miei calcoli su un normale 486 senza coprocessore, o senza il 
waitec nello specifico, il mio programma se ne usciva con codici 
di errore o un reset. Voglio dire che è difficile confrontare le 
performance di due "linguaggi" quando sostanzialmente stai 
facendo competere essenzialmente le librerie di appoggio.
ciao
Soviet_Mario
