Comparativa de rendimiento entre kernels 32, 32 PAE y 64 bits en ubuntu [EN]

Recibimos desde nuestros foros una petición para comparar el rendimiento de Linux usando kernels de 32 bits, 32 bits con PAE y 64 bits. Esto viene despues de que Linus Torvalds dijera que hay unas diferencias de rendimiento del 25% en kernels usando CONFIG_HIGHMEM4G y kernels sin esta opción que permite a los sistemas de 32 bits, redireccionar más de 4 GB de memoria física en un sistema. Decidimos comparar el rendimiento en un sistema moderno, y aquí están los resultados

[#23 Desactivado]

El mejor rendimiento del kernel de 64-bits es debido a los registros adicionales que tienen los procesadores de 64 bits. Estos registros sólo se usan cuando compilas las aplicaciones para 64 bits. Por eso han comparado los kernels de 32 bits, 32 bits PAE (o sea, con acceso a memoria más allá de 4GB) y 64 bits.

Aunque los procesadores x86 de 32 bits tienen 8 registros, eso es sólo teoría, y en la práctica tienes menos para usarlos. Si de eso descuentas algunos que se usan internamente (p. ej. si programas en C++, un registro lo pierdes porque se usa para pasar el puntero a 'this'), resulta que en 32 bits hay muy pocas cosas que se puedan pasar mediante un registro de CPU (o sea, muy rápido), con lo cual tienes que pasar los datos por memoria (muy lento).

Se puede ver el número de registros de los diferentes procesadores aquí:
http://en.wikipedia.org/wiki/Processor_register#Some_examples

Los manuales de optimización de Agner Fog explican muchas más cosas:
http://www.agner.org/optimize/

[#35 spinete]

#2 Ejecutar una aplicación en 64-bit no implica que la aplicación sea más rápida. 64-bit tan solo implica que las direcciones de memoria ocupan 8 bytes en vez de 4 bytes permitiendo reservar memoria más alla de los boundaries de 2^32 (4 GB).

Dado que el bandwidth en una plataforma determinada no cambia (CPU-L1-L2-Lx-MEM) tanto si se compila a 32 o 64-bit la lógica nos diría que el tiempo de ejecución debería ser ligeramente peor, ya que estamos usando mayor bandwidth porque las direcciones ocupan el doble (de 4 bytes a 8 bytes). En definitiva nuestra aplicación tendría mayor riesgo de ser memory bound.

Si esto no sucede con x86 posiblemente el motivo sea lo que comenta #23, por lo que sea (a nivel de compilador o de hardware) a 64-bit se dispone de mayor numero de registros con lo que se reduce la posibilidad de tener register spilling (store&load de registros a pila por no disponer de suficientes).

Os puedo asegurar que con la architectura Power esto no sucede, el numero de registros disponibles es siempre el mismo tanto si se compila a 32-bit o 64-bit (32 GPR y 32 FPR) con lo que las ejecuciones de 64-bit suelen tener peor rendimiento (~5-10%).

[#18 AleD]

#17 Hombre, la verdad es que no sé la situación de compatibilidad y rendimiento actual de Gnash, no digo que ya sea sustituible por adoble flash player, pero no creo que sea correcto que opines de ello hoy en día, si la última vez que lo probaste fue hace 3 años...

[#20 Desactivado]

#18 De la web de Gnash :
"SWF v7+ compliant: Gnash can play many current flash movies."
En otras palabras, .swf 7 funciona, 8 y 9 puede que si, o puede que no y no veas el plano de pistas.

[#21 AleD]

#20 Pues sí, la verdad es que aún está bastante verde, y eso que forma parte de los proyectos prioritarios de desarrollo de GNU.

Hablando del tema, el otro día estuve probando una extensión para Chrome/Chromium que transformaba el flash en vídeo HTML5. Sería una opción muy interesante para nosotros linuxeros pues en verdad el flash en linux es paupérrimo. El problema es que al menos en Chromium no funciona y creo que (ya hablo de todas las plataformas) no tiene soporte de pantalla completa (por las propias especificaciones de HTML5, aunque el autor está currando una alternativa aprovechando el modo de pantalla completa del navegador, F11).

Esta es la extensión en cuestión:
https://chrome.google.com/extensions/detail/kchoimdlcbapmcdnheaahjcdpdjdpfco

Sería ideal ya que el consumo de CPU sería infinítamente menor y nos olvidaríamos de muchos males del adobe flashplayer. Lo ha probado alguien en la beta de Chrome para Linux o algo parecido?

[#19 Desactivado]

#17, bueno, pero no es cuestión de 32 o 64 bits, flash en linux apesta, directamente, en todas sus versiones. Lo que yo hago, dejar cargando el vídeo, darle a pause, ir a /tmp y abrir el vídeo con mi reproductor favorito.

[#29 ZeYt]

#19 pues muy mal porque a mi me funciona estupendamente gnash y el flashplugin-nonfree así que ponte a investigar tus problemas de drivers

[#43 Desactivado]

#29, ¿y por eso me votas negativo?

- Arch Linux x86_64 actualizado al día, con una nvidia 8300 integrada con los drivers 190.42, aceleración activada, sin compiz, en un clónico con un Phenom II X3 710.
- Arch Linux i686 actualizado al día, con una intel (945, creo), con los drivers 2.9.1, aceleración activada, con compiz, en un MSI Wind U100.

En ambos, flash 10.0.42.34, xorg 1.7.3, gnome 2.28.

En ambos sistemas, ver vídeos en flash apesta, lo mires por donde lo mires en un pentium 4 con una nvidia fx5200, con windows xp los vídeos se ven mejor. En el sobremesa se nota menos pero en el portátil más te vale que sean a muy baja resolución o no te queda otra que ir a /tmp y abrirlo con cualquier reproductor.

Gnash no es una opción cuando necesitas visitar ciertas páginas que requieren flash 9/10.

Eh, pero me alegro de que seas tan guay ( ). Ya me dirás qué problemas de drivers tengo.

[#10 Desactivado]

A mi me mosquea el Apache: que sea casi 20 veces más rápido en 64 bits suena a caso patológico. Los demás casos, en cambio, son bastante razonables.

De todas formas, estaría bien repetir las pruebas sobre AMD.

[#6 Desactivado]

Le falta por explicar que el PAE da problemas de estabilidad en cualquier plataforma, os lo puedo asegurar por experiencia propia en mi trabajo donde varios servidores tanto con Windows como con Linux se "petaban" misteriosamente. Casualmente los "petes" desaparecieron despues de desconectar el PAE

[#30 CortoCircuito]

Me parece muy mal que parezca que el rendimiento es solo por el Kernel.

Lo bueno de sistemas Linux es que todas las aplicaciones están compiladas para tu plataforma, asi que el mejor rendimiento de, p.ej. Apache, diría que en un 99% es gracias a que el Apache en sí esta compilado en 64bits, no por el Kernel!!

¿Porqué mejora tanto la eficiencia con 64bits? Aparte de la obviedad de que los registros son más anchos, hay más registros, aparte de otras mejoras:
http://en.wikipedia.org/wiki/X86-64

Usar apps de 32 bits en una máquina de 64 debería estar castigado, a menos que uses Windows donde no sueles disponer de tooodos los programas compilados como quieras porque... no sueles tener los fuentes

[#37 Desactivado]

#30 Algunas aplicaiones que usan ASM en 32 bit, o de fuentes no libres , no te queda mas cojones que usar las lib32- (Arch Linux) .
Ejemplos: pSX,daphne,BasiliskII,ZSNES ( ASM, probablemente el ejemplo más conocido

[#16 nando58]

#16 tienes que cambiar la frase, y decir: "según me ha dicho un amigo"

[#32 RadL]

Esto calla las bocas a aquellos que decían que las aplicaciones compiladas para 64bits no mejoraban el rendimiento.

[#5 albandy]

Me he quedado gratamente sorprendido con el rendimiento de PAE, me esperaba el rendimiento de 64 bits, pero lo que no me esperaba es que el rendimiento del kernel de 32 bits con PAE fuera prácticamente igual al de 32 bits sin PAE, realmente la forma en que el Kernel gestiona la extensión de memoria es impresionante.

[#40 Rubenix]

¡Vaya! Esto me recuerda que aún estoy usando un procesador de 32 bits.

Pero es una buena noticia, cuando me compre mi siguiente portátil, dentro de 3 o 4 años, todo encajará perfectamente...

Por cierto, el flash a pantalla completa en mi Suse 11.2 va perfectamente. Los HD no, pero tampoco en windows, que mi celeron mobile 1,3Ghz no da para mucho más.

De todas formas soy medio miope, así que no noto mucho la diferencia. jejjeje!! el que no se consuela es porque no quiere!!

[#13 nando58]

¿y qué cosa rara haces o tienes para no poder ver pelis en flash en 64 bits?

[#7 cau]

Las aplicaciones que usan en el Ubuntu de 64 bits están compiladas en 32 o 64 bits? A mi me interesaría saber eso, ya que por regla general en todas las pruebas gana de calle el sistema de 64 bits, y estoy interesando en saber como iría mejor WINE, si en 32 o 64 bits, siempre compilado en 32 bits ya que la compilación en 64 bits apena soporta programas.

[#8 albandy]

#7 Estan compiladas en 64 bits, si quieres ejecutar aplicaciones de 32 necesitas instalar las ia32-libs, de todas formas wine es una implementación de las librerías de windows y las aplicaciones que se ejecutan que yo sepa son de 32 bits, por lo que posiblemente te funcione mejor bajo 32 bits que bajo 64.

[#9 cau]

#8 Hombre están implementando soporte de 64-bits, pero claro es muy primitivo y poco funcional. Yo también pienso que funcionará mejor bajo 32 que bajo 64, pero nunca he encontrado reviews sobre el tema.

Sobre los test yo tampoco me fío mucho, porque son programas específicos de tareas intensivas, pero por ejemplo aplicaciones de uso cotidiano nunca usan para las reviews. Realmente se nota usar 64 bits para un uso cotidiano de desktop de un linux?.

No se, como va mas rápido un KDE o un GNOME?, o el OpenOffice por ejemplo?, donde se ejecuta mejor Python, Tk, Tcl, etc etc?, programas así son los que a mi me interesaría saber donde irian mejor.

[#26 Desactivado]

lo primero que me viene a la cabeza, a la vista de los gráficos, es que en las aplicaciones que tienen rendimientos tan parecidos en las diferentes arquitecturas interviene el factor de optimización para x86 o x64. Si una aplicación no está preparada para x64, ya puedes ponerle el procesador que quieras que funcionará igual...

[#27 Desactivado]

#26 O es porque lo que cargan es la gráfica, los benchmarks OpenGL les han dado el mismo resultado en 32 y 64 bits con la misma gráfica y el mismo driver.

[#41 raharu]

Si apache usa un thread por request, los resultados de 32 vs 64 tienen una explicacion bastante logica: la falta de direcciones virtuales:

http://www.kegel.com/c10k.html#threaded

El espacio de direcciones de 64 bits no tiene porque ser una carga para sistemas con menos de 4GB de memoria fisica., soluciona problemas como este y la randomizacion del espacio de direcciones de forma segura (tengo entendido que en 32 bits un exploit puede recurrir a la fuerza bruta para encontrar cualquier simbolo en la libc).

[#28 jemrpo]

Excelente, nunca pensé que las diferencias fueran tan grande, cosa que me sorprende gratamente; afortunadamente Linux y *BSD han hecho grandes avances en esta arquitectura.

[#39 fayser]

Otro detalle a tener en cuenta en las compilaciones para x64 es que se usan las optimizaciones para i686 que aprovecha mejor las características de los procesadores actuales, y no las antiguas i586 para Pentium.

[#36 Brigo]

¿Y las transiciones de disco, diez veces más rápidas, cómo se explican?

[#3 albandy]

Todavía no lo he mirado, quiero comprobar si estoy en lo cierto, el más lento será el que tiene habilitado PAE.

[#4 nando58]

#3 ya te lo digo yo. El PAE es más lento, pero prácticamente igual que el que no lo tiene activado

[#38 Desactivado]

en mi modesta opinion , ubuntu 9.10 acaba de salir , aun tiene para mi punto de vista probelmas , , logicamente 64 es mejor que 32 bits pero claro esta hay que tener un sistema hard preparado para 64 , sino perdemos el tiempo , se puede dar la paradoja de que un sistema 32 vaya a la misma velocidad que un 64 ..

un saludo linuxero , felices fiestas a tod@ssssssssssssssssss

[#11 pom]

Es lo esperado, en un juego no se aprovecha prácticamente el procesador sino la tarjeta gráfica, especialmente en un juego con un motor relativamente antiguo (quake 3).

Hubiera sido más interesante haber hecho una comparativa con procesos de encoding de video por ejemplo (que es donde realmente se vería el rendimiento de los 64 bits) o bien de crackeo de contraseñas WEP. Aun así creo que el rendimiento que ha ganado Apache pone de manifiesto la motivación para cambiar de arquitectura, ya que hasta hace no mucho había muchos excepticos sobre la utilidad del cambio.

[#15 Desactivado]

#11 Sobre lo de WEP, va como el triple de rápido, a ojo, según he probado

[#22 Bad_CRC]

#11 hay unas graficas del john the ripper, de openssl y de encoding de x264...

[#42 morzilla]

#11 Hubiera sido más interesante haber hecho una comparativa con procesos de encoding de video por ejemplo (que es donde realmente se vería el rendimiento de los 64 bits) o bien de crackeo de contraseñas WEP.

Mira las siguientes páginas del artículo. En la última hay un benchmark de encoding con x264. También hay varios criptográficos: OpenSSL, GCrypt, GnuPG y John The Ripper.

[#33 hamster_ruso]

Vamos, que da igual que sea PAE o no PAE, lo que importa es tener un procesador de 64 bits

[#34 krollspell]

#33: precisamente, la comparativa dice lo contrario. Lo que importa es usar un sistema de 64 bits, el procesador es el mismo siempre.

[#1 Desactivado]

Qué resultados más raros, ¿no?. A ver si me animo y hago yo unos benchmark por curiosidad...

[#2 nando58]

#1 ¿Raros? el kernel de 64 bits, aplasta en rendimiento a los otros dos. Era lo esperado ¿no?

[#12 Desactivado]

Y el flash, qué? Otra vez campeón de Europa?
Que baje el rendimiento del Ooffice un 30% me la pela, pero el no poder ver pelis en flash me repatea.

[#14 Almorca]

#12 Flash tiene soporte nativo para 64bit en linux desde la versión 10. Además, tienes altenativas libres como Gnash http://www.gnu.org/software/gnash/ . Así que hay varias alternativas para ver vídeos flash en 64bits en Linux.

A ver si para la próxima nos informamos un poco antes de despotricar.

[#17 Desactivado]

#14 Te devuelvo el negativo porque no es que no este informado, es que estoy viendo una peli de megavideo en flash en Debian.

Sobre el soporte nativo, bien, gracias. Quiero saber el rendimiento. Flash tiene soporte nativo en 32 bits dede hace años pero bien sabe todo el mundo que el rendimiento a pantalla completa en Linux es nulo.
Y ese es el rendimiento que importa a muchos usuarios de linux, como el que suscribe.

Gnash esta muy bien como anecdota, pero no volví a usarlo desde hace 3 años cuando no pude ver unos planos de pistas de esqui, donde simplemente, Gnash no funcionaba.

A ver si para la próxima nos informamos un poco antes de despotricar.

[#31 trollinator]

#12 y además de lo que dice #14, la culpa del pobre rendimiento de flash bajo linux es de Adobe.

[#24 starwars_attacks]

esto es:

spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam spam y no em sale el botón de votos negativos.

[#25 edgard72]

#24 ¿¿Un envío de 150 es spam??