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