<!-- LinuxDoc file was created by LyX 0.10 (C) 1995 1996 by Matthias Ettrich -->
<!-- Export filter v0.5 by Pascal Andre                                -->

<!doctype linuxdoc system>
<!-- Documento traducido por: Joaquín Cuenca Abela -->

<article>

<title>Linux Benchmarking CÓMO
<author>por André D. Balsa, <url url="mailto:andrewbalsa@usa.net"
name="andrewbalsa@usa.net "> &nl;
Traducido por: Joaquín Cuenca Abela, <htmlurl
url="mailto:jcuenca@patan.eleinf.uv.es"
name="jcuenca@patan.eleinf.uv.es">
<date>v0.12, 15 de Agosto de 1997

<abstract>El Linux Benchmarking CÓMO trata sobre algunos aspectos
asociados con el <it/benchmarking/ en los sistemas Linux y presentas
unas herramientas (algo toscas) para realizar medidas del rendimiento
de su sistema, que podría proporcionar una cantidad significativa de
información en un par de horas. Quizás también ayude a hacer que
disminuya el número de artículos sobre el tema que se envían a
comp.os.linux.hardware...
</abstract>

<toc>

<sect>Introducción
<p>

<em>"Lo que no podemos decir acerca de nosotros mismos debería
desaparecer en el silencio."</em>
<quote><em>Ludwig Wittgenstein (1889-1951), filósofo austríaco</em>
</quote>

<it/Benchmarking/ significa <bf/medir/ la velocidad con la que un
ordenador ejecuta una tarea, de forma que se puedan realizar
comparaciones entre diferentes combinaciones de
programas/componentes. Esta definición <bf/no/ tiene en cuenta la
sencillez de utilización, estética o ergonomía o cualquier otro tipo
de juicio subjetivo.

El <it/Benchmarking/ es una tarea repetitiva, tediosa, y hay que
llevar cuidado con los detalles. Es muy normal que los resultados no
sean los que uno espera y que estén sujetos a interpretación (puede
que hoy en día ésta sea la parte más importante).

Para finalizar, el <it/benchmarking/ trata con hechos y datos, no con
opiniones ni aproximaciones.

<sect1>¿Por qué el <it/benchmarking/ es tan importante?
<p>

Aparte de las razones apuntadas en el BogoMips Mini-CÓMO (sección 8,
párrafo 2), podemos tener que ceñirnos a un presupuesto o satisfacer
unas necesidades de rendimiento mientras instalamos un sistema
Linux. En otras palabras, cuando tenemos que hacernos las siguientes
preguntas:
<itemize>
<item>¿Cómo puedo maximizar el rendimiento con un presupuesto dado?
<item>¿Cómo puedo minizar costes manteniendo un nivel mínimo en el
rendimiento?
<item>¿Cómo puedo obtener la mejor relación calidad/precio (con un
presupuesto o unas exigencias dadas)?
</itemize>

Tendremos que examinar, comparar o crear <it/benchmarks/. Minimizar
costes sin tener que mantener un rendimiento en particular implica
utilizar una máquina con partes desfasadas (aquel viejo 386SX-16 que
está tirado en el garaje podría servir) y no necesita <it/bechmarks/,
y maximizar el rendimiento sin que importe el dinero no es una
situación muy realista (a menos que quiera poner un Cray en su casa -
la unidad de alimentación recubierta con cuero es bonita, ¿verdad?).

El <it/benchmarking/ de por si no tiene sentido, y es una estúpida
pérdida de tiempo y dinero; solo tiene sentido como una parte de un
proceso, esto es, si tiene que hacer una elección entre dos o más
alternativas.

Normalmente otro parámetro a tener en cuenta en el proceso de decisión
es el <bf>coste</bf>, pero también la disponibilidad, el servicio, la
seguridad, estrategia o cualquier otra característica medible y
racional que tenga que ver con un ordenador. Por ejemplo, cuando
comparamos el rendimiento de diferentes versiones del núcleo de Linux,
la <bf/estabilidad/ suele ser más importante que la velocidad.

<sect1>Consideraciones no válidas en la medida del rendimiento
<p>

Se pueden leer muy amenudo en los grupos de noticias y las listas de
correo, pero aun así:
<enum>
<item>Reputación del fabricante (no se puede medir y es insensato).
<item>Cuota de mercado del fabricante (insensato e irrelevante). 
<item>Parámetros irracionales (por ejemplo, supersticiones o
prejuicios: ¿Compraría un procesador que se llame 131313ZAP pintado de
rosa?)
<item>Valor estimado (insensato, irracional y no se puede medir).
<item>Cantidad de propaganda: creo que éste es la peor. Personalmente,
estoy harto de los logos ``XXX inside'' o ``kkkkkws compatible''
(ahora se ha unido a la banda el ``aaaaa Powered'' - ¿Quién será el
próximo?). EMMO<footnote>N.T.: En Mi Modesta Opinión</footnote>, los
billones de pesetas gastados en campañas de este tipo estarían mejor
empleados en equipos de investigación que se ocupen de desarrollar
nuevos procesadores libres de fallos, más rápidos y más baratos
:-). Ningún tipo de publicidad puede arreglar un fallo en la unidad de
coma flotante en la nueva hornada de procesadores que acaba de
instalar en su placa base, pero en cambio un procesador rediseñado sí
puede hacerlo.
<item>La opiniones del tipo ``tiene lo que paga'' son sólo eso:
opiniones. Denme hechos, por favor.
</enum>

<sect>Procedimientos de medida e interpretación de resultados
<p>

Unas cuantas recomendaciones semiobvias:
<enum>
<item>Primera y principal, <bf>identifique el rendimiento
objetivo</bf>. ¿Qué es exactamente lo que trata de medir? ¿De qué
forma la medida del rendimiento le ayudará después a tomar una
decisión? ¿Cuánto tiempo y cuántos recursos está dispuesto a gastar en
el proceso de medida?
<item><bf>Utilice herramientas estándar</bf>. Use una versión del
núcleo estable y actualizada, así como un gcc, libc, y una herramienta
de medida del rendimiento actualizados y estándares. Abreviando,
utilice el LBT (ver más adelante).
<item>Dé una <bf>descripción completa</bf> de su configuración (vea el
artículo LBT más adelante).
<item>Trate de <bf>aislar una variable</bf>. Las medidas comparativas
dan más información que las ``absolutas''. <bf>Ya no puedo insistir
más en este punto</bf>.
<item><bf>Verifique sus resultados</bf>. Ejecute sus pruebas unas
cuantas veces y compruebe las fluctuaciones en los resultados, de
haberlas. Las fluctuaciones inexplicables invalidarán sus resultados.
<item>Si cree que su esfuerzo en la medición del rendimiento ha
producido información útil, <bf>compártala</bf> con la comunidad Linux
de forma <bf/breve/ y <bf/concisa/.
<item>Por favor, <bf>olvídese de los BogoMips</bf>. Me he prometido
que algún día implementaré un rapidísimo ASIC con el bucle de los
BogoMips enganchado en él. ¡Entonces veremos lo que tengamos que
ver!
</enum>

<sect1>Entendiendo la elección de la herramienta
<p>

<sect2>Las herramientas de medida sintéticas vs. las de aplicaciones
<p>

Antes de perder el tiempo escogiendo entre todos los tipos de
herramientas de medida, se debe hacer una elección básica entre las
herramientas ``sintéticas'' y las de ``aplicación''.

Las herramientas sintéticas están especialmente diseñadas para medir
el rendimiento de un componente individual de un ordenador,
normalmente llevando el componente escogido a su máxima capacidad. Un
ejemplo de una herramienta sintética muy conocida es el
<bf/Whetstone/, programado originalmente en 1972 por Harold Curnow en
FORTRAN (¿o fue en ALGOL?) y todavía ampliamente utilizada. El
conjunto de herramientas Whetstone medirá el rendimiento de la unidad
de punto flotante de la CPU.

La crítica principal que puede hacérsele a las medidas ``sintéticas''
es que no representan el rendimiento del sistema en las situaciones de
la vida real. Tomemos por ejemplo las herramientas Whetstone: el
blucle principal es muy pequeño y podría caber fácilmente en la caché
primaria de la CPU, manteniendo el bus de la unidad de punto flotante
(FPU) constantemente lleno y ejercitando, por tanto, la FPU a su
máxima velocidad. No podemos criticar las herramientas Whetstone por
esto, ya que hemos de tener presente que fueron programadas hace 25
años (¡y diseñadas en fechas anteriores!), pero hemos de
asegurarnos de que interpretamos los resultados con cuidado cuando
medimos microprocesadores modernos.

Otro punto a tener en cuenta sobre los tests sintéticos es que,
idealmente, deberían darnos información acerca de un aspecto
<bf/específico/ del sistema que estamos comprobando,
independientemente del resto de componentes: un test sintético sobre
la E/S de las tarjetas Ethernet debería devolver el mismo resultado (o
al menos similar) independientemente de si se ejecuta en un 386SX-16
con 4 MBytes de RAM o de si se ejecuta en un Pentium 200 MMX con 64
MBytes de RAM. Sin embargo, el test medirá la rendimiento global de la
combinación CPU/placa base/Bus/tarjeta Ethernet/Subsistema de
memoria/DMA: no es muy útil, ya que la variación en el procesador
podría causar un impacto mayor en los resultados que la variación en
la tarjeta de red Ethernet (naturalmente, ésto es suponiendo que
estamos utilizando la misma combinación de controlador/núcleo, que
también pueden producir grandes cambios).

Para terminar, un error muy común es hacer la media de varios tests
sintéticos y decir que esta media es una buena representación del
rendimiento en la vida real de un sistema.

Aquí tenemos un comentario acerca de los tests FPU, citado con permiso
de Cyrix Corp.:
<quote><em>``Una Unidad de Coma Flotante (<it/Floating Point Unit/,
FPU) acelera los programas diseñados para utilizar matemáticas en coma
flotante: suelen ser programas de CAD, hojas de cálculo, juegos 3D y
diseño de aplicaciones. Sin embargo, hoy en día las aplicaciones más
populares para PC utilizan al mismo tiempo instrucciones en enteros y
en coma flotante. Como resultado, Cyrix ha decidido poner énfasis en
el ``paralelismo'' a la hora de diseñar el procesador 6x86 para acelerar
los programas que entremezclan estos dos tipos de instrucciones.</em>
</quote>
<quote><em>
El modelo de exclusión de la unidad de coma flotante de los x86
permite la resolución de instrucciones con enteros mientras se ejecuta
una instrucción en coma flotante. Por contra, no se puede ejecutar una
segunda instrucción en coma flotante si ya se estaba ejecutando
anteriormente una. Para eliminar la limitación en el rendimiento
creada por el modelo de exclusión de la unidad de coma flotante, el
procesador 6x86 puede realizar especulativamente hasta cuatro
instrucciones en coma flotante al chip FPU mientras sigue ejecutando
instrucciones enteras. Por ejemplo, en una secuencia de código con dos
instrucciones en coma flotante (FLTs) seguidas por seis instrucciones
enteras (INTs) y seguidas por dos FLTs más, el procesador 6x86 puede
mandar las diez instrucciones anteriores a las unidades de ejecución
apropiadas antes de que se termine la primera FLT. Si ninguna de las
instrucciones falla (el caso típico), la ejecución continua con las
unidades de enteros y de coma flotante terminando las instrucciones en
paralelo. Si una de las FLTs falla (el caso atípico), la capacidad de
ejecución especulativa del 6x86 permite que se restaure el estado del
procesador de forma que sea compatible con el modelo de exclusión de
la unidad de coma flotante del x86.</em>
</quote>
<quote><em>Un examen de los test de rendimiento revela que los test
sintéticos de la unidad de coma flotante utiliza un código con
solo operaciones de coma flotante, que no es lo que nos encontramos en
las aplicaciones del mundo real. Este tipo de tests no aprovecha la
capacidad de ejecución especulativa presente en el procesador
6x86. Cyrix cree que las pruebas que utilizan herramientas no
sintéticas, basadas en aplicaciones del mundo real reflejan
mejor el rendimiento real que pueden obtener los usuarios. Las
aplicaciones del mundo real contienen instrucciones mezcladas de
enteros y de coma flotante y utilizan por tanto, la capacidad de
ejecución especulativa del 6x86.''</em>
</quote>

Por lo tanto, la tendencia en los tests de rendimiento es elegir las
aplicaciones más comunes y utilizarlas para medir el rendimiento del
sistema completo. Por ejemplo, <bf/SPEC/, la organización sin ánimo de
lucro que diseñó las herramientas SPECINT y SPECFP, ha lanzado un
proyecto para un nuevo conjunto de herramientas basadas en
aplicaciones. Pero de nuevo, sería muy raro que alguna herramienta
comercial de medida del rendimiento incluya código Linux.

Resumiendo, los tests sintéticos son válidos mientras comprenda sus
propósitos y limitaciones. Las herramientas basadas en aplicaciones
reflejarán mejor el rendimiento global del sistema, pero no hay
ninguna disponible para Linux.

<sect2>Tests de alto nivel vs. test de bajo nivel
<p>

Los tests de bajo nivel miden directamente el rendimiento de los
componentes: el reloj de la CPU, los tiempos de la DRAM y de la caché
SRAM, tiempo de acceso medio al disco duro, latencia, tiempo de cambio
de pista, etc... esto puede ser util en caso de comprar un sistema y
no se sabe con que componentes viene, pero una forma mejor de
comprobar estos datos es abrir la caja, hacer un listado con los
nombres que pueda conseguir y obtener una hoja de características de
cada componente encontrado (normalmente disponibles en la red).

Otro uso de los tests de bajo nivel es comprobar que un controlador de
núcleo ha sido correctamente instalado para un componente específico:
si tiene la hoja de especificaciones del componente, puede comparar
los resultados del test de bajo nivel con las especificaciones
teóricas (las impresas).

Los tests de alto nivel están más enfocados a medir el rendimiento de
la combinación componente/controlador/SO de un aspecto específico del
sistema, como por ejemplo el rendimiento de E/S con ficheros, o el
rendimiento de una determinada combinación de
componentes/controlador/SO/aplicación, p.e. un test Apache en
diferentes sistemas.

Por supuesto, todos los tests de bajo nivel son sintéticos. Los tests
de alto nivel pueden ser sintéticos o de aplicación.

<sect1>Tests estándares disponibles para Linux
<p>

EMMO un test sencillo que cualquiera puede hacer cuando actualiza
cualquier componentes en su Linux es hacer una compilación del núcleo
antes y después de la actualización del componente o del programa y
comparar los tiempos de compilación. Si todas las demás combinaciones
se mantienen igual, entonces el test es válido como medida del
rendimiento en la compilación, y uno ya puede decir que:
<quote>"Cambiar de A a B lleva a una mejora de un x &percnt; en el
tiempo de compilación del núcleo de Linux bajo estas y estas
condiciones".
</quote>

¡Ni más, ni menos!

Ya que la compilación del núcleo es una tarea muy normal en Linux, y
ya que ejercita muchas de las funciones que se realizan normalmente en
los tests (excepto el rendimiento con las instrucciones en coma
flotante), podemos concluir que es un test <bf/individual/ bastante
bueno. Sin embargo en muchos casos, los resultados de un test no puede
ser reproducido por otros usuarios Linux debido a las variaciones en la
configuración de los programas/componentes y por tanto este tipo de
pruebas no puede utilizarse como ``vara de medida'' para comparar
distintos sistemas (a menos que nos pongamos todos de acuerdo en
compilar un núcleo estándar - ver más adelante).

Desgraciadamente, no hay herramientas de medida del rendimiento
específicas para Linux, exceptuando el Byte Linux Benchmarks, que son
una versión modificada del The Byte Unix Benchmarks que data de Mayo
de 1991 (los módulos de Linux se deben a Jon Tombs, autores originales
Ben Smith, Rick Grehan y Tom Yager).

Hay una página central
<tt><htmlurl
url="http://www.silkroad.com/bass/linux/bm.html"
name="http://www.silkroad.com/bass/linux/bm.html"></tt>
para el Byte Linux Benchmarks.

David C. Niemi puso por ahí una versión del Byte Unix Benchmarks
mejorada y actualizada. Para evitar confusiones con alguna versión
anterior la llamó UnixBench 4.01. Aquí está lo que David escribió
sobre sus modificaciones:
<quote><em>``La versión original y las versiones ligeramente
modificadas de BYTE Unix Benchmarks se diferencian en varias cosas que
los hacen ser un indicador inusualmente poco fiable del rendimiento
del sistema. He hecho que los valores de mis ``índices'' parezcan muy
diferentes para evitar confusiones con el viejo test.''</em>
</quote>

David ha creado una lista de correo majordomo para la discusión sobre
las pruebas de rendimiento para Linux y para el resto de SOs. Puede
unirse a la lista enviando un mensaje a <tt><htmlurl
url="mailto:majordomo@wauug.erols.com"
name="majordomo@wauug.erols.com"></tt> escribiendo en el cuerpo
``subscribe bench''. El Grupo de Usuarios de Unix del Area de
Washington está en proceso de crear una página Web
<tt><htmlurl
url="http://wauug.erols.com/bench"
name="http://wauug.erols.com/bench"></tt>
sobre los test de rendimiento en Linux.

También recientemente, Uwe F. Mayer, <tt><htmlurl
url="mailto:mayer@math.vanderbilt.edu"
name="mayer@math.vanderbilt.edu"></tt> portó el conjunto de pruebas Byte
Bytemark a Linux. Éste es un moderno conjunto de herramientas que Rick
Grehan envió a BYTE Magazine para comprobar la CPU, FPU y el
rendimiento del sistema de memoria de los modernos sistemas de
microordenador (hay pruebas estrictamente orientadas al rendimiento
del procesador, sin tener en cuenta el rendimiento de la E/S o del
sistema).

Uwe también ha creado una página Web <tt><htmlurl
url="http://math.vanderbilt.edu:80/~mayer/linux/bmark.html"
name="http://math.vanderbilt.edu:80/~mayer/linux/bmark.html"></tt>
con una base de datos de los resultados de las pruebas de su versión
del Linux BYTEmark benchmarks.

Si busca pruebas sintéticas para Linux, en sunsite.unc.edu podrá
encontrar unas cuantas. Para comprobar la velocidad relativa de los
servidores X y de las tarjetas gráficas, el conjunto de herramientas
xbench-0.2 creado por Claus Gittinger está disponible en
sunsite.unc.edu, ftp.x.org y otros lugares. Xfree86.org rechaza
(prudentemente) el llevar o recomendar ninguna prueba.

El <em>XFree86-benchmarks Survey</em> <tt><htmlurl
url="http://www.goof.com/xbench/"
name="http://www.goof.com/xbench/"></tt>
es una página Web con una base de datos de los resultados de x-bench.

Para el intercambio de E/S de disco, el programa hdparm (incluido con
muchas distribuciones, si no lo tiene puede encontrarlo en
sunsite.unc.edu) puede medir las tasas de transferencia si lo invoca
con las opciones -t y -T.

Hay muchas otras herramientas disponibles de forma libre en Internet
para comprobar varios aspectos del rendimiento de su Linux.

<sect1>Enlaces y referencias
<p>

El comp.benchmarks.faq creado por Dave Sill es la referencia estándar
en las pruebas de rendimiento. No es específico de Linux, pero es una
lectura recomendada para cualquiera que se quiera ver seriamente
implicado en las pruebas de rendimiento. Está disponible en muchos
FTPs y páginas Web y muestra <bf/56 pruebas diferentes/, con enlaces a
direcciones FTP o páginas Web donde se pueden recoger. Algunas de las
pruebas que se mencionan son comerciales (SPEC, por ejemplo).

No voy a nombrar todos y cada uno de los tests que se mencionan en
comp.benchmarks.faq, pero hay al menos una prueba de bajo nivel que me
gustaría comentar: la prueba lmbench <tt><htmlurl
url="http://reality.sgi.com/lm/lmbench/lmbench.html"
name="http://reality.sgi.com/lm/lmbench/lmbench.html"></tt>
de Larry McVoy. Citando a David C. Niemi:
<quote><em>``Linus y David Miller la utilizan mucho ya que es capaz de
realizar medidas útiles de bajo nivel y también puede medir el
trasvase y la latencia de la red si tiene dos ordenadores para hacer
los tests. Pero no intenta conseguir algo así como un ``rendimiento
del sistema'' general...''</em>
</quote>

Alfred Aburto puso en marcha un lugar FTP bastante completo en cuanto a
utilidades <bf/libres/ de medida del rendimiento (<tt><htmlurl
url="ftp://ftp.nosc.mil/pub/aburto"
name="ftp://ftp.nosc.mil/pub/aburto"></tt>).
Las herramientas Whetstone utilizadas en el LBT se encontraron aquí.

También tenemos el <bf/FAQ multiparte de Eugene Miya/ que deja
regularmente en comp.benchmarks; es una referencia excelente.

<sect>El Linux Benchmarking Toolkit (LBT)
<p>

Quiero proponer un conjunto básico de herramientas de medida para
Linux. Es sólo una versión preliminar de un general Linux Benchmarking
Toolkit, que será expandido y mejorado. Tómelo como lo que es,
esto es, como una propuesta. Si no cree que es un conjunto de herramientas
válido, sientase libre de enviarme un correo electrónico con sus
críticas y estaré encantado de hacer los cambios y mejoras, si
puedo. Sin embargo, antes de tomar una decisión, lea este CÓMO y las
referencias mencionadas: las críticas informadas serán bienvenidas,
las críticas sin fundamento no.

<sect1>Bases lógicas
<p>

Ésto es sólo de sentido común:

<enum>

<item>No debe llevar un día el ejecutarlo. Cuando hay que hacer tests
comparativos (varias ejecuciones), no hay nadie que esté dispuesto a
pasar días tratando de averiguar la mejor configuración de un
sistema. Idealmente, el conjunto completo de pruebas debe llevar unos
15 minutos en una máquina media.

<item>Todo el código fuente de los programas de estar libremente
disponible en la Red, por razones obvias.

<item>Los tests deben proporcionar una representación sencilla de los
resultados que refleje el rendimiento medido.

<item>Debe haber una mezcla de tests sintéticos y de tests de
aplicación (con resultados separados, por supuesto).

<item>Cada test <bf/sintético/ debe ejercitar un subsistema particular
hasta su máxima capacidad.

<item>Los resultados de los tests <bf/sintéticos NO/ deben mezclarse
en un sólo resultado general (ésto acaba con la toda la idea que hay
detrás de los tests sintéticos, con una considerable pérdida de
información).

<item>Los tests de aplicación deben consistir en tareas usualmente
ejecutadas en los sistemas Linux.

</enum>

<sect1>Selección de herramientas
<p>

He seleccionado cinco conjuntos de herramientas, tratando de evitar,
en la medida de lo posible, el solapamiento de pruebas. Son éstas:

<enum>

<item>Compilación del Núcleo 2.0.0 (con la configuración por defecto)
utilizando gcc.

<item>La versión 10/03/97 de Whetstone (la última que ha sacado Roy
Longbottom).

<item>xbench-0.2 (con los parámetros de ejecución rápida).

<item>La versión 4.01 de UnixBench (resultados parciales).

<item>La distribución 2 de la versión beta de los test BYTEmark de la
revista BYTE Magazine (resultados parciales).

</enum>

Para las pruebas 4 y 5, ``(resultados parciales)'' significa que no se
tendrán en cuenta todos los resultados producidos por estos tests.

<sect1>Duración de las pruebas
<p>

<enum>

<item>Compilación del Núcleo 2.0.0: 5 - 30 minutos, dependiendo del
rendimiento <bf/real/ de su sistema.

<item>Whetstone: 100 segundos.

<item>Xbench-0.2: &lt; 1 hora. 

<item>Versión 4.01 de los tests UnixBench: aprox. 15 minutos.

<item>Los tests BYTEmark de BYTE Magazine: aprox. 10 minutos. 

</enum>

<sect1>Comentarios
<p>
<sect2>Compilación del Núcleo 2.0.0: 
<p>

<itemize>

<item><bf>Qué:</bf> es el único test de aplicación que hay en el LBT.

<item>El código está ampliamente difundido (finalmente he
encontrado alguna utilidad a mis viejos CD-ROMs con Linux).

<item>Muchos linuxeros recompilan el núcleo a menudo, por lo que es un
medida significativa del rendimiento global del sistema.

<item>El núcleo es grande y gcc utiliza una gran cantidad de memoria:
se atenua la importancia de la caché L2.

<item>Hace un uso frecuente de la E/S al disco.

<item>Procedimiento para realizar la prueba: conseguir el código de la
versión 2.0.0 del núcleo, compilarlo con las opciones por defecto (make
config, pulsar Intro repetidamente). El tiempo a informar debería ser el
que se inverte en la compilación; esto es, después de que escribe make
zImage, <bf>sin</bf> incluir make dep, make clean. Tenga en cuenta que la
arquitectura objetivo por defecto del núcleo es i386, de manera que si
compila en otras arquitecturas, debería configurar también gcc para hacer
una compilación cruzada, teniendo i386 como arquitectura objetivo.

<item><bf>Resultados: </bf>tiempo de compilación en minutos y segundos
(por favor, no indique las fracciones de segundo).

</itemize>

<sect2>Whetstone: 
<p>
<itemize>
<item><bf>Qué: </bf>mide el rendimiento de punto flotante puro con un
bucle corto. El fuente (en C) es muy legible y es fácil de ver qué
operaciones en punto flotante intervienen.
<item>Es la prueba más corta del LBT :-). 
<item>Es una prueba "Clásica": hay disponibles cifras comparativas, sus
defectos y deficiencias son bien conocidos.
<item>Procedimiento para realizar la prueba: se debería obtener el código
en C más reciente del sitio de Aburto. Compile y ejecute en modo de doble
precisión. Especifique gcc y -O2 como opciones de precompilador y
compilador, y defina POSIX 1 para especificar el tipo de máquina.
<item><bf>Resultados: </bf>una cifra del rendimiento de punto flotante en
MWIPS.
</itemize>
<sect2>Xbench-0.2: 
<p>
<itemize>
<item><bf>Qué:</bf> mide el rendimiento del servidor X.
<item>La medida xStones proporcionada por xbench es una media ponderada de
varias pruebas referidas a una vieja estación Sun con una pantalla de un
solo bit de profundidad. Hmmm... es cuestionable como test para servidores
X modernos, pero sigue siendo la mejor herramienta que he encontrado.
<item>Procedimiento para realizar la prueba: compilar con -O2.
Especificamos unas pocas opciones para una ejecución más rápida:<tt>
./xbench -timegoal 3 &gt; results/name_of_your_linux_box.out</tt>. Para
obtener la calificación xStones, debemos ejecutar un guión (script) en
awk; la manera más rápida es escribir <tt>make summary.ms</tt>. Compruebe
el fichero summary.ms: la calificación xStone de su sistema está en la
última columna del renglón que tiene el nombre de su máquina que
especificó durante la prueba.
<item><bf>Resultados:</bf> una figure del rendimiento de X en xStones.
<item>Nota: esta prueba, tal como está, es obsoleta. Debería ser
reescrita.
</itemize>
<sect2>UnixBench versión 4.01: 
<p>
<itemize>
<item><bf>Qué:</bf> mide el rendimiento global de Unix. Esta prueba
ejercitará el rendimiento de E/S de ficheros y multitarea del núcleo.
<item>He descartado los resultados de todas las pruebas aritméticas,
quedándome sólo con los resultados relacionados con el sistema.
<item>Procedimiento para realizar la prueba: compilar con -O2. Ejecutar
con <tt> ./Run -1</tt> (ejecutar cada prueba una vez). Encontrará los
resultados en el fichero ./results/report. Calcule la media geométrica de
los índices EXECL THROUGHPUT, FILECOPY 1, 2, 3, PIPE THROUGHPUT,
PIPE-BASED CONTEXT SWITCHING, PROCESS CREATION, SHELL SCRIPTS y SYSTEM
CALL OVERHEAD.
<item><bf>Resultados:</bf> un índice del sistema.
</itemize>
<sect2>Banco de pruebas BYTEmark de BYTE Magazine BYTEmark: 
<p>
<itemize>
<item><bf>Qué:</bf> proporciona una buena medida del rendimiento de la
CPU. Aquí hay un extracto de la documentación: <em>"Estas pruebas están
pensadas para exponer el límite superior teórico de la arquitectura de
CPU, FPU y memoria de un sistema. No pueden medir transferencias de vídeo,
disco o red (éstos son dominios de un conjunto de pruebas diferentes).
Debería usted, por lo tanto, utilizar los resultados de estas pruebas como
parte, no como un todo, en cualquier evaluación de un sistema."</em>
<item>He descartado los resultados de la prueba de FPU ya que la prueba
Whetstone es representativa del rendimiento de la FPU.
<item>He dividido las pruebas de enteros en dos grupos: aquellos más
representativos del rendimiento memoria-caché-CPU y las pruebas de enteros
de la CPU.
<item>Procedimiento para realizar la prueba: compilar con -O2. Ejecutar la
prueba con <tt>./nbench &gt; myresults.dat</tt> o similar. Entonces, de
myresults.dat, calcule la media geométrica de los índices de las pruebas
STRING SORT, ASSIGNMENT y BITFIELD; éste es el <bf>índice de la
memoria</bf>; calcule la media geométrica de los índices de las pruebas
NUMERIC SORT, IDEA, HUFFMAN y FP EMULATION; éste es el <bf>índice de
enteros</bf>.
<item><bf>Resultados:</bf> un índice de memoria y un índice de enteros
calculado tal como se explica anteriormente.
</itemize>
<sect1>Posibles mejoras
<p>

El conjunto ideal de pruebas debería ejecutarse en pocos minutos, con
pruebas sintéticas que examinen cada subsistema por separado y pruebas de
aplicación que den resultados para diferentes aplicaciones. También
debería generar de forma automática un informe completo y quizá enviarlo
por correo a la base de datos central en la Web.

No estamos interesados en la portabilidad, pero debería al menos poder ser
ejecutado en cualquier versión reciente (&gt; 2.0.0) y 'sabor' (i386,
Alpha, Sparc...) de Linux.

Si alguien tiene alguna idea al respecto de probar la red de una manera
sencilla, fácil y fiable, con una prueba corta (menos de 30 minutos en
configuración y ejecución), por favor, póngase en contacto conmigo.

<sect1>El formulario de informe LBT
<p>
Aparte de las pruebas, el procedimiento de 'benchmarking' no estaría
completo sin un formulario describiendo la configuración, de manera que
aquí está (siguiendo la guía de comp.benchmarks.faq):

<code>LINUX BENCHMARKING TOOLKIT REPORT FORM
</code>
<code>CPU 
== 
Vendor: 
Model: 
Core clock: 
Motherboard vendor: 
Mbd. model: 
Mbd. chipset: 
Bus type: 
Bus clock: 
Cache total: 
Cache type/speed: 
SMP (number of processors): 
</code>
<code>RAM 
==== 
Total: 
Type: 
Speed: 
</code>
<code>Disk 
==== 
Vendor: 
Model: 
Size: 
Interface: 
Driver/Settings: 
</code>
<code>Video board 
=========== 
Vendor: 
Model: 
Bus:
Video RAM type: 
Video RAM total: 
X server vendor: 
X server version: 
X server chipset choice: 
Resolution/vert. refresh rate: 
Color depth: 
</code>
<code>Kernel 
===== 
Version: 
Swap size:
</code>
<code>gcc 
=== 
Version: 
Options: 
libc version: 
</code>
<code>Test notes 
==========
</code>
<code>RESULTS 
======== 
Linux kernel 2.0.0 Compilation Time: (minutes and seconds) 
Whetstones: results are in MWIPS. 
Xbench: results are in xstones. 
Unixbench Benchmarks 4.01 system INDEX:  
BYTEmark integer INDEX:
BYTEmark memory INDEX:
</code>
<code>Comments* 
========= 
* Este campo se incluye para una posible interpretación de los resultados,
y como tal, es opcional. Podría ser la parte más significativa del
informe, sin embargo, especialmente si está haciendo pruebas comparativas.
</code>
<sect1>Pruebas del rendimiento de la red
<p>
Probar el rendimiento de una red es un reto, ya que implica al menos tener
dos máquinas, un servidor y un cliente, y por lo tanto el doble de tiempo
para configurar, más variables a controlar, etc... En una red ethernet,
pienso que su mejor apuesta sería el paquete ttcp. (por expandir)

<sect1>Pruebas SMP
<p>

Las pruebas SMP son otro reto, y cualquier banco de pruebas diseñado
específicamente para probar SMP tendrá dificultades probándose a sí misma
en configuraciones de la vida real, ya que los algoritmos que pueden tomar
ventaja de SMP son difíciles de realizar. Parece que las últimas versiones
del núcleo de Linux (&gt; 2.1.30 o por ahí) harán multiproceso "muy
granulado" (<em>fine-grained</em>), pero no tengo más información al
respecto ahora mismo.

Según David Niemi, <em>" ... shell8 </em>[parte del Unixbench
4.01]<em>hace un buen trabajo comparando hardware similare en los modos
SMP y UP."</em>

<sect>Prueba de ejemplo y resultados
<p>

Ejecuté el LBT en la máquina de mi casa, un Linux de clase Pentium que
puse a mi lado y usé para escribir este COMO. Aquí tiene el Formulario de
Informe LBT de este sistema:

<verb>LINUX BENCHMARKING TOOLKIT REPORT FORM
</verb>
<verb>CPU 
</verb>
<verb>== 
</verb>
<verb>Vendor: Cyrix/IBM 
</verb>
<verb>Model: 6x86L P166+
</verb>
<verb>Core clock: 133 MHz
</verb>
<verb>Motherboard vendor: Elite Computer Systems (ECS)
</verb>
<verb>Mbd. model: P5VX-Be
</verb>
<verb>Mbd. chipset: Intel VX
</verb>
<verb>Bus type: PCI
</verb>
<verb>Bus clock: 33 MHz
</verb>
<verb>Cache total: 256 KB
</verb>
<verb>Cache type/speed: Pipeline burst 6 ns
</verb>
<verb>SMP (number of processors): 1
</verb>
<verb>RAM 
</verb>
<verb>==== 
</verb>
<verb>Total: 32 MB
</verb>
<verb>Type: EDO SIMMs
</verb>
<verb>Speed: 60 ns
</verb>
<verb>Disk 
</verb>
<verb>==== 
</verb>
<verb>Vendor: IBM
</verb>
<verb>Model: IBM-DAQA-33240
</verb>
<verb>Size: 3.2 GB
</verb>
<verb>Interface: EIDE
</verb>
<verb>Driver/Settings: Bus Master DMA mode 2
</verb>
<verb>Video board 
</verb>
<verb>=========== 
</verb>
<verb>Vendor: Generic S3
</verb>
<verb>Model: Trio64-V2
</verb>
<verb>Bus: PCI
</verb>
<verb>Video RAM type: EDO DRAM 
</verb>
<verb>Video RAM total: 2 MB
</verb>
<verb>X server vendor: XFree86
</verb>
<verb>X server version: 3.3
</verb>
<verb>X server chipset choice: S3 accelerated 
</verb>
<verb>Resolution/vert. refresh rate: 1152x864 @ 70 Hz
</verb>
<verb>Color depth: 16 bits
</verb>
<verb>Kernel 
</verb>
<verb>===== 
</verb>
<verb>Version: 2.0.29
</verb>
<verb>Swap size: 64 MB
</verb>
<verb>gcc 
</verb>
<verb>=== 
</verb>
<verb>Version: 2.7.2.1
</verb>
<verb>Options: -O2
</verb>
<verb>libc version: 5.4.23 
</verb>
<verb>Test notes 
</verb>
<verb>==========
</verb>
<verb>Carga muy ligera. Las pruebas anteriores se ejecutaron activando
algunas de las capacidades mejoradas del Cyrix/IBM 6x86, mediante el
programa setx86: fast ADS, fast IORT, Enable DTE, fast LOOP, fast Lin.
VidMem.
</verb>
<verb>RESULTS 
</verb>
<verb>======== 
</verb>
<verb>Linux kernel 2.0.0 Compilation Time: 7m12s
</verb>
<verb>Whetstones: 38.169 MWIPS. 
</verb>
<verb>Xbench: 97243 xStones. 
</verb>
<verb>BYTE Unix Benchmarks 4.01 system INDEX: 58.43
</verb>
<verb>BYTEmark integer INDEX: 1.50
</verb>
<verb>BYTEmark memory INDEX: 2.50
</verb>
<verb>Comments
</verb>
<verb>========= 
</verb>
<verb>Este es un sistema muy estable con un rendimiento homogéneo, ideal
para el uso en casa o para el desarrollo con Linux. ¡Informaré de los
resultados con un procesador 6x86MX tan pronto como le eche las manos
encima!
</verb>
<sect>Falsedades y fallos del benchmarking 
<p>

Después de reunir este COMO empecé a comprender por qué se asocian tan
frecuentemente las palabras "falsedad" y "fallo" con el benchmarking...

<sect1>Comparar manzanas con naranjas
<p>

¿O debería decir Apples<footnote>N. del T.: Apple = manzana, pero también
una famosa compañía que fabrica ordenadores</footnote>con PCs? Es una
disputa tan obvia y antigua que no ahondaré en los detalles. Dudo que el
tiempo que tarda en cargarse Word en un Mac comparado a la media de un
Pentium sea una medida real de nada. Al igual que el tiempo de arranque de
un Linux y un Windows NT, etc... Procure lo más posible comprar máquinas
idénticas con una sola modificación.
<sect1>Información incompleta
<p>

Un solo ejemplo ilustrará este fallo común. A menudo uno lee en
comp.os.linux.hardware la siguiente frase o similar: "Acabo de poner el
procesador XYZ a nnn MHz y ahora compilar el núcleo de linux me lleva sólo
i minutos" (ajustar XYZ, nnn e i a lo que se requiera). Es irritante,
porque no se da más información, esto es, no sabemos siquiera la cantidad
de RAM, tamaño del fichero de intercambio, otras tareas que se ejecutan
simultáneamente, versión del núcleo, módulos seleccionados, tipo de disco
duro, versión del gcc, etc... Le recomiendo que use el Formulario de
Informe LBT, que al menos proporciona un marco de información estándar.

<sect1>Software/hardware Propietario
<p>
Un conocido fabricante de procesadores publicó una vez los resultados de
unas pruebas producidas por una versión especial, adaptada, de gcc. Aparte
las consideraciones éticas, estos resultados no tenían sentido, ya que el
100&percnt; seguiría usando la versión estándar de gcc. Lo mismo va para
el hardware propietario. El benchmarking es mucho más útil cuando trata
con hardware
<!-- DUDA -->
off-the-shelf
<!-- DUDA -->
y sofware libre.
<sect1>Relevancia
<p>
Estamos hablando de Linux, ¿no? De manera que deberíamos olvidarnos de
pruebas producidas en otros sistemoas operativos (este es un caso especial
del "Comparando manzanas y naranjas" que vimos anteriormente). Además, si
vamos a hacer pruebas del rendimiento de un servidor Web, <bf>no</bf>
debemos resaltar el rendimiento de la FPU ni otra información irrelevante.
En tales casos, menos es más. <bf>Tampoco</bf> necesitamos mencionar la
edad de nuestro gato, el humor del que estábamos mientras hacíamos la
prueba, etc...
<sect>FAQ (Preguntas Frecuentes)
<p>
<descrip>
<tag>P1.</tag>¿Hay alguna medida aislada del mérito de los sistemas Linux?
<tag>R:</tag>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.
<tag>P2.</tag>Entonces, ¿qué tal una docena de cifras resumiendo el
rendimiento de diversos sistemas Linux?
<tag>R:</tag>Esa sería la situación ideal. Me gustaría ver que se hace
realidad. ¿Voluntarios para un <bf>Linux Benchmarking Project</bf>? ¿Con un
sitio web y una base de datos en línea, completa y con informes bien
diseñados?
<tag>P3.</tag>... ¿BogoMips...? 
<tag>R:</tag>Los BogoMips no tienen nada que ver con el rendimiento de su
sistema. Lea el BogoMips Mini-HOWTO.
<tag>P4.</tag>¿Cuá es el 'mejor' banco de pruebas para Linux?
<tag>R:</tag>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
(<em>Real-Time</em>), rendimiento del CD-ROM, rendimiento de Quake (¡!),
etc... HDYS<footnote>HDYS = Hasta Donde Yo Sé (AFAIK = As Far As I
Know)</footnote>, no existe ningún conjunto de pruebas para Linux que
realice todas estas pruebas.
<tag>P5.</tag>¿Cuál es el procesador más rápido sobre el que corre Linux?
<tag>R:</tag>¿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 &dollar;.
<tag>P6.</tag>Permítame rehacer la pregunta anterior, entonces: ¿hay algún
procesador que sea más rápido para aplicaciones de propósito general?
<tag>R:</tag>Esa es una difícil con truco, pero tiene una respuesta muy
sencilla: <bf>NO</bf>. 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...
<tag>P7.</tag>¿De manera que la velocidad de reloj influye en el
rendimiento del sistema?
<tag>R:</tag>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.
<tag>P8.</tag>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?
<tag>R:</tag>¡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...
<tag>P9.</tag>¿Qué es un incremento "significativo" de rendimiento?
<tag>R:</tag>Yo diría que cualquier cosa por debajo de 1&percnt; 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&percnt;. 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".
<tag>P10.</tag>¿Cómo obtengo incrementos "significativos" en renadimiento
al menor coste?
<tag>R:</tag>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, <bf>podríamos llamar a un consultor de
Linux</bf>. Lea el Consultants-HOWTO.
</descrip>

<sect>Copyright, reconocimientos y miscelánea
<p>
<sect1>Cómo se produjo este documento
<p>

El primer paso fue leer la sección 4 "Escribir y enviar un HOWTO" del
HOWTO Index de Greg Hankins.

No sabía absolutamente nada sobre SGML o LaTeX, pero estuve tentado de
usar un paquete de generación automática de documentación tras leer varios
comentarios sobre las SGML-Tools. Sin embargo, insertar etiquetas
manualmente en un documento me recuerda los días en que ensamblé a mano un
programa monitor de 512 bytes para un microprocesador de 8 bits ya
difunto, de manera que tomé las fuentes de LyX, lo compilé, y usé su modo
LinuxDoc. Recomiendo la combinación: <bf>LyX y SGML-Tools</bf>.
<sect1>Copyright
<p>

El Linux Benchmarking HOWTO es copyright (C) 1997 de _André D. Balsa. Los
documentos HOWTO de Linux pueden ser reproducidos y distribuidos en su
totalidad o en parte, en cualquier medio físico o electrónico, siempre que
se mantenga esta noticia de copyright en todas las copias. Se permite y
anima a la distribución comercial; sin embargo, el autor quería que se le
avisase de tales distribuciones.

Todas las traducciones, trabajos derivados, o trabajos agregados que
incorporen cualquier documento HOWTO de Linux deberán estar cubiertos por
este copyright. Esto es, no puede procudir un trabajo derivado de un HOWTO
e imponer restricciones adicionales sobre su distribución. Se podrían
permitir excepciones a estas restricciones bajo ciertas condiciones; por
favor, póngase en contacto con el coordinador del Linux HOWTO en la
dirección que damos más adelante.

En resumen, nos gustaría promover la diseminación de esta información a
través de cuantos más canales sea posible. Sin embargo, queríamos retener
el copyright de los documentos HOWTO, y nos gustaría que nos avisase de
cualquier plan para redistribuir los HOWTO.

Si tiene preguntas, diríjase por favor a Greg Hankins, el coordinador de
Linux HOWTO en gregh@sunsite.unc.edu mediante correo electrónico o
llamando al +1 404 853 9989.

<sect1>Nuevas versiones de este documento
<p>

Se pondrán las nuevas versiones del Linux Benchmarking-HOWTO en
sunsite.unc.edu y en sitios espejo. Allí encontrará otros formatos, como
las versiones PostScript y dvi en el directorio other-formats. El Linux
Benchmarking-HOWTO también está disponible para clientes WWW como Grail,
un navegador Web escrito en Python. También será enviado con regularidad
en comp.os.linux.answers.

La versión en castellano de este HOWTO la encontrará en el sitio del Insflug
<tt><htmlurl
url="http://www.insflug.org"
name="http://www.insflug.org"></tt>

<sect1>Realimentación
<p>

Se buscan sugerencias y correciones. Se reconocerá a los contribuyentes.
No necesito 'flames'.

Siempre me puede localizar en andrewbalsa@usa.net.
<sect1>Agradecimientos
<p>
David Niemi, el autor del conjunto de aplicaciones Unixbench, ha probado
ser una fuente infinita de información y críticas (válidas).

También me gustaría agradecer a Greg Hankins, el coordinador del Linux
HOWTO y uno de los mayores contribuyentes al paquete SGML-tools, a Linus
Torvalds y a la comunidad Linux al completo. Este HOWTO es mi manera de
dar algo a cambio.
<sect1>Pliego de descargo
<p>

Su experiencia puede variar (y variará). Tenga en cuenta que el
benchmarking es un tema delicado, y una actividad que consume grandes
cantidades de tiempo y energía.
<sect1>Marcas registradas
<p>
Pentium y Windows NT son marcas registradas de Intel Corporation y
Microsoft Corporation respectivamente.

BYTE y BYTEmark son marcas comerciales de McGraw-Hill, Inc.

Cyrix y 6x86 son marcas comerciales de Cyrix Corporation.

Linux no es una marca comercial, y esperemos que nunca lo sea.

</article>
