-----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