Les variables statiques entravent-elles la mise en cache des données?

En général, Agner Fog sait généralement de quoi il parle.

Si nous lisons la citation dans le contexte de la section 7.1 Différents types de stockage de variables , nous voyons ce qu'il entend par " mise en cache moins efficace " au début du section:

La mise en cache des données est médiocre si les données sont dispersées au hasard dans la mémoire. Il est il est donc important de comprendre comment les variables sont stockées. Les principes de stockage sont les idem pour les variables simples, les tableaux et les objets.

Donc, l'idée derrière le fait de dire que les variables statiques sont moins efficaces en cache est que la probabilité que l'emplacement mémoire où elles sont stockées soit "froide" (plus dans le cache) est plus grande qu'avec pile memory, où la variable avec une durée de stockage automatique serait stockée.

En gardant à l'esprit la mise en cache et la pagination, c'est la combinaison de la localisation physique et temporelle du stockage des données qui affecte les performances.

La déclaration a ou n'a pas de sens selon la façon dont vous la ponctuez:

Lecture 1:

L'avantage des données statiques est qu'elles peuvent être initialisées aux valeurs souhaitées avant le démarrage du programme. L'inconvénient est que l'espace mémoire est occupé pendant toute l'exécution du programme, même si la variable n'est utilisée que dans une petite partie du programme.

Tout ce qui précède rend la mise en cache des données moins efficace.

C'est insensé.

Lecture 2:

L'avantage des données statiques est qu'elles peuvent être initialisées aux valeurs souhaitées avant le démarrage du programme.

L'inconvénient est que l'espace mémoire est occupé pendant toute l'exécution du programme ...

... même si la variable n'est utilisée que dans une petite partie du programme. Il y a un cas où cela pourrait rendre la mise en cache des données moins efficace.

Ce cas serait où la variable statique a été allouée de stockage soit dans une page qui n'est pas toujours permutée, soit sur une ligne de cache qui est rarement utilisée autrement. Vous pouvez subir un manque de cache, ou théoriquement dans le pire des cas une erreur de page (bien que franchement, avec la quantité de mémoire physique à notre disposition ces jours-ci, si cela se produit, vous avez de plus gros problèmes). cas particulier que vous démontrez, la réponse serait "ça dépend".

Oui, l'initialisation de static_arr est une opération unique et peut donc être considérée comme sans coût.

Oui, l'initialisation de local_arr se produit chaque fois que la fonction est appelée, mais il se peut que ce soit:

1. cette initialisation est triviale, ou
2. l'initialisation est élidée par le compilateur dans le cadre d'une passe d'optimisation

En général, sauf si vous avez une optimisation spécifique en tête, il est préférable (tm) d'écrire le code qui énonce explicitement le comportement que vous voulez, c'est-à-dire:

• utiliser des variables statiques (variables avec une durée de stockage statique) lorsque la ou les valeurs de la variable / tableau doivent survivre à des appels successifs à la fonction.

• utiliser des variables locales (strictement, des variables avec une durée de stockage automatique) lorsque les valeurs existantes n'ont pas de sens à l'entrée ou à la sortie de la fonction.

Vous constaterez que le compilateur fera dans presque tous les cas la chose la plus efficace après les passes d'optimisation.

Il existe un cas particulier où l'initialisation statique est meilleure (tm). Dans le cas (par exemple) d'un tampon qui nécessite une allocation dynamique. Vous ne voudrez peut-être pas encourir le coût de l'allocation / désallocation à chaque appel. Vous voudrez peut-être que la mémoire tampon augmente dynamiquement lorsque cela est nécessaire, et qu'elle continue de croître, car les opérations futures pourraient bien avoir besoin de la mémoire à nouveau.

Dans ce cas, l'état réel de la variable est la taille de celle qui lui est allouée. tampon. Ainsi, l'état est important sur l'entrée et la sortie de la fonction, par exemple:

  std::string const& to_string(json const& json_object)
  {
    static thread_local buffer;               // thread-safe, auto-expanding buffer storage
    buffer.clear();                           // does not release memory
    serialise_to_string(buffer, json_object); // may allocate memory occasionally
    return buffer;
  }

La réponse de rustyx l'explique. Les variables locales sont stockées sur la pile. L'espace de pile est libéré lorsqu'une fonction retourne et réutilisé lorsque la fonction suivante est appelée. La mise en cache est plus efficace pour les variables locales car le même espace mémoire est réutilisé encore et encore, tandis que les variables statiques sont dispersées à différentes adresses mémoire qui ne peuvent jamais être réutilisées à d'autres fins. Que les données statiques soient stockées dans la section DATA (initialisée) ou dans la section BSS (non initialisée) ne fait aucune différence à cet égard. L'espace du haut de la pile restera probablement mis en cache tout au long de l'exécution du programme et sera réutilisé plusieurs fois.

Un autre avantage est qu'un nombre limité de variables locales est accessible avec un décalage de 8 bits par rapport au pointeur de pile, tandis que les variables statiques ont besoin d'une adresse absolue 32 bits (en 32 bits x86) ou d'une adresse relative 32 bits (en x86-64). En d'autres termes, les variables locales peuvent rendre le code plus compact et améliorer l'utilisation du cache de code ainsi que du cache de données.

// Example
int main () {
  f();
  g();
  return 0;
}

void f() {
   int x; 
   ...
}

void g() {
   int y;  // y may occupy the same memory address as x
   ...
}