Lorsque vous déplacez une application de 32 bits à 64 bits, où l'utilisation de la mémoire augmentera-t-elle?
Je comprends que les pointeurs doubleront en taille, je soupçonnez que les caractères d'une chaîne sont «groupés» pour utiliser la mémoire plus efficacement (afin qu'il n'utilisera pas beaucoup plus de mémoire).
Où autre serait l'utilisation de la mémoire augmenter? Y a-t-il lieu de diminuer, ou des opérations non arithmétiques verraient une prestation de vitesse?
4 Réponses :
Vous pouvez voir un alignement supplémentaire pour coûter quelques octets supplémentaires ici et là. Le code sera probablement plus important en raison de constantes de 64 bits dans les opérandes.
En ce qui concerne la vitesse, vous pouvez ressentir des ralentissements dues à l'utilisation accrue de la mémoire. Le cache de la CPU se remplira plus rapidement.
J'ai vu des avantages de vitesse importants allant de x86 aller à X64, car le X86 a beaucoup moins de registres que l'architecture x64. Les compilateurs utilisent les registres supplémentaires pour mieux optimiser votre code. J'ai vu 15% de vitesse sur du matériel identique.
Intéressant, je n'avais pas examiné le cache. Un compilateur X86 n'utilisera donc pas tous les registres disponibles sur un processeur compatible de 64 bits? Y a-t-il un moyen de le forcer?
@Peter 32 bits Executables ne peuvent pas accéder au registre 64 bits, autant que je sache. La meilleure façon de dire au compilateur qu'il "peut utiliser" les registres 64 bits consiste à le dire de produire des exécutables 64 bits.
@Peter: Non, il n'y a aucun moyen de faire référence à un registre X64 avec les instructions x86. Compilez pendant 64 bits si vous souhaitez utiliser les différentes extensions de 64 bits.
Comme vous avez noté que les indicateurs seront plus importants. Selon l'architecture du processeur, peut également être De plus, votre espace d'adressage de processus peut apparaître (dans de nombreuses architectures) pour être beaucoup plus grand avec des pointeurs de trames de pile apparaissant dans une mémoire élevée (et poussant vers le bas), mais ils sont des pointeurs de mémoire virtuelle invariablement, la mémoire physique réelle utilisée par votre application est généralement considérablement plus petit. intens et / ou LIPS . Les chaînes doivent rester de la même taille mais être alignées différemment en mémoire d'efficacité. En règle générale, l'alignement de la mémoire des structures de données sur les limites de 64 bits entraînera une fragmentation accrue dans la plupart des cas.
Peu probable que INT soit des largeurs. Les deux modèles de 64 bits les plus courants sont LP64 (POSIX) et LLP64 (Windows) et, dans les deux, INT est toujours 32 bits.
Il y a quelques cas où vous pourriez sauvegarder la mémoire. Le code réel pourrait être un peu plus court dans des endroits, car moins de charges / magasins sont nécessaires en raison de l'augmentation du nombre de registres. La Convention d'appel par défaut transmet des paramètres dans des registres, par exemple.
Globalement, une application 64 bits utilisera probablement un peu de mémoire plus qu'un 32 bits. Mais ça ne va pas être un drakefer.
"Dans l'ensemble, une application 64 bits utilisera probablement un peu plus de mémoire qu'un 32 bits." Mais ce n'est-il pas un peu prendre 8 octets en raison de problèmes d'alignement? ;)
Selon l'architecture, le code peut également se développer. Les variables globales et constantes sont souvent référencées via des adresses absolues (qui sont relocalisées par le chargeur de programme), ces références sont de 64 bits en mode 64 bits. Sur x64 Il existe une instruction MOV explicite pour les constantes de 64 bits afin que le programme ne cultive que de la taille de la constante. Les instructions de saut et d'appel peuvent également devenir plus grandes, mais cela dépend de nombreux paramètres du compilateur et de la liaison. Sur d'autres architectures, il peut même s'aggraver. Sur SPARC, lorsque cela passe de 32 à 64 bits, vous pouvez augmenter le code de manière significative. Comme le SPARC n'a pas d'instruction qui peut charger plus de 22 bits, lors du chargement de l'adresse 32 bits d'une variable ou de constante globale, il nécessite 2 instructions pour charger une constante de 64 bits qu'il nécessite même 5 instructions avec 3 registres. En augmentant la pression du registre, le compilateur manque souvent d'opportunités d'optimisation, rendant le code beaucoup plus grand que nécessaire.
Non seulement la taille du pointeur augmente mais aussi une taille longue longue et non signée.
+1 pmr; Et merveilleusement expliqué ici: développeurs.sun.com/solaris/articles/ilp32tolp64issues.htmlLe_ a>
Voir aussi ce PDF une fois: SCC.USTC.EDU.CN/ZLSC/ CZXT / 200910 / W020100308601263456982.PDF
@PMR: dépend de la plate-forme. Sur X64 sous Windows,
Long Les types sont toujours 32 bits.