Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
temps = 1018
somme = 894782460
temps = 371
somme = 894782460
Je ne sais pas pourquoi, mais µl le dépasse (ainsi que les variantes plus complexes de rand()).
Et pour moi, c'est évident - le retirer de la boucle.
Oui, vous avez raison, j'ai essayé dans VS aussi et pour une raison quelconque, cela n'a pas optimisé du tout, bien qu'une variante aussi simple semble... En fait, cela revient à ceci :
Oui, vous avez raison, j'ai essayé dans VS aussi - pour une raison quelconque, ce n'est pas optimisé du tout, bien qu'il s'agisse d'une option si simple, il semblerait... En substance, cela revient à ceci :
Êtes-vous sûr d'avoir activé toutes les optimisations dans les paramètres du projet? Dans des cas étranges, j'allume la génération de la liste d'assemblage et je la regarde, c'est très instructif.
J'ai décidé de le tester également en C# par curiosité. Non seulement les résultats sont presque les mêmes en termes de vitesse, mais ils fonctionnent également beaucoup plus rapidement qu'en C++.
Résultats :
Somme : 894782460, Temps : 69 ms.
Somme : 894782460, Temps : 56 ms
Et voici un analogue en C++ :
Somme : 894782460, Temps : 2947 ms
Somme : 894782460, Temps : 684 ms
Je le teste dans VS 2019,toutes les optimisations sont activées .
Au diable un tel C++.)
p.s. Les résultats en C# varient agréablement d'un test à l'autre, mais en moyenne les deux variantes sont aussi rapides l'une que l'autre.
Vous devez d'abord comprendre les raisons de ces freins. J'ai fait un peu de recherche, et tout est en ligne sauf l'appel.
qui se trouve dans libstdc++. C'est-à-dire qu'à l'arrière-plan de la boucle presque nue, le goulot d'étranglement est constitué par les appels de fonction eux-mêmes (et il y a aussi quelques appels de ...replaceEmmPKcm). Le compilateur peut optimiser dans une seule unité de traduction. Vous pouvez essayer d'utiliser LTO (link time optimization), c'est-à-dire que cela permet d'optimiser l'étape de liaison. Mais je ne l'ai pas utilisé, je ne le ferai pas maintenant. Eh bien, il n'y a rien de particulièrement compliqué - passer à l'option -flto du compilateur/linker (mais il me manque un plugin), trop paresseux pour le découvrir + il faudra peut-être reconstruire libstdc++.
Comment cela se passera-t-il avec l'optimisation du code en relation avec le vissage des modules à venir (depuis C++20) ? Je ne sais pas, vous pouvez essayer en vs, bien que tout soit brut et expérimentalhttps://habr.com/en/company/pvs-studio/blog/328482/
c++'u va nous manquer ;)).
Par souci d'intérêt, j'ai décidé de tester également en C#. Non seulement les résultats sont presque identiques en termes de vitesse, mais ils sont également plus rapides d'un ordre de grandeur par rapport au C++.
Résultats :
Somme : 894782460, Temps : 69 ms
Somme : 894782460, Temps : 56 ms
Et voici un analogue en C++ :
Somme : 894782460, Temps : 2947 ms.
Somme : 894782460, Temps : 684 ms
Je le teste dans VS 2019,toutes les optimisations sont activées .
Au diable un tel C++.)
p.s. Les résultats en C# fluctuent considérablement d'un test à l'autre, mais en moyenne les deux variantes sont égales en vitesse.
Br-r-r-r-r, pas question ! Sharp a toujours battu les vrais pros par un facteur de deux, mettez le projet en route, s'il vous plaît.
Petits enfants :)
Ils ont étiré le jouet à 10 pages...
Il faut d'abord comprendre les raisons de la lenteur. J'ai creusé un peu et tout est en ligne, sauf l'appel.
qui se trouve dans libstdc++.
Il semble donc avoir compris qu'il alloue et supprime la mémoire à chaque fois, même dans ce cas :
Au fait, j'ai peut-être donné des résultats erronés la dernière fois. C'était probablement en mode x86. Je teste maintenant en mode x64 et les résultats par C++ sont bien meilleurs :
1) ~ 2000 msec
2) ~ 200 ms (c'est 3 fois plus rapide).
Bien que j'aie également mis à jour Studio à la dernière version, cela a dû l'influencer aussi puisque même x86 est plus rapide maintenant que les tests précédents.
Maintenant, le C++ n'est plus aussi honteusement en retard sur le Sharp, mais seulement de trois fois environ.)
Il semble donc avoir compris qu'il alloue et supprime la mémoire à chaque fois, même dans ce cas :
Au fait, j'ai peut-être donné de mauvais résultats la dernière fois. C'était probablement en mode x86. Je teste maintenant en mode x64 et les résultats par C++ sont bien meilleurs :
1) ~ 2000 msec
2) ~ 200 ms (c'est 3 fois plus rapide).
Bien que j'aie également mis à jour Studio à la dernière version, cela a dû l'influencer aussi puisque même x86 est plus rapide maintenant que les tests précédents.
Eh bien, maintenant, le C++ ne perd plus aussi honteusement contre le Sharp. Seulement par 3 fois environ ;)
Brrr-r-rr, pas question ! Sharp a toujours été deux fois plus performant que les plus propres, tu sors le projet plz.
Il vaut mieux tester les modules plus, les résultats y sont plus intéressants, bien qu'ils puissent encore être non documentés.
J'ai vérifié, il s'avère qu'aucun compilateur https://en.cppreference.com/w/cpp/compiler_support n'a terminé les modules, donc il n'y a rien à voir.