Raspbian passe en mode 64 bits

53

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?

zundi
la source
9
Une fois, j'ai travaillé pour une société qui a porté le logiciel DEC / Alpha d'OSF 32 bits à 64 bits (il y a longtemps). Juste une recompilation directe, puisque la base de code était déjà compatible 64 bits. 10% de performance en raison de la consommation supplémentaire de mémoire dans les nombres entiers et les pointeurs. C'était à l'époque où les performances étaient mesurées en mhz à trois chiffres et en mémoires à deux chiffres (peut-être même les triples). Sans 4 + GB de RAM à bord, ce n'est pas forcément une bonne idée.
Chris K
6
Le premier 64 bits rapporte avec plus de mémoire que le Pi.
Thorbjørn Ravn Andersen
2
Sur les systèmes basés sur x86, la difficulté de décider cela a même laissé un hybride abi: en.wikipedia.org/wiki/X32_ABI qui utilise des pointeurs 32 bits et des registres de processeurs 64 bits.
PlasmaHH
1
@ChrisKaminski mais ARM et x86 sont différents. Lorsqu'ils passent de 32 à 64 bits, ils doublent le nombre de registres et modifient certains aspects du jeu d'instructions de manière à accélérer l'exécution du code dans la plupart des cas. Vous pouvez voir beaucoup de points de repère sur Internet
phuclv
@rsaxvc, qu'est-ce que cela ajoute à mon commentaire? J'ai dit "ARM et x86" pour dire que dans ces architectures, 64 bits amélioraient les performances de l'application contrairement à d'autres architectures comme DEC / Alpha ou Sparc, MIPS ...
phuclv

Réponses:

63

é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.

Jacobm001
la source
7
En supposant que vous parlez de C et d'amis, la taille de tout type <= int reste la même. size_t et les pointeurs augmentent en taille, comme cela peut être le cas sous le modèle d'adresse de Linux. Vous manquez également complètement les points de l'espace d'adressage virtuel, ce qui est important lorsque vous effectuez des E / S mappées en mémoire.
3
Il n'est pas avancé de faire la distinction entre les quantités de mémoire physique et la mémoire virtuelle. Il est également pas avancé de ne pas propager la désinformation. sizeof(char)est toujours un. Sous Linux, sizeof(short), sizeof(int), sizeof(float), sizeof(double)ne varient pas avec bitness. Cela a une différence majeure dans vos revendications.
11
J'ai des problèmes avec l'utilisation de x64dans cette réponse. x64est une abréviation de x86-64. Ce n'est pas synonyme de "64 bits". Les processeurs ARM 64 bits sont AArch64.
Oli
6
Il y a plus de professionnels 64 bits que ceux énumérés. Y at - il un avantage de performance à ARM64 , en.wikipedia.org/wiki/64-bit_computing#Pros_and_cons
phuclv
3
Vous avez manqué la principale raison de passer à un système d'exploitation 64 bits. 19 janvier 2038. Linux 32 bits ne peut pas gérer les dates postérieures. Le correctif concerne Linux 64 bits (et la mise à niveau de tout logiciel basé sur le temps unix 32 bits) depuis un certain temps. 2038 est dans 20 ans, mais Raspberry Pi, en tant que petite machine intégrée, pourrait encore être utilisé dans l’avenir. Personne n'a vraiment pris le problème de l'an 2000 au sérieux en 1980 non plus.
Steve Sether
20

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.)

mattdm
la source
5
Même si AArch32 a déjà plus de registres que x86, AArch64 le fait mieux car il existe maintenant des SP et des PC séparés. Avant d'avoir au plus 14 registres à usage général. Vous disposez également d'un ensemble d'instructions mieux conçu. Les instructions ARM64 , instructions ARM 64 bits (Aarch64) boosteront les performances de 15 à 30% par rapport aux instructions ARM 32 bits (Aarch32)
phuclv
Il sera intéressant de voir des points de repère sur la Pi3 (en particulier pour les tâches du monde réel).
Mattdm
6

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) 1 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.

Boucles d'or
la source
1
raspbian.org/RaspbianFAQ#What_is_Raspbian.3F déclare (parle de Raspbian): Le port est nécessaire car la version officielle de Debian Wheezy armhf n’est compatible qu’avec les versions de l’architecture ARM postérieures à celle utilisée sur les unités Raspberry Pi (ARMv7-A). et supérieur, par rapport au processeur ARMv6 du Raspberry Pi). Est-ce toujours le cas avec le RPi3?
Zundi
@sandy je pense que c'est 1) relativement ancien; 2) Confus et / ou non corrigé depuis, puisque Debian armhf est compilé avec hard float, c’est le rôle du hf, c’est contre un autre debian pour ARMv4 / 5 que je pense a été le premier à être utilisé sur le et que ISA ne l’a pas avoir des flotteurs durs (je ne pense pas non plus que 6 jusqu'à un certain point, mais cela a été ainsi la plupart du temps, aka ARM1176JZ (F) -S). Il n’ya donc qu’une version de Raspbian, point, ARMv6 avec support matériel en virgule flottante, la seule différence entre les modèles A / B / + / 0 et le noyau 2 est le noyau utilisé, vraisemblablement aussi avec le 3.
goldilocks
2
... "armel" est la Debian non-hf qui était utilisée avant Raspbian.
goldilocks
@sandy cette phrase a été écrite du temps du pi1. Ainsi, quand il dit pi, cela signifie ce que nous appellerions maintenant pi1. Il existe des tierces parties qui publient des images Debian Armhf pour la pi2 (et probablement la pi3), mais le RPF a décidé de s'en tenir à une seule image pour tous les forums.
Peter Green
5

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.

Steve Robillard
la source
Je pensais que le code serait le même, mais le compilateur serait en charge d'optimiser le code final pour tirer parti de l'architecture. Est-il relativement facile de faire une nouvelle construction? Dites, exécuter Debian en 64 bits?
zundi
@sandy Easy dépend de votre niveau de compétence et de votre expérience. Quel est le cas d'utilisation qui en a besoin maintenant?
Steve Robillard
Aucun en particulier, nous voulons juste maximiser les performances dont le RPi3 est capable.
zundi
@sandy La fondation a déclaré que le remplacement du Pi3 ne viendra pas aussi rapidement que celui-ci a suivi le Pi2 (environ 1 an). Ils peuvent utiliser le commutateur 64 bits pour améliorer les performances sans nécessiter de nouveau matériel. Notez que ce ne sont que des spéculations de ma part.
Steve Robillard
4

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.

Daniel Glasser
la source
Peut-être avons-nous besoin d'un ABI x32 pour ARM. Ensuite, nous pouvons avoir de petits pointeurs et tous les registres.
Rsaxvc
4

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é.

GTC
la source
2

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.

halfer
la source
Bizarrement, cela dépend de votre plate-forme. Ce n'est généralement pas la taille entière, mais la taille de time_t dans la bibliothèque 'C'. Même sur les plates-formes 32 bits, il est possible d'utiliser un time_t 64 bits avec une surcharge de temps CPU, mais de nombreuses plates-formes 32 bits ne le font pas encore, car il y a un problème de compatibilité binaire.
Rsaxvc
@rsaxvc, intéressant, merci. Donc, pourrais-je obtenir une gestion du temps en 64 bits en recompilant PHP, ou faudrait-il également modifier les bibliothèques C sous-jacentes? Le premier serait à ma portée, mais je ne suis pas sûr du dernier - je pensais recompiler moi-même l'ensemble de Ras [bian], mais il ne semble pas qu'il y ait d'instructions simples pour le faire (encore, en tout cas).
Halfer
pour Linux, vous devez patcher le noyau, la libc et votre application. Cela n'en vaut probablement pas la peine. Après quelques lectures, OpenBSD (no on RPi) time_t est 64 bits depuis la version 5.5. Sous Windows 32 bits, Visual Studio 2005 ou une version plus récente, time_t est 64 bits.
Rsaxvc
@rsaxvc: d'accord, merci. Je me demande s'il est logique pour moi d'attendre qu'un système d'exploitation 64 bits soit disponible - cela semblait imminent pour quelques articles de presse publiés il y a quelques mois ....:-)
halfer
-4

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) 
    } 
}
bobx
la source
5
L'endianisme n'a rien à voir avec la taille des mots. Heck, de nombreuses architectures permettent au programmeur de sélectionner l’endianité, y compris ARM! En outre, "64 bits" peut avoir des conséquences totalement différentes selon l'architecture en question, et il est difficile de comparer les architectures ou d'essayer de les rapprocher.
Bob
1
Je ne pense pas que je = - est valide.
Rsaxvc