salu2,
hago un copy-paste que creo aporta mucha información sobre el tema, al menos desde la óptica de "lo que nos quieren vender"
he usado mac 6y pc, y en sentido esctricto lo + importante es PARA QUÉ USES EL ORDENADOR, no hay que olvidarlo, porque un chimpancé con un pc o un mac hará lo mismo: nada.
Pruebas de Rendimiento vs. Realidad
Sinceramente, creo que hoy en día, el marketing ha adquirido una fuerza demasiado grande. Para entender que se esconde detrás de unas pruebas de rendimiento y descubrir una posible manipulación hay que conocer una lista de aspectos bastante grande y la realidad usualmente suele ser demasiado compleja y no se resume en una única verdad de validez universal.
Algunas ideas sobre Benchmarking: Hardware
Es necesario conocer en profundidad la arquitectura de las máquinas que se comparan para poder determinar sus puntos fuertes y débiles. A modo de advertencia, algunos de los puntos de este apartado de hardware que siguen son algo técnicos.
Una CPU x86 (Intel, AMD) moderna lo que hace de una manera muy general y simplificando mucho es traducir las instrucciones a un formato interno del procesador (decodificación) y reorganizarlas (scheduling) para una ejecución más óptima. En esta reorganización el procesador obviamente no ejecuta el código de la manera secuencial en la que fue escrito. En dicha ejecución se predicen que valores tendrá un instrucción condicional (if...else) por los predictores de ramificaciones (branch predictors). Todos estos procesos se realiza en diferentes fases en los que esta segmentado un procesador.
Una primera aproximación a los aspectos importantes a tener en cuenta de cara a hacer pruebas de rendimiento podría ser:
* CPU:
· Unidades funcionales: Cuantos productos y sumas pueden “salir” del procesador como máximo cada ciclo. Detrás de cuantos puertos están situados las unidades de ejecución, cuantos ciclos se tarda “de media” en efectuar un producto o una suma, etc.
· Longitud de pipeline (fases de segmentación). La cadena de ejecución de un procesador está dividida en diferentes fases. El número de fases está directamente relacionado con los MHz que alcanza un procesador. Las instrucciones al ejecutarse van pasando por dichas fases.
· Diseño del decodificador de instrucciones del procesador
· Comportamiento del Scheduler (reorganizador), número de instrucciones al vuelo, etc.
· Calidad del Branch predictor (predictor de ramificaciones)
· Velocidad y anchura del FSB (bus que conecta el micro con el chipset)
· Caches de nivel 1 y 2: tamaño, latencia, frecuencia de funcionamiento (MHz), si están integrada on-die la cache de nivel 2, asociatividad, puertos, anchura y velocidad de la conexión entre las caches de nivel 1 y 2, etc.
* Subsistema de memoria
· Latencia
· Ancho de banda
· Tamaño
* Subsistema gráfico
· Frecuencias de funcionamiento del micro gráfico y de la memoria
· Tamaño de memoria local
· Conexión micro gráfico – memoria
· Unidades funcionales del micro gráfico
· Fase de optimización de los controladores gráficos
· Algoritmos usados para aliasing (supersampling, multisampling), filtro anisotrópico, otros filtrado de texturas, etc
* Chipset
· Absolutamente crítico ya que controla muchas transferencias en del sistema
· Latencia que introduce de cara al micro en un acceso a memoria
· Implementación del controlador de memoria
· Implementación del controlador AGP
· Conexión puente norte-sur de cara a rendimiento de discos duros, podría influir en caso de que se tenga disco duros en RAID, controladoras Gigabit Ethernet o controladoras SCSI 3.
Algunas ideas sobre Benchmarking: Software
Saber que hacen los benchmarks usados y como consecuencia de que elemento del hardware se ven más influenciados es absolutamente primordial.
Por ejemplo, planteemos algunos escenarios o tipos de aplicaciones posibles:
1. Aplicación que se ve muy favorecida por caches de nivel 1 y 2 muy rápidas, quedando su tamaño a un segundo plano. Vaya, esto es perfecto para la rápida pero pequeña cache de nivel 1 de los P4.
2. Aplicación que se ve muy favorecida por caches de nivel 1 y 2 grandes, quedando su velocidad a un segundo plano. Esto le viene como anillo al dedo al Athlon por su enorme cache L1.
3. Aplicación con muchas sentencias condicionales (if ...else). Aquí el procesador con mejor predictor de ramificaciones ganaría supuestamente. Resulta que la realidad es algo más compleja ya que hay que tener en cuenta también el número de fases del pipeline de ejecución puesto que cuando se predice una ramificación mal toda la cadena de ejecución se vacía y se comienza de nuevo. Por ello, en un procesador con pipeline con más fases, Pentium 4, la penalización ante una ramificación mal predicha es mayor que en un Athlon. Por ello, un P4 no siempre gana a un Athlon en este tipo de aplicaciones a pesar de tener un predictor mejor.
4. Aplicación muy dependiente del subsistema de memoria, de su latencia y ancho de banda. Aquí en un principio brilla el P4 debido a que su bus (FSB) puede absorber todo el ancho de banda de la memoria. Luego os cuento que tienen que ver las pruebas SPEC CPU con esto.
5. Aplicación que depende del poder flotante de la máquina. Aquí veo dos escenarios. No se optimiza para SSE/SSE2 y por lo tanto en x87 el Athlon se merienda al P4 debido a que posee 3 unidades de FPU frente a 1 del P4. Se optimiza para SSE2, aquí el Athlon muerde el polvo. Si hablamos de Apple sustituir SSE por Altivec donde haga falta.
6. Aplicación muy dependiente de la tarjeta gráfica. Luego os cuento una historia muy divertida respecto a este apartado.
7. Prestad especial atención a este apartado: Aplicación muy intensiva en cuanto a CPU, cuya función principal se basa en un algoritmo relativamente “pequeño”. Aquí caen especialmente aplicaciones como compresores MP3, compresores de video, filtros de Adobe Photoshop (vaya esto suena a benchmarks usados por Apple, ¿no?), clientes distribuidos (RC5), etc. Resulta que estos algoritmos, se prestan especialmente a la optimización. Muchos de vosotros conocerán el hecho de que el 90% del tiempo de ejecución suele transcurrir en tan sólo en un 10% del código. Pues imaginaros además que ocurre cuando este 10% es especialmente optimizable además de ser relativamente “poca cantidad” de código. El resultado de la optimización es absolutamente increíble. Luego es cuento un par de sucesos reales sobre esto.
Como os podéis imaginar la gente que se encarga de los benchmarks en las empresas grandes conoce de una manera perfectamente detallada todo lo que estoy comentado y tras correr los benchmarks elige los que más le favorecen.
También ocurre que muchas veces no se juega limpio y para el sistema de la competencia no se optimiza nada. Por ejemplo veamos algunos trucos recientes de los que me acuerdo al escribir este artículo:
1. Tradicionalmente Intel implementa caches más pequeñas de nivel 1 que AMD, por ello siempre se ha dicho que Intel elige benchmarks que favorecen caches pequeñas y rápidas mientras que AMD prefiere aplicaciones que favorecen caches más grandes de nivel 1.
2. Me acuerdo que cuando AMD introdujo su procesador Duron me pasé por su web y vi unos benchmark que lo comparaban al Celeron de núcleo P6 (Pentium PRO, PII, PIII) de Intel. Yo creo que nadie dudó en su momento de que el Duron era un procesador superior en todos los aspectos al Celeron basado en la arquitectura P6. Esto también quedaba claro en las pruebas hechas por AMD. Al repasar las configuraciones de los equipos, me hizo gracia descubrir que el Celeron corría sobre una placa base basada en i810 o i810e con tarjeta gráfica integrada mientras que el Duron lo hacía con una tarjeta gráfica discreta, indudablemente varias veces más rápida. Conclusión: las pruebas con exigencia gráfica no eran válidas para tener en consideración.
3. nVidia pretendió hace no mucho, ni más ni menos que convencer al mundo de que sus tarjetas eran capaces de renderizar en tiempo real imagenes con la calidad Pixar (creadores de Toy Story entre otras películas). La gente de Pixar se indignó mucho y hasta me acuerdo de leer la respuesta de algún miembro de dicha compañía que decía que si esto fuera cierto, Pixar no tendría granjas de render de 1024 procesadores que cuestan millones de dólares, sino una Geforce de 300 dólares en cada mesa.
4. ATI: a muchos les sonará el hecho de que ATI sacó al mundo unos controladores especialmente optimizados para Quake III. Fue divertido lo que descubrieron ciertas webs: si renombraban el archivo “quake.exe” a “quack.exe” y lo editaban para sustituir todas las referencias a “quake.exe” con “quack.exe” el rendimiento mostrado por la tarjeta era diferente, siendo superior en el caso de que todo se llamase “quake.exe”. Se rumoreo que nVidia susurró a ciertas webs dicha trampa de ATI.
5. Hace poco tiempo en su plan, John Carmak el famoso programador que se esconde detrás de los motores de juegos tan famosos como Quake y Doom, decía que podría fácilmente elegir escenarios de su próximo Doom III, donde ganase una tarjeta gráfica basada en chips Radeon y otros donde lo hiciese una una basada en chips Geforce.
6. SPEC: Son los benchmarks cross-plataforma por defecto (cross-plataforma, es decir, de comparación entre diferentes máquinas: Intel x32, Itanium (EPIC), HP PA-Risc, SUN Sparc, IBM Power family, Alpha, SGI MIPS). Mucha gente no conoce estos benchmarks, pero a pesar de ello, son posiblemente los de mayor peso en la industria. Dicho esto quizá no sorprenda saber que Intel por ejemplo dispone de gente que trabaja específicamente en optimizaciones para SPEC. La frase de que “Intel desarrolla compiladores específicamente para SPEC” quizá sea demasiado fuerte, no obstante se ve a menudo en discusiones en ciertos foros técnicos.
De todas maneras, los demás pesos pesados de la industria hacen exactamente lo mismo. Desde que Compaq vendió su división Alpha a Intel y desmantelo prácticamente su desarrollo de sus compiladores AMD ha perdido un gran aliado. No hay que olvidarse de que la gente que desarrolla compiladores es, en mi opinión, posiblemente uno de los colectivos más profesionales y de mayor cualificación de toda la industria de la computación. Desarrollar compiladores además de ser complejo, exige tiempo y dinero. Los compiladores son uno de los factores más importantes para el éxito de una CPU. De ellos dependerá el futuro del Intel Itanium y AMD Opteron.
Los benchmarks SPEC CPU muestran demasiada dependencia con el rendimiento del subsistema de memoria. En mi opinión posiblemente más de lo que ocurre en la vida real. Por ello y por el asunto de la optimización particular para estos benchmarks a mi no me gustan demasiado. En Aceshardware.com se puede encontrar mucha información de calidad sobre SPEC.
Voy a comentar varios casos respecto del último tipo de aplicación que citaba: “Aplicación muy intensiva en cuanto a CPU, cuya función principal se basa en un algoritmo relativamente pequeño”.
Voy a utilizar un compresor mp3 que como ya he dicho es una aplicación que cae exactamente dentro de esta categoría. El programa es el WinGoGo con DLL 2.351 para comprimir un archivo Wav (51MB de tamaño, 44100 Hz de muestreo a 16 bits, Stereo) a MP3 de 160Kbps CBR sobre un Athlon XP1600+, 512MB DDR, Seagate Barracuda IV 7200 RPM + Windows XP. WinGoGo está altamente optimizado para MMX, SSE, 3DNOW original y 3DNOW Enhanced de los Athlon y permite seleccionar que opciones de optimización se desean utilizar.
Se han probado dos modos, un primero sin ninguna optimización y un segundo con todas las optimizaciones posibles que soporta el Athlon XP (SSE1, 3DNOW original y Enhanced + MMX).
Los resultados han sido los siguientes:
Como podéis ver con todas las opciones de optimización activadas el rendimiento básicamente se duplica.
He querido también hacer unas pruebas de compresión DivX usando VirtualDub pero este no me permite desactivar las opciones de optimización SSE/3DNOW/MMX con lo que al final no ha sido posible.
Para seguir demostrando que este tipo de aplicaciones son altamente optimizables voy a citar otro ejemplo más. En Noviembre del año 2000 Tomshardware.com publicó una serie de artículos sobre el recién salido Pentium 4.
En uno de estos artículos se hablaba sobre el rendimiento del Pentium 4 usando la popular combinación de ripeo de DVDs FlasK/DivX. Se hicieron una serie benchmarks de este combinación de software que usaban mucho la unidad de coma flotante del procesador donde el Pentium 4 salía perdiendo de mucho (Ver).
Tras ver dichos resultados, varias personas de Intel Alemania no durmieron durante una noche y optimizaron los binarios de Flask de una manera increíble consiguiendo mejoras de aproximadamente 200-300%. (Ver)
Como os podéis ver la mejora es tremenda y en tan poco tiempo. Estoy contando esto tan sólo para demostrar lo optimizables que son este tipo de aplicaciones.
¿Cómo actúa muchas veces Apple?
No deseo crear polémica, pero no puedo dejar de decir que ciertamente la actitud de Apple en el aspecto de benchmarking muchas veces me ha parecido vergonzosa.
Apple se empeña en usar benchmarks que pertenecen al último tipo que citaba, tratándose normalmente de filtros de Adobe Photoshop. Hay que señalar que dichos filtros representan un escenario especialmente optimizable para el Velocity Engine (Altivec) o SSE. Me acuerdo de que hace algún tiempo salió un parche que mejoraba el rendimiento de algunos filtros de Adobe Photoshop hasta un 70% en caso de usar procesadores Pentium 4, creo que sobra decir, que este tipo de aumentos de rendimiento no se ven todos los días.
¿Entonces los benchmarks de filtros de Photoshop sirven para comparar sistemas? ¡Rotundamente NO!
¿Entonces no valen absolutamente para nada?
El único caso para decidir que sistema usar, Mac o PC, con un benchmark de filtros de Photoshop podría ser definir un conjunto de filtros determinado que nos interesa especialmente a nosotros y ver bajo que sistema funciona mejor. Pero repito, los filtros de Photoshop no sirven bajo ningún punto de vista como una prueba de rendimiento cuyos resultados sean extrapolables a otro tipo de aplicaciones.
Otro de los benchmarks que hizo furor en las comparaciones Mac vs PC fue el cliente distribuido de romper claves (RC5). El rendimiento del procesador G4/G4+ que utiliza Apple era superior a los de Intel/AMD.
Resulta que de nuevo estamos en el último tipo de aplicación que he descrito. De nuevo aplicación altamente optimizable.
¿Se puede usar este programa para comparar ambos sistemas y sacar conclusiones extrapolables a otros escenarios? Rotundamente NO!
¿Entonces nos quedaran los benchmarks cross-plataforma SPEC? Bien, si hacemos caso omiso de lo que he comentado anteriormente sobre estos benchmarks, aquí por primera vez deberíamos poder hacer una comparación Mac vs PC “decente”. (fijaros en las comillas)
Pues, no se puede! Resulta que Apple no realiza mediciones SPEC oficiales. En la web se pueden encontrar resultados SPEC de los procesadores G4/G4+ que utiliza Apple, pero normalmente estos números son tremendamente bajos.
¿Entonces ya está no, los procesadores de Apple son muy inferiores a los de Intel/AMD?
Pues mi respuesta a esta pregunta es: Esta conclusión no es válida. Apple no está en la carrera de optimizar sus compiladores para SPEC posiblemente porque no quiere gastar dinero en ello y además porque aunque lo haga seguramente Intel/AMD le seguirán ganando en este benchmark ya que sus subsistemas de memoria + FSB son más potentes.
¿Entonces con los benchmarks citados hasta ahora se puede hacer una comparación válida PC vs. Mac? Pues NO, por lo menos en mi opinión.
También me gustaría dejar claro que el hecho que yo considere la actitud de Apple vergonzosa en cuanto a su continuo uso de filtros de Photoshop para demostrar la superioridad de sus procesadores frente a los de Intel no quiere decir en absoluto que mi opinión de los Mac sea negativa. En realidad todo lo contrario, creo que los Mac tienen un sistema operativo bueno/excelente y unos procesadores digamos aceptables/buenos. Además creo firmemente que la actitud de Apple en cuanto al benchmarking perjudica a sus propios usuarios puesto que envuelve el rendimiento de sus sistemas en mentiras cuando esto no es necesario ya que su rendimiento no es malo.
A modo de conclusión quiero decir que siempre que veáis unas pruebas de rendimiento penséis hasta que punto se adaptan a vuestro perfil de usuarios, las condiciones en las que fueron realizadas y que hacen exactamente los benchmarks usados.
Si veis algún análisis sin configuraciones detalladas de los equipos, versiones del software y condiciones del test no le hagáis ni caso porque seguramente no merece la pena.
¿Entonces cuándo unas pruebas de rendimiento son válidas o representativas?
Yo creo que lo mejor es observar tendencias y no resultados concretos, es decir,
si vemos 10 benchmarks diferentes de juegos y en conjunto un procesador vence esto quiere decir que seguramente ese procesador es más competitivo en juegos. Ahora bien esto se puede deber a que se optimiza más para él o porque el procesador es más rápido en sí pero todo esto ya es otro tema de conversación.
En mi opinión es claramente erróneo extrapolar los resultados de una prueba de rendimiento en concreto a todas las demás situaciones.
¿Las pruebas de rendimiento sintéticas (las que no derivan de aplicaciones sino sólo sirven para medir) sirven para algo?
Sí, permiten ver como rinden aspectos concretos del sistema: CPU, memoria, HDD, tarjeta gráfica, etc. Yo las considero útiles siempre y cuando se tenga en cuenta que las mejoras de rendimiento vistas de un hardware a otro bajo un test sintético no se pueden trasladar directamente a una aplicación real. Lo normal sería que en software normal las mejora de rendimiento de un hardware a otro sean menores de las vistas en pruebas sintéticas.
¿Se puede hacer una prueba de rendimiento entre PC y Mac representativa?
Pues aquí yo lo que haría es lo siguiente: Si existe un programa concreto que nos interesa y este está disponible para ambas plataformas lo que se puede hacer es coger las últimas versiones para cada plataforma y ver donde se ejecutan mejor las funciones concretas que nosotros utilizamos. Una vez más, esto no permite sacar resultados concluyentes a cerca de que máquina es más rápida en general.
Todo lo dicho es tan sólo mi opinión personal, no creo que mi opinión sea más válida que la de otros, ni me considero más sabio que otros. Mi única motivación para escribir esta editorial es mi pasión por las pruebas de rendimiento y por el hardware/software en general.
Roumen Chirinov
Noticias3D.com
