6. FAQ (Preguntas Frecuentes)

P1.

¿Hay alguna medida aislada del mérito de los sistemas Linux?

R:

No, gracias al cielo nadie ha salido todavía con una medida Lhinuxstone (tm). Y si hubiera una, no tendría mucho sentido: los sistemas Linux se usan para diversas tareas, desde servidores Web muy cargados hasta estaciones gráficas para uso individual. Ninguna medida de mérito por separado puede describir el rendimiento de un sistema Linux bajo tales situaciones diferentes.

P2.

Entonces, ¿qué tal una docena de cifras resumiendo el rendimiento de diversos sistemas Linux?

R:

Esa sería la situación ideal. Me gustaría ver que se hace realidad. ¿Voluntarios para un Linux Benchmarking Project? ¿Con un sitio web y una base de datos en línea, completa y con informes bien diseñados?

P3.

... ¿BogoMips...?

R:

Los BogoMips no tienen nada que ver con el rendimiento de su sistema. Lea el BogoMips Mini-HOWTO.

P4.

¿Cuá es el 'mejor' banco de pruebas para Linux?

R:

Todo depende de qué aspecto del rendimiento de un sistema Linux quiera medir uno. Hay diferentes bancos de pruebas para medir la red (tasa sostenida de transferencia Ethernet), servidores de ficheros (NFS), E/S de disco, FPU, enteros, gráficos, 3D, ancho de banda procesador-memoria, rendimiento CAD, tiempo de transacción, rendimiento SQL, rendimiento de servidor web, rendimiento en tiempo real (Real-Time), rendimiento del CD-ROM, rendimiento de Quake (¡!), etc... HDYS

HDYS = Hasta Donde Yo Sé (AFAIK = As Far As I Know)

, no existe ningún conjunto de pruebas para Linux que realice todas estas pruebas.

P5.

¿Cuál es el procesador más rápido sobre el que corre Linux?

R:

¿Más rápido en qué tarea? Si estamos orientados a un gran procesamiento de números, un Alpha de gran velocidad de reloj (600MHz y superior) debería ser más rápido que ninguna otra cosa, ya que los Alpha se han diseñado para ese tipo de rendimiento. Si, por otro lado, uno quiere poner un servidor de news muy rápido, es probable que la elección de un subsistema de disco duro muy rápido y muchísima RAM de un rendimiento mucho más alto que un cambio de procesador, por la misma cantidad de $.

P6.

Permítame rehacer la pregunta anterior, entonces: ¿hay algún procesador que sea más rápido para aplicaciones de propósito general?

R:

Esa es una difícil con truco, pero tiene una respuesta muy sencilla: NO. Siempre podremos diseñar un sistema más rápido incluso para aplicaciones de uso general, independientemente del procesador. Normalmente, siendo todos los demás elementos iguales, mayores tasas de reloj darán sistemas de mayor rendimiento (y también más dolores de cabeza). Sacando un viejo Pentium a 100MHz de una (no suele ser así) placa madre actualizable, y enchufando la versión a 200MHz, uno debería sentir el "umppffff" extra. Por supuesto, con sólo 16 MBytes de RAM, se podría haber hecho la misma inversión, más sabiamente, en unos SIMM extra...

P7.

¿De manera que la velocidad de reloj influye en el rendimiento del sistema?

R:

Para la mayoría de las tareas excepto los bucles NOP vacíos (por cierto, son eliminados por los compiladores optimizadores modernos), un aumento en la velocidad del reloj no nos dará un aunmento lineal en rendimiento. Los programas muy pequeños e intensivos que quepan enteros en la caché primaria del procesador (la caché L1, normalmente de 8 o 16K), obtendrán un aumento de rendimiento equivalente al de la velocidad de reloj, pero la mayoría de los programas "reales" son mucho más grandes que eso, tienen bucles que no caben en la caché L1, comparten la caché L2 (externa) con otros procesos, dependen de componentes externos y obtendrán incrementos mucho menores de rendimiento. Esto es así porque la caché L1 funciona a la misma velocidad de reloj que el procesador, mientras que la mayoría de las caché L2 y el resto de los subsistemas (DRAM, por ejemplo, funcionan de forma asíncrona a menores velocidades.

P8.

Bien, entonces, una última pregunta sobre el asunto: ¿cual es el procesador que proporciona una mejor tasa precio/rendimiento para usos de propósito general de Linux?

R:

¡Definir "uso de propósito general de Linux no es fácil! Para cualquier aplicación particular, siempre hay un procesador con EL MEJOR precio/rendimiento en un momento dado, pero cambia tan frecuentemente como los fabricantes sacan al mercado nuevos procesadores, de manera que responder Procesador XYZ ejecutándose a n MHz sería una respuesta válida sólo temporalmente. De todas maneras, el precio del procesador es insignificante comparado al precio global del sistema que vamos a poner, De manera que, realmente, la cuestión debería ser ¿cómo podemos maximizar la tasa precio/rendimiento de un sistema dado? Y la respuesta a esa cuestión depende muchísimo de los requerimientos mínimos de rendimiento y en el coste mínimo/máximo establecido para la configuración que estamos considerando. Algunas veces, el hardware que podemos comprar en las tiendas no nos dará el rendimiento mínimo necesario, y la única alternativa serán costosos sistemas RISC. Para algunos usos, recomiendo un sistema equilibrado y homogéneo :-); la elección de un procesador es una decisión importante, pero no más que elegir el tipo y capacidad del disco duro, la cantidad de RAM, la tarjeta de vídeo, etc...

P9.

¿Qué es un incremento "significativo" de rendimiento?

R:

Yo diría que cualquier cosa por debajo de 1% no es significativo (podría ser descrito como "marginal"). Nosotros, los humanos, difícilmente distinguiremos la diferencia entre dos sistemas con una diferencia en tiempo de respuesta del 5%. Por supuesto, algunos de los más duros realizadores de pruebas no son humanos, y le dirán que, comparando dos sistemas con índices de 65'9 y 66'5, este último es "definitivamente más rápido".

P10.

¿Cómo obtengo incrementos "significativos" en renadimiento al menor coste?

R:

Como la mayoría del código fuente para Linux está disponible, un examen atento y un rediseño algorítmico de las subrutinas clave podrían alcanzar incrementos de rendimiento en órdenes de magnitud en algunos casos. Si estamos tratando con un proyecto comercial y no deseamos meternos demasiado en el código C, podríamos llamar a un consultor de Linux. Lea el Consultants-HOWTO.

Hosting by: hurra.com
Generated: 2007-01-26 18:00:33