"Reste alors à vérifier par exemple qu'il ne s'agit pas de tas de petites allocations de ~1-8 octets (métrique min_size)"
Il y a des gens qui font des allocations de 8 octets ?! Une si petite allocation implique l'utilisation massive de pointeurs, qui prennent de la place, qui implique beaucoup d'indirection dans la mémoire, et une utilisation des mémoires caches toutes pourris (une ligne de cache L1 est de 32 octets, cela veut dire qu'à chaque lecture, 32 octets sont transférés). Le CPU et gcc veulent des gros morceaux de mémoire (multiple de 2 ou 4 Mo, pour utiliser les 'huge' pages) avec des accès séquentiels ou avec un pattern qui peut se prédire, de 32 ou 64 octets. De préférence, il faut grouper lectures, puis écritures, pour éviter de forcer l'unité mémoire à vérifier, que l'on ne relit pas, ce que l'on est en train d'écrire, ce qui créé des cycles d'attentes.
[^] # Re: J’ai testé MALT
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Profileurs mémoire MALT et NUMAPROF. Évalué à 3.
Il y a des gens qui font des allocations de 8 octets ?! Une si petite allocation implique l'utilisation massive de pointeurs, qui prennent de la place, qui implique beaucoup d'indirection dans la mémoire, et une utilisation des mémoires caches toutes pourris (une ligne de cache L1 est de 32 octets, cela veut dire qu'à chaque lecture, 32 octets sont transférés). Le CPU et gcc veulent des gros morceaux de mémoire (multiple de 2 ou 4 Mo, pour utiliser les 'huge' pages) avec des accès séquentiels ou avec un pattern qui peut se prédire, de 32 ou 64 octets. De préférence, il faut grouper lectures, puis écritures, pour éviter de forcer l'unité mémoire à vérifier, que l'on ne relit pas, ce que l'on est en train d'écrire, ce qui créé des cycles d'attentes.
"La première sécurité est la liberté"