[opensuse-es] [OT] Comparativa de kernels de 32 bits, PAE y 64 bits
Hola, Parece que los de Phoronix han hecho una experimento interesante y han comparado el rendimiento de 3 sistemas iguales con Ubuntu pero montando un kernel de 32 bits, otro PAE y un kernel de 64 bits. Los resultados de los distintos "tests", aquí: *** Ubuntu 32-bit, 32-bit PAE, 64-bit Kernel Benchmarks http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae&num=1 In the fourteen tests for this article we did not find using Ubuntu's 32- bit PAE kernel to have a dramatic performance impact whether it be positive or negative. Granted, we were using just 4GB of system memory that is common to many desktops, but if using 8GB, 16GB, or even a greater memory capacity the performance penalties are perhaps higher. By far though exhibiting the best performance was the Ubuntu 64-bit kernel that often ended up being leaps and bounds better than the 32-bit kernel. Unless you have technical or business reasons for not migrating to 64-bit Linux with compatible hardware, there is no reason to stick around with a 32-bit kernel and worrying about physical address extension. *** Resumen: sale ganando el kernel puro de 64 bits. Nota 1 (@Rafa G.): sí, que sí, que síiii, ya sabemos que los "tests" son sólo "tests" y que son variables, cambiantes y estresantes, pero también necesarios para las mentes inquietas :-P Nota 2 (@Carlos E. R.): sí, que sí, que síiiii, ya sabemos que no te fías de la metodología ni del procedimiento de los de Phoronix :-P Nota 3: no hay que morder al "mensajero" O:-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
2009/12/31 Camaleón <noelamac@gmail.com>:
Hola,
Parece que los de Phoronix han hecho una experimento interesante y han comparado el rendimiento de 3 sistemas iguales con Ubuntu pero montando un kernel de 32 bits, otro PAE y un kernel de 64 bits.
Los resultados de los distintos "tests", aquí:
*** Ubuntu 32-bit, 32-bit PAE, 64-bit Kernel Benchmarks http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae&num=1
In the fourteen tests for this article we did not find using Ubuntu's 32- bit PAE kernel to have a dramatic performance impact whether it be positive or negative. Granted, we were using just 4GB of system memory that is common to many desktops, but if using 8GB, 16GB, or even a greater memory capacity the performance penalties are perhaps higher. By far though exhibiting the best performance was the Ubuntu 64-bit kernel that often ended up being leaps and bounds better than the 32-bit kernel. Unless you have technical or business reasons for not migrating to 64-bit Linux with compatible hardware, there is no reason to stick around with a 32-bit kernel and worrying about physical address extension. ***
Esos benchmark, están hechos con aplicaciones que han sido optimizadas para 64 bits, pero en el universo de aplicaciones linux, hay muchas de 32 bits, que solamente han sido "adaptadas" a los 64 bits, y cuando las versiones de 32 bits eran estables, las de 64 bits de esa misma aplicación ya no lo son. No todas las aplicaciones funcionan bien en 64 bits, mas si vas a cargar alguna aplicación de "los otros sistemas operativos" a traves de wine. http://archives.free.net.ph/message/20091117.092452.ab87349c.en.html Y no entremos en el tema de aplicaciones propietarias, como java a flash, que dan bastantes quebraderos de cabeza, y para colmo en entornos de servidores como apache tomcat, donde consume el doble de memoria la versión de 64 bits: http://www.linuxforums.org/forum/linux-tutorials-howtos-reference-material/6... http://www.velocityreviews.com/forums/t150547-tomcat-on-64-bit-optimized-jvm... http://stackoverflow.com/questions/559433/benefits-drawbacks-to-running-64-b... También es cierto, que hay aplicaciones Linux propietarias, como por ejemplo la suite de aplicaciones para cine de Autodesk, que solamente vienen para Linux de 64 bits. http://latinoamerica.autodesk.com/adsk/servlet/item?siteID=7411870&id=11277996 Salu2 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Thu, 31 Dec 2009 13:45:58 -0300, Juan Erbes escribió:
2009/12/31 Camaleón:
Parece que los de Phoronix han hecho una experimento interesante y han comparado el rendimiento de 3 sistemas iguales con Ubuntu pero montando un kernel de 32 bits, otro PAE y un kernel de 64 bits.
Los resultados de los distintos "tests", aquí:
*** Ubuntu 32-bit, 32-bit PAE, 64-bit Kernel Benchmarks http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae&num=1
Esos benchmark, están hechos con aplicaciones que han sido optimizadas para 64 bits, pero en el universo de aplicaciones linux, hay muchas de 32 bits, que solamente han sido "adaptadas" a los 64 bits, y cuando las versiones de 32 bits eran estables, las de 64 bits de esa misma aplicación ya no lo son.
Bueno, pero habrá que aprovechar las que sí están optimizadas ¿no? :-)
No todas las aplicaciones funcionan bien en 64 bits, mas si vas a cargar alguna aplicación de "los otros sistemas operativos" a traves de wine.
http://archives.free.net.ph/message/20091117.092452.ab87349c.en.html
¿Lotus Notes... wine? ¿Quien los necesita teniendo máquinas virtuales optimizadas para sistemas de 64 bits?
Y no entremos en el tema de aplicaciones propietarias, como java a flash, que dan bastantes quebraderos de cabeza,
Esa cantinela ya está pasada. Yo no me he encontrado con ningún problema, salvo los propios de flash, claro. La JRE de Sun no me ha dado problemas tampoco, ya está superado.
y para colmo en entornos de servidores como apache tomcat, donde consume el doble de memoria la versión de 64 bits:
http://www.linuxforums.org/forum/linux-tutorials-howtos-reference- material/69585-should-you-choose-32-bit-64-bit-linux.html
Mensaje del año 2.006 y estamos ya casi en el 2010 :-P
http://www.velocityreviews.com/forums/t150547-tomcat-on-64-bit- optimized-jvm.html
Otro del año 2.006. Juan, tienes que actualizar esos enlaces ;-)
http://stackoverflow.com/questions/559433/benefits-drawbacks-to- running-64-bit-jvm-on-64-bit-linux-server
Y la primera respuesta (la más valorada) de esta página dice que no hay grandes diferencias: ** At the Kepler Science Operations Center we have about 50 machines with 32-64G each. The JVMs heaps are typically 7-20G. We are using Java 6. The OS has Linux 2.6 kernel. When we migrated to 64bit I expected there would be some issues with running the 64-bit JVM But really there have not been. Out of memory conditions are more difficult to debug since the heap dumps are so much larger. The Java Service Wrapper needed some modifications to support larger heap sizes. There are some sites on the web claiming GC does not scale well past 2G, but I've not seen any problems. Finally, we are doing throughput intensive rather interactive intensive computing. I've never looked at latency differences; my guess is worst case GC latency will be longer with the larger heap sizes. ***
También es cierto, que hay aplicaciones Linux propietarias, como por ejemplo la suite de aplicaciones para cine de Autodesk, que solamente vienen para Linux de 64 bits. http://latinoamerica.autodesk.com/adsk/servlet/item? siteID=7411870&id=11277996
¿Has visto los datos del apache 64 bits sirviendo páginas web estáticas? El incremento de rendimiento es tremento con respecto a los otros kernels... ¿será que el apache sí está optimizado? ;-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On Jueves, 31 de Diciembre de 2009 18:33:49 Camaleón escribió:
También es cierto, que hay aplicaciones Linux propietarias, como por ejemplo la suite de aplicaciones para cine de Autodesk, que solamente vienen para Linux de 64 bits. http://latinoamerica.autodesk.com/adsk/servlet/item?
siteID=7411870&id=11277996
¿Has visto los datos del apache 64 bits sirviendo páginas web estáticas? El incremento de rendimiento es tremento con respecto a los otros kernels... ¿será que el apache sí está optimizado? ;-)
Tarde o temprano todo ira adaptandose a los 64 bits, gastara casi el doble de memoria pero eso cada vez es menos problema, esta barata y lo estara mas. Cada vez que hay un cambio basico de tamaño de acumulador, se producen estas discusiones. En el cambio 8 a 16, habia mucha gente a la que precia que era del todo innecesario. Nuevos tamaños hacen nacer nuevas aplicaciones o nuevas formas de hacer algunas de ellas. -- Saludos Lluis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2009-12-31 19:48, Lluis wrote:
Tarde o temprano todo ira adaptandose a los 64 bits, gastara casi el doble de memoria pero eso cada vez es menos problema, esta barata y lo estara mas.
Depende. Yo buscaba una placa de 16 gigas o más, y me he tenido que "conformar" con una de 8.
Cada vez que hay un cambio basico de tamaño de acumulador, se producen estas discusiones. En el cambio 8 a 16, habia mucha gente a la que precia que era del todo innecesario. Nuevos tamaños hacen nacer nuevas aplicaciones o nuevas formas de hacer algunas de ellas.
Cierto. Pero también ocurre que si simplemente recompilas, muchas variables doblan su tamaño innecesariamente, porque, por ejemplo, un longint del compilador pasa de tener 32 bits a tener 64. - -- Cheers / Saludos, Carlos E. R. (from 11.2 "Emerald" GM (bombadillo)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAks9B4EACgkQU92UU+smfQWm/ACggYpZXq8BxsTVmcpkZ1MFvXM8 9HcAnRVKdXJPHh2ON9iRhqZV/uh90Fxv =LWcG -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2009-12-31 18:33, Camaleón wrote:
** At the Kepler Science Operations Center we have about 50 machines with 32-64G each. The JVMs heaps are typically 7-20G. We are using Java 6. The OS has Linux 2.6 kernel.
Es que las máquinas que se gastan esa gente son enormes. - -- Cheers / Saludos, Carlos E. R. (from 11.2 "Emerald" GM (bombadillo)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAks9CBIACgkQU92UU+smfQVmzgCeI7doOaESi14rTZkQ8u0lFiyu 0zEAnjQ4ZpAEOSGAoE6s5/O39SGgSzZX =eC8f -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El día 31 de diciembre de 2009 14:33, Camaleón <noelamac@gmail.com> escribió:
El Thu, 31 Dec 2009 13:45:58 -0300, Juan Erbes escribió:
2009/12/31 Camaleón:
Parece que los de Phoronix han hecho una experimento interesante y han comparado el rendimiento de 3 sistemas iguales con Ubuntu pero montando un kernel de 32 bits, otro PAE y un kernel de 64 bits.
Los resultados de los distintos "tests", aquí:
*** Ubuntu 32-bit, 32-bit PAE, 64-bit Kernel Benchmarks http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae&num=1
Esos benchmark, están hechos con aplicaciones que han sido optimizadas para 64 bits, pero en el universo de aplicaciones linux, hay muchas de 32 bits, que solamente han sido "adaptadas" a los 64 bits, y cuando las versiones de 32 bits eran estables, las de 64 bits de esa misma aplicación ya no lo son.
Bueno, pero habrá que aprovechar las que sí están optimizadas ¿no? :-)
No todas las aplicaciones funcionan bien en 64 bits, mas si vas a cargar alguna aplicación de "los otros sistemas operativos" a traves de wine.
http://archives.free.net.ph/message/20091117.092452.ab87349c.en.html
¿Lotus Notes... wine? ¿Quien los necesita teniendo máquinas virtuales optimizadas para sistemas de 64 bits?
Y no entremos en el tema de aplicaciones propietarias, como java a flash, que dan bastantes quebraderos de cabeza,
Esa cantinela ya está pasada. Yo no me he encontrado con ningún problema, salvo los propios de flash, claro.
La JRE de Sun no me ha dado problemas tampoco, ya está superado.
y para colmo en entornos de servidores como apache tomcat, donde consume el doble de memoria la versión de 64 bits:
http://www.linuxforums.org/forum/linux-tutorials-howtos-reference- material/69585-should-you-choose-32-bit-64-bit-linux.html
Mensaje del año 2.006 y estamos ya casi en el 2010 :-P
http://www.velocityreviews.com/forums/t150547-tomcat-on-64-bit- optimized-jvm.html
Otro del año 2.006. Juan, tienes que actualizar esos enlaces ;-)
http://stackoverflow.com/questions/559433/benefits-drawbacks-to- running-64-bit-jvm-on-64-bit-linux-server
Y la primera respuesta (la más valorada) de esta página dice que no hay grandes diferencias:
** At the Kepler Science Operations Center we have about 50 machines with 32-64G each. The JVMs heaps are typically 7-20G. We are using Java 6. The OS has Linux 2.6 kernel.
When we migrated to 64bit I expected there would be some issues with running the 64-bit JVM But really there have not been. Out of memory conditions are more difficult to debug since the heap dumps are so much larger. The Java Service Wrapper needed some modifications to support larger heap sizes.
There are some sites on the web claiming GC does not scale well past 2G, but I've not seen any problems. Finally, we are doing throughput intensive rather interactive intensive computing. I've never looked at latency differences; my guess is worst case GC latency will be longer with the larger heap sizes. ***
También es cierto, que hay aplicaciones Linux propietarias, como por ejemplo la suite de aplicaciones para cine de Autodesk, que solamente vienen para Linux de 64 bits. http://latinoamerica.autodesk.com/adsk/servlet/item? siteID=7411870&id=11277996
¿Has visto los datos del apache 64 bits sirviendo páginas web estáticas? El incremento de rendimiento es tremento con respecto a los otros kernels... ¿será que el apache sí está optimizado? ;-)
Si le pones apache tomcat, que pasa? Por otro lado, del consumo de memoria de uno u otro sistema, no dice ni mu. Salu2 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-01-01 a las 08:33 -0300, Juan Erbes escribió:
Por otro lado, del consumo de memoria de uno u otro sistema, no dice ni mu.
Es queso depende realmente de lo trabajado que esté el fuente para compilar en 64. O más bien, de cuanta memoria le sobre al desarrollador en su maquinón y las ganas de trabajar que tenga >:-) - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAks94QMACgkQtTMYHG2NR9WTAQCZAbVMkNlnnW+iOxnrvNTbLlqe rc0Anjiv1240YxZhHVNpz0NPyq/tDMOP =TMq6 -----END PGP SIGNATURE-----
El Fri, 01 Jan 2010 08:33:04 -0300, Juan Erbes escribió:
El día 31 de diciembre de 2009 14:33, Camaleón
¿Has visto los datos del apache 64 bits sirviendo páginas web estáticas? El incremento de rendimiento es tremento con respecto a los otros kernels... ¿será que el apache sí está optimizado? ;-)
Si le pones apache tomcat, que pasa?
Que tendrías que leer la documentación para optimizar el uso de la memoria y analizar con lupa las aplicaciones que tengan un consumo elevado de ram, tanto para un kernel pae como para un kernel de 64 bits puro.
Por otro lado, del consumo de memoria de uno u otro sistema, no dice ni mu.
Supongo que el uso de la memoria es una de las variables que se toman en cuenta en cada uno de los tests, incidiendo en el resultado final. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Saludos y, Feliz Año Nuevo ;) On Thursday 31 December 2009 09:42:03 Camaleón wrote:
Hola,
Parece que los de Phoronix han hecho una experimento interesante y han comparado el rendimiento de 3 sistemas iguales con Ubuntu pero montando un kernel de 32 bits, otro PAE y un kernel de 64 bits.
Le di un vistazo, en todos los test se ve que con 64bits los resultados son muy favorables, razón que me anima a conseguir 4 GB de memoria. Sin embargo para los legos como yo, los números entusiasman sin embargo los nombres no. =( Ayudaría un montón, si la gente de Phoronix explicara que beneficios ofrecen esos números al usuario de escritorio y lego. (A simple vista parecen números para sysadmins y sus juguetes, servidores)
Los resultados de los distintos "tests", aquí:
*** Ubuntu 32-bit, 32-bit PAE, 64-bit Kernel Benchmarks http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae&num=1
In the fourteen tests for this article we did not find using Ubuntu's 32- bit PAE kernel to have a dramatic performance impact whether it be positive or negative. Granted, we were using just 4GB of system memory that is common to many desktops, but if using 8GB, 16GB, or even a greater memory capacity the performance penalties are perhaps higher. By far though exhibiting the best performance was the Ubuntu 64-bit kernel that often ended up being leaps and bounds better than the 32-bit kernel. Unless you have technical or business reasons for not migrating to 64-bit Linux with compatible hardware, there is no reason to stick around with a 32-bit kernel and worrying about physical address extension. ***
Resumen: sale ganando el kernel puro de 64 bits.
Nota 1 (@Rafa G.): sí, que sí, que síiii, ya sabemos que los "tests" son sólo "tests" y que son variables, cambiantes y estresantes, pero también necesarios para las mentes inquietas :-P
Después de las fiestas de navidad esta más inquieta de la usual. =P
Nota 2 (@Carlos E. R.): sí, que sí, que síiiii, ya sabemos que no te fías de la metodología ni del procedimiento de los de Phoronix :-P
=/ ¿Alguna sugerencia de a quien creer? =P
Nota 3: no hay que morder al "mensajero" O:-)
Saludos,
Creo que la gente de la lista tiende más a roer, no a morder. ;P Nuevamente, feliz año nuevo a todos. -- Carlos A. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On Thursday 31 December 2009 13:47:45 you wrote:
Saludos y, Feliz Año Nuevo ;)
On Thursday 31 December 2009 09:42:03 Camaleón wrote:
Hola,
Parece que los de Phoronix han hecho una experimento interesante y han comparado el rendimiento de 3 sistemas iguales con Ubuntu pero montando un kernel de 32 bits, otro PAE y un kernel de 64 bits.
Le di un vistazo, en todos los test se ve que con 64bits los resultados son muy favorables, razón que me anima a conseguir 4 GB de memoria. Sin embargo para los legos como yo, los números entusiasman sin embargo los nombres no. =(
Ayudaría un montón, si la gente de Phoronix explicara que beneficios ofrecen esos números al usuario de escritorio y lego. (A simple vista parecen números para sysadmins y sus juguetes, servidores)
Los resultados de los distintos "tests", aquí:
*** Ubuntu 32-bit, 32-bit PAE, 64-bit Kernel Benchmarks http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae&num=1
In the fourteen tests for this article we did not find using Ubuntu's 32- bit PAE kernel to have a dramatic performance impact whether it be positive or negative. Granted, we were using just 4GB of system memory that is common to many desktops, but if using 8GB, 16GB, or even a greater memory capacity the performance penalties are perhaps higher. By far though exhibiting the best performance was the Ubuntu 64-bit kernel that often ended up being leaps and bounds better than the 32-bit kernel. Unless you have technical or business reasons for not migrating to 64-bit Linux with compatible hardware, there is no reason to stick around with a 32-bit kernel and worrying about physical address extension. ***
Resumen: sale ganando el kernel puro de 64 bits.
Nota 1 (@Rafa G.): sí, que sí, que síiii, ya sabemos que los "tests" son sólo "tests" y que son variables, cambiantes y estresantes, pero también necesarios para las mentes inquietas :-P
Después de las fiestas de navidad esta más inquieta de la usual. =P
Nota 2 (@Carlos E. R.): sí, que sí, que síiiii, ya sabemos que no te fías de la metodología ni del procedimiento de los de Phoronix :-P
=/ ¿Alguna sugerencia de a quien creer? =P
Nota 3: no hay que morder al "mensajero" O:-)
Saludos,
Creo que la gente de la lista tiende más a roer, no a morder. ;P
Nuevamente, feliz año nuevo a todos.
=/ Me faltaba mirar a esto: Características del Hardware: http://www.notebookreview.com/default.asp?newsID=3708&review=ThinkPad+T61 Tarjeta de Video: http://www.phoronix.com/scan.php?page=article&item=nvidia_140m&num=1 4GB reales, pensaba que no tendría video discreto. ;( -- Carlos A. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Fri, 01 Jan 2010 10:07:49 -0500, Shinji Ikari escribió:
Le di un vistazo, en todos los test se ve que con 64bits los resultados son muy favorables, razón que me anima a conseguir 4 GB de memoria. Sin embargo para los legos como yo, los números entusiasman sin embargo los nombres no. =(
Ayudaría un montón, si la gente de Phoronix explicara que beneficios ofrecen esos números al usuario de escritorio y lego. (A simple vista parecen números para sysadmins y sus juguetes, servidores)
Bueno, son los resultados que arrojan las pruebas de rendimiento que han ejecutado con su Test Suite. Se supone que cada prueba hace hincapié en distintos aspectos que según el tipo de usuario que seas te resultarán más útiles o menos. Por ejemplo, si eres jugón, te interesarán los tests de rendimiento con OpenGL, el Physics Engine o el C-Ray. Si estás en el campo de la administración, pues el de Apache, el de PostGresSQL o el del PostMark (disco duro) pueden ser interesantes. El resto, pues son genéricos, miden el rendimiento para la codificación de vídeo (hace poco hemos estado hablado de esto, precisamente) o el tiempo de cifrado (GnuPG).
Nota 1 (@Rafa G.): sí, que sí, que síiii, ya sabemos que los "tests" son sólo "tests" y que son variables, cambiantes y estresantes, pero también necesarios para las mentes inquietas :-P
Después de las fiestas de navidad esta más inquieta de la usual. =P
O:-)
Nota 2 (@Carlos E. R.): sí, que sí, que síiiii, ya sabemos que no te fías de la metodología ni del procedimiento de los de Phoronix :-P
=/ ¿Alguna sugerencia de a quien creer? =P
Me parece que te pondría pegas a cualquier cosa que le pusieras delante :-)
Nota 3: no hay que morder al "mensajero" O:-)
Creo que la gente de la lista tiende más a roer, no a morder. ;P
Je :-)
Nuevamente, feliz año nuevo a todos.
Igualmente.
=/ Me faltaba mirar a esto:
Características del Hardware: http://www.notebookreview.com/default.asp?newsID=3708&review=ThinkPad +T61
Tarjeta de Video: http://www.phoronix.com/scan.php?page=article&item=nvidia_140m&num=1
4GB reales, pensaba que no tendría video discreto. ;(
El equipo no es un "maquinón" (lleva un micro de gama media/alta pero no deja de ser un portátil). La gráfica tampoco es de las que "se salen". La gama NVS de nvidia son de tipo profesional, es decir, son muy estables para aplicaciones 2D con prestaciones comedidas pero lejos de ofrecer un buen rendimiento con juegos 3D y demás. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-01-01 a las 15:48 -0000, Camaleón escribió:
El Fri, 01 Jan 2010 10:07:49 -0500, Shinji Ikari escribió:
Nota 2 (@Carlos E. R.): sí, que sí, que síiiii, ya sabemos que no te fías de la metodología ni del procedimiento de los de Phoronix :-P
=/ ¿Alguna sugerencia de a quien creer? =P
Me parece que te pondría pegas a cualquier cosa que le pusieras delante :-)
¡Que va! ¿Yo poner pegas? Si yo no pongo pegas a casi nada, soy un santito. Habrase visto, pegas yo...
:-P
- -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAks+G48ACgkQtTMYHG2NR9XcuwCgj5NF6QwDLIYgYtKjNLUXrQbO ND0AniEwfxRgg6/gNc6e4V0oMLrGxA1L =EjC+ -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2009-12-31 15:42, Camaleón wrote:
Hola,
Parece que los de Phoronix han hecho una experimento interesante y han comparado el rendimiento de 3 sistemas iguales con Ubuntu pero montando un kernel de 32 bits, otro PAE y un kernel de 64 bits.
Los resultados de los distintos "tests", aquí:
*** Ubuntu 32-bit, 32-bit PAE, 64-bit Kernel Benchmarks http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae&num=1
In the fourteen tests for this article we did not find using Ubuntu's 32- bit PAE kernel to have a dramatic performance impact whether it be positive or negative. Granted, we were using just 4GB of system memory that is common to many desktops, but if using 8GB, 16GB, or even a greater memory capacity the performance penalties are perhaps higher. By far though exhibiting the best performance was the Ubuntu 64-bit kernel that often ended up being leaps and bounds better than the 32-bit kernel. Unless you have technical or business reasons for not migrating to 64-bit Linux with compatible hardware, there is no reason to stick around with a 32-bit kernel and worrying about physical address extension. ***
Resumen: sale ganando el kernel puro de 64 bits.
Observa esto: With Ubuntu to properly address 4GB or greater of system memory you need to use a PAE kernel as the Physical Address Extension support through the kernel's high-mem configuration options are not enabled in the default 32-bit kernels. CONFIG_HIGHMEM4G is enabled in the default Ubuntu kernel, but the Ubuntu PAE kernel uses CONFIG_HIGHMEM64G (and other build options) for handling up to 64GB of system memory. Me da la impresión que eso quiere decir que no han probado un kernel de 32 bits non-pae. Además, la máquina que han usado es de 4 GiB, con lo que tampoco han podido probar el efecto que pueda tener tanta memoria por encima del limite de ls 4 gigas. Es decir, no me extraña que no saquen diferencia entre los dos kernels de 32 bits que han probado. Algunas aplicaciones se ven más lentas en 64 bits. Otras en cambio mucho más rápidas, supongo que porque tienen que mover muchos datos y se nota.
Nota 1 (@Rafa G.): sí, que sí, que síiii, ya sabemos que los "tests" son sólo "tests" y que son variables, cambiantes y estresantes, pero también necesarios para las mentes inquietas :-P
:-)
Nota 2 (@Carlos E. R.): sí, que sí, que síiiii, ya sabemos que no te fías de la metodología ni del procedimiento de los de Phoronix :-P
Pues no mucho, la verdad. Ya se lo podían haber currado un poco, usado varias máquinas y varias distros. No es serio.
Nota 3: no hay que morder al "mensajero" O:-)
Güeno :-) - -- Cheers / Saludos, Carlos E. R. (from 11.2 "Emerald" GM (bombadillo)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAks9C5QACgkQU92UU+smfQUwmgCeIhSFAsPY1u4pIGYL9rgYaU7E sd8AoJGVBikzURPRicwBeqDnagyyeuX6 =kpdi -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Thu, 31 Dec 2009 21:37:40 +0100, Carlos E. R. escribió:
On 2009-12-31 15:42, Camaleón wrote:
Parece que los de Phoronix han hecho una experimento interesante y han comparado el rendimiento de 3 sistemas iguales con Ubuntu pero montando un kernel de 32 bits, otro PAE y un kernel de 64 bits.
(...)
Observa esto:
¡¡Arrrghh!! Creo que serías capaz de discutir en medio de una tormenta "si realmente llueve o si se trata sólo de 'una caída de agua fina'". Le sacas punta a todo :-)
With Ubuntu to properly address 4GB or greater of system memory you need to use a PAE kernel as the Physical Address Extension support through the kernel's high-mem configuration options are not enabled in the default 32-bit kernels. CONFIG_HIGHMEM4G is enabled in the default Ubuntu kernel, but the Ubuntu PAE kernel uses CONFIG_HIGHMEM64G (and other build options) for handling up to 64GB of system memory.
Me da la impresión que eso quiere decir que no han probado un kernel de 32 bits non-pae.
¿Por qué lo dices? Ah... ya entiendo. Te adelanto que sí, que llevas razón "en parte" (uno sería un kernel pae "aguachinado" -4 GB- y el otro sería un kernel pae "puro" -64GB-). Lo explica más abajo: *** The only differences in the kernel configuration between Ubuntu's PAE and non-PAE 32-bit kernels are enabling the CONFIG_X86_CMPXCHG64, CONFIG_HIGHMEM64G instead of CONFIG_HIGHMEM4G, CONFIG_X86_PAE, CONFIG_ARCH_PHYS_ADDR_T_64BIT, CONFIG_PHYS_ADDR_T_64BIT, CONFIG_I2O_EXT_ADAPTEC_DMA64, and disabling CONFIG_ASYNC_TX_DMA. The rest of the kernel configuration is the same. The Linux kernel also requires that the CPU itself supports PAE, but these days that is practically all Intel and AMD processors. *** Uséase, la diferencia de rendimiento parece que está entre usar una configuración del kernel con "CONFIG_HIGHMEM4G" (que físicamente limita al kernel a no poder usar más de esos 4 GB.) o "CONFIG_HIGHMEM64G" (limitándolo a los 64 GB.). En este caso, como el equipo monta 4 GB. "físicos" no debería notarse ninguna variación en cuanto al rendimiento (porque el kernel sólo va a poder direccionar 4 GB.) pero el "/quid/" de la cuestión es que parece que *sí afecta* la elección entre un parámetro u otro (más abajo pongo el mensaje donde Linus T. hace hincapié precisamente en este punto).
Además, la máquina que han usado es de 4 GiB, con lo que tampoco han podido probar el efecto que pueda tener tanta memoria por encima del limite de ls 4 gigas.
4 GB es la configuración más común que montan los ensambladores hoy día. Habrán querido hacer un test realista y práctico.
Es decir, no me extraña que no saquen diferencia entre los dos kernels de 32 bits que han probado.
Ellos mismos lo mencionan al final del artículo: a mayor cantidad de ram, mayor sería la penalización (supuestamente) con el kernel PAE "puro" (llamémoslo así) que puede acceder a más memoria, que es lo que comentaba Linus T. hace poco en la lista del kernel y lo cual es el origen de esta tanda de pruebas por parte de los de Phoronix: *** http://lwn.net/Articles/356724/ (...) And for the kernel, the bigger virtual address space really is a _huge_ deal. HIGHMEM accesses really are very slow. You don't see that in user space, but I really have seen 25% performance differences between non-highmem builds and CONFIG_HIGHMEM4G enabled for things that try to put a lot of data in highmem (and the 64G one is even more expensive). And that was just with 2GB of RAM. (inciso de Camaleón: nótese el "and the 64G one is even more expensive. And that was just with 2GB of RAM"). And when it makes the difference between doing IO or not doign IO (ie caching or not caching - when the dentry cache can't grow any more because it _needs_ to be in lowmem), you can literally see an order-of- magnitude difference. With 8GB+ of ram, I guarantee you that the kernel spent tons of time on just mappign high pages, _and_ it couldn't grow inodes and dentry caches nearly as big as it would have wanted to. Going to x86-64 makes all those issues just go away entirely. So it's not "you can save a few instructions by not spilling to stack as much". It's a much bigger deal than that. There's a reason I personally refuse to even care about >2GB 32-bit machines. There's just no excuse these days to do that. *** Ea :-P
Algunas aplicaciones se ven más lentas en 64 bits. Otras en cambio mucho más rápidas, supongo que porque tienen que mover muchos datos y se nota.
¿Has visto el resultado del test de rendimiento que analiza las transacciones del disco por segundo (TPS)? Kernel 32 bits -> 235 Kernel 32 bits PAE -> 227,40 Kernel 64 bits -> 2.297,33 Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2009-12-31 22:37, Camaleón wrote:
El Thu, 31 Dec 2009 21:37:40 +0100, Carlos E. R. escribió:
On 2009-12-31 15:42, Camaleón wrote:
Parece que los de Phoronix han hecho una experimento interesante y han comparado el rendimiento de 3 sistemas iguales con Ubuntu pero montando un kernel de 32 bits, otro PAE y un kernel de 64 bits.
(...)
Observa esto:
¡¡Arrrghh!!
Creo que serías capaz de discutir en medio de una tormenta "si realmente llueve o si se trata sólo de 'una caída de agua fina'".
Le sacas punta a todo :-)
¿No esperabas que lo hiciera? >:-)
With Ubuntu to properly address 4GB or greater of system memory you need to use a PAE kernel as the Physical Address Extension support through the kernel's high-mem configuration options are not enabled in the default 32-bit kernels. CONFIG_HIGHMEM4G is enabled in the default Ubuntu kernel, but the Ubuntu PAE kernel uses CONFIG_HIGHMEM64G (and other build options) for handling up to 64GB of system memory.
Me da la impresión que eso quiere decir que no han probado un kernel de 32 bits non-pae.
¿Por qué lo dices?
Ah... ya entiendo. Te adelanto que sí, que llevas razón "en parte" (uno sería un kernel pae "aguachinado" -4 GB- y el otro sería un kernel pae "puro" -64GB-).
Sasto. Pero creo que en openSUSE sí hubieran podido probar un verdadero kernel no pae. ¿No lo usabas tú, que no te reconocía toda la ram por eso?
Lo explica más abajo:
*** The only differences in the kernel configuration between Ubuntu's PAE and non-PAE 32-bit kernels are enabling the CONFIG_X86_CMPXCHG64, CONFIG_HIGHMEM64G instead of CONFIG_HIGHMEM4G, CONFIG_X86_PAE, CONFIG_ARCH_PHYS_ADDR_T_64BIT, CONFIG_PHYS_ADDR_T_64BIT, CONFIG_I2O_EXT_ADAPTEC_DMA64, and disabling CONFIG_ASYNC_TX_DMA. The rest of the kernel configuration is the same. The Linux kernel also requires that the CPU itself supports PAE, but these days that is practically all Intel and AMD processors. ***
Uséase, la diferencia de rendimiento parece que está entre usar una configuración del kernel con "CONFIG_HIGHMEM4G" (que físicamente limita al kernel a no poder usar más de esos 4 GB.) o "CONFIG_HIGHMEM64G" (limitándolo a los 64 GB.).
En este caso, como el equipo monta 4 GB. "físicos" no debería notarse ninguna variación en cuanto al rendimiento (porque el kernel sólo va a poder direccionar 4 GB.) pero el "/quid/" de la cuestión es que parece que *sí afecta* la elección entre un parámetro u otro (más abajo pongo el mensaje donde Linus T. hace hincapié precisamente en este punto).
Bueno, es que también les critico que sólo hayan probado en una máquina. Hablamos de /los/ de phoronix, pero es que así podría hacer yo las pruebas en mi casa, con un sólo ordenador. Las comparativas han de ser más extensas. Son un poco ratas si sólo hacen pruebas en un portátil, eso también puedo hacerlo yo con mi cutre sueldo.
Además, la máquina que han usado es de 4 GiB, con lo que tampoco han podido probar el efecto que pueda tener tanta memoria por encima del limite de ls 4 gigas.
4 GB es la configuración más común que montan los ensambladores hoy día. Habrán querido hacer un test realista y práctico.
Hay que ir un poco más allá. A mi 4 GiB me parece poca memoria hoy en dia, sobre todo pensando en usar cpus de 64 bits. Caray, que mi ordenador antiguo de casi diez años tiene un giga desde hace seis años. ¿Sólo cuatro veces más ram en estos años? Se quedan cortos al probar la potencia.
Es decir, no me extraña que no saquen diferencia entre los dos kernels de 32 bits que han probado.
Ellos mismos lo mencionan al final del artículo: a mayor cantidad de ram, mayor sería la penalización (supuestamente) con el kernel PAE "puro" (llamémoslo así) que puede acceder a más memoria, que es lo que comentaba Linus T. hace poco en la lista del kernel y lo cual es el origen de esta tanda de pruebas por parte de los de Phoronix:
Sí, supuestamente, pero ellos no lo han demostrado. Eso es lo que espero de un sitio que se dedica a hacer pruebas, a que lo prueben, a que hagan el experimento.
*** http://lwn.net/Articles/356724/ (...)
And for the kernel, the bigger virtual address space really is a _huge_ deal. HIGHMEM accesses really are very slow. You don't see that in user space, but I really have seen 25% performance differences between non-highmem builds and CONFIG_HIGHMEM4G enabled for things that try to put a lot of data in highmem (and the 64G one is even more expensive). And that was just with 2GB of RAM.
(inciso de Camaleón: nótese el "and the 64G one is even more expensive. And that was just with 2GB of RAM").
And when it makes the difference between doing IO or not doign IO (ie caching or not caching - when the dentry cache can't grow any more because it _needs_ to be in lowmem), you can literally see an order-of- magnitude difference.
With 8GB+ of ram, I guarantee you that the kernel spent tons of time on just mappign high pages, _and_ it couldn't grow inodes and dentry caches nearly as big as it would have wanted to. Going to x86-64 makes all those issues just go away entirely.
So it's not "you can save a few instructions by not spilling to stack as much". It's a much bigger deal than that. There's a reason I personally refuse to even care about >2GB 32-bit machines. There's just no excuse these days to do that. ***
Ea :-P
Claro, si me lo creo. Pero quiero que me lo midan, que experimenten, que me lo prueben...
Algunas aplicaciones se ven más lentas en 64 bits. Otras en cambio mucho más rápidas, supongo que porque tienen que mover muchos datos y se nota.
¿Has visto el resultado del test de rendimiento que analiza las transacciones del disco por segundo (TPS)?
Kernel 32 bits -> 235 Kernel 32 bits PAE -> 227,40 Kernel 64 bits -> 2.297,33
Sí, lo he visto. Pero no sé exactamente que hace ese test. ¿Que es una transacción? ¿Abrir un fichero de 1KiB? ¿Grabarlo, escribirlo, cerrarlo, que? ¿De un mega, de un giga? ¿Una mezcla? ¿Operaciones de escritura de 10 KiB con posicionamiento en un fichero de 2 GiB? Hay muchas posibilidades. Si la transacción es únicamente la creación de ficheros, o la escritura de trozos pequeños, me resulta llamativo el resultado. Si se trata de escribir una cantidad considerable de datos, entonces es totalmente lógico: el bus es más ancho, se escriben más datos por operación. Ah, mira, alguno de los comentarios dan en clavos interesantes. El #2: If the latter do you know what Ubuntu compiles it's 32bit user space as? If memory serves I think ubuntu are using i486 on 32bit user space where as the 64bit user space will be using sse2 as default which could explain some of the differences Would it be possible to try the same test again using Gentoo or Arch (or another distro that uses i686 as default) Es decir, realmente deberían probar con un kernel custom, en el que sólo cambian alguna de las variables. Kernel y todas las librerías, claro. Hay diferencia entre un target 486 y un 686. El #3 explica la diferencia de velocidad en los tests de openssl y john the ripper, y no es por los 64 bits en el acceso a memoria. - -- Cheers / Saludos, Carlos E. R. (from 11.2 "Emerald" GM (bombadillo)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAks9PBcACgkQU92UU+smfQVw5QCfRpByHcZdVu67qQKLANyHOe1A t/wAn0XvO8VqnZwa3Pa21Sgz2YP1a5pA =L6xh -----END PGP SIGNATURE----- -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El Fri, 01 Jan 2010 01:04:39 +0100, Carlos E. R. escribió:
On 2009-12-31 22:37, Camaleón wrote:
Le sacas punta a todo :-)
¿No esperabas que lo hiciera? >:-)
Por eso puse las notas a pie en el primer correo, anticipándome al devenir del hilo :-)
Me da la impresión que eso quiere decir que no han probado un kernel de 32 bits non-pae.
¿Por qué lo dices?
Ah... ya entiendo. Te adelanto que sí, que llevas razón "en parte" (uno sería un kernel pae "aguachinado" -4 GB- y el otro sería un kernel pae "puro" -64GB-).
Sasto.
Pero creo que en openSUSE sí hubieran podido probar un verdadero kernel no pae. ¿No lo usabas tú, que no te reconocía toda la ram por eso?
No sé qué parámetros utilizarían en openSUSE 10.3 para el kernel-default de 32 bits :-?. Pero parece que en este caso pasa lo mismo: el kernel que usan con "CONFIG_HIGHMEM4G" no puede acceder a más de 3 GB. de ram.
Uséase, la diferencia de rendimiento parece que está entre usar una configuración del kernel con "CONFIG_HIGHMEM4G" (que físicamente limita al kernel a no poder usar más de esos 4 GB.) o "CONFIG_HIGHMEM64G" (limitándolo a los 64 GB.).
En este caso, como el equipo monta 4 GB. "físicos" no debería notarse ninguna variación en cuanto al rendimiento (porque el kernel sólo va a poder direccionar 4 GB.) pero el "/quid/" de la cuestión es que parece que *sí afecta* la elección entre un parámetro u otro (más abajo pongo el mensaje donde Linus T. hace hincapié precisamente en este punto).
Bueno, es que también les critico que sólo hayan probado en una máquina. Hablamos de /los/ de phoronix, pero es que así podría hacer yo las pruebas en mi casa, con un sólo ordenador. Las comparativas han de ser más extensas. Son un poco ratas si sólo hacen pruebas en un portátil, eso también puedo hacerlo yo con mi cutre sueldo.
Son pruebas que hacen porque la gente se lo ha pedido, no le des más vueltas. Pruebas que analizan el rendimiento de equipos que podemos tener cualquier de nosotros... si hasta han usado un portátil :-) Es decir, son tests de "estar por casa" pero un poco más afinados de los que podríamos hacer nosotros.
4 GB es la configuración más común que montan los ensambladores hoy día. Habrán querido hacer un test realista y práctico.
Hay que ir un poco más allá. A mi 4 GiB me parece poca memoria hoy en dia, sobre todo pensando en usar cpus de 64 bits. Caray, que mi ordenador antiguo de casi diez años tiene un giga desde hace seis años. ¿Sólo cuatro veces más ram en estos años? Se quedan cortos al probar la potencia.
Es un ordenador portátil, no han probado en un equipo de sobremesa. A ver, la elección de 4GB tiene su parte lógica, ya que es la cantidad justa para que la memoria no fuera un factor determinante en los resultados de los tests. Si hubieran montado 8GB (o más) en los equipos, el que usa un kernel de 32 bits con PAE "limitado" a 4 GB hubiera tenido una disminución-discriminación del rendimiento notable y eso hubiera desvirtuado los resultados. Es decir, el objetivo de los tests entiendo que no era el uso de la ram sino analizar cómo "una sola variable" puede alterar el rendimiento del mismo kernel en el mismo equipo con la misma cantidad de RAM.
Ellos mismos lo mencionan al final del artículo: a mayor cantidad de ram, mayor sería la penalización (supuestamente) con el kernel PAE "puro" (llamémoslo así) que puede acceder a más memoria, que es lo que comentaba Linus T. hace poco en la lista del kernel y lo cual es el origen de esta tanda de pruebas por parte de los de Phoronix:
Sí, supuestamente, pero ellos no lo han demostrado. Eso es lo que espero de un sitio que se dedica a hacer pruebas, a que lo prueben, a que hagan el experimento.
Para hacer esa prueba tendrían que comparar sólo el kernel PAE (64GB) y el kernel de 64 bits, con una cantidad de ram mayor en el equipo (8, 16 y32, por ejemplo). Pero ¿sabes qué hubiera pasado? Que entonces la gente se hubiera quejado (te incluyo >:-P) de que la configuración de esos equipos "no se corresponde con la realidad", "que nadie monta 32 GB de ram", etc... Tenéis que entender el test no como una verdad absoluta sino como respuesta a una petición popular.
With 8GB+ of ram, I guarantee you that the kernel spent tons of time on just mappign high pages, _and_ it couldn't grow inodes and dentry caches nearly as big as it would have wanted to. Going to x86-64 makes all those issues just go away entirely.
So it's not "you can save a few instructions by not spilling to stack as much". It's a much bigger deal than that. There's a reason I personally refuse to even care about >2GB 32-bit machines. There's just no excuse these days to do that. ***
Ea :-P
Claro, si me lo creo. Pero quiero que me lo midan, que experimenten, que me lo prueben...
A ver si hacen otro análisis >:-) Pero yo me fío de las palabras de Linus, si él lo dice (y lo ha visto, además) pues algo habrá...
¿Has visto el resultado del test de rendimiento que analiza las transacciones del disco por segundo (TPS)?
Kernel 32 bits -> 235 Kernel 32 bits PAE -> 227,40 Kernel 64 bits -> 2.297,33
Sí, lo he visto. Pero no sé exactamente que hace ese test. ¿Que es una transacción? ¿Abrir un fichero de 1KiB? ¿Grabarlo, escribirlo, cerrarlo, que? ¿De un mega, de un giga? ¿Una mezcla? ¿Operaciones de escritura de 10 KiB con posicionamiento en un fichero de 2 GiB? Hay muchas posibilidades.
Si la transacción es únicamente la creación de ficheros, o la escritura de trozos pequeños, me resulta llamativo el resultado. Si se trata de escribir una cantidad considerable de datos, entonces es totalmente lógico: el bus es más ancho, se escriben más datos por operación.
Eso te lo podrá decir mejor Rafa, qué es lo que se analiza en este tipo de tests. Este en concreto se llama PostMark... busquemos en Google a ver qué pone (ojo, es un PDF): *** PostMark: A New File System Benchmark http://communities.netapp.com/servlet/JiveServlet/download/2609-1551/Katcher... Abstract Existing file system benchmarks are deficient in portraying performance in the ephemeral small-file regime used by Internet software, especially: electronic mail; netnews; and web-based commerce. PostMark is a new benchmark to measure performance for this class of application. In this paper, PostMark test results are presented and analyzed for both UNIX and Windows NT application servers. Network Appliance Filers (file server appliances) are shown to provide superior performance (via NFS or CIFS) compared to local disk alternatives, especially at higher loads. Such results are consistent with reports from ISPs (Internet Service Providers) who have deployed NetApp filers to support such applications on a large scale. ***
Ah, mira, alguno de los comentarios dan en clavos interesantes. El #2:
If the latter do you know what Ubuntu compiles it's 32bit user space as? If memory serves I think ubuntu are using i486 on 32bit user space where as the 64bit user space will be using sse2 as default which could explain some of the differences
Would it be possible to try the same test again using Gentoo or Arch (or another distro that uses i686 as default)
Es decir, realmente deberían probar con un kernel custom, en el que sólo cambian alguna de las variables. Kernel y todas las librerías, claro. Hay diferencia entre un target 486 y un 686.
Que sí... juvar :-). Pero Ubuntu es una distribución que, en términos generales, comparte características (en cuanto a parámetros de compilación del kernel, espacio de usuario, etc...) similares a openSUSE o Fedora. Es decir, la gente quiere analizar cuál es el comportamiento de una distribución que puedan tener instalada en sus equipos, en lugar de conocer el rendimiento de sistemas optimizados para una arquitectura u otra.
El #3 explica la diferencia de velocidad en los tests de openssl y john the ripper, y no es por los 64 bits en el acceso a memoria.
Es otra ventaja de usar un kernel de 64 bits puro: "it's optimized by design" :-P Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-01-01 a las 13:10 -0000, Camaleón escribió:
El Fri, 01 Jan 2010 01:04:39 +0100, Carlos E. R. escribió:
Me da la impresión que eso quiere decir que no han probado un kernel de 32 bits non-pae.
¿Por qué lo dices?
Ah... ya entiendo. Te adelanto que sí, que llevas razón "en parte" (uno sería un kernel pae "aguachinado" -4 GB- y el otro sería un kernel pae "puro" -64GB-).
Sasto.
Pero creo que en openSUSE sí hubieran podido probar un verdadero kernel no pae. ¿No lo usabas tú, que no te reconocía toda la ram por eso?
No sé qué parámetros utilizarían en openSUSE 10.3 para el kernel-default de 32 bits :-?. Pero parece que en este caso pasa lo mismo: el kernel que usan con "CONFIG_HIGHMEM4G" no puede acceder a más de 3 GB. de ram.
El kernel sí, las aplicaciones, no. Eso es lo que tengo entendido, tendría que mirarlo. El kernel pae de la 11.0 no lo usa: # CONFIG_NOHIGHMEM is not set # CONFIG_HIGHMEM4G is not set CONFIG_HIGHMEM64G=y El default si: # CONFIG_NOHIGHMEM is not set CONFIG_HIGHMEM4G=y # CONFIG_HIGHMEM64G is not set
Bueno, es que también les critico que sólo hayan probado en una máquina. Hablamos de /los/ de phoronix, pero es que así podría hacer yo las pruebas en mi casa, con un sólo ordenador. Las comparativas han de ser más extensas. Son un poco ratas si sólo hacen pruebas en un portátil, eso también puedo hacerlo yo con mi cutre sueldo.
Son pruebas que hacen porque la gente se lo ha pedido, no le des más vueltas. Pruebas que analizan el rendimiento de equipos que podemos tener cualquier de nosotros... si hasta han usado un portátil :-)
Es decir, son tests de "estar por casa" pero un poco más afinados de los que podríamos hacer nosotros.
Pues eso critico, que sean de andar por casa.
4 GB es la configuración más común que montan los ensambladores hoy día. Habrán querido hacer un test realista y práctico.
Hay que ir un poco más allá. A mi 4 GiB me parece poca memoria hoy en dia, sobre todo pensando en usar cpus de 64 bits. Caray, que mi ordenador antiguo de casi diez años tiene un giga desde hace seis años. ¿Sólo cuatro veces más ram en estos años? Se quedan cortos al probar la potencia.
Es un ordenador portátil, no han probado en un equipo de sobremesa.
A ver, la elección de 4GB tiene su parte lógica, ya que es la cantidad justa para que la memoria no fuera un factor determinante en los resultados de los tests. Si hubieran montado 8GB (o más) en los equipos, el que usa un kernel de 32 bits con PAE "limitado" a 4 GB hubiera tenido una disminución-discriminación del rendimiento notable y eso hubiera desvirtuado los resultados.
Es decir, el objetivo de los tests entiendo que no era el uso de la ram sino analizar cómo "una sola variable" puede alterar el rendimiento del mismo kernel en el mismo equipo con la misma cantidad de RAM.
Me resulta pobre. Que la memoria no afecta es una suposición.
Ellos mismos lo mencionan al final del artículo: a mayor cantidad de ram, mayor sería la penalización (supuestamente) con el kernel PAE "puro" (llamémoslo así) que puede acceder a más memoria, que es lo que comentaba Linus T. hace poco en la lista del kernel y lo cual es el origen de esta tanda de pruebas por parte de los de Phoronix:
Sí, supuestamente, pero ellos no lo han demostrado. Eso es lo que espero de un sitio que se dedica a hacer pruebas, a que lo prueben, a que hagan el experimento.
Para hacer esa prueba tendrían que comparar sólo el kernel PAE (64GB) y el kernel de 64 bits, con una cantidad de ram mayor en el equipo (8, 16 y32, por ejemplo).
Pero ¿sabes qué hubiera pasado? Que entonces la gente se hubiera quejado (te incluyo >:-P) de que la configuración de esos equipos "no se corresponde con la realidad", "que nadie monta 32 GB de ram", etc...
Tenéis que entender el test no como una verdad absoluta sino como respuesta a una petición popular.
Pero es que podrían probarlo todo. Eso es lo que yo espero de una entidad que se dedica a hacer probatinas.
With 8GB+ of ram, I guarantee you that the kernel spent tons of time on just mappign high pages, _and_ it couldn't grow inodes and dentry caches nearly as big as it would have wanted to. Going to x86-64 makes all those issues just go away entirely.
So it's not "you can save a few instructions by not spilling to stack as much". It's a much bigger deal than that. There's a reason I personally refuse to even care about >2GB 32-bit machines. There's just no excuse these days to do that. ***
Ea :-P
Claro, si me lo creo. Pero quiero que me lo midan, que experimenten, que me lo prueben...
A ver si hacen otro análisis >:-)
Pero yo me fío de las palabras de Linus, si él lo dice (y lo ha visto, además) pues algo habrá...
Y yo también, pero si esta gente se dedica a hacer purebas, pues que lo prueben.
¿Has visto el resultado del test de rendimiento que analiza las transacciones del disco por segundo (TPS)?
Kernel 32 bits -> 235 Kernel 32 bits PAE -> 227,40 Kernel 64 bits -> 2.297,33
Sí, lo he visto. Pero no sé exactamente que hace ese test. ¿Que es una transacción? ¿Abrir un fichero de 1KiB? ¿Grabarlo, escribirlo, cerrarlo, que? ¿De un mega, de un giga? ¿Una mezcla? ¿Operaciones de escritura de 10 KiB con posicionamiento en un fichero de 2 GiB? Hay muchas posibilidades.
Si la transacción es únicamente la creación de ficheros, o la escritura de trozos pequeños, me resulta llamativo el resultado. Si se trata de escribir una cantidad considerable de datos, entonces es totalmente lógico: el bus es más ancho, se escriben más datos por operación.
Eso te lo podrá decir mejor Rafa, qué es lo que se analiza en este tipo de tests.
Los hay de todas clases. En pruebas que he visto otras veces en revistas que publican tests, el test de ficheros son varios, con tiempos desglosados entre ficheros grandes medios y pequeños, aperturas, seeks... este sólo da una única medida no especificada.
Este en concreto se llama PostMark... busquemos en Google a ver qué pone (ojo, es un PDF):
*** PostMark: A New File System Benchmark http://communities.netapp.com/servlet/JiveServlet/download/2609-1551/Katcher...
Abstract Existing file system benchmarks are deficient in portraying performance in the ephemeral small-file regime used by Internet software, especially: electronic mail; netnews; and web-based commerce.
Ah, o sea, software para internet. Mmm. Pues entonces no resulta un test demasiado interesante.
Ah, mira, alguno de los comentarios dan en clavos interesantes. El #2:
If the latter do you know what Ubuntu compiles it's 32bit user space as? If memory serves I think ubuntu are using i486 on 32bit user space where as the 64bit user space will be using sse2 as default which could explain some of the differences
Would it be possible to try the same test again using Gentoo or Arch (or another distro that uses i686 as default)
Es decir, realmente deberían probar con un kernel custom, en el que sólo cambian alguna de las variables. Kernel y todas las librerías, claro. Hay diferencia entre un target 486 y un 686.
Que sí... juvar :-).
Pero Ubuntu es una distribución que, en términos generales, comparte características (en cuanto a parámetros de compilación del kernel, espacio de usuario, etc...) similares a openSUSE o Fedora.
Es decir, la gente quiere analizar cuál es el comportamiento de una distribución que puedan tener instalada en sus equipos, en lugar de conocer el rendimiento de sistemas optimizados para una arquitectura u otra.
Si se trata de hacer pruebas, pues claro que interesa.
El #3 explica la diferencia de velocidad en los tests de openssl y john the ripper, y no es por los 64 bits en el acceso a memoria.
Es otra ventaja de usar un kernel de 64 bits puro: "it's optimized by design" :-P
Pero es que no es eso, es que esos programs en particular se benefician de unas instrucciones concretas que tiene la cpu de 64 bits. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAks+IoYACgkQtTMYHG2NR9V+iQCgkPWagADtqN8DOuJj+8wGhjzH DfkAniBEkrrMbkQLWbJ0vk/V+z9gGH5O =wTCB -----END PGP SIGNATURE-----
El Fri, 01 Jan 2010 17:27:43 +0100, Carlos E. R. escribió:
Este en concreto se llama PostMark... busquemos en Google a ver qué pone (ojo, es un PDF):
*** PostMark: A New File System Benchmark http://communities.netapp.com/servlet/JiveServlet/download/2609-1551/ Katcher97-postmark-netapp-tr3022.pdf
Abstract Existing file system benchmarks are deficient in portraying performance in the ephemeral small-file regime used by Internet software, especially: electronic mail; netnews; and web-based commerce.
Ah, o sea, software para internet. Mmm. Pues entonces no resulta un test demasiado interesante.
Si no utilizas aplicaciones que muevan archivos pequeños, pues quizá no te interese.
El #3 explica la diferencia de velocidad en los tests de openssl y john the ripper, y no es por los 64 bits en el acceso a memoria.
Es otra ventaja de usar un kernel de 64 bits puro: "it's optimized by design" :-P
Pero es que no es eso, es que esos programs en particular se benefician de unas instrucciones concretas que tiene la cpu de 64 bits.
Y que por tanto no se habilitan con un kernel de 32 bits (aunque la cpu sea la misma en ambos casos) por lo que el rendimiento cae en picado cuando se ejecutan esos tests. Normal. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-01-01 a las 17:02 -0000, Camaleón escribió:
El Fri, 01 Jan 2010 17:27:43 +0100, Carlos E. R. escribió:
Ah, o sea, software para internet. Mmm. Pues entonces no resulta un test demasiado interesante.
Si no utilizas aplicaciones que muevan archivos pequeños, pues quizá no te interese.
A veces se manejan pequeños, a veces grandes. Hay que estudiar el comportamiento en todos los casos.
Pero es que no es eso, es que esos programs en particular se benefician de unas instrucciones concretas que tiene la cpu de 64 bits.
Y que por tanto no se habilitan con un kernel de 32 bits (aunque la cpu sea la misma en ambos casos) por lo que el rendimiento cae en picado cuando se ejecutan esos tests. Normal.
Eso es lo que llevo diciendo nosecuanto. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAks+SjEACgkQtTMYHG2NR9WQtgCcD/AMF96Pt1NgrWZd/3hkf5JL MdgAn04zGbg5ouQB3G5qc0rKOvS3mna1 =+L32 -----END PGP SIGNATURE-----
Hola :) On Thursday 31 December 2009 15:42:03 Camaleón wrote:
Hola,
Parece que los de Phoronix han hecho una experimento interesante y han comparado el rendimiento de 3 sistemas iguales con Ubuntu pero montando un kernel de 32 bits, otro PAE y un kernel de 64 bits.
Los resultados de los distintos "tests", aquí:
*** Ubuntu 32-bit, 32-bit PAE, 64-bit Kernel Benchmarks http://www.phoronix.com/scan.php?page=article&item=ubuntu_32_pae&num=1
In the fourteen tests for this article we did not find using Ubuntu's 32- bit PAE kernel to have a dramatic performance impact whether it be positive or negative. Granted, we were using just 4GB of system memory that is common to many desktops, but if using 8GB, 16GB, or even a greater memory capacity the performance penalties are perhaps higher. By far though exhibiting the best performance was the Ubuntu 64-bit kernel that often ended up being leaps and bounds better than the 32-bit kernel. Unless you have technical or business reasons for not migrating to 64-bit Linux with compatible hardware, there is no reason to stick around with a 32-bit kernel and worrying about physical address extension. ***
Resumen: sale ganando el kernel puro de 64 bits.
Nota 1 (@Rafa G.): sí, que sí, que síiii, ya sabemos que los "tests" son sólo "tests" y que son variables, cambiantes y estresantes, pero también necesarios para las mentes inquietas :-P
No seré muy pesao 0;) Me parece interesante qu elo hayan hecho (no quiero entrar en debates ni dar MHO porque ya la conocéis ;) Pero me parece interesante que lo hagan porque parece ser que se está ya dando el paso a los 64 bits 100%. Así que este tipo de benchmarks vendrán bien aunque sólo sea para hacernos una idea de por dónde van los tiros. Otra cosa que me gusta es que Phoronix está haciendo pruebas de los kernels y va diciendo si la versión nueva tiene problemas o da resultados mejores o peores que versiones antiuas, ... NOTA: no se me ha subido el champán ni el vino ni me estoy volviendo blando ;) Sigo sin "creer al 100% en los benchmarks generalistas", pero hay veces que hay que reconocer que de vez en cuando vienen bien (esto lo digo con la boca pequeña y en voz baja para que no se oiga ;) Ahora que tenemos estas pruebas, los desarrolladores y empresas desarrolladoras deben hacer los suyos y analizar si realmente vamos mejorando o no. Pruebas "de verdad" que analicen entornos reales de producción. Otra cosa que seguiré repitiendo hasta la saciedad es que hay que tener cuidado a la hora de interpretar los resultados y entender cómo funciona cada aplicación y el hardware en sí antes de decidir si algo es "bueno o malo".
Nota 2 (@Carlos E. R.): sí, que sí, que síiiii, ya sabemos que no te fías de la metodología ni del procedimiento de los de Phoronix :-P
Qué tío, si es que con tal de llevar la contraria ;)
Nota 3: no hay que morder al "mensajero" O:-)
;) Rafa -- "We cannot treat computers as Humans. Computers need love." rgriman@skype.com rgriman@jabberes.org Happily using KDE 4.3.3 :) -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2010-01-05 a las 17:59 +0100, Rafa Grimán escribió:
On Thursday 31 December 2009 15:42:03 Camaleón wrote:
...
Nota 2 (@Carlos E. R.): sí, que sí, que síiiii, ya sabemos que no te fías de la metodología ni del procedimiento de los de Phoronix :-P
Qué tío, si es que con tal de llevar la contraria ;)
Es que si no, no te dan el título >:-) - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAktD2c0ACgkQtTMYHG2NR9XsKQCfdAZrikweOXgqnQMUFq+JyxDg XLYAnRzcZ67SsjrUSOvr9NSHeebaevMD =N1+8 -----END PGP SIGNATURE-----
participants (7)
-
Camaleón -
Carlos E. R. -
Carlos E. R. -
Juan Erbes -
Lluis -
Rafa Grimán -
Shinji Ikari