Creuser autour de dans le références sur le amas sous Windows (ainsi que un peu de infosec articles sur le sujet), il y a quelques informations sur ralentissements courants du tas qui stipule que quelques-uns sont
- Ralentissement suite à des opérations de répartition.
- Ralentissement suite à des opérations libres.
- Ralentissement dû à des allocations et réallocations fréquentes.
Ce qui aide à expliquer pourquoi il y a un ralentissement (c'est-à-dire des allocations et réallocations fréquentes), mais cela n'explique pas réellement pourquoi il y a un ralentissement.
La première chose à noter est que sizeof(long) != sizeof(long) c'est-à-dire, dans les tests que j'ai effectués avec des constructions 64 bits utilisant g++ et Visual Studio 12, sizeof(long) sur Windows était 4 et sous Linux, c'était 8 . Il s'agit d'une remarque importante lors de l'allocation/désallocation de la mémoire. Si vous modifiez votre code à partir de la version long à un type où sizeof(T) == 8 (comme long long ), le problème disparaît et les temps sont cohérents entre les itérations. Exemple :
void iteration() {
int n = 25000;
// Allocate memory
long long** blocks = new long long*[n];
for (int i = 0; i < n; ++i) {
blocks[i] = new long long[100008];
}
// Free all allocated memory
for (int i = 0; i < n; ++i) {
delete[] blocks[i];
}
delete[] blocks;
}
// sizeof(long long) == 8 on my Linux/Unix and Windows 64-bit machines
Il convient également de noter que le problème de synchronisation ne disparaît que dans les cas suivants exactement ce code.
Si vous gardez le type de long long mais ajusté 100008 pour dire 16666 le problème se pose à nouveau ; en outre, si vous le changez en 16668 et a exécuté le long long immédiatement suivie par l'itération long version, le timing serait en haut pour le long long la fonction, alors en bas pour le long par exemple :
template < typename T >
void iteration() {
int n = 25000;
// Allocate memory
T** blocks = new T*[n];
for (int i = 0; i < n; ++i) {
blocks[i] = new T[16668];
}
// Free all allocated memory
for (int i = 0; i < n; ++i) {
delete[] blocks[i];
}
delete[] blocks;
}
for (int i = 0; i < nbItrs; ++i) {
iteration<long long>(); // time goes UP
}
for (int i = 0; i < nbItrs; ++i) {
iteration<long>(); // time goes DOWN
}
De plus, le code affiché produit des résultats similaires en utilisant malloc / free , LocalAlloc / LocalFree et/ou HeapAlloc / HeapFree depuis new / malloc (sous Windows) appelle HeapAlloc . La raison est liée à la façon dont Windows gère sa mémoire de tas et les emplacements de la mémoire libérée. Lorsque des pages doivent être supprimées, un nettoyage de la liste des blocs libres doit être effectué et la liste doit être ajustée en conséquence.
C'est cet ajustement qui peut prendre du temps, pendant la recherche et le remplacement ou la suppression des anciens blocs de mémoire de la liste. Si les blocs ne tombent pas sur des frontières propres, il peut être nécessaire de procéder à des ajustements supplémentaires de la liste des blocs libres du tas.
Pour approfondir le pourquoi et le comment de la gestion du tas de Windows, il faudrait expliquer la conception du noyau de Windows et sa gestion de la mémoire. Cela dépasserait le cadre de cette question/réponse, un peu de de la articles J'ai fait le lien avec au-dessus de ont d'excellentes vues d'ensemble et expliquent très bien le comment et le pourquoi.
Cependant, vous avez demandé
comment faire pour que le code soit stable sous Windows ?
Comme indiqué plus haut, le changement de type permettrait d'obtenir un calendrier plus cohérent. réponse En supprimant la liste dans l'ordre inverse, vous obtiendrez également des temps plus cohérents ;
for (int i = n; i > 0; --i )
{
delete[] blocks[i-1];
}
Cela est dû au fait que le gestionnaire de mémoire de Windows utilise une liste singulièrement liée pour maintenir les emplacements du tas, ce qui explique pourquoi les temps peuvent augmenter lorsque le programme est en cours d'exécution. delete C'est pourquoi les temps peuvent être plus lents sous Windows que sous Linux (bien que mes tests aient produit des temps similaires dans les deux cas).
J'espère que cela pourra vous aider.
