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