Rapidit� C++ vs VB.NET

Bonjour � tous,
On m'a dit que le C++ �tait tr�s rapide, plus rapide que le VB.NET :mouarf:
Alors, j'ai fais deux teste, pour comparer la rapidit� des deux langages.

VB.NET :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

Module Module1   Sub Main() For i As Integer = 0 To 1000000 Console.WriteLine(i) Next   Console.ReadLine() End Sub   End Module

---

C++ :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

#include <iostream>   using namespace std;   int main() { for (int compteur = 0 ; compteur < 1000000 ; compteur++) { cout << compteur << endl; }   char repo; cin >> repo; return 0; }

---

A ma grande surprise, le VB.NET allait trois fois plus vite que le C++ avec pourtant exactement le m�me code !
Savez-vous pourquoi �a c'est pass� ainsi ?

1. Comment as-tu mesurer?
2. Est-ce que tu as compile en configuration "Debug"? Si oui ca n'a aucun sens de tester les performances dans ce mode. Il faut le faire dans la configuration finale, en "Release" par defaut sous VS.
3. Remplace endl par '\n'. Sauf si tu feux flusher la console a chaque output, ce que VB ne fait certainement pas.
4. Au passage, pour ce genre de code, VB.Net devrait avoir des performances similaires (mais certainement en defaveur de .Net). C'est plutot avec des manipulations complexes et lourdes que tu vas voir une reelle difference. Essaie avec quelque chose de plus realiste?

Merci pour ta r�ponse :ccool:

Citation:

---

1. Comment as-tu mesurer?

---

J'ai mesur� en fonction du temps qui s'�coulait du d�but du traitement jusqu�� la fin du traitement.

Citation:

---

2. Est-ce que tu as compile en configuration "Debug"? Si oui ca n'a aucun sens de tester les performances dans ce mode. Il faut le faire dans la configuration finale, en "Release" par defaut sous VS.

---

J'ai bien fait l'op�ration en Release

Citation:

---

3. Remplace endl par '\n'. Sauf si tu feux flusher la console a chaque output, ce que VB ne fait certainement pas.

---

M�me r�sultat ...

Citation:

---

4. Au passage, pour ce genre de code, VB.Net devrait avoir des performances similaires (mais certainement en defaveur de .Net). C'est plutot avec des manipulations complexes et lourdes que tu vas voir une reelle difference. Essaie avec quelque chose de plus realiste?

---

Pour l'instant, je veux juste tester �a :mrgreen:
Une fois que j'aurai compris, j'essayerai surement d'autre chose.

Par contre, j'ai remarqu� que l'application C++ prenait seullement 620K de m�moire, alors que le programme en VB.NET en prend 2816K !

Comment augmenter la m�moire du programme C++ pour le faire acc�l�rer ?

La vitesse d'ex�cution n'a strictement rien � voir avec la m�moire allou�e pendant son ex�cution.
Par ailleurs ta m�thode de "calcul" de la vitesse d'ex�cution me semble... Bancale pour ne pas dire ridicule et naze.
Vue la simplicit� du code, la diff�rence sera probablement inf�rieure � la seconde, et je doute tr�s grandement que tu aies une telle pr�cision.

OK ok :roll:
Bref, j�abandonne ce test.

Tu n'aurai pas une id�e de programme qui montrerai vraiment la diff�rence entre les deux langages ?

un bete produit scalaire de deux tableaux de N > 10^6 elements de type double

Citation:

---

un bete produit scalaire de deux tableaux de N > 10^6 elements de type double

---

Merci :ccool:
Mais j'ai rien compris :?

D�finition du produit scalaire:

Citation:

---

Dans l'espace Rn, on d�finit le produit scalaire canonique : (x1, x2, ..., xn) . (y1, y2, ..., yn) = x1*y1 + x2*y2 + ... + xn*yn

---

Dans ton cas, n >= 10⁶, une possible impl�mentation en C++ serait :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

#include <vector> #include <algorithm> #include <cstdlib> #include <iostream> #include <ctime> #include <chrono>   using namespace std;   int main(int argc, char* argv[]) { const int size = 10000000; vector<double> v1(size), v2(size); const int max = 5; auto f = [max]{ return rand() % max; };   srand(time(nullptr)); generate(begin(v1), end(v1), f); generate(begin(v2), end(v2), f);   double scalar_product = 0; auto it = begin(v2);   auto t1 = chrono::high_resolution_clock::now(); for_each(begin(v1), end(v1), [&scalar_product, &it](double e){ scalar_product += e * (*it); ++it; }); auto t2 = chrono::high_resolution_clock::now();   cout << "scalar_product = " << scalar_product << " duration = " << chrono::duration_cast<chrono::milliseconds>(t2 - t1).count() << endl;   return 0; }

---

[EDIT]en changeant le type des �l�ments des array en double, le code plante, idem si je mets une taille trop grande genre 2 000 000 ? 8O

Citation:

---

Envoy� par backlash

[EDIT]en changeant le type des �l�ments des array en double, le code plante, idem si je mets une taille trop grande genre 2 000 000 ? 8O

---

(Sans trop m'avancer sur la v�ritable raison.)
std::array vit dans la pile (il n'y a pas pas d'allocation dynamique). La taille de la pile est bien plus limit�e que celle du tas. Si tu remplaces ton std::array par un std::vector �a devrait fonctionner.

il semblerait que tu aies raison Ehonn, cela semble coh�rent car je tourne sur une distrib Ubuntu 64bits, en tapant la commande ulimit -a j'ai comme info que ma stack size = 8192kbytes, autrement dit ma stack ne peut contenir que (approximativement) 8 192 000 / sizeof(int) = 8 192 000 / 4 = 2 048 000 int, ce qui semblait �tre (approximativement) la limite de mon array.

Ainsi le code a �t� �dit� en utilisant cette fois ci un vector.

Citation:

---

Envoy� par backlash

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

#include <vector> #include <algorithm> #include <cstdlib> #include <iostream> #include <ctime> #include <chrono>   using namespace std;   int main(int argc, char* argv[]) { const int size = 10000000; vector<double> v1(size), v2(size); const int max = 5; auto f = [max]{ return rand() % max; };   srand(time(nullptr)); generate(begin(v1), end(v1), f); generate(begin(v2), end(v2), f);   double scalar_product = 0; auto it = begin(v2);   auto t1 = chrono::high_resolution_clock::now(); for_each(begin(v1), end(v1), [&scalar_product, &it](double e){ scalar_product += e * (*it); ++it; }); auto t2 = chrono::high_resolution_clock::now();   cout << "scalar_product = " << scalar_product << " duration = " << chrono::duration_cast<chrono::milliseconds>(t2 - t1).count() << endl;   return 0; }

---

---

Existe-t-il toutes ces librairies dans VB.NET ? sinon, la comparaison va �tre difficile.

Citation:

---

Envoy� par MicBeastKiller

Existe-t-il toutes ces librairies dans VB.NET ? sinon, la comparaison va �tre difficile.

---

J'ose esp�rer qu'on peut utiliser des tableaux de donn�es en VB oui..
Aucune lib particuli�re n'est utilis�e ici.

Citation:

---

Envoy� par Bousk

J'ose esp�rer qu'on peut utiliser des tableaux de donn�es en VB oui..
Aucune lib particuli�re n'est utilis�e ici.

---

Je parlais justement de <vector> (et aussi <algorithm>) qui n'est certes pas une librairie � proprement parl�, mais reste n�anmoins tr�s �volu� compar� � un tableau classique. Donc si l'impl�mentation en VB se fait par du tableau classique, la comparaison va �tre difficile.
J'aurais plut�t fait une impl�mentation avec des choses tr�s basiques, pour �tre s�r de pouvoir le faire dans les deux langages.

Utiliser un vector, array ou "tableau classique" ne change strictement rien quant � l'utilisation des donn�es. Il s'agit de donn�es contigu�s en m�moire et cest tout ce qui importe. On ne parle pas de la cr�ation de ces donn�es.
De m�me que algorithm ne fournit rien de particulier, �crire une boucle for et faire un appel � la m�thode utilis�e par le foncteur ne change rien au traitement des donn�es.

Citation:

---

Envoy� par MicBeastKiller

Je parlais justement de <vector> (et aussi <algorithm>) qui n'est certes pas une librairie � proprement parl�, mais reste n�anmoins tr�s �volu� compar� � un tableau classique. Donc si l'impl�mentation en VB se fait par du tableau classique, la comparaison va �tre difficile.
J'aurais plut�t fait une impl�mentation avec des choses tr�s basiques, pour �tre s�r de pouvoir le faire dans les deux langages.

---

C'est VB.NET, ya les container et algos qu'en C# a ce que je sache, et ya bien leurs equivalent a c++.