Discussion :

[Community Management]

Chers membres du club,

J'ai le plaisir de vous présenter ce tutoriel de Dan Levin pour vous apprendre à rendre vos codes plus rapides (performants) avec C++14 et C++17.

L'écriture de codes performants est toujours une tâche difficile. L'application directe des algorithmes théoriques « purs » n'est pas toujours suffisante dans les architectures du monde réel.

Lorsqu'on a commencé à améliorer la rapidité de ces algorithmes purs, on se trouve rapidement confronté à un dilemme : certaines implémentations s'avèrent relativement rapides sur une architecture, mais effroyablement lentes sur d'autres. Dans le même temps, dans certains contextes, une nouvelle implémentation va dépasser les performances de la première, mais perdre de la vitesse dans tous les autres.

De nombreuses optimisations, grandes et petites, pour chacune des architectures prises en charge peuvent rapidement faire gonfler notre code et nous faire perdre du temps. Souvent, nous sommes donc ramenés à choisir entre deux options : un beau code trop lent, ou bien un code rapide mais illisible.

Bonne lecture .



Retrouvez les meilleurs cours et tutoriels pour apprendre la programmation C++

[grunk]

Alors je suis pas expert dans le domaine mais quand je lit ça :

Le code précédent est équivalent à ce code, écrit en C++03 ou bien C++11 :

Code :

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
switch(log2n)
{
case 1:
    add_stage<internal::fft_specialization_t<T, 1, false>::template type>(size, type);
    break;
case 2:
    add_stage<internal::fft_specialization_t<T, 2, false>::template type>(size, type);
    break;
case 3:
    add_stage<internal::fft_specialization_t<T, 3, false>::template type>(size, type);
    break;
case 4:
    add_stage<internal::fft_specialization_t<T, 4, false>::template type>(size, type);
    break;
case 5:
    add_stage<internal::fft_specialization_t<T, 5, false>::template type>(size, type);
    break;
case 6:
    add_stage<internal::fft_specialization_t<T, 6, false>::template type>(size, type);
    break;
case 7:
    add_stage<internal::fft_specialization_t<T, 7, false>::template type>(size, type);
    break;
case 8:
    add_stage<internal::fft_specialization_t<T, 8, false>::template type>(size, type);
    break;
default:
    if(is_even(log2n))
    {
        make_fft(size, type, cbool<true>, ctrue);
        add_stage<internal::fft_reorder_stage_impl_t<T, true>::template type>(size, type);
    }
    else
    {
        make_fft(size, type, cbool<false>, ctrue);
        add_stage<internal::fft_reorder_stage_impl_t<T, false>::template type>(size, type);    
    }
}

Je me dis que j'aurais plutôt fait un truc comme ça :

Code :

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

1
2
3
4
5
6
7
if(log2n >= 1 && log2n <= 8) {
    add_stage<internal::fft_specialization_t<T, log2n, false>::template type>(size, type);
} else {
    bool isEven = is_even(log2n);
    make_fft(size, type, cbool<isEven>, ctrue);
    add_stage<internal::fft_reorder_stage_impl_t<T, isEven>::template type>(size, type);
}

Donc soit j'ai pas compris une subtilité , soit l'auteur original y met un peu de mauvaise fois histoire d'appuyer un peu plus son article

[Luc Hermitte]

log2n est une variable dynamique. Tu ne peux pas l'utiliser directement comme paramètre template sans passer par un dispatching à coups de switch ou autre.

[bacelar]

C'est l'une des différences entre les Template C++ et les génériques JAVA.
Les templates sont compilés et optimisés au moment de la compilation.
En JAVA, ce n'est qu'un modèle de code qui est généré à la compilation lors de la génération d'un générique.

[ternel]

rectification, en java, ce n'est pas un modèle, c'est une seule classe/fonction, utilisant Object, et l'utilisation est compilée (en byte code) à grand renfort de cast.

[Médinoc]

Par contre, en C#...

En revanche, il y a des limitations: Pas de SFINAE, pas de génériques sur des valeurs (seulement des types), etc.

[Oscar.STEFANINI]

Super article mais... je n'ai rien compris du code, c'est grave ? personnellement j'aurais fais des pointeurs sur fonctions, mais je suis surement passé à côté d'un truc absolument pas de mon niveau, déjà que j'ai pas compris à quoi servait l'algorithme...

[foetus]

Simple : à générer à la compilation 1 et 1 seul "algo" à chaque appel, dans ton code, de make_fft.

Donc toi tu auras des pointeurs (unsafe + déférencement), là tu auras une grosse boucle + 2-3 subtilités comme des trucs "en dur" (du moins je le pense parce que je n'ai pas vu l'algo )

[Oscar.STEFANINI]

c'est quoi le problème avec des pointeurs ? générer à la compilation ?? j'abandonne, trop fort pour moi

[koala01]

Salut,

c'est quoi le problème avec des pointeurs ?

Le problème des pointeurs, c'est qu'on les associe régulièrement avec l'allocation dynamique de mémoire (new ou new[]) et que, pour éviter les fuites mémoire, il faut penser à libérer cette mémoire à coup de delete (ou delete[]).

Mais, si allocation dynamique de mémoire il y a, encore faut il trouver "juste le bon moment" pour la libérer :
Tropt tôt, on risque de vouloir accéder à l'adresse mémoire représentée par le pointeur alors qu'elle a été libérée,
trop tard, on coure le risque d'avoir déjà perdu l'adresse mémoire représentée par le pointeur, et nous ne pourrons donc plus la libérer --> fuite mémoire.

De plus, il faut savoir que C++ est un langage à exception, et que ca complique encore le fait de décider que "c'est juste le bon moment" pour libérer la mémoire

Mais on a des outils très sympa pour éviter la plupart de ces problèmes : les pointeurs intelligents. Lorsqu'on les utilise, on peut assez facilement garantir que la mémoire allouée à un pointeur sera détruite... strictement au moment opportun.

Enfin, un pointeur peut aussi représenter une valeur particulière (nullptr) qui représente explicitement le fait que l'adresse représentée est invalide. Pour manipuler sereinement des pointeurs, la première chose à faire est... de s'assurer que l'adresse représentée est valide, et ca, ca demande du code et du temps à l'exécution.

C'est la raison pour laquelle on préfère généralement avoir recours aux références à chaque fois que faire se peut, car elles fournissent une garantie de "non nullité" (l'objet référencé existe forcément lorsque la référence est créée)

générer à la compilation ?? j'abandonne, trop fort pour moi

Pour faire simple : entre le code que tu écris et l'exécutable que tu lances, il y a deux étapes (en fait, il y en a plus, mais ces deux là sont suffisantes pour comprendre le fonctionnement):

• la compilation proprement dite : le compilateur génère du "code binaire exécutable" (souvent appelé "code objet")
• l'édition de liens : un outil appelé "éditeur de liens" reprend tous les "codes objets" générés par le compilateur, ainsi que celui utilisé qu'il trouve dans les bibliothèques pour créer l'exécutable final.

Généré à la compilation représente donc "tout ce qui est fait durant la compilation", pour faire la distinction avec "ce qui est fait lorsque l'application est exécutée". Et le compilateur peut faire énormément de choses qui permettront au code objet (et donc à l'exécutable final) d'être "plus performant".

[Oscar.STEFANINI]

Merci pour les explications, même si en fait les pointeurs j'en fait pendant 1 année non stop (mon école m'a fait faire du C pendant 1 an). J'ai pas encore eu le temps de regarder les pointeurs intelligents, mais c'est vrai que j'aime bien les références (d'ailleurs j'ai une question, est-ce que passer une référence à une fonction c'est aussi léger que passer un pointeur ?).

D'accord !! en gros c'est juste du code optimisé... Pour la compilation et du coup pour l’exécution ? ce qui finalement.. correspond au titre de l'article !

En fait j'ai mal interprété le message précédent, voilà tout merci !

[nikko34]

En C++ par défaut on utilise pas de pointeurs, et on passe les données soit par référence ou par copie, sachant qu'il existe des "référence const" qui ne évitent les copies inutiles.

On utilise les pointeurs quand on sait vraiment que l'on en a besoin, et dans ce cas là, on les encapsulera dans des pointeurs intelligents. En gros on utilise des pointeurs mais sans jamais écrire de new ni de delete (à partir de C++14).

[camboui]

... En gros on utilise des pointeurs mais sans jamais écrire de new ni de delete (à partir de C++14).

Ne découvrant que depuis pas longtemps ce qu'on nous propose depuis C++11 (et suivant), quelles sont les fonctionalités nous permettant d'allouer dans le heap sans faire de new ?

[foetus]

Ne découvrant que depuis pas longtemps ce qu'on nous propose depuis C++11 (et suivant), quelles sont les fonctionalités nous permettant d'allouer dans le heap sans faire de new ?

Regarde ici: Gestion dynamique de la mémoire

Je retire la partie commentée, parce que koala01 a sorti du bois: il a fait sa grosse réponse très précise et il a pris ces 3 points "as usual"

[nikko34]

Code :

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

auto wPtr = std::make_unique< Widget >();

Sans "écrire" de new, mais ça en fera un.

Après, hors polymorphisme dynamique et cas spéciaux, par défaut tu dois faire:

Code :

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

  Widget w;

[ternel]

l'ancien "auto_ptr" a la propriété de lacher facilement la propriété d'un pointé.
Notamment, en argument de fonction, le pointeur de l'appeleur perd la propriété.

[nikko34]

auto_ptr n'existe plus (il était mal fait et ne devait pas être utilisé dans les containers par ex.) Maintenant c'est std::unique_ptr et std::shared_ptr.

[koala01]

Merci pour les explications, même si en fait les pointeurs j'en fait pendant 1 année non stop (mon école m'a fait faire du C pendant 1 an). J'ai pas encore eu le temps de regarder les pointeurs intelligents, mais c'est vrai que j'aime bien les références (d'ailleurs j'ai une question, est-ce que passer une référence à une fonction c'est aussi léger que passer un pointeur ?).

Oui, tout à fait... En fait, si tu regarde au niveau du code binaire généré (ou au niveau du code assembleur généré), tu te rendra compte qu'une référence est transmise exactement comme s'il s'agissait d'un pointeur: c'est l'adresse mémoire à laquelle se trouve la donnée qui est transmise

La seule différence entre les deux, c'est que le langage (et donc le compilateur) est beaucoup plus permissif en ce qui concerne les pointeurs : on peut changer la valeur de l'adresse mémoire qu'ils reprsentent, et il peuvent représenter une adresse invalide (nullptr), alors que les références doivent être définies une bonne fois pour toute à la création, et qu'elle doivent référencer un objet qui existe lorsqu'elles sont créées.

• unique_ptr<> -> new/ delete
• weak_ptr<> -> XXX& ou const XXX& ou [XXX* ou const XXX*]
• shared_ptr -> je ne sais trop, mais je dirais reference counting + une liste de weak_ptr<>
• auto_ptr<> -> new/ delete mais le "avec sémantique stricte propriété de l'objet" semble dire copie/ transfert interdits

Humm...

• unique_ptr<> (new/new[] delete/delete[](make_unique depuis C++14))
  
  1. unique responsable (propriétaire) du pointeur qui lui est confié
  2. copie et affectation interdites,
  3. copie par déplacement et affectation par déplacement autorisées
  4. possibilité de changer le pointeur sous jacent (la mémoire allouée au pointeur sous-jacent est alors automatiquement libérée) : reset
  5. possibilité de forcer la libération du pointeur sous jascent : reset
  6. possibilité de récupérer la responsabilité du pointeur sous jascent release
  7. possibilité de récupérer le pointeur sous jascent (sans libérer unique_ptr de la responsabilité) : opérateurs * et ->, get
• shared_ptr<> (new/new[] delete/delete[](make_shared depuis C++11)) :
  
  1. plusieurs responsables / propriétaires du pointeur qui lui est confié(le dernier shared_ptr à référencer le pointeur s'occupe de la libération de la mémoire)
  2. copie et affectation autorisée
  3. copie par déplacement et affectation par déplacement autorisées
  4. possibilité de connaitre le nombre de références associées au pointeur sous-jacent : use_count
  5. possiblité d'obtenir un shared_ptr (voir plus loin)
  6. possibilité de modifier le pointeur sous jacent (reset)
  7. possibilité de forcer la libération du pointeur sous jacent (reset)
  8. possibilité de savoir si le pointeur sous jacent est toujours valide (operator bool)
• weak_ptr<> (à partir d'un shared_ptr)
  
  1. transmet un pointeur partagé sans intervenir dans le comptage de référence (n'intervient pas dans le processus de libération de la mémoire)
  2. copie et affectation autorisées
  3. copie par déplacement et affectation par déplacement autorisées
  4. ne permet d'accéder au pointeur sous jacent qu'en créant un nouveau shared_ptr (lock)
  5. permet de connaire le nombre de références associées au pointeur sous jacent (use_count)
  6. permet de savoir si le pointeur sous-jacen n'est plus valide (expired)
• auto_ptr<> (déprécié en C++11, supprimé en C++14)
  
  1. la sauce n'a jamais vraiment pris
  2. posait pas mal de problèmes, trop long à citer ici

tous les pointeurs intelligents fournissent les opérateurs de comparaison

A noter que C++11 date déjà de plus de cinq ans et que, depuis, C++14 est sortie (déjà depuis près de trois ans)... Cette dernière norme apporte apporte pas mal de nouveautés supplémentaires, et devrait être "la norme par défaut" utilisée, en remplacement de C++11

[Oscar.STEFANINI]

visiblement j'ai posé une bonne question

[jblecanard]

Hello

J'ajouterais une propriété intéressante de shared_ptr: il est thread safe tant que chaque thread possède son shared_ptr. Le comptage de référence est implémenté avec des atomics.