Cela dépend du processeur et du fonctionnement exacts. Sur les Pentium IV 64 bits, par exemple, la multiplication des registres 64 bits était un peu plus lente. Les processeurs Core 2 et versions ultérieures ont été conçus pour un fonctionnement 64 bits à partir de zéro.
Généralement, même le code écrit pour une plate-forme 64 bits utilise des variables 32 bits dans lesquelles les valeurs s'adapteront. Ce n'est pas principalement parce que l'arithmétique est plus rapide (sur les processeurs modernes, ce n'est généralement pas le cas), mais parce qu'elle utilise moins de mémoire et de bande passante mémoire.
Une structure contenant une douzaine d'entiers aura la moitié de la taille si ces entiers sont de 32 bits que s'ils sont de 64 bits. Cela signifie qu'il faudra deux fois moins d'octets à stocker, deux fois moins d'espace dans le cache, etc.
Les registres natifs 64 bits et l'arithmétique sont utilisés là où les valeurs peuvent ne pas tenir dans 32 bits. Mais les principaux avantages en termes de performances proviennent des registres à usage général supplémentaires disponibles dans le jeu d'instructions x86_64. Et bien sûr, il y a tous les avantages qui viennent des pointeurs 64 bits.
Donc la vraie réponse est que cela n'a pas d'importance. Même si vous utilisez le mode x86_64, vous pouvez (et le faites généralement) toujours utiliser l'arithmétique 32 bits là où elle le fera, et vous bénéficiez des avantages de pointeurs plus grands et de registres plus généraux. Lorsque vous utilisez des opérations natives 64 bits, c'est parce que vous avez besoin d'opérations 64 bits, et vous savez qu'elles seront plus rapides que de simuler avec plusieurs opérations 32 bits - votre seul autre choix. Ainsi, les performances relatives des registres 32 bits par rapport aux registres 64 bits ne devraient jamais être un facteur décisif dans une décision de mise en œuvre.
Je viens de tomber sur cette question, mais je pense qu'il manque un aspect très important ici:si vous regardez vraiment le code assembleur en utilisant le type 'int' pour les index, cela ralentira probablement le code généré par votre compilateur. C'est parce que 'int' par défaut sur un type 32 bits sur de nombreux compilateurs et plates-formes 64 bits (Visual Studio, GCC) et effectuer des calculs d'adresse avec des pointeurs (qui sont nécessairement 64 bits sur un système d'exploitation 64 bits) et 'int' entraînera le compilateur à émettre des conversions inutiles entre les registres 32 et 64 bits .Je viens de faire l'expérience de cela dans une boucle interne très critique pour les performances de mon code. Passer de "int" à "long long" car l'index de boucle a amélioré le temps d'exécution de mon algorithme d'environ 10 %, ce qui était un gain assez énorme compte tenu de la vectorisation SSE/AVX2 étendue que j'utilisais déjà à ce moment-là.