Discussion :

[Klaim]

Bonjour!

J'ai une question qui concerne plus ou moins de l'optimization, mais aussi la façon dont un compilo gère les namespaces et plus précisément les variables globales "enfermées" dans des namespaces.

Dans le document suivant consacré à l'optimization en C++, on peut lire à la page 24 :

The advantage of static data is that they can be initialized to desired values before the
program starts. The disadvantage is that the memory space is occupied throughout the
whole program execution, even if the variable is only used in a small part of the program.
This makes data caching less efficient.
Do not make variables global if you can avoid it. Global variables may be needed for
communication between different threads, but that’s about the only situation where they are
unavoidable. It may be useful to make a variable global if it is accessed by several different
functions and you want to avoid the overhead of transferring the variable as function
parameter. But it may be a better solution to make the functions that access the saved
variable members of the same class and store the shared variable inside the class. Which
solution you prefer is a matter of programming style.

Source : http://www.agner.org/optimize/ le premier PDF.

Vu le conseil donné ici de complètement éviter les variables globales (non constantes), je me demandais si le fait de les encapsuler dans des espaces de nom n'aidait pas à indiquer au compilo de ne pas charger en permanence les dites variables (a ce que j'ai compris). Ou bien les espaces de noms sont-ils uniquement gérés comme des extension des noms des variables?

Je me demandais ça parceque la configuration (provenant d'un .ini) de mon application est actuellement reflétée par des variables globales (les seules de l'application si on omet les membres statiques de classes) qui peuvent potentiellement être modifées par pas mal de code différent, donc ça me semblait plus naturel de simplement les encapsuler dans un namespace plutot que de faire une classe avec uniquement des membres statiques (vu que je ne veux pas d'instanciation). (note : ce ne sont que des types de bases ou des std::string)

Je me demande aussi si ça vaut vraiment le coup de se poser la question : est-ce que ça peut vraiment plomber des perfs globales a cause de l'impact sur la stack ou est-ce que c'est tellement mineur que je peux oublier jusqu'à ce que ça pose de manière évidente un problème de perf?

[JolyLoic]

Qu'elles soient globales dans ::, globales dans un namespace, ou variables statiques de classe n'a à mon avis absolument aucun impact en terme de perfs. Et en terme de qualité de design du code non plus : C'est aussi problématique dans un cas que dans l'autre.

[zais_ethael]

Je ne sais pas d'où tu tires ce petit speech, mais il n'est pas génial.
Pour ce qui est de l'utilisation mémoire, ça revient bien entendu au même d'initialiser une donnée au début du main -> si c'est utilisé dans tout le programme ça occupe inévitablement de la mémoire pendant toute l'exécution du programme.
Et pour ce qui est de l'aspect multithread, et bien il se trouve justement qu'elles sont bien souvent la cause de problème dans ces programmes (haaa, les fonctions de manipulation de date en C).
Pour résumer grossièrement, le seul cas qui nécessite réellement une variable globale ou statique (statique, en C++, c'est mieux) c'est lors de l'utilisation d'un pattern singleton (et encore, faut protéger ça à coup de mutex quand on est un programmeur consciencieux, et ça ça a un impact sur les perfs).

[Alp]

Pour résumer grossièrement, le seul cas qui nécessite réellement une variable globale ou statique (statique, en C++, c'est mieux) c'est lors de l'utilisation d'un pattern singleton (et encore, faut protéger ça à coup de mutex quand on est un programmeur consciencieux, et ça ça a un impact sur les perfs).

Je suis malheureusement tout à fait d'accord

[Klaim]

Ok donc j'ai pas trop a m'en soucier finalement...

Au passage l'auteur du document dit aussi que les appels fonction de DLL sont plus lent que les appels aux fonctions en statique. On m'avait dit le contraire (comme quoi une fois les dll chargé en mémoire ça revenais au même).
En lisant ça du coup je commence a douter. Est-ce que quelqu'un peut me copnfirmer dans un sens ou un autre?

Ya des infos d'optimization interessantes dans ce doc mais ya des parties sur lesquelles j'ai de sérieux doute par rapport a ce que j'ai lu autre part....

[ram-0000]

Je ne voie pas en quoi appeller un fonction dans une DLL serait plus long que d'appeler cette meme fonction dans le programme (je ne suis même pas sûr que ce que je viens de dire aie un sens ).

Attention, je dit bien "APPELER", pas "CHARGER" la DLL car le temps de chargement d'une DLL et le process de relocation des appels n'est pas nul.

[Klaim]

Oui je parle bien d'appeler.

D'après l'auteur, page 16 :

It takes longer time to call a function in a dynamic link library than in a static link library
because it needs an extra jump through a pointer in an import table.

Et plein d'autres choses que je savais pas comme par exemple :

The memory space becomes more fragmented when the code is distributed between
multiple DLLs. The DLLs are always loaded at round memory addresses divisible by
the memory page size (4096). This will make all DLLs contend for the same cache
lines. This makes code caching and data caching less efficient.

[wiztricks]

Bonsoir,

Les recommandations faites ou les points à surveiller dans les développements me semblent raisonnables et sa lecture est intéressante.

1 - Il préfére une allocation dans la pile d'exécution plutôt que des accès aux variables globales parce que le haut de la pile sera probablement dans le cache L1 du CPU.

2 - Les appels de fonctions DLL signfie une indirection via la table des vecteurs qui décrit les points d'entrées de la DLL. Ca fait deux acces mémoires de trop. Il préfère les libraries statiques: ca fait du code plus compact.

3 - Les DLLs sont mappés sur des frontières de pages. Ca peut faire des collisions dans le cache L2. Si on doit passer par des DLLs, préférer de grosses DLL à plein de petites.

Ceci dit, comme toutes optimisations est ce que çà va apporter plus de performances (suivant le soft bien sûr, mais est ce que c'est important pour des softs lambda?) à condition de ne pas trop sacrifier à la maintenabilité et aux coûts de développements.
=> Sans oublier qu'on tirera plus de performance d'un CPU en évitant de... cela reste à arbitrer avec d'autres aspects qui ne sont pas toujours compatibles.
- W

[Klaim]

Ok je vais donc continuer a lire tout ça pour savoir et m'en servir si j'ai besoin d'optimizations plus tard.

[nicroman]

1 - Il préfére une allocation dans la pile d'exécution plutôt que des accès aux variables globales parce que le haut de la pile sera probablement dans le cache L1 du CPU.

Sauf que la pile n'est pas extensible à l'infini.... (tout comme le cache L1)...
Et j'ai déjà vu de pietres programmeurs ne pas comprendre pourquoi leur char[8192] déclaré dans la pile cassait leur programme....

2 - Les appels de fonctions DLL signfie une indirection via la table des vecteurs qui décrit les points d'entrées de la DLL. Ca fait deux acces mémoires de trop. Il préfère les libraries statiques: ca fait du code plus compact.

Faux... Les processeurs ont une fonction de call avec indirection depuis belle lurette... Le code est donc nullement 'plus compact'. "Eventuellement" il peut y avoir un cache-miss à la lecture de la table d'indirection... Et du jour ou la fonction est une methode virtuelle de classe, que la fonction soit en DLL ou non ne change plus rien du tout (même indirection utilisée dans les deux cas). Et programmer en C++ sans utilisation de fonction virtuelle, c'est un peu comme faire du Visual Basic pour Linux

[JolyLoic]

A mon avis, un des coûts principaux en terme de perf d'une DLL, c'est que le programme ne peut pas inliner les appels.

Le coût principal en terme de gestion, c'est qu'on doit gérer plein de fichiers au lieu d'en gérer un seul.

[Emmanuel Deloget]

Pour résumer grossièrement, le seul cas qui nécessite réellement une variable globale ou statique (statique, en C++, c'est mieux) c'est lors de l'utilisation d'un pattern singleton (et encore, faut protéger ça à coup de mutex quand on est un programmeur consciencieux, et ça ça a un impact sur les perfs).

std::cout ? (+ version wchar_t)
std::cin ? (+ version wchar_t)
std::cerr ? (+ version wchar_t)
std::clog ? (+ version wchar_t)

Pour ma part, je ne pense pas que le pattern singleton ajoute quoi que ce soit à une instance globale (et il n'y a pas de réelle différence entre une statique de classe et une instance globale).

[wiztricks]

Sauf que la pile n'est pas extensible à l'infini.... (tout comme le cache L1)...
Et j'ai déjà vu de pietres programmeurs ne pas comprendre pourquoi leur char[8192] déclaré dans la pile cassait leur programme....

Le propos ici est de se servir de la localité dans le cache L1 et d'arbitrer entre l'usage de variable déclarées dans la pile par rapport à des variables globales.
Le fait est que pour aller dans L1, il va falloir référencer la mémoire... pas seulement déclarer la variable. Ce qui peut éventuellement aider c'est la taille des chunks avec laquelle la mémoire est transférée dans le cache et la réduction du nombre de collisions qu'il peut y avoir dans le cache lorsque les adresses sont contigues (vs. ailleurs).

Faux... Les processeurs ont une fonction de call avec indirection depuis belle lurette... Le code est donc nullement 'plus compact'. "Eventuellement" il peut y avoir un cache-miss à la lecture de la table d'indirection... Et du jour ou la fonction est une methode virtuelle de classe, que la fonction soit en DLL ou non ne change plus rien du tout (même indirection utilisée dans les deux cas). Et programmer en C++ sans utilisation de fonction virtuelle, c'est un peu comme faire du Visual Basic pour Linux

Plus compact est dans le cas d'utilisation de librairies statiques. Lorque qu'on a une DLL, on mappe dans l'espace virtuel toute la DLL et pas seulement les routines qui nous interressent.

Dans le cas d'une librairie statique, un génére un 'gros' exécutable n'incluant que les fonctions appellées.
On peut relativiser la comparaison en disant que la mémoire virtuelle ne coûte pas cher et que nous n'aurons en mémoire physique que les fonctions appelées.

Tu conviendras que l'appel d'une routine qui est dans une DLL coute une indirection qui n'existe pas lorsqu'on appelle une fonction dans une librarie statique.

- W

[JolyLoic]

Pour ma part, je ne pense pas que le pattern singleton ajoute quoi que ce soit à une instance globale.

Plus de possibilité sur l'ordre d'initialisation des données.

[philmor34]

faut relativiser pour les appels dll qui sont plus lents.

générallement, tu utilise que quelques fonctions de la DLL dans ton code, et les fonctions de la DLL appelle les fonctions dans la DLL, qui celles-là, n'ont pas besoin de passer par la table d'indirection

et j'ai comparé il y a quelques semaines la différence sur plusieurs appels de fonctions dans une DLL contre une dans une statique, la différence était minime.

quand tu développe, tu dois pas te préoccuper de l'optimisation de ton code, mais seulement arriver a quelque chose qui fonctionne. Ensuite, tu utilise un programme pour voir ou tu peut optimiser ton code

parce qu'en général, les ralentissements ne sont pas là ou tu pense

[loufoque]

De manière générale dès qu'on fait un truc qui ressemble un peu à un DSEL où on introduit des terminaux il faut des variables globales.
Les iostreams ont déjà été cités.
Pour lambda/phoenix, il faut les placeholders et toutes les fonctions lazy, qui sont des instances de foncteurs.
On peut aussi penser à des adapteurs de ranges, etc.

[nicroman]

Tu conviendras que l'appel d'une routine qui est dans une DLL coute une indirection qui n'existe pas lorsqu'on appelle une fonction dans une librarie statique.

En C oui... peut être (et encore... le cout est vraiment minime).
Mais prenons un cas "classique" d'utilisation de DLL en C++:

Code "Executable"

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
 
interface IMonObjet
{
      virtual void   faisQuelqueChose() = 0;
};
typedef IMonObject* __cdecl (*CreateObject_func)(void);
 
 
void MaFonction(IMonObjet* pObj)
{
    for (int i = 0; (i < 100000); ++i)
        pObj->faisQuelqueChose(i);
}
 
 
void main()
{
    // exemple... on peut faire du DLL import aussi
    // pseudo-code... pas les fonctions Windows
    dll = LoadLibrary(dllName); 
    CreateObject_func func = GetProcAddress(dll,"CreateObject");
    IMonObject* pobj = (*func)();
    MaFonction(pobj);
}

Code de la DLL:

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
 
interface IMonObjet
{
      virtual void   faisQuelqueChose(int ) = 0;
};
typedef IMonObject* __cdecl (*CreateObject_func)(void);
 
 
 
class DllObject : public IMonObjet
{
      virtual void faisQuelqueChose(int );
};
 
 
extern "C" {
IMonObject* CreateObject()
{
     return new DllObject();
}
}
CreateObject_func  CreateObject_typeCheck = &CreateObject;

Je te mets au défi de trouver une différence de rapidité avec la version statique !
En effet, l'indirection à l'appel de la fonction se fait par rapport à la table virtuelle, et n'ajoute aucune indirection supplémentaire.


Attention, je ne dis pas... faites des DLLs pour faire des DLLs... Si c'est juste pour faire pouet pouet sans complètement cacher les implémentations, ça n'a aucun interêt... L'interêt de la DLL est vraiment de pouvoir la remplacer à tout moment, sans que le client (l'executable) en sois informé...

[wiztricks]

Les DLL C++ présentent souvent la particularité de ne pouvoir être appelées que via un wrapper C. Ce wrapper ajoute déjà suffisament d'overhead...
S
i en plus on fait un binding "on call" plutôt que de faire faire un binding "on load" (par le loader)...
Ca fait quand même pas mal d'overhead explicites.
- W

[Klaim]

Les DLL C++ présentent souvent la particularité de ne pouvoir être appelées que via un wrapper C

Wrapper? O___o

Je m'y connais pas trop mais de loin ça ressemble juste à une difference de nomage dans les symboles générés, non?

[Médinoc]

Convention de nommage, ET convention d'appel: Rien de tout cela n'est standardisé pour le C++ sous Windows 32 bits.
Ainsi, une DLL C++ compilée avec un compilo sous certains réglages ne marchera pas sous un autre compilo, voire même sous le même compilo avec des réglages différents!

Le code de nicroman résout presque le problème et suffit à la plupart des cas.
Mais pour une compatibilité garantie, il faut faire un objet COM (les méthodes doivent avoir la convention d'appel __stdcall, et ne pas retourner d'objets par valeur), voire un objet COM automation-compatible (encore plus de restrictions sur les types de paramètres, méthodes retournent forcément un HRESULT).