Libertonia || Comments || Ahora en serio: 64 bits, ¿para quién?


Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios

Ahora en serio: 64 bits, ¿para quién? | 226 comentarios (212 temáticos, 14 editoriales, 0 ocultos)

Todo el mundo es un x86 none (#6)
por Draco a las Tue Nov 22nd, 2005 at 12:32:45 PM CET
(Información Usuario)

Rapidamente, que tengo un montón de curro. Me parece que muchas de las virtudes que atribuyes a los 64 bits no son tales, aparte del espacio de direccionamiento de más de 4GB. Es bien sabido que muchas aplicaciones se degradan en modo 64bits, lo que pasa es que x86-64 tiene bastantes más registros que x86. Resumiendo, que podrías haber puesto de título "más registros: ¿para quién?".
There are two major products to come out of Berkeley: LSD & BSD Unix. I don't believe this to be a coincidence.

Jum jum none (#13)
por man ls a las Wed Nov 23rd, 2005 at 10:18:39 PM CET
(Información Usuario)

Lo siento, Draco, pero no entiendo ni palabra de tu mensaje. Empezando por el título, y siguiendo con las virtudes que no son exclusivas de la arquitectura amd64. ¿Como qué? ¿No resulta más rápido el código de POV-Ray, o los cálculos de OpenSSH? Cierto que algunos programas son más lentos, pero sólo porque se vuelven más grandes y el procesador tiene que mover más datos. No está claro si los programas de propósito general pierden mucho al correr en modo de 64 bits, yo he leído que un 10 o un 5 %.

[ Padre ]

Es más lento en la mayoría de los casos none (#14)
por jorginius ("jorginius" en Google Mail) a las Thu Nov 24th, 2005 at 01:41:53 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

Cierto que algunos programas son más lentos, pero sólo porque se vuelven más grandes y el procesador tiene que mover más datos.

Por norma general un programa de 64 bits siempre es más lento. Dejando a un lado lo que ocupe ahora en memoria, la causa principal es que código y datos más grandes implican cachés más grandes y jerarquías más complicadas para conseguir la misma media de aciertos.

Luego, en Linux en particular, hay otros factores como que que gcc ha tenido tradicionalmente un montón de problemas con el código de 64 y que mucho código que usamos está optimizado expresamente para 32 bits: optimizaciones obvias como usar aritmética de punteros en los bucles o desenrollar éstos jugando con el alineamiento y la caché pueden volverse en nuestra contra al compilar para 64 bits.

Las aplicaciones en las que esos bits pueden mejorar el rendimiento son las de cómputo intensivo (con el mínimo imprescindible de accesos a memoria). Ésas y las que realmente necesitan un espacio de direcciones mayor son las únicas en las que los 64 bits tienen sentido.

Como curiosidad, en Sparc64 puedes compilar para V8PLUS (ABI de 32 bits conforme a la ISA V9) y así usar los registros de 64 mientras mantienes direcciones de 32 bits. Dejas por el camino lo de las direcciones por encima de las 4GB pero el rendimiento de las aplicaciones es mejor.

En fin, a mí me da la impresión de que un 5% de penalización es irreal. En general un 10% o un 15% en "propósito general" creo que es más realista pero todo depende de la aplicación, del compilador y de detalles de la arquitectura. El AMD64 se desmarca por los cambios en la arquitectura.

[ Padre ]

Ahora en serio: 64 bits, ¿para quién? | 226 comentarios (212 temáticos, 14 editoriales, 0 ocultos)

Menu

· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login


Nueva cuenta
Usuario:
Contraseña:

Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda