Raspbian se mueve al modo de 64 bits

En esta página , el anuncio oficial de RPi3 dice:

Necesitará una imagen NOOBS o Raspbian reciente de nuestra página de descargas. En el lanzamiento, estamos utilizando el mismo país de usuario Raspbian de 32 bits que usamos en otros dispositivos Raspberry Pi; en los próximos meses investigaremos si hay valor en pasar al modo de 64 bits.

Mi pregunta es, dado que el procesador es de 64 bits, ¿no es obvio que ejecutar el sistema operativo en 64 bits será mejor en todos los sentidos? ¿Qué me estoy perdiendo?

Dado que el procesador es de 64 bits, ¿no es obvio que ejecutar el sistema operativo en 64 bits será mejor en todos los sentidos?

No, en realidad no lo es. De alguna manera, ejecutar un sistema operativo de 64 bits podría deteriorar el rendimiento de la Raspberry Pi.

Beneficios de 64 bits :

Los dos beneficios principales de usar un procesador / sistema operativo de 64 bits es que el dispositivo puede manejar más de 4 GB de RAM y manejar de forma nativa enteros más grandes que 2^32sin la necesidad de una biblioteca bignum.

La Raspberry Pi no tiene más de 4 GB de RAM. Con 1 GB de RAM, ha perdido por completo el primero de los dos beneficios principales. En cuanto al segundo beneficio, ¿qué porcentaje de personas está usando suficientes números gigantes como para que la fundación tenga soporte para un segundo sistema operativo completo? Tal como está, el RPi puede usar grandes cantidades a través de métodos de software, pero parece que si vas a estar consistentemente en ese ámbito, de todos modos necesitas usar un mejor hardware.

Problemas con 64 bits :

La capacidad de almacenar un número mayor no es otorgada por magia. Por el contrario, el tamaño de los objetos de memoria debe aumentarse. En C (y C ++) esto significa cambiar un inta int64_t. Esto no se hace automáticamente, de ahí los comentarios sobre la fundación que no quiere mantener dos ramas.

Además, muchas aplicaciones simplemente no proporcionan un beneficio (para la mayoría de los usuarios) cuando se ejecutan en modo de 64 bits. Tenga en cuenta que la mayoría de los navegadores web, MS Office y una gran cantidad de otro software popular todavía se envían y mantienen de una manera de 32 bits. Claro que puede obtener una versión de 64 bits de MS Office, pero rara vez se usa.

Si la aplicación / sistema operativo está escrito para aprovechar una arquitectura de 64 bits, su aplicación usará más memoria, simplemente porque las variables y los punteros están ocupando más espacio. Por lo general, esta es una compensación relativamente pequeña para las máquinas que se beneficiarán de las ventajas. En nuestro caso, tenemos muy pocas ventajas y muy poca RAM.

También de nota :

El hecho de que se ejecute en una máquina de 64 bits no significa que la aplicación no se ejecute como 32 bits. Windows deja esto muy claro al tener dos rutas de instalación diferentes, C:\Program Filesy C:\Program Files (x86).

Entonces, ¿la fundación probablemente proporcionará soporte de 64 bits? :

Estamos de vuelta en el mismo punto de "Algunas personas pueden ver el beneficio, pero la mayoría no lo verá". Ciertamente verá otros proyectos que ofrecen compilaciones de 64 bits, pero a menos que la base reciba una gran cantidad de fallas inmerecidas (imo), probablemente no lo harán y no deberían (imo). Crear y mantener una rama separada de 64 bits no es una tarea pequeña y, sinceramente, no parece que valga la pena.

Vale la pena señalar que la situación es diferente para ARM e Intel / AMD. Esto se debe a que el cambio a x86_64 también se usó como una oportunidad para actualizar la arquitectura muy antigua, básicamente paralizada al tener solo 8 registros de uso general, y se duplicó en el modo de 64 bits. Por lo tanto, cambiar un sistema Intel / AMD al modo de 64 bits también significa habilitar funciones reales que marcan una diferencia significativa en el rendimiento.

Para empezar, ARM no tiene este problema (aunque AArch64 agrega registros, las arquitecturas de 32 bits no estaban hambrientos de ellos), por lo que los beneficios son básicamente una memoria más directamente direccionable y soporte nativo de enteros grandes, mucho menos. trato, y tal vez contrarrestado por la desventaja (más memoria utilizada para todo).

(Por otro lado, por esta razón, ha habido algo de trabajo en la creación de un "x32" abi para Intel / AMD Linux , manteniendo las mejoras de la CPU pero utilizando punteros de 32 bits).

Estoy seguro de que ya hay personas que ejecutan Debian Aarch64 (ARMv8) en el Pi 3; ciertamente no sería tan difícil para muchas personas ( vea aquí algunas pistas sobre eso podría funcionar) ^1, aunque para la mayoría de los usuarios probablemente sea un poco exagerado.

Sin embargo, si Raspbian y / o la Fundación no salen con una versión de 64 bits, verá cada vez más personas con blogs, etc., que le explicarán cómo ejecutar uno y aún obtener los beneficios que necesita.

Ahora hay una versión de Fedora aarch64 para Pi 3.

^{1. Habrá algunas complicaciones con las /opt/vccosas de 32 bits , no estoy seguro de lo superable que es; solía haber bibliotecas de compatibilidad de 32 bits para x86-64 pero Aarch64 ... tal vez no.}

Como parte de la publicidad de lanzamiento, vi que mencionó que una preocupación es el esfuerzo requerido para mantener dos bases de código separadas (32 y 64 bits). el video de lanzamiento de Adafruit PI3 también mencionó que el cambio a un procesador de 64 bits se debió más al aumento de la velocidad del reloj que proporcionó el nuevo chip que al uso del modo de 64 bits.

Al abordar la afirmación de que los programas nativos de 64 bits son más grandes (más memoria para datos y punteros), y que no hay beneficios notables para un sistema operativo de 64 contra 32 bits en ARMv8 con menos de 4 GB de RAM, deseo aumentar algunos puntos.

Hay algunas diferencias significativas en cómo se hacen las cosas en ARMv7 (y antes) y ARMv8, arquitectónicamente, que hacen que la ejecución de ARMv8 sea más eficiente. Algo de esto proviene de las rutas de datos internas más amplias, otra es la eliminación de casos especiales y una canalización mucho más profunda). Estos mismos cambios hacen que el ARMv8 sea mejor para ejecutar el código ARMv7 (32 bits).

Las aplicaciones nativas de 64 bits usan punteros de 64 bits y 'size_t' es de 64 bits, por lo que los elementos que los usan se hacen más grandes. El resto de los datos tenderá a permanecer del mismo tamaño. La importancia de esto es menor, sin embargo, para el tamaño de las imágenes ejecutables.

Donde el nativo de 64 bits realmente brilla (si no te importan los enteros grandes y las cosas de coma flotante) es tener un espacio de dirección virtual más grande:

• El sistema operativo puede dividir el espacio de direcciones virtuales en secciones cada vez más grandes, lo que permite una administración más fácil de los recursos compartidos, cambios de contexto más ágiles entre diferentes niveles de privilegios, etc.
• Si ha habilitado el intercambio, puede ejecutar procesos más y más grandes, excediendo los límites de memoria física (esto también es cierto en 32 bits, pero está menos limitado en 64 bits)

Ya sea que el sistema operativo se aproveche de esto o no, va a hacer una diferencia a medida que la corriente principal se aleje de 32 bits.

Creo que el mejor argumento para pasar a un kernel AArch64 nativo de 64 bits es la portabilidad: el escritorio principal se ha movido a procesadores en su mayoría de 64 bits, y veo más paquetes que suponen 64 bits, y portar dicho código de nuevo a 32 bits es más difícil que portar de 32 a 64 bits. En el espacio de usuario, puede ejecutar aplicaciones de 32 bits y aplicaciones de 64 bits una al lado de la otra, suponiendo que haya instalado las bibliotecas de múltiples arcos, por lo que no es necesario portar de 32 a 64 bits donde no importar. Un sistema operativo de 64 bits simplemente le dará la mayor selección de software.

No estoy diciendo que la producción de un núcleo de 64 bits para Raspberry PI 3 sea fácil: existen diferencias significativas que requieren cambios a bajo nivel, no todos los controladores de dispositivo están limpios a 64 bits (especialmente los controladores para GPU específicas de ARM). Puede ser que Raspberian siga siendo un sistema operativo de 32 bits, pero creo que (a largo plazo) es miope.

Un solo medio de arranque (tarjeta SD, por ejemplo) puede contener versiones de 64 y 32 bits del sistema operativo, y el software de arranque secundario (u-boot, arm-boot y otros) puede determinar cuál cargar. La parte más difícil es la tierra de usuarios: el sistema de archivos tendría que ser de arco múltiple, incluso en sistemas de 32 bits donde las cosas de 64 bits serán inútiles. Me ocuparía de esto con un script o utilidad que podría ejecutarse después del arranque inicial para eliminar las bibliotecas y los ejecutables de programa innecesarios en sistemas de solo 32 bits.

El direccionamiento de 64 bits puede ser útil incluso si no tiene más de 1 GB de memoria.

Le permite mapear archivos grandes en la memoria, por lo que tiene un puntero y deja que el sistema operativo haga la E / S de forma transparente. Solo otra forma de hacer E / S. Necesita un direccionamiento de 64 bits para hacer esto en archivos grandes.

Otro ejemplo donde veo que puede ser útil es permitir que los procesos tengan más de 2 GB de espacio de direcciones, utilizando el espacio de intercambio. Recientemente tuve un problema en un NAS de 32 bits con mucho almacenamiento y un sistema de archivos dañado. El proceso fsck se quedó sin memoria, incluso con las opciones de almacenamiento en caché activadas. Agregar espacio de intercambio no pudo resolver el problema, el espacio de direcciones de 32 bits era el límite duro allí. Así que no había manera de ejecutar fsck en este gran sistema de archivos dañado con un binario de 32 bits. Con un binario de 64 bits y algo de espacio de intercambio, se habría ejecutado.

Las respuestas existentes cubren muy bien los problemas de un arco de 64 bits, pero no veo muchas ventajas declaradas de la actualización. Entonces, aquí hay dos que he descubierto recientemente:

• Cuando PHP maneja las marcas de tiempo de Unix, el tamaño entero en un arco de 32 bits establece un límite superior en las fechas, de modo que no pueden ir más allá de un día en particular en 2038 . Espero que este sea un problema para todos los idiomas que manejan marcas de tiempo. (Afortunadamente, la mayoría de los subsistemas de manejo de fechas que no usan marcas de tiempo Unix, como DateTime de PHP, están diseñados específicamente para no estar limitados por este problema, incluso en las CPU más antiguas).

• Mongo está limitado a bases de datos de menos de 2G de tamaño en este arco, y las compilaciones de 32 bits pronto serán obsoletas. Del manual :

  A partir de MongoDB 3.2, los binarios de 32 bits están en desuso y no estarán disponibles en futuras versiones.

  Aunque las compilaciones de 32 bits existen para Linux y Windows, no son adecuadas para implementaciones de producción. Las compilaciones de 32 bits tampoco son compatibles con el motor de almacenamiento WiredTiger.

Mis pensamientos sobre esto: aunque no sé exactamente cómo un procesador ARM aborda la memoria, puedo decirle esto de las arquitecturas de CPU múltiples anteriores que programé (SPARC / Alpha / i386 / AMD64 / X86_64): cuando uso memoria compartida y direccionamiento por su puntero de dirección virtual "real", el movimiento a 64 bits no es trivial. Aunque memcpy hace lo que se supone que debe hacer, debe tener en cuenta que en 64 bits los datos se almacenan así (bit hacia atrás):

HGFEDCBA
HGFEDCBA
HGFEDCBA

pero en 32 bits se ve así:

ABCD
ABCD
ABCD

Entonces, en 32 bits cuando almacena, digamos un jpeg en RAM, puede leer sus bytes de encabezado, o hacer detección de bordes, sin ningún problema de forma lineal * digamos yendo byte por byte hacia adelante. Pero en una arquitectura de 64 bits esto cambia:

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