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