juste curieux s'il y a un effet sur les performances lors de l'itération / l'accès aux objets de la liste. Je veux supposer qu'il n'y aurait pas de différence, mais toujours curieux.
3 Réponses :
Le deuxième cas peut être plus rapide si vous allouez une mémoire comme celle-ci: une structure près d'autres. En conséquence, la CPU peut lire des structures dans une seule ligne de cache.
Si vous avez alloué beaucoup de littlestract s en succession rapide. S'il y a d'autres allocations entre les deux, ils pourraient être également fragmentés
dépend de la manière dont vous allouez les nœuds.
Si vous allouez les nœuds d'un pool de mémoire de sorte que les nœuds ont une localité élevée, les nœuds plus faibles en permettent davantage d'entre eux de s'adapter au cache de la CPU ou à une page de mémoire, ce qui réduirait la fréquence des fautes de cache et des défauts de page. < / p>
Si les nœuds n'ont pas de localité élevée, la taille n'a pas d'importance pour l'itération de la liste. Ceci est susceptible d'être le cas lorsque vous utilisez l'allocator global (I.E. Pour savoir s'il a un effet significatif dans votre programme, vous pouvez le mesurer.
P.s. Si vous vous souciez de la performance, il y a une bonne chance que la liste liée ne soit pas la meilleure structure de données pour vous. STD :: MALLOC ) pour chaque nœud.
Comment puis-je le mesurer?
@ Scottc11 Utilisez une horloge pour mesurer la durée de fonctionner pour votre programme. Modifiez le programme pour utiliser le nœud plus grand et mesurer à nouveau. Répétez la mesure plusieurs fois et utilisez des statistiques pour déterminer s'il existe une différence significative. Il existe de nombreuses subtilités à l'analyse comparative, alors prenez vos résultats avec un grain de sel.
@erorika: L'analyse comparative significative est devenue extrêmement difficile dans les systèmes modernes, car les variations subtiles de ce que font le code extérieur peut avoir des effets énormes sur la performance. Si, par exemple, un allocator arrive à aligner des objets 1,5 lignes de cache de taille aux limites de la ligne de demi-cache et qu'un programme alloue de nombreuses paires d'objets de ligne de cache de cache, mais utilise les objets de chaque paire différemment, la question Sur quels objets commencent sur une limite de la ligne de cache pourraient avoir un impact énorme sur la performance.
Les meilleures performances peuvent être obtenues si les structures sont suffisamment petites que plusieurs d'entre elles peuvent s'intégrer dans une ligne de cache et que l'allocation est faite de manière à le rendre probable que les structures accessibles bientôt après l'autre. être placé dans la même ligne de cache.
Si les structures sont beaucoup plus grandes que les lignes de cache, les meilleures performances peuvent être obtenues en garantissant que des parties d'une structure qui seront souvent accessibles en succession seront proches les unes des autres.
considérer les trois structures suivantes: comme accessible par la boucle suivante: la performance du Deuxièmement, il sera probablement beaucoup mieux que celui du premier depuis le premier engager deux cachettes pour la plupart des itérations de la boucle alors que la seconde n'enferait qu'une seule. Si la petite taille permettrait aux structures d'être placées proches les unes des autres, la performance du troisième pourrait être encore meilleure que la seconde lors du traitement de la boucle ci-dessus (éventuellement entraînant une moyenne inférieure à une cache Miss par itération), mais bien pire que la seconde lors de l'accès des premiers éléments de Notez que les points de repère de performance seront probablement trompeurs à moins qu'ils ne se produisent pas dans des conditions "du monde réel". Il est peu probable que dat (puisque la structure dans le cache apporterait également les premiers éléments de dat lors de l'utilisation du deuxième formulaire, mais pas lorsque Utilisation du troisième). struct S2 effectuerait pire que S1 sous la plupart des conditions du monde réel, mais les performances relatives entre S2 et S3 < / code> pourrait être significativement affecté par les variations subtiles de ce que fait le code extérieur.
Vous dites: "Est-ce important". La matière dans quel sens?
désolé je voulais dire pour la performance - titre modifié
À partir d'un List Traversal Standard - Peu importe la taille de votre structure. Toute la liste contient est un pointeur sur le nœud. Ce nœud peut contenir 1-Char et votre pointeur
-> Suivant ou peut contenir à la structure de 1024 membres - le pointeur n'est toujours qu'un pointeur. La différence sera vue dans la fonction Create-noeud où vous devez allouer et initialiser tous les membres de la structure et toute autre fonction où vous devez manipuler les membres de la structure. Mais cela n'a aucune incidence sur la rapidité avec laquelle une traversée de base sera.Si vous avez une raison en termes de ressources de mémoire, il est clair que dans le premier cas, vous consommerez plus de ressources. Du côté du processeur, cela dépend de la partie // fait des trucs si vous avez plus d'éléments de structure, vous risquez de faire plus de choses, de sorte que vous consommerez plus de CPU. Concernant
côté = temp-> suivant ; Pas de changement, que votresuivant point sur 1 octet ou 100Mo, il a concédé d'incrément de pointeur