¿Hay una buena razón para ejecutar software de 32 bits en lugar de 64 bits en máquinas de 64 bits?

56

¿Hay alguna buena razón para suministrar una versión de 32 bits junto con una versión de 64 bits de cualquier software dirigido a máquinas de escritorio modernas, que ejecuten sistemas operativos modernos de 64 bits en hardware de 64 bits?

Parece que el software de 64 bits sería más eficiente, permitiría un mayor uso de memoria si fuera necesario, etc. Apple incluso usa procesadores de 64 bits para sus teléfonos, a pesar de que solo tienen 1-2 GB de RAM, muy por debajo de los 4 GB límite para CPU de 32 bits.

hardware 64-bit 32-bit

— Filip Haglund
fuente

16

No todas las máquinas modernas ejecutan SO de 64 bits

— Bálint

44

¿Tienes algún ejemplo?

— Filip Haglund

8

Pregunta a tus clientes.

— Murphy

22

Pregunta retórica: ¿hay alguna razón para suministrar una versión de 64 bits de cualquier software, ya que la mayoría de los sistemas operativos modernos de 64 bits también permiten ejecutar aplicaciones de 32 bits y 64 bits?

— Doc Brown

2

No es un duplicado @gnat. Esa pregunta se trata de ajustar una marca de tiempo y una identificación de desarrollador en el código de error devuelto cuando sale un programa.

— Filip Haglund

80

Beneficios del software de 32 bits en entornos de 64 bits

Menor huella de memoria, especialmente en aplicaciones con muchos indicadores, 64 bits frente a 32 bits pueden duplicar fácilmente los requisitos de memoria.
Los archivos de objetos también son más pequeños.
Compatibilidad con entornos de 32 bits.
Las pérdidas de memoria están limitadas a 2 GB, 3 GB o 4 GB y no afectarán todo el sistema.

Inconvenientes del software de 32 bits en entornos de 64 bits

Límite de memoria de 2 GB, 3 GB o 4 GB por proceso. (Solo por proceso, en suma, varios procesos de 32 bits pueden usar la memoria completa del sistema disponible).
No usar registros adicionales y extensiones de conjunto de instrucciones dependiendo de x64. Esto es altamente compilador y específico de la CPU.
Puede requerir versiones de 32 bits de todas las bibliotecas (la mayoría de las distribuciones de Linux) o poco comunes (la mayoría de las versiones de Windows) y entornos de tiempo de ejecución. Si una versión de 32 bits de una biblioteca compartida se carga exclusivamente para su aplicación, y eso cuenta para su huella. No hay diferencia en absoluto si está vinculando estáticamente.

Otros aspectos

Los conductores generalmente no son un problema. Solo las bibliotecas de espacio de usuario deben diferir entre 32 bits y 64 bits, no la API de los módulos del núcleo.
Tenga cuidado con los diferentes anchos predeterminados para los tipos de datos enteros, se necesitan pruebas adicionales.
La arquitectura de CPU de 64 bits puede no ser compatible con 32 bits.
Ciertas técnicas como ASLR y otras que dependen de un espacio de direcciones mucho más grande que la memoria física no funcionarán bien (o no funcionarán) en un modo de ejecución de 32 bits.

A menos que compare aquí una arquitectura de CPU, un sistema operativo y una infraestructura de biblioteca muy específicos, no podré entrar en más detalles.

— Ext3h
fuente

8

"La arquitectura de CPU de 64 bits puede que ni siquiera admita 32 bits". ¿Es esto más una preocupación teórica o existe en el mundo?

— mucaho

10

@mucaho Ciertamente ha habido arquitecturas de CPU de solo 64 bits, como Alpha e IA64. Sin embargo, ambos son moribundos. No sé de mi cabeza si actualmente hay arquitecturas de 64 bits solo producidas, ¿AArch64, tal vez? ¿Alguien sabe si ARM de 32 bits es un componente obligatorio de eso?

— zwol

10

@zwol No, 32 bits no es obligatorio para ARM, y tampoco lo es 64 bits. Hay solo CPU ARM de 64 bits, mientras que otros admiten procesos de 32 bits y de 64 bits.

— Ext3h

3

Hay un beneficio adicional de simplemente elegir una arquitectura y apegarse a ella: desarrollo y prueba más simples.

— jl6

77

@Joshua Siempre existió? ¿Lo sabían los faraones?

— candied_orange

7

La diferencia entre el software de 32 bits y el software de 64 bits es el tamaño de los punteros, y tal vez el tamaño de los registros enteros. Eso es.

Eso significa que todos los punteros en su programa son dos veces más grandes. Y (al menos en una arquitectura ILP32 / LP64) sus longs también son dos veces más grandes. Esto generalmente se traduce en un aumento del 30% en el tamaño del código de objeto. Esto significa que …

su código objeto tardará ~ 30% más en cargarse del disco a la RAM
su código objeto ocupará ~ 30% más espacio en la memoria
ha reducido efectivamente el ancho de banda de su memoria (para el código objeto) en ~ 20%
ha reducido efectivamente el tamaño de la caché de instrucciones en ~ 20%

Esto tiene un efecto negativo no despreciable en el rendimiento.

Hacer esto solo tiene sentido si puede "recomprar" esos costos de rendimiento de alguna manera. Básicamente, hay dos formas de hacer esto: haces muchos cálculos enteros de 64 bits o necesitas más de 4 memorias mapeadas GiByte. Si uno o ambos son ciertos, tiene sentido usar software de 64 bits, de lo contrario no lo hace.

Nota: hay algunas arquitecturas donde no hay variantes correspondientes de 32 o 64 bits. En ese caso, la pregunta obviamente no tiene sentido. Los más conocidos son IA64, que tiene solo 64 bits y no tiene una variante de 32 bits, y x86 / AMD64 que, aunque están estrechamente relacionados, son arquitecturas diferentes , x86 es solo de 32 bits, AMD64 es solo de 64 bits.

En realidad, esa última afirmación ya no es 100% cierta. Linux agregó recientemente el x32 ABI, que le permite ejecutar código AMD64 con punteros de 32 bits, por lo que, aunque no es una arquitectura de CPU "adecuada", es una forma de utilizar la arquitectura AMD64 de manera tal que tuviera un nativo Variante de 32 bits. Esto se hizo precisamente porque el rendimiento de arriba he mencionado anteriormente estaba causando reales medibles, cuantificables problemas para los usuarios del mundo real que ejecutan código del mundo real en los sistemas del mundo real.

— Jörg W Mittag
fuente

8

¿Qué pasa con los registros e instrucciones adicionales en amd64 en comparación con x86? ¿Cuánto mejora eso el rendimiento?

— Filip Haglund

2

Google para "punteros etiquetados" utilizados en Objective-C en MacOS X e iOS. Cantidades muy sustanciales de objetos no tienen memoria asignada, pero todo el objeto está falsificado dentro del puntero en sistemas de 64 bits. (Escuché que Java hace algo similar). En C ++, std :: string en 64 bits a menudo contiene hasta 22 caracteres en el propio objeto sin ninguna asignación de memoria. Grandes ahorros de memoria y mejoras de velocidad.

— gnasher729

3

El tamaño de los punteros y los enteros es? ¿Qué pasa con el espacio de direcciones más grande y los registros adicionales en la mayoría de las arquitecturas de 64 bits?

1

"has [reducido] el caché de instrucciones en ~ 20%" es discutible ya que el conjunto de instrucciones es completamente diferente (y a menudo más eficiente)

— BlueRaja - Danny Pflughoeft

3

"Esto tiene un efecto negativo no despreciable en el rendimiento". Si bien esta afirmación es cierta en un sentido absoluto, ignora el hecho de que la gran mayoría de los cuellos de botella de rendimiento de las aplicaciones no se encuentran en el tiempo de carga, ni en el uso de la memoria / ancho de banda, o la cantidad de instrucciones en la memoria caché.

— Ian Kemp

6

Si el software necesita interactuar directamente con sistemas, controladores o bibliotecas heredados, entonces es posible que deba proporcionar una versión de 32 bits, ya que AFAIK el sistema operativo en general (definitivamente Windows y Linux AFAIK) no permite la mezcla de 64 bits y 32 -código de bit dentro de un proceso.

Por ejemplo, si su software necesita acceder a hardware especializado, no es raro que los clientes operen modelos más antiguos para los que solo hay disponibles controladores de 32 bits.

— Michael Borgwardt
fuente

2

Usted puede mezclar de 32 bits y 64 bits en el mismo proceso en Windows y Linux: stackoverflow.com/q/12716419/703382

— Navin

1

@Navin: ¿Pero es práctico? ¿Podría usar un componente COM en una aplicación de Windows de 64 bits (por ejemplo, una aplicación .NET marcada como Cualquier CPU que se ejecute en una versión de Windows de 64 bits)?

— Peter Mortensen

3

Si su software es una DLL, DEBE proporcionar versiones de 32 bits y de 64 bits. No tiene idea de si el cliente utilizará software de 32 o 64 bits para comunicarse con la DLL, y la DLL debe usar la misma longitud de bits que la aplicación. Esto no es negociable.

Si su software es un ejecutable independiente, es menos claro. Si no necesita que su software se ejecute en sistemas operativos más antiguos, es posible que no necesite proporcionar una versión de 32 bits. Simplemente manténgase en 64 bits, especifique que requiere un sistema operativo de 64 bits y haga el trabajo.

Sin embargo, si necesita que su software se ejecute en sistemas operativos más antiguos, es posible que NO desee proporcionar una versión de 64 bits. Si tiene dos versiones, entonces tiene el doble de pruebas, y probar el software correctamente en una variedad de versiones de sistema operativo e idiomas no es un proceso rápido. Dado que el software de 32 bits se ejecuta perfectamente en una plataforma de 64 bits, todavía es bastante común que el software se lance solo como 32 bits, especialmente por desarrolladores más pequeños.

También tenga en cuenta que la mayoría de los móviles son de 32 bits. Tal vez algunos de alta gama ahora tienen 64 bits, pero hay pocas razones convincentes para dar ese paso. Entonces, si está desarrollando multiplataforma y podría querer que su código también se ejecute en Android, quedarse con 32 bits es una opción segura.

— Graham
fuente

Yo argumentaría en contra de su posición sobre las pruebas reducidas. En cambio, argumentaría probar en múltiples plataformas, particularmente con no solo diferentes tamaños de registro, sino también con diferentes órdenes de bytes, como una manera fácil de aumentar las pruebas y detectar errores sutiles. Además, también haría pruebas en computadoras que no cumplan con los requisitos mínimos de hardware recomendados, ya que eso también expondrá problemas adicionales que de otra manera no se mostrarían, excepto con conjuntos de datos muy grandes.

— hildred

@hildred Con recursos de prueba ilimitados, estoy de acuerdo. Sin embargo, en la práctica, si tiene más control sobre su objetivo, es posible que no necesite hacer esta prueba de inmediato. Tampoco es en absoluto una "forma fácil": seguramente puede simular algunas de estas plataformas en una VM, pero si necesita configurar el hardware físico, esto implica grandes cantidades de trabajo manual (no automatizable). Puede evitar que escriba un arnés de prueba para probar esto explícitamente, pero de ninguna manera es gratis.

— Graham

1

No es gratis, pero francamente barato. Si limita su prueba fuera de la plataforma a pruebas automatizadas, la prueba idiota ocasional, el hardware usado Aparte de su configuración, sus costos para las pruebas exitosas después de su configuración inicial se limitarían a la potencia y a aproximadamente 7 minutos de hombre por pase de prueba. El costo de las pruebas fallidas, por supuesto, sería mayor, pero por lo general valdría más (siempre hay una falla de hardware). Este tipo de configuración es particularmente útil para los programadores de c porque expone fácilmente una cierta clase de problemas de puntero que de otro modo serían difíciles de rastrear.

— hildred