Linux Benchmarking C�MO
por Andr� D. Balsa,
[email protected] <mailto:andrew�
[email protected]>
Traducido por: Joaqu�n Cuenca Abela,
[email protected]�
inf.uv.es
v0.12, 15 de Agosto de 1997
El Linux Benchmarking C�MO trata sobre algunos aspectos asociados con
el _b_e_n_c_h_m_a_r_k_i_n_g 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...
______________________________________________________________________
�ndice general
1. Introducci�n
1.1 �Por qu� el benchmarking es tan importante?
1.2 Consideraciones no v�lidas en la medida del rendimiento
2. Procedimientos de medida e interpretaci�n de resultados
2.1 Entendiendo la elecci�n de la herramienta
2.1.1 Las herramientas de medida sint�ticas vs. las de aplicaciones
2.1.2 Tests de alto nivel vs. test de bajo nivel
2.2 Tests est�ndares disponibles para Linux
2.3 Enlaces y referencias
3. El Linux Benchmarking Toolkit (LBT)
3.1 Bases l�gicas
3.2 Selecci�n de herramientas
3.3 Duraci�n de las pruebas
3.4 Comentarios
3.4.1 Compilaci�n del N�cleo 2.0.0:
3.4.2 Whetstone:
3.4.3 Xbench-0.2:
3.4.4 UnixBench versi�n 4.01:
3.4.5 Banco de pruebas BYTEmark de BYTE Magazine BYTEmark:
3.5 Posibles mejoras
3.6 El formulario de informe LBT
3.7 Pruebas del rendimiento de la red
3.8 Pruebas SMP
4. Prueba de ejemplo y resultados
5. Falsedades y fallos del benchmarking
5.1 Comparar manzanas con naranjas
5.2 Informaci�n incompleta
5.3 Software/hardware Propietario
5.4 Relevancia
6. FAQ (Preguntas Frecuentes)
7. Copyright, reconocimientos y miscel�nea
7.1 C�mo se produjo este documento
7.2 Copyright
7.3 Nuevas versiones de este documento
7.4 Realimentaci�n
7.5 Agradecimientos
7.6 Pliego de descargo
7.7 Marcas registradas
______________________________________________________________________
11.. IInnttrroodduuccccii��nn
_"_L_o _q_u_e _n_o _p_o_d_e_m_o_s _d_e_c_i_r _a_c_e_r_c_a _d_e _n_o_s_o_t_r_o_s _m_i_s_m_o_s _d_e_b_e_r_�_a _d_e_s_a_p_a_r_e_c_e_r
_e_n _e_l _s_i_l_e_n_c_i_o_._"
_L_u_d_w_i_g _W_i_t_t_g_e_n_s_t_e_i_n _(_1_8_8_9_-_1_9_5_1_)_, _f_i_l_�_s_o_f_o _a_u_s_t_r_�_a_c_o
_B_e_n_c_h_m_a_r_k_i_n_g significa mmeeddiirr 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 nnoo
tiene en cuenta la sencillez de utilizaci�n, est�tica o ergonom�a o
cualquier otro tipo de juicio subjetivo.
El _B_e_n_c_h_m_a_r_k_i_n_g 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 _b_e_n_c_h_m_a_r_k_i_n_g trata con hechos y datos, no con
opiniones ni aproximaciones.
11..11.. ��PPoorr qquu�� eell bbeenncchhmmaarrkkiinngg eess ttaann iimmppoorrttaannttee??
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:
� �C�mo puedo maximizar el rendimiento con un presupuesto dado?
� �C�mo puedo minizar costes manteniendo un nivel m�nimo en el
rendimiento?
� �C�mo puedo obtener la mejor relaci�n calidad/precio (con un
presupuesto o unas exigencias dadas)?
Tendremos que examinar, comparar o crear _b_e_n_c_h_m_a_r_k_s. 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 _b_e_c_h_m_a_r_k_s, 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 _b_e_n_c_h_m_a_r_k_i_n_g 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 ccoossttee, 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 eessttaabbiilliiddaadd suele ser m�s importante que la velocidad.
11..22.. CCoonnssiiddeerraacciioonneess nnoo vv��lliiddaass eenn llaa mmeeddiiddaa ddeell rreennddiimmiieennttoo
Se pueden leer muy amenudo en los grupos de noticias y las listas de
correo, pero aun as�:
1. Reputaci�n del fabricante (no se puede medir y es insensato).
2. Cuota de mercado del fabricante (insensato e irrelevante).
3. Par�metros irracionales (por ejemplo, supersticiones o prejuicios:
�Comprar�a un procesador que se llame 131313ZAP pintado de rosa?)
4. Valor estimado (insensato, irracional y no se puede medir).
5. 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 (-- N.T.: En Mi Modesta Opini�n--) , 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.
6. La opiniones del tipo ``tiene lo que paga'' son s�lo eso:
opiniones. Denme hechos, por favor.
22.. PPrroocceeddiimmiieennttooss ddee mmeeddiiddaa ee iinntteerrpprreettaaccii��nn ddee rreessuullttaaddooss
Unas cuantas recomendaciones semiobvias:
1. Primera y principal, iiddeennttiiffiiqquuee eell rreennddiimmiieennttoo oobbjjeettiivvoo. �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?
2. UUttiilliiccee hheerrrraammiieennttaass eesstt��nnddaarr. 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).
3. D� una ddeessccrriippccii��nn ccoommpplleettaa de su configuraci�n (vea el art�culo
LBT m�s adelante).
4. Trate de aaiissllaarr uunnaa vvaarriiaabbllee. Las medidas comparativas dan m�s
informaci�n que las ``absolutas''. YYaa nnoo ppuueeddoo iinnssiissttiirr mm��ss eenn eessttee
ppuunnttoo.
5. VVeerriiffiiqquuee ssuuss rreessuullttaaddooss. Ejecute sus pruebas unas cuantas veces y
compruebe las fluctuaciones en los resultados, de haberlas. Las
fluctuaciones inexplicables invalidar�n sus resultados.
6. Si cree que su esfuerzo en la medici�n del rendimiento ha producido
informaci�n �til, ccoommpp��rrttaallaa con la comunidad Linux de forma bbrreevvee
y ccoonncciissaa.
7. Por favor, oollvv��ddeessee ddee llooss BBooggooMMiippss. 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!
22..11.. EEnntteennddiieennddoo llaa eelleeccccii��nn ddee llaa hheerrrraammiieennttaa
22..11..11.. LLaass hheerrrraammiieennttaass ddee mmeeddiiddaa ssiinntt��ttiiccaass vvss.. llaass ddee aapplliiccaacciioonneess
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 WWhheettssttoonnee,
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
eessppeecc��ffiiccoo 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.:
_`_`_U_n_a _U_n_i_d_a_d _d_e _C_o_m_a _F_l_o_t_a_n_t_e _(_F_l_o_a_t_i_n_g _P_o_i_n_t _U_n_i_t, 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 ``par�
alelismo'' a la hora de dise�ar el procesador 6x86 para
acelerar los programas que entremezclan estos dos tipos de
instrucciones.
_E_l _m_o_d_e_l_o _d_e _e_x_c_l_u_s_i_�_n _d_e _l_a _u_n_i_d_a_d _d_e _c_o_m_a _f_l_o_t_a_n_t_e _d_e _l_o_s
_x_8_6 _p_e_r_m_i_t_e _l_a _r_e_s_o_l_u_c_i_�_n _d_e _i_n_s_t_r_u_c_c_i_o_n_e_s _c_o_n _e_n_t_e_r_o_s _m_i_e_n_�
_t_r_a_s _s_e _e_j_e_c_u_t_a _u_n_a _i_n_s_t_r_u_c_c_i_�_n _e_n _c_o_m_a _f_l_o_t_a_n_t_e_. _P_o_r
_c_o_n_t_r_a_, _n_o _s_e _p_u_e_d_e _e_j_e_c_u_t_a_r _u_n_a _s_e_g_u_n_d_a _i_n_s_t_r_u_c_c_i_�_n _e_n _c_o_m_a
_f_l_o_t_a_n_t_e _s_i _y_a _s_e _e_s_t_a_b_a _e_j_e_c_u_t_a_n_d_o _a_n_t_e_r_i_o_r_m_e_n_t_e _u_n_a_. _P_a_r_a
_e_l_i_m_i_n_a_r _l_a _l_i_m_i_t_a_c_i_�_n _e_n _e_l _r_e_n_d_i_m_i_e_n_t_o _c_r_e_a_d_a _p_o_r _e_l _m_o_d_�
_e_l_o _d_e _e_x_c_l_u_s_i_�_n _d_e _l_a _u_n_i_d_a_d _d_e _c_o_m_a _f_l_o_t_a_n_t_e_, _e_l _p_r_o_c_e_�
_s_a_d_o_r _6_x_8_6 _p_u_e_d_e _r_e_a_l_i_z_a_r _e_s_p_e_c_u_l_a_t_i_v_a_m_e_n_t_e _h_a_s_t_a _c_u_a_t_r_o
_i_n_s_t_r_u_c_c_i_o_n_e_s _e_n _c_o_m_a _f_l_o_t_a_n_t_e _a_l _c_h_i_p _F_P_U _m_i_e_n_t_r_a_s _s_i_g_u_e
_e_j_e_c_u_t_a_n_d_o _i_n_s_t_r_u_c_c_i_o_n_e_s _e_n_t_e_r_a_s_. _P_o_r _e_j_e_m_p_l_o_, _e_n _u_n_a
_s_e_c_u_e_n_c_i_a _d_e _c_�_d_i_g_o _c_o_n _d_o_s _i_n_s_t_r_u_c_c_i_o_n_e_s _e_n _c_o_m_a _f_l_o_t_a_n_t_e
_(_F_L_T_s_) _s_e_g_u_i_d_a_s _p_o_r _s_e_i_s _i_n_s_t_r_u_c_c_i_o_n_e_s _e_n_t_e_r_a_s _(_I_N_T_s_) _y
_s_e_g_u_i_d_a_s _p_o_r _d_o_s _F_L_T_s _m_�_s_, _e_l _p_r_o_c_e_s_a_d_o_r _6_x_8_6 _p_u_e_d_e _m_a_n_d_a_r
_l_a_s _d_i_e_z _i_n_s_t_r_u_c_c_i_o_n_e_s _a_n_t_e_r_i_o_r_e_s _a _l_a_s _u_n_i_d_a_d_e_s _d_e _e_j_e_�
_c_u_c_i_�_n _a_p_r_o_p_i_a_d_a_s _a_n_t_e_s _d_e _q_u_e _s_e _t_e_r_m_i_n_e _l_a _p_r_i_m_e_r_a _F_L_T_. _S_i
_n_i_n_g_u_n_a _d_e _l_a_s _i_n_s_t_r_u_c_c_i_o_n_e_s _f_a_l_l_a _(_e_l _c_a_s_o _t_�_p_i_c_o_)_, _l_a _e_j_e_�
_c_u_c_i_�_n _c_o_n_t_i_n_u_a _c_o_n _l_a_s _u_n_i_d_a_d_e_s _d_e _e_n_t_e_r_o_s _y _d_e _c_o_m_a
_f_l_o_t_a_n_t_e _t_e_r_m_i_n_a_n_d_o _l_a_s _i_n_s_t_r_u_c_c_i_o_n_e_s _e_n _p_a_r_a_l_e_l_o_. _S_i _u_n_a _d_e
_l_a_s _F_L_T_s _f_a_l_l_a _(_e_l _c_a_s_o _a_t_�_p_i_c_o_)_, _l_a _c_a_p_a_c_i_d_a_d _d_e _e_j_e_c_u_c_i_�_n
_e_s_p_e_c_u_l_a_t_i_v_a _d_e_l _6_x_8_6 _p_e_r_m_i_t_e _q_u_e _s_e _r_e_s_t_a_u_r_e _e_l _e_s_t_a_d_o _d_e_l
_p_r_o_c_e_s_a_d_o_r _d_e _f_o_r_m_a _q_u_e _s_e_a _c_o_m_p_a_t_i_b_l_e _c_o_n _e_l _m_o_d_e_l_o _d_e
_e_x_c_l_u_s_i_�_n _d_e _l_a _u_n_i_d_a_d _d_e _c_o_m_a _f_l_o_t_a_n_t_e _d_e_l _x_8_6_.
_U_n _e_x_a_m_e_n _d_e _l_o_s _t_e_s_t _d_e _r_e_n_d_i_m_i_e_n_t_o _r_e_v_e_l_a _q_u_e _l_o_s _t_e_s_t
_s_i_n_t_�_t_i_c_o_s _d_e _l_a _u_n_i_d_a_d _d_e _c_o_m_a _f_l_o_t_a_n_t_e _u_t_i_l_i_z_a _u_n _c_�_d_i_g_o
_c_o_n _s_o_l_o _o_p_e_r_a_c_i_o_n_e_s _d_e _c_o_m_a _f_l_o_t_a_n_t_e_, _q_u_e _n_o _e_s _l_o _q_u_e _n_o_s
_e_n_c_o_n_t_r_a_m_o_s _e_n _l_a_s _a_p_l_i_c_a_c_i_o_n_e_s _d_e_l _m_u_n_d_o _r_e_a_l_. _E_s_t_e _t_i_p_o _d_e
_t_e_s_t_s _n_o _a_p_r_o_v_e_c_h_a _l_a _c_a_p_a_c_i_d_a_d _d_e _e_j_e_c_u_c_i_�_n _e_s_p_e_c_u_l_a_t_i_v_a
_p_r_e_s_e_n_t_e _e_n _e_l _p_r_o_c_e_s_a_d_o_r _6_x_8_6_. _C_y_r_i_x _c_r_e_e _q_u_e _l_a_s _p_r_u_e_b_a_s
_q_u_e _u_t_i_l_i_z_a_n _h_e_r_r_a_m_i_e_n_t_a_s _n_o _s_i_n_t_�_t_i_c_a_s_, _b_a_s_a_d_a_s _e_n _a_p_l_i_c_a_�
_c_i_o_n_e_s _d_e_l _m_u_n_d_o _r_e_a_l _r_e_f_l_e_j_a_n _m_e_j_o_r _e_l _r_e_n_d_i_m_i_e_n_t_o _r_e_a_l _q_u_e
_p_u_e_d_e_n _o_b_t_e_n_e_r _l_o_s _u_s_u_a_r_i_o_s_. _L_a_s _a_p_l_i_c_a_c_i_o_n_e_s _d_e_l _m_u_n_d_o _r_e_a_l
_c_o_n_t_i_e_n_e_n _i_n_s_t_r_u_c_c_i_o_n_e_s _m_e_z_c_l_a_d_a_s _d_e _e_n_t_e_r_o_s _y _d_e _c_o_m_a
_f_l_o_t_a_n_t_e _y _u_t_i_l_i_z_a_n _p_o_r _t_a_n_t_o_, _l_a _c_a_p_a_c_i_d_a_d _d_e _e_j_e_c_u_c_i_�_n
_e_s_p_e_c_u_l_a_t_i_v_a _d_e_l _6_x_8_6_._'_'
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, SSPPEECC, 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.
22..11..22.. TTeessttss ddee aallttoo nniivveell vvss.. tteesstt ddee bbaajjoo nniivveell
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.
22..22.. TTeessttss eesstt��nnddaarreess ddiissppoonniibblleess ppaarraa LLiinnuuxx
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:
"Cambiar de A a B lleva a una mejora de un x % en el tiempo
de compilaci�n del n�cleo de Linux bajo estas y estas condi�
ciones".
�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 iinnddiivviidduuaall 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
http://www.silkroad.com/bass/linux/bm.html 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:
_`_`_L_a _v_e_r_s_i_�_n _o_r_i_g_i_n_a_l _y _l_a_s _v_e_r_s_i_o_n_e_s _l_i_g_e_r_a_m_e_n_t_e _m_o_d_i_f_i_�
_c_a_d_a_s _d_e _B_Y_T_E _U_n_i_x _B_e_n_c_h_m_a_r_k_s _s_e _d_i_f_e_r_e_n_c_i_a_n _e_n _v_a_r_i_a_s _c_o_s_a_s
_q_u_e _l_o_s _h_a_c_e_n _s_e_r _u_n _i_n_d_i_c_a_d_o_r _i_n_u_s_u_a_l_m_e_n_t_e _p_o_c_o _f_i_a_b_l_e _d_e_l
_r_e_n_d_i_m_i_e_n_t_o _d_e_l _s_i_s_t_e_m_a_. _H_e _h_e_c_h_o _q_u_e _l_o_s _v_a_l_o_r_e_s _d_e _m_i_s
_`_`_�_n_d_i_c_e_s_'_' _p_a_r_e_z_c_a_n _m_u_y _d_i_f_e_r_e_n_t_e_s _p_a_r_a _e_v_i_t_a_r _c_o_n_f_u_s_i_o_n_e_s
_c_o_n _e_l _v_i_e_j_o _t_e_s_t_._'_'
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
[email protected]
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
http://wauug.erols.com/bench sobre los test de rendimiento en Linux.
Tambi�n recientemente, Uwe F. Mayer,
[email protected] 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
http://math.vanderbilt.edu:80/~mayer/linux/bmark.html 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 _X_F_r_e_e_8_6_-_b_e_n_c_h_m_a_r_k_s _S_u_r_v_e_y
http://www.goof.com/xbench/ 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.
22..33.. EEnnllaacceess yy rreeffeerreenncciiaass
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 5566 pprruueebbaass ddiiffeerreenntteess, 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
http://reality.sgi.com/lm/lmbench/lmbench.html de Larry McVoy. Citando
a David C. Niemi:
_`_`_L_i_n_u_s _y _D_a_v_i_d _M_i_l_l_e_r _l_a _u_t_i_l_i_z_a_n _m_u_c_h_o _y_a _q_u_e _e_s _c_a_p_a_z _d_e
_r_e_a_l_i_z_a_r _m_e_d_i_d_a_s _�_t_i_l_e_s _d_e _b_a_j_o _n_i_v_e_l _y _t_a_m_b_i_�_n _p_u_e_d_e _m_e_d_i_r
_e_l _t_r_a_s_v_a_s_e _y _l_a _l_a_t_e_n_c_i_a _d_e _l_a _r_e_d _s_i _t_i_e_n_e _d_o_s _o_r_d_e_n_a_d_o_r_e_s
_p_a_r_a _h_a_c_e_r _l_o_s _t_e_s_t_s_. _P_e_r_o _n_o _i_n_t_e_n_t_a _c_o_n_s_e_g_u_i_r _a_l_g_o _a_s_�
_c_o_m_o _u_n _`_`_r_e_n_d_i_m_i_e_n_t_o _d_e_l _s_i_s_t_e_m_a_'_' _g_e_n_e_r_a_l_._._._'_'
Alfred Aburto puso en marcha un lugar FTP bastante completo en cuanto
a utilidades lliibbrreess de medida del rendimiento
(
ftp://ftp.nosc.mil/pub/aburto). Las herramientas Whetstone
utilizadas en el LBT se encontraron aqu�.
Tambi�n tenemos el FFAAQQ mmuullttiippaarrttee ddee EEuuggeennee MMiiyyaa que deja regularmente
en comp.benchmarks; es una referencia excelente.
33.. EEll LLiinnuuxx BBeenncchhmmaarrkkiinngg TToooollkkiitt ((LLBBTT))
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.
33..11.. BBaasseess ll��ggiiccaass
�sto es s�lo de sentido com�n:
1. 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.
2. Todo el c�digo fuente de los programas de estar libremente
disponible en la Red, por razones obvias.
3. Los tests deben proporcionar una representaci�n sencilla de los
resultados que refleje el rendimiento medido.
4. Debe haber una mezcla de tests sint�ticos y de tests de aplicaci�n
(con resultados separados, por supuesto).
5. Cada test ssiinntt��ttiiccoo debe ejercitar un subsistema particular hasta
su m�xima capacidad.
6. Los resultados de los tests ssiinntt��ttiiccooss NNOO 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).
7. Los tests de aplicaci�n deben consistir en tareas usualmente
ejecutadas en los sistemas Linux.
33..22.. SSeelleeccccii��nn ddee hheerrrraammiieennttaass
He seleccionado cinco conjuntos de herramientas, tratando de evitar,
en la medida de lo posible, el solapamiento de pruebas. Son �stas:
1. Compilaci�n del N�cleo 2.0.0 (con la configuraci�n por defecto)
utilizando gcc.
2. La versi�n 10/03/97 de Whetstone (la �ltima que ha sacado Roy
Longbottom).
3. xbench-0.2 (con los par�metros de ejecuci�n r�pida).
4. La versi�n 4.01 de UnixBench (resultados parciales).
5. La distribuci�n 2 de la versi�n beta de los test BYTEmark de la
revista BYTE Magazine (resultados parciales).
Para las pruebas 4 y 5, ``(resultados parciales)'' significa que no se
tendr�n en cuenta todos los resultados producidos por estos tests.
33..33.. DDuurraaccii��nn ddee llaass pprruueebbaass
1. Compilaci�n del N�cleo 2.0.0: 5 - 30 minutos, dependiendo del
rendimiento rreeaall de su sistema.
2. Whetstone: 100 segundos.
3. Xbench-0.2: < 1 hora.
4. Versi�n 4.01 de los tests UnixBench: aprox. 15 minutos.
5. Los tests BYTEmark de BYTE Magazine: aprox. 10 minutos.
33..44.. CCoommeennttaarriiooss
33..44..11.. CCoommppiillaaccii��nn ddeell NN��cclleeoo 22..00..00::
� QQuu��:: es el �nico test de aplicaci�n que hay en el LBT.
� El c�digo est� ampliamente difundido (finalmente he encontrado
alguna utilidad a mis viejos CD-ROMs con Linux).
� Muchos linuxeros recompilan el n�cleo a menudo, por lo que es un
medida significativa del rendimiento global del sistema.
� El n�cleo es grande y gcc utiliza una gran cantidad de memoria: se
atenua la importancia de la cach� L2.
� Hace un uso frecuente de la E/S al disco.
� 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, ssiinn 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.
� RReessuullttaaddooss:: tiempo de compilaci�n en minutos y segundos (por favor,
no indique las fracciones de segundo).
33..44..22.. WWhheettssttoonnee::
� QQuu��:: 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.
� Es la prueba m�s corta del LBT :-).
� Es una prueba "Cl�sica": hay disponibles cifras comparativas, sus
defectos y deficiencias son bien conocidos.
� 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.
� RReessuullttaaddooss:: una cifra del rendimiento de punto flotante en MWIPS.
33..44..33.. XXbbeenncchh--00..22::
� QQuu��:: mide el rendimiento del servidor X.
� 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.
� Procedimiento para realizar la prueba: compilar con -O2.
Especificamos unas pocas opciones para una ejecuci�n m�s
r�pida:./xbench -timegoal 3 > results/name_of_your_linux_box.out.
Para obtener la calificaci�n xStones, debemos ejecutar un gui�n
(script) en awk; la manera m�s r�pida es escribir make summary.ms.
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.
� RReessuullttaaddooss:: una figure del rendimiento de X en xStones.
� Nota: esta prueba, tal como est�, es obsoleta. Deber�a ser
reescrita.
33..44..44.. UUnniixxBBeenncchh vveerrssii��nn 44..0011::
� QQuu��:: mide el rendimiento global de Unix. Esta prueba ejercitar� el
rendimiento de E/S de ficheros y multitarea del n�cleo.
� He descartado los resultados de todas las pruebas aritm�ticas,
qued�ndome s�lo con los resultados relacionados con el sistema.
� Procedimiento para realizar la prueba: compilar con -O2. Ejecutar
con ./Run -1 (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.
� RReessuullttaaddooss:: un �ndice del sistema.
33..44..55.. BBaannccoo ddee pprruueebbaass BBYYTTEEmmaarrkk ddee BBYYTTEE MMaaggaazziinnee BBYYTTEEmmaarrkk::
� QQuu��:: proporciona una buena medida del rendimiento de la CPU. Aqu�
hay un extracto de la documentaci�n: _"_E_s_t_a_s _p_r_u_e_b_a_s _e_s_t_�_n _p_e_n_s_a_d_a_s
_p_a_r_a _e_x_p_o_n_e_r _e_l _l_�_m_i_t_e _s_u_p_e_r_i_o_r _t_e_�_r_i_c_o _d_e _l_a _a_r_q_u_i_t_e_c_t_u_r_a _d_e _C_P_U_,
_F_P_U _y _m_e_m_o_r_i_a _d_e _u_n _s_i_s_t_e_m_a_. _N_o _p_u_e_d_e_n _m_e_d_i_r _t_r_a_n_s_f_e_r_e_n_c_i_a_s _d_e
_v_�_d_e_o_, _d_i_s_c_o _o _r_e_d _(_�_s_t_o_s _s_o_n _d_o_m_i_n_i_o_s _d_e _u_n _c_o_n_j_u_n_t_o _d_e _p_r_u_e_b_a_s
_d_i_f_e_r_e_n_t_e_s_)_. _D_e_b_e_r_�_a _u_s_t_e_d_, _p_o_r _l_o _t_a_n_t_o_, _u_t_i_l_i_z_a_r _l_o_s _r_e_s_u_l_t_a_d_o_s
_d_e _e_s_t_a_s _p_r_u_e_b_a_s _c_o_m_o _p_a_r_t_e_, _n_o _c_o_m_o _u_n _t_o_d_o_, _e_n _c_u_a_l_q_u_i_e_r
_e_v_a_l_u_a_c_i_�_n _d_e _u_n _s_i_s_t_e_m_a_._"
� He descartado los resultados de la prueba de FPU ya que la prueba
Whetstone es representativa del rendimiento de la FPU.
� 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.
� Procedimiento para realizar la prueba: compilar con -O2. Ejecutar
la prueba con ./nbench > myresults.dat 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 ��nnddiiccee ddee llaa
mmeemmoorriiaa; calcule la media geom�trica de los �ndices de las pruebas
NUMERIC SORT, IDEA, HUFFMAN y FP EMULATION; �ste es el ��nnddiiccee ddee
eenntteerrooss.
� RReessuullttaaddooss:: un �ndice de memoria y un �ndice de enteros calculado
tal como se explica anteriormente.
33..55.. PPoossiibblleess mmeejjoorraass
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 (> 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.
33..66.. EEll ffoorrmmuullaarriioo ddee iinnffoorrmmee LLBBTT
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):
______________________________________________________________________
LINUX BENCHMARKING TOOLKIT REPORT FORM
______________________________________________________________________
______________________________________________________________________
CPU
==
Vendor:
Model:
Core clock:
Motherboard vendor:
Mbd. model:
Mbd. chipset:
Bus type:
Bus clock:
Cache total:
Cache type/speed:
SMP (number of processors):
______________________________________________________________________
______________________________________________________________________
RAM
====
Total:
Type:
Speed:
______________________________________________________________________
______________________________________________________________________
Disk
====
Vendor:
Model:
Size:
Interface:
Driver/Settings:
______________________________________________________________________
______________________________________________________________________
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:
______________________________________________________________________
______________________________________________________________________
Kernel
=====
Version:
Swap size:
______________________________________________________________________
______________________________________________________________________
gcc
===
Version:
Options:
libc version:
______________________________________________________________________
______________________________________________________________________
Test notes
==========
______________________________________________________________________
______________________________________________________________________
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:
______________________________________________________________________
______________________________________________________________________
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.
______________________________________________________________________
33..77.. PPrruueebbaass ddeell rreennddiimmiieennttoo ddee llaa rreedd
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)
33..88.. PPrruueebbaass SSMMPP
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 (> 2.1.30 o por ah�) har�n
multiproceso "muy granulado" (_f_i_n_e_-_g_r_a_i_n_e_d), pero no tengo m�s
informaci�n al respecto ahora mismo.
Seg�n David Niemi, _" _._._. _s_h_e_l_l_8 [parte del Unixbench 4.01]_h_a_c_e _u_n _b_u_e_n
_t_r_a_b_a_j_o _c_o_m_p_a_r_a_n_d_o _h_a_r_d_w_a_r_e _s_i_m_i_l_a_r_e _e_n _l_o_s _m_o_d_o_s _S_M_P _y _U_P_._"
44.. PPrruueebbaa ddee eejjeemmpplloo yy rreessuullttaaddooss
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:
LINUX BENCHMARKING TOOLKIT REPORT FORM
CPU
==
Vendor: Cyrix/IBM
Model: 6x86L P166+
Core clock: 133 MHz
Motherboard vendor: Elite Computer Systems (ECS)
Mbd. model: P5VX-Be
Mbd. chipset: Intel VX
Bus type: PCI
Bus clock: 33 MHz
Cache total: 256 KB
Cache type/speed: Pipeline burst 6 ns
SMP (number of processors): 1
RAM
====
Total: 32 MB
Type: EDO SIMMs
Speed: 60 ns
Disk
====
Vendor: IBM
Model: IBM-DAQA-33240
Size: 3.2 GB
Interface: EIDE
Driver/Settings: Bus Master DMA mode 2
Video board
===========
Vendor: Generic S3
Model: Trio64-V2
Bus: PCI
Video RAM type: EDO DRAM
Video RAM total: 2 MB
X server vendor: XFree86
X server version: 3.3
X server chipset choice: S3 accelerated
Resolution/vert. refresh rate: 1152x864 @ 70 Hz
Color depth: 16 bits
Kernel
=====
Version: 2.0.29
Swap size: 64 MB
gcc
===
Version: 2.7.2.1
Options: -O2
libc version: 5.4.23
Test notes
==========
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.
RESULTS
========
Linux kernel 2.0.0 Compilation Time: 7m12s
Whetstones: 38.169 MWIPS.
Xbench: 97243 xStones.
BYTE Unix Benchmarks 4.01 system INDEX: 58.43
BYTEmark integer INDEX: 1.50
BYTEmark memory INDEX: 2.50
Comments
=========
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!
55.. FFaallsseeddaaddeess yy ffaallllooss ddeell bbeenncchhmmaarrkkiinngg
Despu�s de reunir este COMO empec� a comprender por qu� se asocian tan
frecuentemente las palabras "falsedad" y "fallo" con el
benchmarking...
55..11.. CCoommppaarraarr mmaannzzaannaass ccoonn nnaarraannjjaass
�O deber�a decir Apples (-- N. del T.: Apple = manzana, pero tambi�n
una famosa compaa que fabrica ordenadores--) 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.
55..22.. IInnffoorrmmaaccii��nn iinnccoommpplleettaa
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.
55..33.. SSooffttwwaarree//hhaarrddwwaarree PPrrooppiieettaarriioo
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% 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 off-the-shelf y sofware libre.
55..44.. RReelleevvaanncciiaa
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, nnoo debemos resaltar el rendimiento de la FPU ni otra
informaci�n irrelevante. En tales casos, menos es m�s. TTaammppooccoo
necesitamos mencionar la edad de nuestro gato, el humor del que
est�bamos mientras hac�amos la prueba, etc...
66.. FFAAQQ ((PPrreegguunnttaass FFrreeccuueenntteess))
PP11..
�Hay alguna medida aislada del m�rito de los sistemas Linux?
RR:: 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.
PP22..
Entonces, �qu� tal una docena de cifras resumiendo el
rendimiento de diversos sistemas Linux?
RR:: Esa ser�a la situaci�n ideal. Me gustar�a ver que se hace
realidad. �Voluntarios para un LLiinnuuxx BBeenncchhmmaarrkkiinngg PPrroojjeecctt? �Con
un sitio web y una base de datos en l�nea, completa y con
informes bien dise�ados?
PP33..
... �BogoMips...?
RR:: Los BogoMips no tienen nada que ver con el rendimiento de su
sistema. Lea el BogoMips Mini-HOWTO.
PP44..
�Cu� es el 'mejor' banco de pruebas para Linux?
RR:: 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 (_R_e_a_l_-_T_i_m_e), 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.
PP55..
�Cu�l es el procesador m�s r�pido sobre el que corre Linux?
RR:: �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
$.
PP66..
Perm�tame rehacer la pregunta anterior, entonces: �hay alg�n
procesador que sea m�s r�pido para aplicaciones de prop�sito
general?
RR:: Esa es una dif�cil con truco, pero tiene una respuesta muy
sencilla: NNOO. 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...
PP77..
�De manera que la velocidad de reloj influye en el rendimiento
del sistema?
RR:: 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.
PP88..
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?
RR:: �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...
PP99..
�Qu� es un incremento "significativo" de rendimiento?
RR:: 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".
PP1100..
�C�mo obtengo incrementos "significativos" en renadimiento al
menor coste?
RR:: 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,
ppooddrr��aammooss llllaammaarr aa uunn ccoonnssuullttoorr ddee LLiinnuuxx. Lea el Consultants-
HOWTO.
77.. CCooppyyrriigghhtt,, rreeccoonnoocciimmiieennttooss yy mmiisscceell��nneeaa
77..11.. CC��mmoo ssee pprroodduujjoo eessttee ddooccuummeennttoo
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:
LLyyXX yy SSGGMMLL--TToooollss.
77..22.. CCooppyyrriigghhtt
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
[email protected] mediante correo electr�nico o
llamando al +1 404 853 9989.
77..33.. NNuueevvaass vveerrssiioonneess ddee eessttee ddooccuummeennttoo
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
http://www.insflug.org
77..44.. RReeaalliimmeennttaaccii��nn
Se buscan sugerencias y correciones. Se reconocer� a los
contribuyentes. No necesito 'flames'.
Siempre me puede localizar en
[email protected].
77..55.. AAggrraaddeecciimmiieennttooss
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.
77..66.. PPlliieeggoo ddee ddeessccaarrggoo
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.
77..77.. MMaarrccaass rreeggiissttrraaddaass
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.
