Nous avons commencé à compiler des versions 32 et 64 bits de certaines de nos applications. L'un des gars de mon projet nous encourage à changer tous nos entiers 32 bits à leurs équivalents de 64 bits, même si les valeurs sont garanties dans un espace 32 bits. Par exemple, j'ai une valeur garantie de ne jamais dépasser 10 000 que je stocke dans un Int non signé. Sa recommandation est de le changer à une taille_t afin de s'étendre à 64 bits dans un environnement 64 bits, même si nous n'aurons jamais besoin de l'espace supplémentaire. Il dit que l'utilisation de variables de 64 bits accélérera l'application quelles que soient les valeurs stockées dans chaque variable. Est-ce qu'il a raison? Il s'agit d'être beaucoup de travail et je ne suis pas impatient de mettre dans l'effort s'il ne fait pas de différence.
Nous utilisons Microsoft Visual C ++ 2008. Je suis un peu en espérant une réponse plus générale indépendante de la plate-forme.
Alors, que pensez-vous? N'avons-nous raison de passer du temps à changer nos types de données pour des raisons de performance plutôt que des raisons d'amplitude?
6 Réponses :
Je pense que vous avez un énorme cas d'optimisation pré-mature vous fixant au visage. Ne faites jamais de micro changements comme celui-ci dans votre application jusqu'à ce qu'un profileur vous ait définitivement dit qu'il s'agit d'une source de problèmes de performance significatifs.
Sinon, vous passerez beaucoup de temps Fixation non-problèmes.
Eh bien, si les opérations 32 bits se déroulent dans des registres 64 bits, certaines instructions supplémentaires doivent être émises pour gérer des objets tels que la fixation des drapeaux de transport / débordement, etc. Je serais surpris si vous avez réalisé une performance notable. amélioration, cependant. Je peux tout sauf que vous garantissez qu'il y a des goulots d'étranglement bien pires dans votre programme.
Est-ce vrai sur x64? Je ne suis pas assez familier avec le niveau de montage à savoir, mais ce serait un peu surprenant pour moi. Je sais que la question ne demande pas de spécificités x64, mais je suis curieux de savoir.
Hm, c'est une bonne question. Je devrais sortir des livres et vérifier. Comme vous pourriez imaginer, cela ne valait jamais la peine de déterminer. Je suis loin plus familier avec le bras, et sur cette architecture, en utilisant la taille natale est beaucoup mieux en ce qui concerne le code de Code. Travailler avec des types de 8 bits provoque toutes sortes d'opérations de masquage et de changement supplémentaires pour apparaître dans le code. Cela dit, il n'a pas tendance à avoir une incidence sur la performance significative.
Je m'attendrais également à ce que les opérations 32 bits soient effectuées via des instructions spécifiques à 32 bits qui s'occupent des drapeaux de transport / débordement. Mais je ne sais pas!
@rstevens, j'ai pensé à cela aussi; L'un des avantages d'avoir un ensemble d'instructions complexes!
Lol, je peux garantir qu'il y a des empoisonneurs aussi!
Je suppose (et c'est juste une hypothèse) que vous ne verrez probablement aucune amélioration de la performance et que vous pouvez voir une légère chute si la quantité d'augmentation de la mémoire entraîne un accès à la mémoire de perdre la localité de référence et de pousser les choses de la mémoire la cache plus souvent qu'avant.
comme JaredPar dit , s'il n'y a pas de raison factuelle de le faire ou si vous avez besoin de la portée accrue du plus grand Ints, c'est probablement une perte de temps.
L'idée que l'utilisation d'un entier 64 bits vs. Un entier 32 bits accélérera les choses en place est un mythe. La chose la plus importante dans votre code est d'utiliser les types appropriés. Par exemple, lorsque vous faites référence à la taille d'une matrice ou d'une structure de données, utilisez un Ne changez pas simplement tout pour tout changer en taille_t parce que c'est ce qu'un taille_t est censé représenter. Si vous stockez une partie de données, utilisez un int et non un Taille_t car c'est ce qu'un int est destiné à décrire. < / p>
Taille_T car il "deviendra automatiquement 64 bits", cela n'entraînera probablement aucune amélioration. Cela entraînera une augmentation de la mémoire plus grande qui provoquera probablement ralentir la ralentissement du fait que le cache manque de cache à cause de l'espace mémoire plus important. Il va également probablement causer des bugs inattendus.
Tout d'abord, l'utilisation d'INT 64 bits au lieu d'une INT de 32 bits dans un environnement 64 bits ne sera généralement pas accélérer. Selon le contexte et sur les capacités du compilateur, cela pourrait effectivement ralentir les choses. Normalement, vous préférez utiliser l'utilisation de (code> int / Deuxièmement, quiconque conseille d'utiliser non signé afin de stocker des valeurs intégrales dans votre programme, de passer à d'autres types uniquement lorsque cela est vraiment nécessaire. En fin de compte, la réponse définitive à la question ne peut être obtenue que par une expérience réelle, car elle dépend trop de variables.
taille_t à cette fin (en tant que type générique non signé) doit être immédiatement refusé l'accès au code et envoyé pour prendre des classes C / C ++ avant leur autorisation de toucher le code à nouveau.
Un contre-argument: court / int / long / etc. est quelque peu risqué d'utiliser, car leur comportement n'est pas garanti d'être identique à toutes les plateformes. Par exemple, si vous stockez Stockez votre valeur comme INT, alors sur certaines plates-formes, la valeur stockable maximale est (2 ^ 31) -1, et sur certaines plates-formes, elle est (2 ^ 63) -1. Dans de nombreux cas, le changement de comportement ne fera aucune différence, mais dans certains cas, ce sera, et ce n'est pas toujours évident à l'avant, quels cas sont ceux. Par conséquent, INT32_T, INT64_T, etc., sont préférables car ils définissent explicitement le comportement du type dans tous les cas.
Ne le faites pas. Cela signifie simplement que la CPU ne sera pas en mesure de contenir autant de données dans le cache et que la pénalité pour aller à la mémoire principale est beaucoup plus élevée que la plupart des autres choses.
Pourquoi n'écrivez-vous pas une référence pour l'essayer?
@Amuck, +1 pour l'essayer juste et découvrir.
J'aime l'idée de benchmarking, tant que cela ne prend pas autant de temps que j'espère éviter de gaspiller en apportant tous ces changements de code.
Je serais surpris que cela a provoqué une vitesse d'accélération et que votre code puisse exécuter plus lentement - la bande passante de la mémoire reste un facteur limitant. En allant des entiers de 64 bits au lieu de 32 bits à travers le tableau, vous augmentez la quantité de mémoire qui doit être déplacée dans le bus et augmentez les chances de cache Misses.
Le type INT est censé être (par définition de langue) le type d'entier le plus efficace sur votre compilateur. Pourquoi ne pas vérifier ce que le résultat de la taille de (int) est.