Stocker des données efficacement

Question

peut-être que j'ai une question stupide comme toujours, mais de toute façon je ne peux pas google out comment dois-je stocker les variables de sorte qu'il est efficace. Notre professeur sur C++ a juste laissé tomber quelque chose sur la façon dont la taille du type de données stockées pouvait affecter la vitesse de stockage (comme la recherche du bloc de mémoire continue le plus proche) et j'aimerais en savoir plus. Pourriez-vous s'il vous plaît me donner quelques indications?

Answer 1

En général, pour les variables numériques (telles que les compteurs de boucles), vous devez utiliser "int" et laisser le compilateur choisir la taille la plus efficace pour la tâche. Si vous avez un besoin particulier pour une taille spécifique (par exemple uint16 pour une partie de 16 bits d'un en-tête de paquet reçu sur un réseau, ou similaire), utilisez un typedef qui donne cette taille spécifique sur votre plate-forme spécifique; sinon, utilisez simplement int. Cela dit, il semble que votre professeur ait parlé d'allocateurs de mémoire dynamique (c'est-à-dire le code derrière "malloc" et "free"). Si vous demandez d'allouer 64 octets, disons, l'allocateur est chargé de vous fournir un bloc d'au moins cette taille, et de garder une trace de celui-ci afin qu'il puisse être retourné au stockage disponible quand il est libéré. Il ya beaucoup d'informations à ce sujet, par exemple sur Wikipedia ici: http://en.wikipedia.org/wiki/Dynamic_memory_allocation

Answer 2

Voulez-vous dire stockage persistant ou allocation en mémoire? En mémoire, la structure de données que vous définissez, la façon dont vous allouez de la mémoire pour votre structure de données (tas ou pile) au compilateur que vous utilisez et la norme C++ déterminent ensemble comment la mémoire est allouée.

Le stockage persistant est une histoire tout à fait différente.

Answer 3

Comment stocker les variables est rarement à vous. Mais le type, et par conséquent la taille, d'une variable est souvent à vous.

Il se réfère peut-être à des choses comme "si vous avez besoin de stocker un petit nombre entier, comme une adresse de rue, vous ne devriez probablement pas utiliser un long, mais plutôt un short". Ces choses ont tendance à exiger un peu de connaissance du domaine, il est facile de vous optimiser dans un coin (pensez au problème de l'an 2000, par exemple).

Answer 4

L'une des façons consiste à utiliser des types de variables. Il n'est pas nécessaire de stocker une valeur de 1 à 10 dans un int64. L'idée est de faire correspondre les valeurs possibles d'une variable avec un type de variable qui correspond le mieux à ses valeurs possibles. Cela réduira la mémoire utilisée et, dans des structures de données plus complexes, réduira la vitesse de traitement.

Answer 5

La vitesse d'écriture et de récupération des données sera influencée par les performances de votre mécanisme de stockage local. Sur les CPU modernes il y a des registres, 2 niveaux de cache (L1 & L2), DRAM et parfois disque (via swap). Si les motifs d'accès et la taille utilisent effectivement le cache Ll (c'est-à-dire petit et localement cohérent), une fois que les données sont dans L1, il suffit de les charger dans les registres auxquels la CPU doit accéder. Si les données requises sont dans le cache L2, elles doivent d'abord être chargées dans L1 avant d'être chargées dans un registre pour traitement. La même chose vaut pour DRAM à L2 à L1 pour les registres. Les registres sont plus rapides que L1, L1 est plus rapide que L2, et DRAM est juste lent.

Herb Sutter a prononcé un discours qui aborde ces questions il y a plusieurs années à NWCPP:

http://video.google.com/videoplay?docid=-4714369049736584770#

Du point de vue de la programmation, si vos données peuvent adapter à l'intérieur d'une ligne de cache et doit être à plusieurs reprises accès ou écrit à, vous aurez des performances plus élevées en raison de moins d'échecs de cache (résultant dans le besoin de récupérer à partir d'un niveau supérieur de cache).Cela est vrai pour tous les niveaux de "cache" qu'ils soient des registres, L1, L2, DRAM, disque ou un serveur lointain.

Answer 6

Ce que votre enseignant voulait probablement dire, c'est que lorsque vous allouez un objet sur le tas (avec new) tout le processus a tendance à être plus lent, plus l'objet est gros. J'ai écrit a little program pour mesurer cet effet.

Voici les résultats que je reçois (Compilé en mode de déclenchement avec VS2008 et optimisations désactivé):

Cost of allocating 1 chars: 0.104 microseconds 
Cost of allocating 4 chars: 0.1 microseconds 
Cost of allocating 16 chars: 0.104 microseconds 
Cost of allocating 64 chars: 0.128 microseconds 
Cost of allocating 256 chars: 0.192 microseconds 
Cost of allocating 1024 chars: 0.416 microseconds 
Cost of allocating 4096 chars: 1.28 microseconds 
Cost of allocating 16384 chars: 2.56016 microseconds 
Cost of allocating 65536 chars: 3.0722 microseconds 
Cost of allocating 262144 chars: 3.58423 microseconds 

Ainsi, votre professeur avait raison, l'attribution d'énormes objets peut être beaucoup plus lent que d'allouer des objets de taille normale (mais très vite néanmoins, on parle de quelques microsecondes dans le pire des cas).