Raspbian passe en mode 64 bits

Dans cette page , l'annonce officielle de RPi3 indique:

Vous aurez besoin d'une image NOOBS ou Raspbian récente à partir de notre page de téléchargement. Au lancement, nous utilisons le même environnement utilisateur Raspbian 32 bits que nous utilisons sur d’autres appareils Raspberry Pi; Au cours des prochains mois, nous étudierons s'il est utile de passer au mode 64 bits.

Ma question est, étant donné que le processeur est de 64 bits, n'est-il pas évident que faire fonctionner le système d'exploitation en 64 bits sera meilleur à tous points de vue? Qu'est-ce que je rate?

étant donné que le processeur est en 64 bits, n'est-il pas évident que faire fonctionner le système d'exploitation en 64 bits sera meilleur à tous points de vue?

Non en fait, ce n'est pas. À certains égards, l’exécution d’un système d’exploitation 64 bits pourrait nuire aux performances du Raspberry Pi.

Avantages du 64 bits :

L’utilisation d’un processeur / système d’exploitation 64 bits présente les deux principaux avantages d’un dispositif capable de gérer plus de 4 Go de RAM et de gérer de manière native des entiers plus volumineux que si 2^32aucune bibliothèque bignum n’était nécessaire.

Le Raspberry Pi ne dispose pas de plus de 4 Go de RAM. Avec 1 Go de RAM, vous avez complètement perdu le premier des deux avantages principaux. En ce qui concerne le deuxième avantage, quel pourcentage de personnes utilise suffisamment de nombres géants pour qu'il soit logique que la fondation prenne en charge un deuxième système d'exploitation? Dans l’état actuel des choses, le RPi peut utiliser d’énormes nombres à l’aide de méthodes logicielles, mais il semble que si l’on veut rester cohérent dans ce domaine, il faut de toute façon utiliser un meilleur matériel.

Problèmes avec 64 bits :

La capacité de stocker un plus grand nombre n'est pas donnée par magie. Au contraire, la taille des objets de mémoire doit être augmentée. En C (et C ++), cela signifie changer un inten int64_t. Cela ne se fait pas automatiquement, d'où les commentaires sur la fondation ne souhaitant pas conserver deux branches.

En outre, de nombreuses applications n'offrent tout simplement pas d'avantages (pour la plupart des utilisateurs) lorsqu'elles sont exécutées en mode 64 bits. Notez que la plupart des navigateurs Web, MS Office et une foule d'autres logiciels populaires sont toujours livrés et maintenus en 32 bits. Bien sûr, vous pouvez mettre la main sur une version 64 bits de MS Office, mais elle est rarement utilisée.

Si l'application / le système d'exploitation est écrit pour tirer parti d'une architecture 64 bits, votre application utilisera davantage de mémoire, tout simplement parce que les variables et les pointeurs occupent plus d'espace. Généralement, il s’agit d’un compromis relativement modeste pour des machines qui bénéficieront des avantages. Dans notre cas, nous avons très peu d’avantages et très peu de RAM.

Aussi à noter :

Ce n’est pas parce que vous utilisez une machine 64 bits que l’application ne fonctionne pas en tant que 32 bits. Windows le dit très clairement en ayant deux chemins d’installation différents, C:\Program Fileset C:\Program Files (x86).

La fondation fournira-t-elle probablement un support 64 bits? :

Nous sommes de retour au même moment où "Certaines personnes peuvent voir des avantages, mais la plupart ne les verront pas". Vous verrez certainement d’autres projets proposant des versions 64 bits, mais à moins que la fondation reçoive beaucoup d’imprimés non mérités (imo), ils ne le feront probablement pas et ne devraient pas (imo). Créer et maintenir une branche distincte de 64 bits n'est pas une mince affaire et, honnêtement, cela ne semble pas en valoir la peine.

Il convient de noter que la situation est différente pour ARM et Intel / AMD. Cela est dû au fait que le passage à x86_64 a également été utilisé pour mettre à jour l’architecture très vieillissante, gênée par le fait qu’elle ne possède que 8 registres à usage général - et doublée en mode 64 bits. Par conséquent, basculer un système Intel / AMD en mode 64 bits signifie également activer des fonctionnalités réelles qui améliorent considérablement les performances.

ARM n'a pas ce problème pour commencer (bien que AArch64 ajoute des registres, les architectures 32 bits ne sont pas affamés pour eux), les avantages sont donc une mémoire plus directement adressable et un support natif pour les grands nombres entiers - beaucoup moins volumineux. affaire, et peut-être contré par les inconvénients (plus de mémoire utilisée pour tout).

(En passant, pour cette raison, il y a eu du travail dans la création d'un abi "x32" pour Intel / AMD Linux , en conservant les améliorations du processeur, mais en utilisant des pointeurs 32 bits.)

Je suis sûr qu'il y a déjà des gens qui utilisent Debian Aarch64 (ARMv8) sur le Pi 3; ce ne serait certainement pas si difficile pour beaucoup de gens ( voir ici quelques indices à ce sujet pourraient fonctionner) ¹ bien que pour la plupart des utilisateurs cela soit probablement un peu exagéré.

Toutefois, si Raspbian et / ou la Fondation ne proposent pas de version 64 bits, vous verrez de plus en plus de gens avec des blogs, etc., vous expliquant comment en exécuter un tout en conservant les avantages dont vous avez besoin.

Il existe maintenant une version Fedora aarch64 pour le Pi 3.

^{1. Il y aura quelques complications avec les /opt/vctrucs 32 bits , je ne sais pas comment c'est surmontable; Auparavant, il y avait des bibliothèques compatibles 32 bits pour x86-64 mais Aarch64 ... peut-être pas.}

Dans la publicité de lancement, j'ai vu qu'il était mentionné que l'une des préoccupations était l'effort requis pour maintenir deux bases de code distinctes (32 et 64 bits). La vidéo de lancement d'Adafruit PI3 a également indiqué que le passage à un processeur 64 bits était davantage lié à l'augmentation de la vitesse d'horloge de la nouvelle puce fournie qu'à l'utilisation du mode 64 bits.

Abordant l’affirmation selon laquelle les programmes natifs 64 bits sont plus volumineux (plus de mémoire pour les données et les pointeurs), et qu’il n’ya aucun avantage notable pour un système d’exploitation 64 vs 32 bits sur ARMv8 avec moins de 4 Go de RAM, je souhaite en soulever quelques-uns. points.

Il existe des différences significatives dans la façon dont les choses sont effectuées dans ARMv7 (et avant) et dans ARMv8, sur le plan architectural, qui rendent l'exécution de ARMv8 plus efficace. Cela provient en partie des chemins de données internes plus larges, l’élimination des cas particuliers et un pipeline beaucoup plus profond). Ces mêmes modifications permettent à ARMv8 de mieux exécuter le code ARMv7 (32 bits).

Les applications natives 64 bits utilisent des pointeurs 64 bits et 'size_t' étant 64 bits, les éléments qui les utilisent deviennent donc plus grands. Le reste des données aura tendance à rester de la même taille. Cela n'a toutefois qu'une importance mineure pour la taille des images exécutables.

Là où le natif 64 bits brille vraiment (si vous ne vous souciez pas des gros nombres entiers et en virgule flottante), c'est d'avoir un espace d'adressage virtuel plus grand:

• Le système d'exploitation peut diviser l'espace d'adressage virtuel en sections plus nombreuses et plus grandes, permettant une gestion plus facile des ressources partagées, des commutations de contexte simplifiées entre différents niveaux de privilèges, etc.
• Si vous avez activé la permutation, vous pouvez exécuter des processus plus nombreux et plus volumineux, dépassant les limites de mémoire physique (ceci est également vrai en 32 bits, mais vous êtes moins limité en 64 bits)

Que le système d'exploitation en profite ou non, cela fera une différence, car le courant dominant s'éloigne du 32 bits.

Je pense que le meilleur argument pour passer à un noyau natif AArch64 64 bits est la portabilité: le poste de travail principal est passé pour l’essentiel à des processeurs 64 bits. que le portage de 32 à 64 bits. Dans l'espace utilisateur, vous pouvez exécuter des applications 32 bits et 64 bits côte à côte, en supposant que vous ayez installé les bibliothèques à plusieurs archivages. Il n'est donc pas nécessaire de porter le port 32 à 64 bits là où il ne l'est pas. matière. Un système d'exploitation 64 bits va simplement vous donner la plus grande sélection de logiciels.

Je ne dis pas que produire un noyau 64 bits pour le Raspberry PI 3 est facile - il existe des différences importantes nécessitant des modifications de bas niveau, tous les pilotes de périphérique ne sont pas «propres» en 64 bits (en particulier les pilotes pour les GPU spécifiques à ARM). Il se peut que Raspberian reste un système d’exploitation 32 bits, mais je pense qu’à long terme, il est myope.

Un seul support de démarrage (carte SD, par exemple) peut contenir les versions 64 et 32 ​​bits du système d'exploitation, et le logiciel de démarrage secondaire (u-boot, arm-boot et autres) peut déterminer laquelle charger. La partie la plus difficile est celle de l’utilisateur: le système de fichiers doit être multi-arch, même sur des systèmes 32 bits où les fichiers 64 bits seront inutiles. Je voudrais résoudre ce problème avec un script ou un utilitaire pouvant être exécuté après le démarrage initial pour supprimer les bibliothèques inutiles et les programmes exécutables sur des systèmes 32 bits uniquement.

L'adressage 64 bits peut être utile même si vous ne disposez pas de plus de 1 Go de mémoire.

Il vous permet de mapper en mémoire des fichiers volumineux. Vous disposez donc d'un pointeur et laissez le système d'exploitation effectuer les E / S de manière transparente. Juste une autre façon de faire I / O. Vous avez besoin d'un adressage 64 bits pour le faire sur des fichiers volumineux.

Un autre exemple où je vois que cela peut être utile est de permettre aux processus de disposer de plus de 2 Go d'espace d'adressage, en utilisant l'espace d'échange. J'ai récemment eu un problème sur un NAS 32 bits avec beaucoup de stockage et un système de fichiers endommagé. Le processus fsck n'a plus de mémoire, même lorsque les options de mise en cache sont activées. L'ajout d'espace de swap n'a pas permis de résoudre le problème. L'espace adresse 32 bits était la limite absolue. Il n’y avait donc aucun moyen d’exécuter fsck sur ce système de fichiers endommagé avec un binaire 32 bits. Avec un fichier binaire 64 bits et un espace de swap, il se serait exécuté.

Les réponses existantes couvrent très bien les problèmes d'une arche 64 bits, mais je ne vois pas beaucoup d'avantages déclarés à la mise à niveau. Alors, voici deux que j'ai récemment découvert:

• Lorsque PHP gère les horodatages Unix, la taille entière dans une archive 32 bits définit une limite supérieure pour les dates, de sorte qu'elles ne peuvent pas dépasser un jour particulier en 2038 . Je suppose que c'est un problème pour toutes les langues qui gèrent les horodatages. (Heureusement, la plupart des sous-systèmes de traitement des dates qui n'utilisent pas les horodatages Unix, tels que DateTime de PHP, sont spécifiquement conçus pour ne pas être limités par ce problème, même sur des processeurs plus anciens).

• Mongo est limité aux bases de données de taille inférieure à 2G sur cette arche et les versions 32 bits seront bientôt obsolètes. Du manuel :

  À partir de MongoDB 3.2, les fichiers binaires 32 bits sont obsolètes et ne seront plus disponibles dans les prochaines versions.

  Bien que les versions 32 bits existent pour Linux et Windows, elles ne conviennent pas aux déploiements en production. Les versions 32 bits ne prennent pas non plus en charge le moteur de stockage WiredTiger.

Mon opinion à ce sujet: Bien que je ne sache pas exactement comment un processeur ARM adresse la mémoire, je peux vous le dire à partir de plusieurs architectures de CPU précédentes sur lesquelles j'avais programmé (SPARC / Alpha / i386 / AMD64 / X86_64): lors de l'utilisation de la mémoire partagée et de l'adressage par son "vrai" pointeur d'adresse virtuelle, le passage à 64 bits n'est pas anodin. Bien que memcpy fasse ce qu’il est supposé faire, vous devez prendre en compte le fait que dans 64 bits les données sont stockées comme ceci (bit en arrière):

HGFEDCBA
HGFEDCBA
HGFEDCBA

pourtant en 32 bits cela ressemble à ceci:

ABCD
ABCD
ABCD

Ainsi, en 32bits, lorsque vous stockez un fichier jpeg dans la RAM, vous pouvez lire ses octets d’entête ou effectuer une détection de bord, sans aucun problème de manière linéaire *, par exemple, en passant octet par octet. Mais dans une architecture 64 bits, cela change:

32bit:

for (i=0; i< img_length/4; i++) 
{ 
    address=shm_start+i; 
    for (c=0; c< 4; c++) 
    { 
        byte=((*address >> c) & 15) 
    } 
}

64bit:

for (i=-; i< img_length/8; i++) 
{ 
    address=shm_start+i; 
    for (c=7; c>=0; c--) 
    { 
        byte=((*address >> c) & 15) 
    } 
}