Désolé si la question sonne stupide. Je ne suis que via vaguement conscient de la question de l'alignement des données et je n'ai jamais fait de programmation 64 bits. Je travaille sur un code X86 32 bits en ce moment. Il accède fréquemment à un tableau d'int. Parfois, un entier 32 bits est lu. Parfois, deux ou plus sont lus. À un moment donné, j'aimerais faire le code 64 bits. Ce que je ne suis pas sûr, c'est si je devrais déclarer ce tableau Int comme int ou long int . Je préférerais garder la largeur de l'entier de la même manière, je n'ai donc pas à vous soucier des différences. Je suis en quelque sorte inquiet de lire / écrire une adresse qui n'est pas alignée sur le mot naturel pourrait être lente.
4 Réponses :
Il y a beaucoup de bonnes informations disponibles ici: performance 32 bits contre 64 bits arithmétique
encore plus d'informations https://superuser.com/questions/56540/32- Bit-VS-64-Bit-Systems , où la réponse affirme avoir vu le pire ralentissement de 5% (du point de vue de l'application, pas des opérations individuelles).
La réponse courte est non, vous ne prendrez pas une performance touchée.
Les processeurs X86 de 64 bits X86 sont toujours fortement optimisées pour une manipulation efficace de valeurs 32 bits. Même sur des systèmes d'exploitation 64 bits, l'accès à des valeurs 32 bits est au moins aussi rapide que d'accéder à des valeurs 64 bits. En pratique, il sera effectivement plus rapide car moins l'espace cache et la bande passante de la mémoire est consommée.
Les pénalités de désalignement ne se produisent que lorsque la charge ou le stockage traverse une limite d'alignement. La limite est généralement la plus petite de:
Si vous chargez un mot de 4 octets sur une architecture de 64 bits (8 octets). Il n'a pas besoin d'être aligné de 8 octets. Il suffit d'être aligné de 4 octets.
De même, si vous chargez un chargement de 1 octet sur n'importe quelle machine, il n'a pas besoin d'être aligné du tout.
* Notez que les vecteurs SIMD peuvent impliquer une taille de mot naturelle plus importante. Par exemple, la SSE de 16 octets nécessite toujours un alignement de 16 octets sur X86 et X64. (sauf des charges / magasins mal alignés explicites)
Donc en bref, non, vous n'avez pas à vous soucier de l'alignement des données. La langue et le compilateur tentent assez fort pour vous empêcher de devoir vous en soucier.
Il suffit de rester avec n'importe quel type de données a le plus de sens pour vous.
Chaque fois que vous accédez à un emplacement de mémoire, une ligne de cache entière est lue dans le cache L1, et tout accès ultérieur à tout ce qui est de cette ligne est aussi rapide que possible. Sauf si votre accès 32 bits traverse une ligne de cache (qu'elle ne sera pas si elle est sur un alignement 32 bits), il sera aussi rapide qu'un accès 64 bits.
Pas assez. L'accès à 1 valeur sera la même. Si vous accédez à une autre valeur 32 bits située dans la même ligne de cache, il sera déjà là - vous l'indiquez même avec «suivant ...». En utilisant des tailles de données plus petites, c'est généralement plus de cache amical pour charger plus d'éléments de données par ligne de cache.
Si vous voulez des entiers à largeur fixe, essayez:
int32_t dans int est le type naturel de l'architecture. Sauf si vous avez une bonne raison d'utiliser un type différent, ne le faites pas.@Petebecker non, ce n'est pas le cas.
int n'est toujours que 32 bits sur la plupart des systèmes aujourd'hui.AFAIK, il n'y a pas de pénalité pour accéder à un DODL aligné par 4 mais pas par 8.
@ Mysticial - À partir de la norme C ++: "Les INT de nature ont la taille naturelle suggérée par l'architecture de l'environnement d'exécution". Si "la plupart des systèmes d'aujourd'hui" ne fais pas cela, il y a un problème grave avec la conception du système. (Mais notez que le "système" ne définit pas la taille des entiers; le compilateur fait).
@Petebecker Je pense que la raison pour laquelle
int n'a jamais été promu à 64 bits sur les machines de 64 bits d'aujourd'hui est partiellement en raison de la compatibilité à l'envers avec le code qui leur reposait 32 bits.En fait, je pense que la raison est que sur les processeurs Intel, même pour 64 bits, la taille de l'opérande par défaut est de 32 bits. Donc, en termes d'arithmétique, sur Intel, la taille naturelle est de 32 bits, même pour un code de 64 bits. En termes d'adresses, bien sûr, 64 bits, le code BITS utilisera 64 bits.
@Mystical - un
int est toujours 32 bits sur les processeurs 64 bits d'aujourd'hui car l'utilisation deint est plus rapide, un lot entier plus rapidement, que l'utilisation delong . Essayez-le.@Analog Dossier afin que les arithmétiques utilisant du mode long long en 64 bits sont plus lents qu'avec la longue?
@Petebecker - La norme C ++ est la fiction.
@cleong Cela dépend de la durée de longue durée et de ce qui est long.