Sortie cet été, la nouvelle version majeure de la distribution a déjà bien évolué. La fondation Raspberry Pi en profite pour mettre à jour son propre système.
Dans un billet de blog, elle détaille les nouveautés apportées, de GTK+3 à mutter qui remplace openbox comme gestionnaire de fenêtres. Le système de notifications a été revu, avec désormais l'annonce de nouvelles mises à jour disponibles.
Le pilote d'affichage KMS est désormais utilisé par défaut, n'étant plus fermé et spécifique au Raspberry Pi, simplifiant d'autant la vie des développeurs. Pour la prise de vue, libcamera est désormais utilisée, là aussi pour standardiser l'accès.
On est par contre toujours sans nouvelle d'une éventuelle version 64 bits par défaut, ce qui incite un nombre croissant d'utilisateurs à opter pour une distribution tierce, comme Manjaro ou Ubuntu.
Commentaires (9)
#1
A noter que les RPi 1 sont toujours supportés. Ce qui est plutôt cool quand on voit la conso ridicule de ces RPi face à ses successeurs.
#2
Je n’arrive toujours pas à imaginer qu’il y a un intérêt flagrant à utiliser un OS 64 bits sur une machine de 8GB ou moins. Certes il y a des applications qui bénéficieraient d’un espace adressable de plus de 32 bits, mais ces mêmes applications gagneraient encore significativement plus à tourner sur un hardware un peu plus musclé ; les faire tourner sur un Pi tient actuellement plus de l’exercice de style que d’une recherche de l’efficacité maximum.
#3
Bonjour,
Compiler en 64 bits, ne propose pas que de gerer + de 4GB de memoire par process, ca ouvre a des jeux d’instructions specialisés bien + performant, non dispo en 32 bits (vrai sur x64 mais je l’extrapole, peut etre a tord, entre du ARMv7 et du aarch64)
#3.1
Oui, on est bien d’accord sur tout ça. Mais en pratique, est-ce que ces nouvelles instructions sont suffisamment plus performantes pour que des applications standard en bénéficient ? Notamment, la consommation mémoire bien moindre (le stack, les pointeurs, mais aussi le code plus compact) des processus 32 bits ne rend-t-elle pas très aléatoires les gains de performance de ces instructions pour une application traditionnelle ? Par exemle, à quoi bon avoir une instruction pour additionner efficacement deux entiers de 64 bits si c’est pour quand-même faire tourner du Node.js ou du Python qui ne connaissent les nombres que sous une forme boxée, et ne pourront bénéficier de cette instruction que dans des cas particuliers, mais qui vont en permanence se taper des pointeurs qui prennent deux fois plus de place dans la cache du processeur ?
Dans mes divers essais, sur une machine (intel) avec 4GB, linux Mint 19 en version 32 bits est parfaitement utilisable, mais se traiîne lamentablement en 64 bits et passe sa vie à swapper même avec à-peu-près aucune application en train de tourner, juste le bureau.
Autant je suis d’accord qu’avec 16 (voire 12) GB de RAM le 64 bits devient intrinsèquement plus performant, quand on a moins de mémoire c’est nettement plus mititgé. Or aucun Pi n’a autant de mémoire, et beaucoup en on significativement moins.
Accessoirement, sous Windows, il est parfaitement possible d’allouer toute la RAM disponible à un unique processus 32 bits. Ce process devra utilser MapViewOfFile pour mapper une portion cette RAM dans son propre espace de 4GB (comme on le faisait avec la mémoire EMS à la grande époque). C’est chiant mais c’est possible.
Je ne sais pas si Linux a un truc équivalent (ça m’étonnerait que ce soit un standard Posix)
#4
Je vois surtout une raison de compatibilité. On peut imaginer que sur le très long terme, beaucoup de programmes ne seront plus distribués en 32 bits (c’est pas d’ailleurs Steam ou Ubuntu qui à un moment ne voulait plus accepter les jeux en 32 bits ?)
On pourrait faire le parallèle entre 32⁄64 bits et IPv4/IPv6, même si pour le coup pas sûr que ce soit le meilleur exemple…
#5
Oui tu as raison il faut mesurer les gains possibles. Par exemple le jeux d’instruction AES-NI fait que le benchmark openssl est 3 fois + rapide en cryptage AES, et ca n’est dispo qu’en 64 bits. C’est pas rien. Mais apres oui tout depend du contexte d’usage et savoir s’il faut arbitrer entre la RAM utilisé et la perf CPU. Sur un pi, rester en 32 bits a du sens bien sur. Sur une machine de prod a 128 GB de ram, la perf, les I/O etc … sont la priorités
#6
Tu n’as pas de bol, parce que tous mes tests depuis le Core 2 Duo montrent le contraire: quelque soit le Linux/Windows, en 64bits on ne voit pas de différence au pire, sinon c’est mieux (notamment tout ce qui est multimédia).
Surtout que sur PC en plus, en 64 bits on double le nombre de registres, ce qui simplifie beaucoup d’algos.
Si tu veux le meilleur des deux mondes, il te faut une distribution x32 (lancée en 64 bits, mais avec un ABI 32bits)
Sur RPI je n’ai pas essayé le 64bits. Mais je fais confiance à ARM qui a toujours des petites astuces comme le mode thumb. De mémoire le 64bits garde la même taille d’instructions, les pointeurs étant stockés en registres.
Par ailleurs, si ta RAM consommée dépend trop des pointeurs, alors tu as un GROS problème de perf, chaque pointeur suivi déclenchant potentiellement un chargement de page/un context switch.
On considérait en 2006 que passer en 64bits augmenterait la conso de RAM de 5 à 20% selon l’appli (20 étant pour les applis type Java).
Euh, non, ça n’alloue pas toute la RAM justement, ça ouvre une fenêtre sur une fichier potentiellement plus grand que la RAM (ancienne programmation depuis longtemps perdue).
mmap(). La fameuse fonction qui manquait à BeOS (mais n’a jamais manqué à Linux)
#7
Euh si. On peut appeler CreateFileMapping en passant null comme fichier, ce qui alloue en RAM avec swapping sur la mémoire virtuelle. Si ton PC a 32GB de RAM, un processus 32 bits peut appeler CreateFileMapping (fd = null, size = 30GB) et il recevra un handle vers 30GB de RAM (sujette au swapping si nécessaire). Une fois qu’il a reçu la RAM, le processus peut appeler MapViewOfFile pour “voir” une partie de cette RAM dans son propre espace de 4GB. Tant que le processeur a de la place en ram physique, il n’y a aucun swapping et c’est tout aussi efficace (à part les appels à MapViewOfFile) que de la RAM “normale” obtenue par virtualalloc.
#8
Merci! Oui, avec CreateFileMapping je suis d’accord.
Très bon exemple de vieille programmation (à l’époque où une image scannée dépassait la taille de la RAM, et de loin).
Toutefois, il est (était?) déconseillé de lancer CreateFileMapping au hasard sur la mémoire virtuelle puisque cela la retaillait et l’initialisait à zéro, donc ça pouvait être long: créer un fichier de la taille voulue et se mapper dessus.
C’était aussi utilisé pour charger des exe (ou les créer en mémoire), et ça montre qu’un exe peut dépasser la taille de la RAM (winword faisait 8Mo passés, mais se lançait sur 4Mo).
Maintenant, il est extrêmement rare de recourrir à ce genre d’artifice, les performances des disques et la taille de la RAM nous permet de charger les fichiers totalement en RAM.
Toutefois des anti-virus le font toujours avec des définitions (on le voit avec la mémoire privé énorme et le working set ridicule). J’ajoute qu’avec les bonnes options, ça swappe (avec le disque) quand le cache est épuisé.