Raspbian se mueve al modo de 64 bits

53

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?

zundi
fuente
99
Una vez trabajé para una empresa que portaba software de 32 bits a 64 bits OSF en DEC / Alpha (hace mucho tiempo). Solo una recompilación directa, ya que la base de código ya era compatible con 64 bits. 10% de rendimiento alcanzado por el consumo de memoria adicional en enteros y punteros. Esto fue en los días en que el rendimiento se midió en memorias de tres dígitos mhz y dobles (tal vez un triple bajo). Sin tener más de 4 GB de RAM a bordo, no necesariamente es una buena idea.
Chris K
66
Primero, 64 bits vale más con más memoria que la Pi.
Thorbjørn Ravn Andersen
2
En sistemas basados ​​en x86, la dificultad para decidir esto incluso ha permitido un abi híbrido: en.wikipedia.org/wiki/X32_ABI que utiliza punteros de 32 bits y registros de CPU de 64 bits.
PlasmaHH
1
@ChrisKaminski pero ARM y x86 son diferentes. Cuando pasan de 32 a 64 bits, duplican el número de registros y rediseñan algunos aspectos del conjunto de instrucciones que hacen que el código se ejecute más rápido en la mayoría de los casos. Puedes ver muchos puntos de referencia en Internet
phuclv
@rsaxvc, ¿qué agrega eso a mi comentario? Le dije: "ARM y x86" decir que en esas arquitecturas que van de 64 bits mejora el rendimiento de la aplicación a diferencia de otras arquitecturas como DIC / Alfa o Sparc, MIPS ...
phuclv

Respuestas:

63

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.

Jacobm001
fuente
77
Suponiendo que habla de C y sus amigos, el tamaño de cualquier tipo <= int sigue siendo el mismo. size_t y los punteros aumentan de tamaño, como puede suceder con el modelo de dirección de Linux. También se pierde por completo los puntos del espacio de direcciones virtuales, lo que es importante cuando realiza E / S mapeadas en memoria.
3
No está avanzado hacer una distinción entre las cantidades de memoria física y la memoria virtual. Tampoco está avanzado para no propagar información errónea. sizeof(char)es siempre uno Bajo Linux, sizeof(short), sizeof(int), sizeof(float), sizeof(double)no varían con el valor de bits. Eso tiene una gran diferencia en sus reclamos.
11
Tengo problemas con el uso de x64en esta respuesta. x64es una abreviatura de x86-64. Esto NO es sinónimo de "64 bits". Las CPU ARM de 64 bits son AArch64.
Oli
66
Hay más profesionales de 64 bits de los que enumeró. ¿Existe una ventaja de rendimiento para ARM64 , en.wikipedia.org/wiki/64-bit_computing#Pros_and_cons
phuclv
3
Te perdiste la mayor razón para pasar a un sistema operativo de 64 bits. 19 de enero de 2038. 32 bits Linux no puede manejar fechas pasadas esta vez. La solución ha sido Linux de 64 bits (y la actualización de cualquier software basado en el tiempo de Unix de 32 bits) durante bastante tiempo. 2038 está a 20 años de distancia, pero Raspberry Pi, al ser una máquina pequeña incrustada, tiene algún potencial para ser utilizado en el futuro. Nadie realmente se tomó en serio el problema Y2K en 1980 tampoco.
Steve Sether
20

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

mattdm
fuente
55
Aunque AArch32 ya tiene más registros que x86, AArch64 lo hace mejor porque ahora hay SP y PC separados. Antes de tener como máximo 14 registros de propósito general. Usted también tiene un conjunto de instrucciones mejor diseñadas ¿Hay ventaja de rendimiento a ARM64 , 64 bits de ARM (Aarch64) Instrucciones de aumentar el rendimiento en un 15 a 30% comparado con 32 bits ARM Instrucciones (Aarch32)
phuclv
Será interesante ver puntos de referencia en el Pi3 (particularmente con tareas del mundo real).
mattdm
6

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.

Ricitos de oro
fuente
1
raspbian.org/RaspbianFAQ#What_is_Raspbian.3F afirma (hablando de Raspbian): El puerto es necesario porque la versión oficial de Debian wheezy armhf es compatible solo con versiones de la arquitectura ARM posteriores a la utilizada en las CPUs Raspberry Pi (ARMv7-A) y superior, frente a la CPU ARMv6 de Raspberry Pi). ¿Sigue siendo cierto con el RPi3?
zundi
@sandy Creo que es 1) Relativamente antiguo; 2) Confundido y / o no corregido desde entonces, ya que Debian armhf está compilado con hard float, para eso está el hf, en comparación con otro debian para ARMv4 / 5 que creo que fue el primero utilizado en el y que ISA no tienen flotadores duros (creo que tampoco 6 hasta cierto punto, pero ha sido así la mayor parte del tiempo, también conocido como ARM1176JZ (F) -S). Entonces, solo hay una versión de Raspbian, punto, ARMv6 con soporte de coma flotante de hardware, la única diferencia entre los modelos A / B / + / 0 y el 2 es el kernel utilizado, presumiblemente también con el 3.
Ricitos de oro
2
... "armel" es el Debian no hf que se utilizó antes de Raspbian.
Ricitos de oro
@sandy esa sesión se escribió en los días de pi1, por lo que cuando dice pi significa lo que ahora llamaríamos pi1. Hay terceros que lanzan imágenes debian armhf para el pi2 (y presumiblemente pi3), pero el rpf ha decidido quedarse con una imagen para todos los tableros por ahora.
Peter Green
5

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.

Steve Robillard
fuente
Pensé que el código sería el mismo, pero el compilador se encargaría de optimizar el código final para aprovechar la arquitectura. ¿Es relativamente fácil hacer una nueva construcción? Digamos, ¿ejecutar Debian en 64 bits?
zundi
@sandy Easy dependería de tu nivel de habilidad y experiencia. ¿Cuál es el caso de uso que necesita esto ahora?
Steve Robillard
Ninguno en particular, solo queriendo maximizar el rendimiento del RPi3 es capaz de hacerlo.
zundi
@sandy La fundación ha dicho que el reemplazo del Pi3 no llegará tan rápido como el Pi3 siguió al Pi2 (aproximadamente 1 año). Pueden usar el interruptor a 64 bits para un aumento de rendimiento sin requerir nuevo hardware. Tenga en cuenta que esto es todo especulación de mi parte.
Steve Robillard
4

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.

Daniel Glasser
fuente
Quizás necesitemos un x32 ABI para ARM. Entonces podemos tener pequeños punteros y todos los registros.
rsaxvc
4

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.

GTC
fuente
2

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.

halfer
fuente
Extrañamente, esto depende de su plataforma. Por lo general, no es el tamaño entero, sino el tamaño de time_t en la biblioteca 'C'. Incluso en plataformas de 32 bits, es posible usar un time_t de 64 bits con algo de sobrecarga de tiempo de CPU, pero muchas plataformas de 32 bits aún no lo hacen, ya que hay un problema de compatibilidad binaria al hacerlo.
rsaxvc
@rsaxvc, interesante, gracias. Entonces, ¿podría obtener un manejo del tiempo de 64 bits recompilando PHP, o requeriría también la modificación de las bibliotecas C subyacentes? Lo primero estaría dentro de mi capacidad, pero no estoy seguro acerca de lo segundo: estaba pensando en recompilar todo Ras [bian yo también, pero no parece haber instrucciones simples para hacerlo (todavía, de todos modos).
halfer
para Linux, necesitaría parchear el kernel, libc y su aplicación. Probablemente no valga la pena. Después de leer un poco, OpenBSD (no en RPi) time_t es de 64 bits desde 5.5. En Windows de 32 bits con Visual Studio 2005 o posterior, time_t es de 64 bits.
rsaxvc
@rsaxvc: bien, gracias. Me pregunto si tiene sentido para mí que esperar para un sistema operativo de 64 bits está disponible - sonaba inminente en unos pocos artículos de noticias desde hace unos meses ....:-)
halfer
-4

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) 
    } 
}
bobx
fuente
55
Endianness no tiene nada que ver con el tamaño de la palabra. ¡Diablos, muchas arquitecturas permiten al programador seleccionar la resistencia, incluido ARM! Además, "64 bits" puede tener consecuencias completamente diferentes dependiendo de la arquitectura en cuestión, y es difícil comparar entre arquitecturas o tratar de establecer similitudes entre ellas.
Bob
1
No creo que i = - sea válido.
rsaxvc