2010-03-04 11 views
63

Supongo que me estoy enfocando en x86, pero en general estoy interesado en el cambio de 32 a 64 bits.¿Son los programas de 64 bits más grandes y más rápidos que las versiones de 32 bits?

Lógicamente, puedo ver que las constantes y punteros, en algunos casos, serán más grandes, por lo que es probable que los programas sean más grandes. Y el deseo de asignar memoria a los límites de palabras para la eficiencia significaría más espacio en blanco entre las asignaciones.

También he oído que el modo de 32 bits en el x86 tiene que vaciar su caché cuando se cambia de contexto debido a la posible superposición de espacios de direcciones 4G.

Entonces, ¿cuáles son los beneficios reales de 64 bits?

Y como pregunta complementaria, ¿128 bit sería aún mejor?

Editar:

que acabo de escribir mi primer programa de 32/64 bits. Hace listas enlazadas/árboles de objetos de 16 bytes (versión 32b) o de 32 bytes (versión 64b) y imprime mucho en stderr, no es un programa realmente útil, y no es algo típico, pero es el primero.

Tamaño: 81128 (32b) v 83672 (64b) - así que no hay mucha diferencia

Velocidad: 17s (32b) v 24s (64b) - que se ejecuta en OS 32 bits (OS-X 10.5.8)

actualización:

observo que un nuevo híbrido x32 ABI (Application Binary Interface) que se está desarrollando es 64b pero utiliza punteros 32b. Para algunas pruebas da como resultado un código más pequeño y una ejecución más rápida que 32b o 64b.

https://sites.google.com/site/x32abi/

+1

Parece un duplicado de http://stackoverflow.com/questions/324015/supplying-64-bit-specific-versions-of-your-software – Suma

+1

Y la mía desde hace unos días: http://stackoverflow.com/questions/2334148/is-there-any-real-point-compiling-a-windows-application-as-64-bit –

+0

Existe cierta coincidencia, estoy de acuerdo, pero todavía no hay compradores en la memoria caché de la CPU y en las partes de 128 bits. Gracias a Suma y John por los enlaces. – philcolbourn

Respuesta

21

A menos que necesite acceder a más memoria que el direccionamiento 32b le permitirá, los beneficios serán pequeños, en su caso.

Cuando se ejecuta en una CPU de 64b, obtiene la misma interfaz de memoria sin importar si está ejecutando el código 32b o 64b (está utilizando la misma memoria caché y el mismo BUS).

Si bien la arquitectura x64 tiene unos pocos registros más que permiten optimizaciones más sencillas, esto a menudo se ve contrarrestado por el hecho de que los punteros son ahora más grandes y el uso de cualquier estructura con punteros genera un mayor tráfico de memoria. Estimo que el aumento en el uso general de la memoria para una aplicación 64b en comparación con una 32b es alrededor del 15-30%.

+2

¿Cuál es su opinión sobre ABI x32 propuesto? – philcolbourn

+0

Creo que memcpy y strcpy serán más rápidos que la CPU de 32 bits porque leerá una palabra cada vez, ya que una palabra tiene 8 bytes en la CPU de 64 bits –

+0

misma memoria caché pero menos memoria caché debido a punteros más grandes –

14

Independientemente de los beneficios, sugeriría que siempre compilar el programa para el tamaño de texto predeterminado del sistema (32 bits o 64 bits), ya que si se compila una biblioteca como de 32 bits binario y proporcionarlo en un sistema de 64 bits, obligará a cualquiera que quiera vincularse con su biblioteca a proporcionar su biblioteca (y cualquier otra dependencia de la biblioteca) como un binario de 32 bits, cuando la versión de 64 bits sea la predeterminada disponible . Esto puede ser bastante molesto para todos. En caso de duda, proporcione ambas versiones de su biblioteca.

En cuanto a los beneficios prácticos de 64 bits ... el más obvio es que obtienes un espacio de direcciones más grande, así que si mmap un archivo, puedes abordar más de una vez (y cargar archivos más grandes en la memoria) . Otra ventaja es que, suponiendo que el compilador realiza un buen trabajo de optimización, muchas de sus operaciones aritméticas se pueden paralelizar (por ejemplo, colocar dos pares de números de 32 bits en dos registros y realizar dos adiciones en una operación de suma única), y grandes los cómputos numéricos se ejecutarán más rápidamente. Dicho esto, todo lo de 64 bits frente a 32 bits no te ayudará con la complejidad asintótica en absoluto, así que si estás buscando optimizar tu código, probablemente deberías mirar los algoritmos en lugar de los factores constantes como este.

EDITAR:
Haga caso omiso de mi declaración acerca de la adición parallelized. Esto no lo realiza una declaración add ordinaria ... Estaba confundiendo eso con algunas de las instrucciones vectorizadas/SSE. Un beneficio más preciso, aparte del espacio de direcciones más grande, es que hay registros de propósito más general, lo que significa que se pueden mantener más variables locales en el archivo de registro de la CPU, que es mucho más rápido de acceder, que si coloca las variables en el pila de programas (que generalmente significa ir a la caché L1).

+0

> "por ejemplo, colocando dos pares de números de 32 bits en dos registros y realizando dos agregaciones en la operación de adición única" ¿Hay algún compilador haciendo esto? Además, parece que lo mismo podría hacerse en x86 utilizando las instrucciones SSE. – Suma

+0

Pensando en esos "dos agregados en uno" más, es una tontería y ningún compilador puede hacerlo como una optimización, porque la adición del inferior 32b podría desbordarse al 32b superior. Necesitas instrucciones SIMD para esto. – Suma

+0

Supongo que si estuvieras interesado podrías hacer aritmética múltiple de 16 bits en registros de 64 bits. Parecería desordenado, pero apuesto a que ya está hecho. – philcolbourn

0

Se transfieren más datos entre la CPU y la RAM para cada recuperación de memoria (64 bits en lugar de 32), por lo que los programas de 64 bits pueden ser más rápidos siempre que estén escritos para aprovecharlos adecuadamente.

+9

En realidad, esto no es así: el bus de memoria es de cualquier ancho, que no tiene nada que ver con el ancho de los registros del procesador. Algunos sistemas de 32 bits obtienen 128 bits a la vez, hay sistemas de 64 bits que buscan 32 a la vez, e incluso sistemas de 32 bits que obtienen memoria de no más de 8 bits a la vez. –

+0

OK, no estaba al tanto de eso, aún así, ¿no es correcto que una sola instrucción mov transfiera 64 bits en una CPU de 64 bits y 32 bits en una CPU de 32 bits? Entonces, cuando se copia una gran cantidad de memoria del punto A al punto B, al menos esto significaría que se necesitarían ejecutar menos instrucciones mov en una CPU de 64 bits (incluso si el bus de memoria es el cuello de botella). –

+2

Cuando mueva una gran cantidad de memoria, usará las instrucciones 128b SIMD tanto en x86 como en x64. – Suma

2

En el caso específico de x68 a x68_64, el programa de 64 bits tendrá aproximadamente el mismo tamaño, si no es un poco más pequeño, usará un poco más de memoria y funcionará más rápido. Sobre todo esto se debe a que x86_64 no solo tiene registros de 64 bits, sino que también tiene el doble. x86 no tiene suficientes registros para hacer que los lenguajes compilados sean tan eficientes como podrían ser, por lo que el código x86 gasta muchas instrucciones y el ancho de banda de la memoria transfiere datos hacia adelante y hacia atrás entre los registros y la memoria. x86_64 tiene mucho menos de eso, por lo que requiere menos espacio y funciona más rápido. Las instrucciones de vector de coma flotante y de intercambio de bits también son mucho más eficaces en x86_64.

En general, sin embargo, el código de 64 bits no es necesariamente más rápido, y suele ser más grande, tanto para el uso de código y memoria en tiempo de ejecución.

34

Por lo general, veo una mejora del 30% de velocidad para el código de cálculo intensivo en x86-64 en comparación con x86. Probablemente esto se deba al hecho de que tenemos registros de propósito general de 16 x 64 bits y 16 registros SSE en lugar de registros de propósito general de 8 x 32 bits y 8 registros SSE. Esto es con el compilador Intel ICC (11.1) en un Linux x86-64. Los resultados con otros compiladores (por ejemplo, gcc) o con otros sistemas operativos (por ejemplo, Windows) pueden ser diferentes, por supuesto.

+1

Por 'cálculo intensivo' Significa gráficos, matriz, DFTs? – philcolbourn

+2

@phil: sí, principalmente procesamiento de imágenes, principalmente entero (punto fijo), muchos códigos SIMD, etc. –

+0

He observado que los compiladores de 64 bits usan los registros SSE, mientras que los compiladores de 32 bits usan la ALU estándar. Esto hace que el código de 64 bits sea más rápido debido al ancho FP más estrecho (64 vs 80) más instrucciones adicionales. – IamIC

2

La única justificación para mover su aplicación a 64 bits es la necesidad de más memoria en aplicaciones como grandes bases de datos o aplicaciones ERP con al menos 100s de usuarios concurrentes donde se superarán los 2 GB bastante rápido cuando las aplicaciones almacenan en caché para un mejor rendimiento. Este es el caso especialmente en el sistema operativo Windows donde entero y largo aún es de 32 bits (tienen la nueva variable _int64. Solo los punteros son de 64 bits. De hecho, WOW64 está altamente optimizado en Windows x64, por lo que las aplicaciones de 32 bits se ejecutan con baja penalización en Windows de 64 bits OS. Mi experiencia en Windows x64 es una versión de aplicación de 32 bits ejecutada 10-15% más rápido que 64 bit ya que en el caso anterior al menos para bases de datos de memoria patentadas puede usar puntero aritmático para mantener b-tree (la mayoría de los sistemas de base de datos con procesador intensivo) Aplicaciones intensivas de compilación que requieren decimales grandes para una mayor precisión no permitida por el doble en el sistema operativo de 32-64 bits. Estas aplicaciones pueden usar _int64 en forma nativa en lugar de emulación de software.Por supuesto, las bases de datos grandes basadas en disco también mostrarán mejorías de más de 32 bits debido a a la capacidad de utilizar memoria grande para el almacenamiento en caché de planes de consulta, etc.

+0

Primero, 'int' permanece en 32 bits en todas partes, independientemente del tamaño de palabra del entorno de ejecución. ¿Para qué compilador es 'largo' todavía de 32 bits cuando se compila para 64 bits? ¿Estás afirmando que MSVC hace esto? AFAIK, esto es incluso [aproximadamente] cubierto en el estándar C++ 11: 'sizeof (long) == sizeof (void *)' Por favor, alguien, corrígeme si me equivoco, ya que no tengo fácil acceso a MSVC. –

+2

@Matthew Hall: su estándar de sistema operativo Windows de 64 bit y por lo tanto MSVC sigue este modelo LLP64 (frente a LP64 para variantes de Unix). Consulte (http://msdn.microsoft.com/en-us/library/3b2e7499 (v = vs.100) .aspx). – GirishK

+0

¡Gracias! Mi suposición está corregida. –

3

Además de tener más registros, 64 bits tiene SSE2 por defecto. Esto significa que puedes realizar algunos cálculos en paralelo. Las extensiones de SSE también tenían otros extras. Pero supongo que el principal beneficio es no tener que verificar la presencia de las extensiones. Si es x64, tiene SSE2 disponible. ... Si mi memoria me sirve correctamente.

1

Cualquier aplicación que requiera uso de CPU como transcodificación, rendimiento de visualización y representación multimedia, ya sea de audio o visual, sin duda requerirá (en este punto) y se beneficiará del uso de 64 bits frente a 32 bits debido a la capacidad de la CPU para lidiar con la gran cantidad de datos que se le arrojan. No es tanto una cuestión de espacio de direcciones, ya que es la forma en que se tratan los datos. Un procesador de 64 bits, con un código de 64 bits, funcionará mejor, especialmente con cosas matemáticamente difíciles como la transcodificación y los datos VoIP; de hecho, cualquier tipo de aplicaciones 'matemáticas' deberían beneficiarse con el uso de CPU y sistemas operativos de 64 bits. Prueba que estoy equivocado.

+0

No. No lo hará Si el requisito de RAM excede los 4 GB, solo será más rápido. Puede buscar fácilmente 1000Millions integer array en menos de 4 GB de datos en una arquitectura de 32 bits. Entonces, usar una máquina de 64 bits aquí disminuirá la velocidad – sapy

Cuestiones relacionadas