Newsgroup: it.comp.lang.visual-basic
Titolo: TUTTO QUELLO CHE AVRESTE VOLUTO SAPERE...

... MA CHE NON AVETE MAI OSATO CHIEDERE:
---- E' + VELOCE IL VB O IL C++? ----
Ebbene ora a questo c'è risposta. Ho fatto due prg, due cavolate, dato ke in
vb è il MIO primo prg funzionante (eheh dopo mi dite come và ;) ) che
svolgono le stesse indentiche operazioni, entrambi x win32!!! Sono fatti
tipo benchmarc, per cui come risultato avrete un numerino da confrontare...
Dettagli? (uff ma ke pall..) Li trovate tutti sul file... NON FATE GLI
SCHIZZINOSI, sono solo 24k, c'è un ULTRAReadme.txt da leggere e i due
eseguibili... richiede ovviamente (x il prg in vb) i runtime del vb6!
Chi vincerà la sfida? VB o C++? Provate a indovinare e poi provateli...
members.xoom.com/wavexx/files/purespeed.zip
24k zippati
Contenuto:
-ULTRAReadme.txt
-PURESpeedvb.exe
-PURESpeedcxx.exe
by Wave++
members.xoom.com/wavexx
wav...@apexmail.com
// Meglio l'uovo fritto o sbattuto?

members.xoom.com/wavexx/files/PURESpeed.zip
Skizzinosetto il server eh ;)


Il c++, non c'è bisogno di prove.
Bye

>---- E' + VELOCE IL VB O IL C++? ----
veramente lo sappiamo gia'... il C e' + veloce vel VB ......
Che trucco subdolo per aumentare un contatore di accessi ! :)
Ciao
********* Federico Emanuele Galli  *********
Sideralis Programs (Visual-Basic and Delphi)
 
http://www.softitaly.com/sideralis
  Hai domande ? It.comp.lang.visual-basic
---> 
http://www.murialdo.it/it_lang_vb
 <---

straccia il c x un numero ben superiore!
Io ho provato e devo dire che il numero che sputa fuori č maggiore da
VB che da C, ma (sinceramente) la cosa non mi convince per nulla (ma
proprio per nulla).
Se non ho capito male il programma inizia a contare da 0 fino a che
non sono passati i secondi indicati dall'utente.
Non č che potresti mandarmi il sorgente dei programmi?
Ciao
Marco Frazzoli

Ciao
Non c'è trucco e non è x aumentare il contatore di accessi! che me ne dovrei
fare?
E inoltre vince il vb! Strano ma vero....
VINCE IL VB sennò perchè mai avrei postato! Agli inizi ho pensato:


proprio per nulla).
Tempo fa ricordo che Stefanelli avva provato ad aprire i file in
binario e il C stracciava di brutto Vb...


 wrote in message 7i7bjl$gis$1...@hermes.iol.it...

Non ci credo nemmeno se lo vedo!
Che compilatore C hai usato?
Che versione di VB?
Potresti mandarmi i sorgenti di entrambi?
--
Roal Zanazzi
z...@iol.it


riciao :)

Che versione di VB?
tanto x la cronaca: vb6 pro e vc++ pro! entrambi m$, entrambi merd... cmq, i
sorgenti del vb li ho postati, ora trovo quelli del c

altri linguaggi... :-)
Che ne dici di postare anche il tuo di esempio ?



Credici Roal! Succedeva anche con il mio crivello di Eratostene...
BTW, certo che il VB la Standard Template Library (STL per gli amici) non se
la sogna nemmeno (e nemmeno Delphi, tie'! :-) )
Affettuosamente
Gian Michele Bertoni
homepage: 
http://space.tin.it/computer/gbertoni

>Credici Roal! Succedeva anche con il mio crivello di Eratostene...
in effetti sembra strano... ho fatto il profiling e il maggior tempo
utilizzato č dalla dunzione time(x), evidentemente non bene implementata
come quella semplice del vb timer... bah

>Che ne dici di postare anche il tuo di esempio ?
non serve... basta aprire un file e fare una copia char x char su un'altro
file! in c++ in mezzo sek ti copia anche 2 mega... col vb, poveretto, fą
pietą :)


Le misurazioni le avevo fatte con la GetTickCount sotto NT. La risoluzione
e' di circa 1/100 di sec. Quello che ho misurato e' stato il loop di calcolo
(niente messaggi o altro, solo il riempimento di un array). I codici sono i
seguenti:
----------------VB---------------
    nStartTime = GetTickCount()
    For i = 2 To Int(r / 2)
        r2 = Int(r / i)
        For j = 2 To r2
            m_anNumbers(j * i) = False
        Next j
    Next i
    nEndTime = GetTickCount()
----------------/VB---------------
----------------VC++---------------
 nStartTime = ::GetTickCount();
 for (i = 2; i < r / 2; i++) {
  r2 = r / i;
  for (j = 2; j <= r2; j++) m_abPrime[j * i] = false;
 }
 nEndTime = ::GetTickCount();
----------------/VC++---------------
Ciao



Veramente per Delphi esiste la SDL (non e' standard, ma di un tizio che ha
preso come modello proprio la STL)... e comunque, in Delphi non ci sono le
template classes, ma almeno e' OOP! (VB nemmeno quello...)
--
Roal Zanazzi
z...@iol.it


OK, ho fatto delle prove, con VB5SP3, ma dato che il to codice non mi
piaceva l'ho un po' modificato. Il loop di attesa l'ho fatto con
GetTickCount.
Confronto: VB5SP3 contro Delphi3
Il codice Delphi3 e' pressoche' identico a quello VB (chiaramente con le
minime differenze dovute alla diversita' di linguaggio, ma il ciclo di
attesa e di conteggio sono identici.
Il conteggio ricavato dall'app Delphi3 e' piu' di 10 volte superiore a
quello di VB5SP3 (compilato in nativo, of course), sul tempo di 10 secondi.
Non ho fatto prove con tempi diversi perche' mi sembra una perdita di ...
tempo, appunto :-)
Sono proprio curioso di vedere il tuo codice C... ma temo che ci sia un
vizio di fondo (gia' il fatto che hai usato la funzione Timer in VB e Time
in C, la dice lunga...)
P.S. se ti interessa, wave++, posso spedirti (via e-mail) il codice VB e
Delphi, con i compilati, cosi' "tocchi con mano"... 126Kb di .zip)
--
Roal Zanazzi
z...@iol.it

template classes, ma almeno e' OOP! (VB nemmeno quello...)
In effetti, dopo aver voluto provare per un anno a scrivere applicazioni
serie in VB, trovo piu' produttivo, anche per cose semplici il (V)C++...



Non e' vero. Punto.
Al limite VB puo' essere veloce quanto VC++.
E la spiegazione e' molto semplice:
VB5 ha lo _stesso_ back-end compiler e lo _stesso_ linker di VC++5.
Quindi il codice macchina prodotto e' , nel caso migliore per VB, identico.
Lo stesso vale per VB6 e VC++6.
Peccato pero' che VB ha un linguaggio meno "potente" del C/C++ e basa la sua
gestione della memoria su un sistema di garbage collection, che non e'
nemmeno considerabile nel caso si vogliano raggiungere performance estreme
(e lo sanno bene tutti coloro che con il garbage collector di VB5 ci hanno
litigato almeno una volta!).
E non parliamo del modo in cui VB gestisce i controlli visuali (questo
dovresti ricordarlo, dal "tuo" crivello di Eratostene...).
P.S. non vorrei sembrare "quello che crede di essere il custode della
verita' assoluta", ma quando si continua ostinatamente a cercare di
dimostrare il falso, magari prendendo il particolare e facendolo passare
come "la regola", proprio non mi va giu'.
Un esempio significativo e' il test comparativo di VB6 e Delphi4
commissionato dalla Microsoft all'uscita di VB6 e pubblicato sul sito M$...
una vergognosa serie di stronzate...
Per non parlare poi del test comparativo Windows NT server vs Linux, sempre
(guarda caso) commissionato dalla M$, in cui risulta che NT e' piu'
performante di Linux a parita' di hardware... peccato che l'hardware
"sembrasse" fatto apposta per lo scopo... e devono aver faticato parecchio a
trovare una macchina su cui NT girasse meglio di Linux... e peccato anche
che la configurazione di Linux sembrasse fatta da uno psicopatico che fa il
macellaio come secondo lavoro...
P.P.S. per terminare, e' vero, VB non e' certo l'ambiente/linguaggio di
sviluppo dei miei sogni, ma ammetto che e' valido e sta migliorando
(ultimamente), ma, per favore, non cercate di dimostrare che e' "er mejo"...
rischiereste di sembrare ridicoli...
Scusate lo sfogo.
--
Roal Zanazzi
z...@iol.it

>GetTickCount.
Ok, ok, tu hai usato gettick ecc... e hai una precisione di un centesimo
circa, ma se noti prima del conteggio faccio un ciclo di attesa in modo da
ottenere l'inizio del secondo spaccato! Vabbč potrň perdere qualche ciclo,
ma roba di poco (penso :))) eruditemi su questo... )
by Wave++ (loving c++)



Beh, calcola che in vb ne so poco-niente! E poi che c'è che non và nella
funzione time? Che dovevo fare? Chiamate dirette con l'assembler? (che poi
lo conosco poco)
Cmq, dato che voglio sempre imparare spedici spedisci :)


riguardanti i sistemi di sviluppo elencati.
Questo e' scorretto oltreche' censurabile: hai sempre accettato (e nessuno
mi ha detto il contrario) i miei dati.
Credo poi di essere stato il solo a fare le prove sia su NT sia su Win98 con
13 prove, scartando le prime 3 e facendo la media sulle restanti 10, altro
che "simpatie personali". Tu non hai mai detto in che modo hai fatto le tue
prove ed avevi a disposizione i miei sorgenti prima di produrre i tuoi.
Quindi ancora una volta fai accuse infondate e poco rispettose della verita'
dei fatti.
Il famoso thread, comunque, e' iniziato un po' come questo: tu hai fatto
un'affermazione un po' esagerata:
RZ>VB, anche compilando in modo nativo, ha seri problemi
RZ>di performance (dovuti alle limitazioni intrinseche
RZ>nell'architettura interna, al garbage collector e altro).
al che ho risposto, pacatamente:
GMB>Beh, le cose non sono cosi' tragiche:
GMB><omissis...>
GMB>Non ho provato, ma se fai un crivello
GMB>di Eratostene in VC++ ed in VB le
GMB>prestazioni dovrebbero essere simili.
A questo punto, dopo avermi dato dell'"ottimista sognatore" ti sei
incaponito a dimostrare, senza ancora sapere come, quello che avevi scritto.
Quando ti ho dimostrato, dati alla mano, come stavano le cose, prima mi hai
dato ragione:
RZ>Come si vede dai risultati (i test sono stati
RZ>effetuati con le medesime condizioni),
RZ>effettivamente VB5 compilato in nativo offre
RZ>prestazioni simili a quelle di Delphi, almeno
RZ>per quanto riguarda il calcolo puro (anche se
RZ>Delphi e' comunque piu' performante).
poi hai ripiegato su altri aspetti non in discussione per dimostrare la tesi
(ed io non ho mai sostenuto una tesi contraria) che Delphi sia piu'
performante di VB, cosi' come hai fatto anche stavolta.
Queste "tecniche" potranno andar bene in una tribuna elettorale (o in un
asilo...), non in un newsgroup di programmazione!
Grazie, e' veramente bello parlare con te.
Gian Michele Bertoni
homepage: 
http://space.tin.it/computer/gbertoni
P.S. Non ho "simpatie" verso VB ne' verso il mondo MS in generale: sono solo
strumenti (come ce ne sono altri) della mia attivita'. Ho letto gli
"Halloween documents" e sto facendo i miei esperimenti con Linux. Ho
tuttavia sviluppato alcune applicazioni che girano da anni senza problemi
con questo linguaggio.
Dall'inizio del 1998, stimolato da alcune precedenti discussioni su
newsgroup esteri, ho cercato di applicare tecniche di programmazione
solitamente riservate ad altri tipi di linguaggi, come il multithreading, a
VB avendo un discreto successo. Ho condotto analoghi esperimenti
(decisamente falliti a causa del compilatore inadeguato) con Java.
Oggi tuttavia ritengo che questa esperienza debba dirsi conclusa e che sia
piu' produttivo tornare ad usare il C++.

Allora, devo aver perso i sorgenti del c o buttati da qualche parte ma la
cosa non è iportante, il codice in c era scritto identico (volutamente) a
quello vb, quindi al posto del xx.print ho usato cout e invece della funzioe
timer in vb in c ho usato time(x) in c. Le funzioni sono identiche (mi pare
che la funzione attendi del c però fosse inline), i cicli di attesa uguali
(persino la dimensione è pressochè identica =)) ), allora sul mio pc il vb
mi dava un valore di circa una volta e mezzo + grande di quello del c, e
questo compilato in visual c, ora (avendo cambiato compilatore) ho preso
quello della borlad (non c'è paragone) e UDITE UDITE i valori del c ora sono
i valori del c che superano di una volta e mezza circa quelli del vb...
SENZA ottimizzazione, che daltronde avevo disabilitato anche in vc e vb.
Vi sembra possibile una simile DIFFERENZA?
(Daltronde borland è borland come dice sempre il buon Zanazzi)
