Discussion :

[Steinvikel]

La plupart des optimisations en langage "compilé" sont faites par le compilateur, pas par le codeur... et la qualité de l'optimisation dépend de : les paramétrage du compilateur, ses limites, et la verbosité du codeur. --> écrire simplement "auto i = 3;" et écrire "static const int i = 3;" n'entraine pas du tout la même profondeur d'optimisation suivant le contexte.

exemple en vidéo de 27:00 à 28:30
CppCon 2016: Jason Turner “Rich Code for Tiny Computers: A Simple Commodore 64 Game in C++17”
https://youtu.be/zBkNBP00wJE?t=1596
Dans ce cas précis, tu as oublié un "const" et paff, au lieu de 4 lignes assembleur en mémoire (il fait tourner l'ensemble du programme sur le cache du processeur) tu rajoutes plus de 350 lignes !!.

Je ne suis pas sûr que les erreurs courantes en C# et en C++ soient plus coûteuse chez l'un que chez l'autre, en revanche, il y a peut-être généralement plus de rigueur chez les C++ de par la pluralité paradigmatique (j'étais inspiré, dsl), à l'image du Pascal ou un pet de mouche empêche la compilation.
Bref, je pense que les problèmes de perf sont plus lié à des facteurs convergeant, comme les habitudes communautaires, les nécessités absolues, les facilités, les spécialisations... plutôt que le langage en lui même.

[Invité]

"Nonante" c'est mieux que "quatre vingt dix", plus logique et plus court.

C'est surtout que ça n'a rien à voir avec la news. Si vous voulez disserter là dessus, pourquoi ne pas créer un topic dans la section taverne ?

[Aurelien.Regat-Barrel]

Moi j'avais regarder ça : https://www.codeproject.com/Articles...-Csharp-vs-NET

On dit parfois que C++ ne donne pas de la performance, il donne accès à la performance. Les techniques d'optimisations sont les mêmes au delà du langage car c'est le hardware sous jacent qui dicte ça, et c'est une expertise à part entière. La différence en C++ c'est qu'il est plus "hardware sympathic" et en ne te faisant pas payer pour ce que tu n'utilises pas. Au hasard le garbage collector qui met régulièrement en micro-pause ton programme et déclenche des recopies complète de tes data en mémoire.

Pour ce qui est des micro benchmark, ile ne veulent pas dire grand chose car la performance dans und vraie application se trouve aussi (voire surtout) dans la data, et plus exactement dans l'empreinte et l'agencement mémoire de ton programme. Dès que tu satures la taille de tes caches (quelques Mo), les performances s'écroulent (du genre 10 à 50 fois plus lent). Et si tes data ne sont pas ordonnées de manière continue, c'est la même sanction. Et donc un langage qui t'imposent d'allouer à tout va sur le heap en rajoutant en plus un overhead pour le type System.Object de base obligatoire c'est catastrophique pour les perfs passé un certaine taille.

Une intro de qualité par un exellent speaker (vers la 22eme min):
https://channel9.msdn.com/Events/Build/2014/2-661

Concernant les erreurs de programmation qui dégradent les perf, la règle d'or en optimisation c'est de commencer par profiler ton code, ainsi tu découvres vite les erreurs de ce type. Mais aussi de nos jours on a des outils d'analyse statique de code (gratuits) qui peuvent détecter certaines copies inutiles. CLion par exemple te signale dans ton code ce genre de cas et t'invite à faire un move ou un const ref.

Enfin, la tendance moderne est de prendre en input un string_view ou un span quand tu ne fait que consulter la data, de cette manière il n'y a aucun risque en terme de perfs en plus d'avoir une meilleur sémantique vis à vis du code.

Ces exemples résument mes propos initiaux : oui en C++ il est facile (comme dans d'autres langages) d'écrire du code avec de mauvaises performances. Mais une fois localisé, on a beaucoup d'options assez simples pour régler efficacement le problème.

[Matthieu76]

Merci, tout cas est hyper intéressant mais en réalité je suis sur des 99% de la lenteur de mon code vient de la conception des algo et de l'architecture du code. Avoir du code avec des objets contenant des vectors d'objet contenant des vectors d'objet contenant des vectors de float et faire des calculs en boucle sur ces float ça doit être au moins 100 fois plus lent que si j'avais juste un tableau 3D de float. Après si j'avais juste des structs et des tableaux de float j'aurais un code plus rapide mais complètement imbitable avec des erreurs de calcul et d'index partout, un enfer à debugger !

PS : Ne pas oublier les options de compilation, le jour ou j'ai découvert ça j'ai rendu mon code 4 fois plus rapides !

[Pyramidev]

Avoir du code avec des objets contenant des vectors d'objet contenant des vectors d'objet contenant des vectors de float et faire des calculs en boucle sur ces float ça doit être au moins 100 fois plus lent que si j'avais juste un tableau 3D de float. Après si j'avais juste des structs et des tableaux de float j'aurais un code plus rapide mais complètement imbitable avec des erreurs de calcul et d'index partout, un enfer à debugger !

Tu n'es pas obligé de créer un vecteur de vecteur de vecteur pour avoir une syntaxe commode. Tu peux aussi encapsuler ton tableau 3D dans une classe dont tu choisis la syntaxe.

Exemple simple de template de classe pour gérer un tableau 3D dont on ne connaît les dimensions qu'au runtime :

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

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
32
33
#include <cassert>
#include <vector>
 
template<class T>
class DynamicArray3D {
private:
	size_t m_sizeX;
	size_t m_sizeY;
	size_t m_sizeZ;
	std::vector<T> m_elements;
public:
	DynamicArray3D(size_t sizeX, size_t sizeY, size_t sizeZ) :
		m_sizeX{sizeX},
		m_sizeY{sizeY},
		m_sizeZ{sizeZ},
		m_elements(sizeX*sizeY*sizeZ)
	{}
	T& operator()(size_t x, size_t y, size_t z) {
		assert(x < m_sizeX);
		assert(y < m_sizeY);
		assert(z < m_sizeZ);
		return m_elements[x + y*m_sizeX + z*m_sizeX*m_sizeY];
	}
	T const& operator()(size_t x, size_t y, size_t z) const {
		assert(x < m_sizeX);
		assert(y < m_sizeY);
		assert(z < m_sizeZ);
		return m_elements[x + y*m_sizeX + z*m_sizeX*m_sizeY];
	}
	size_t getSizeX() const { return m_sizeX; }
	size_t getSizeY() const { return m_sizeY; }
	size_t getSizeZ() const { return m_sizeZ; }
};

Exemple d'utilisation :

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

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
32
33
34
35
36
37
38
39
40
41
#include <iostream>
 
DynamicArray3D<double> createMyDynamicArray3D(size_t sizeX, size_t sizeY, size_t sizeZ)
{
	DynamicArray3D<double> dynArr{sizeX, sizeY, sizeZ};
	for(size_t z = 0; z < sizeZ; ++z)
		for(size_t y = 0; y < sizeY; ++y)
			for(size_t x = 0; x < sizeX; ++x)
				dynArr(x, y, z) = 100*z + 10*y + x;
	return dynArr;
}
 
void print(DynamicArray3D<double> const& dynArr)
{
	const size_t sizeX = dynArr.getSizeX();
	const size_t sizeY = dynArr.getSizeY();
	const size_t sizeZ = dynArr.getSizeZ();
	for(size_t z = 0; z < sizeZ; ++z) {
		for(size_t y = 0; y < sizeY; ++y) {
			for(size_t x = 0; x < sizeX; ++x) {
				std::cout << dynArr(x, y, z);
				if(x+1 < sizeX)
					std::cout << ", ";
			}
			if(y+1 < sizeY)
				std::cout << '\n';
		}
		if(z+1 < sizeZ)
			std::cout << "\n\n";
	}
}
 
int main()
{
	constexpr size_t sizeX = 5;
	constexpr size_t sizeY = 3;
	constexpr size_t sizeZ = 2;
	const DynamicArray3D<double> dynArr = createMyDynamicArray3D(sizeX, sizeY, sizeZ);
	print(dynArr);
	return 0;
}

[Matthieu76]

Tu n'es pas obligé de créer un vecteur de vecteur de vecteur pour avoir une syntaxe commode. Tu peux aussi encapsuler ton tableau 3D dans une classe dont tu choisis la syntaxe.

Cela est-il vraiment plus rapide qu'un vector<vector<vector<float>>> ?
N'il a-t'il pas un moyen d'utiliser des pointers intelligent qui point un tableaux 3D à la place ? Ça serait plus rapide non ?

Et puis en vrai j'ai pas vraiment ça, je travaille sur des réseaux de neurones, j'ai donc une classe NeuralNetwork qui contient un vector<Layer> qui contient un vector<Neuron> qui contient un vector<int>. Enfin pour avoir un code lisible et compréhensible je suis un peu obligé de sacrifier l'optimisation. Et plus bon c'est bien gentil tout cas mais le meilleur moyen d’optimiser mon code reste quand même le multi-threading tant que mon code ne tournera pas sur les 8 cœurs de mon processeur ça ne sert à rien d'optimiser le reste enfin pas à ce niveau d'optimisation. J'avais essayer de faire tourner mon code sur ma carte graphics en recodant tout en CUDA mais j'avais obtenu un code totalement illisible et quasiment impossible à maintenir donc j'ai abandonné.
(J'arrivais pas à copier des structures sur ma carte graphique du coup je passais tout par pointeur par conséquent j'avais des méthodes avec une 10e de paramètres d'entrés.) En puis bon vu que je passe mon temps à retoucher mes algo je préfère un code maintenable qu'un code optimisé au poil de ***.