Systèmes 32 bits et 64 bits

Je ne suis pas sûr de pouvoir répondre à toutes vos questions sans écrire un essai complet (il y a toujours Google...), mais vous n'avez pas besoin de concevoir vos applications différemment pour 64 bits. Je suppose que ce à quoi il est fait référence est que vous devez être attentif à des choses comme les tailles des pointeurs qui ne sont plus de la même taille que les ints. Et vous avez toute une série de problèmes potentiels avec des hypothèses intégrées sur certains types de données de quatre octets qui peuvent ne plus être vraies.

Cela risque de perturber toutes sortes de choses dans votre application - de l'enregistrement/chargement à partir d'un fichier, de l'itération dans les données, de l'alignement des données, jusqu'aux opérations sur les données par bit. Si vous avez une base de code existante que vous essayez de porter, ou si vous travaillez sur les deux, il est probable que vous aurez beaucoup de petits problèmes à résoudre.

Je pense qu'il s'agit d'un problème de mise en œuvre, plutôt que de conception. Je pense que la "conception" d'un logiciel de retouche photo, par exemple, sera la même quelle que soit la taille du mot. Nous écrivons du code qui se compile à la fois en 32 bits et en 64 bits, et la conception ne diffère certainement pas entre les deux - c'est la même base de code.

Le "gros problème" fondamental du 64 bits est que vous avez accès à un espace d'adressage mémoire beaucoup plus grand que le 32 bits. Cela signifie que vous pouvez vraiment ajouter plus de 4 Go de mémoire à votre ordinateur et faire en sorte que cela fasse une différence.

Je suis sûr que d'autres réponses entreront dans les détails et les avantages plus que moi.

Pour détecter la différence, il suffit de vérifier la taille d'un pointeur (par exemple sizeof (void*)). La réponse de 4 signifie qu'il s'agit de 32 bits, et 8 signifie que vous êtes dans un environnement 64 bits.

Un processus 32 bits dispose d'un espace d'adressage virtuel de 4 Go, ce qui peut être insuffisant pour certaines applications. Une application 64 bits dispose d'un espace d'adressage virtuellement illimité (bien sûr, il est limité, mais vous n'atteindrez probablement pas cette limite).

Sous OSX, il y a d'autres avantages. Voir le article suivant En résumé, pourquoi le fait de faire fonctionner le noyau dans un espace d'adressage de 64 bits (que votre application fonctionne en 64 ou en 32) ou de faire fonctionner votre application dans un espace d'adressage de 64 bits (alors que le noyau est toujours en 32 bits) permet d'obtenir de bien meilleures performances. Pour résumer : Si l'un ou l'autre est en 64 bits (noyau ou application, ou les deux bien sûr), la TLB ("translation lookaside buffer") n'a pas besoin d'être vidée chaque fois que vous passez du noyau à l'espace d'utilisation et inversement (ce qui accélère l'accès à la RAM).

Vous bénéficiez également de gains de performance lorsque vous travaillez avec des variables "long long int" (variables 64 bits comme uint64_t). Un processeur 32 bits peut ajouter/diviser/soustraire/multiplier deux valeurs 64 bits, mais pas en une seule opération matérielle. Au lieu de cela, il doit diviser cette opération en deux (ou plus) opérations 32 bits. Ainsi, une application qui travaille beaucoup avec des nombres de 64 bits aura un gain de vitesse en étant capable de faire des maths de 64 bits directement dans le matériel.

Enfin, l'architecture x86-64 offre plus de registres que les architectures x86 classiques. Travailler avec des registres est beaucoup plus rapide que de travailler avec de la RAM et plus le processeur a de registres, moins il a besoin de permuter les valeurs des registres vers la RAM et inversement.

Pour savoir si votre processeur peut fonctionner en mode 64 bits, vous pouvez consulter diverses variables sysctl. Par exemple, ouvrez un terminal et tapez

sysctl machdep.cpu.extfeatures

S'il indique EM64T, votre processeur prend en charge l'espace d'adressage 64 bits conformément à la norme x86-64. Vous pouvez également rechercher

sysctl hw.optional.x86_64

S'il indique 1 (vrai/activé), votre processeur prend en charge le mode x86-64 Bit, s'il indique 0 (faux/désactivé), il ne le fait pas. Si le paramètre n'est pas trouvé du tout, considérez qu'il est faux.

Note : Vous pouvez également récupérer les variables sysctl à partir d'une application C native, sans avoir besoin d'utiliser l'outil de ligne de commande. Voir

man 3 sysctl

Notez que l'espace d'adressage peut être utilisé pour plus que la mémoire (réelle). Il est également possible de mapper en mémoire de gros fichiers, ce qui peut améliorer les performances dans des schémas d'accès plus étranges, car la mise en cache au niveau de la VM, plus puissante et plus efficace, entre en jeu. Il est également plus sûr d'allouer de grands blocs de mémoire sur 64 bits car le gestionnaire de tas est moins susceptible de rencontrer une fragmentation de l'espace d'adressage qui ne lui permettra pas d'allouer un grand bloc.

Certaines des choses dites dans ce fil (comme le doublement du nombre de registres) ne s'appliquent qu'à x86-> x86_64, et non à 64 bits en général. Tout comme le fait que sous x86_64, on a la garantie d'avoir SSE2, des opcodes 686 et un moyen bon marché de faire du PIC. Ces caractéristiques ne sont pas strictement liées au 64 bits, mais à la réduction de l'héritage et à la correction des limitations connues du x86.

De plus, les gens pointent souvent du doigt le doublement des registres comme étant la cause de l'accélération, alors que c'est plus probablement l'utilisation par défaut de SSE2 qui fait l'affaire (en accélérant memcpy et les fonctions similaires). Si vous activez le même ensemble pour x86, la différence est beaucoup plus faible. (*) (***)

Gardez également à l'esprit qu'il y a souvent une pénalité initiale impliquée parce que la structure de données moyenne augmentera simplement parce que la taille d'un pointeur est plus grande. Cela a également des effets sur le cache, mais est plus perceptible dans le fait que le memcpy() moyen (ou l'équivalent de la copie de mémoire dans votre langage) prendra plus de temps. Ce n'est que de l'ordre de quelques pourcents, mais les gains de vitesse mentionnés ci-dessus sont également de cet ordre.

En général, la surcharge d'alignement est également plus importante sur les architectures 64 bits (les enregistrements qui n'étaient auparavant que 32 bits deviennent souvent un mélange de valeurs 32 bits et 64 bits), ce qui gonfle encore plus les structures.

Dans l'ensemble, mes tests simples indiquent qu'ils s'annuleront grosso modo, si les pilotes et les bibliothèques d'exécution se sont pleinement adaptés, ne donnant pas de différence de vitesse significative pour l'application moyenne. Cependant, certaines applications peuvent soudainement devenir plus rapides (par exemple, lorsqu'elles dépendent de l'AES) ou plus lentes (une structure de données cruciale est constamment déplacée, scannée ou parcourue et contient beaucoup de pointeurs). Les tests ont été effectués sous Windows, et l'optimisation du PIC n'a donc pas été évaluée.

Notez que la plupart des langages JIT-VM (Java, .NET) utilisent en moyenne beaucoup plus de pointeurs (en interne) que le C++, par exemple. Il est probable que leur utilisation de la mémoire augmente plus que pour le programme moyen, mais je n'ose pas l'assimiler directement à des effets de ralentissement (puisqu'il s'agit d'une bête complexe et funky, souvent difficile à prévoir sans mesure).

Windows 64 bits utilise par défaut SSE2 pour la virgule flottante, ce qui semble accélérer les opérations simples et ralentir les opérations complexes (sin, cos, etc.).

(*) un fait peu connu est que le nombre de registres SSE double également en mode 64 bits.

(**) Le Dr Dobbs a publié un article intéressant à ce sujet il y a quelques années.

Outre les problèmes évidents d'espace mémoire que la plupart des gens mentionnent ici, je pense qu'il vaut la peine d'examiner la notion de "calcul par mots larges" dont Knuth (entre autres) a parlé récemment. Il y a beaucoup d'efficacité à gagner par la manipulation des bits, et les opérations par bit sur un mot de 64 bits vont beaucoup plus loin que sur un mot de 32 bits. En bref, vous pouvez effectuer davantage d'opérations dans les registres sans avoir à utiliser la mémoire, et du point de vue des performances, c'est un gain considérable.

Jetez un coup d'œil au volume 4, avant le Fascicule 1A, pour voir quelques exemples des trucs sympas dont je parle.

Outre la possibilité d'adresser plus de mémoire, les x86_64 ont également plus de registres, ce qui permet au compilateur de générer un code plus efficace. Cependant, l'amélioration des performances est généralement assez faible.

L'architecture x86_64 est rétrocompatible avec x86. Il est possible d'exécuter des systèmes d'exploitation 32 bits non modifiés. Il est également possible d'exécuter des logiciels 32 bits non modifiés à partir d'un système d'exploitation 64 bits. Cela nécessitera cependant toutes les bibliothèques 32 bits habituelles. Il peut être nécessaire de les installer séparément.