FASE 0: Definición de equipos y metodología de trabajo
En principio se han utilizado estas configuraciones:
- Viejo: Raspberry Pi modelo B 1.0 (256 megas), usando la distribución Debian recomendada en aquel tiempo (pero actualizada) y sin oveclock.
- Base: Raspberry Pi modelo B 1.0, usando Raspbian actualizada y sin overclock (las frecuencias de reloj son 700/250). Se supone que este equipo es la referencia.
- Normal: Raspberry Pi modelo B 2.0 (512 megas), usando Raspbian y sin overclock (700/250).
- Medio: Raspberry Pi modelo B 2.0, usando Raspbian con overclock medio (900/250).
- Turbo: Raspberry Pi modelo B 2.0, usando Raspberry con overclock turbo (1000/500).
- Pi 2: Raspberry Pi 2 Modelo B, con Raspbian para ARM 7 y sin overclock.
Por el lado de los PCs, tenemos:
- Fujitsu: Fujitsu Siemens Lifebook C6387. Portátil con Celeron a 850Mhz, 512 megas de RAM y una tarjeta i815.
- Probook: HP Probook 6470b. Portátil con i5-3320M (4 cores@2600), 8 Gb de RAM y una tarjeta Intel HD4000.
- ilunator: Clónico con AMD/FX6100 (6 cores@3300), 8 GB de RAM y nvidia GTS450.
- QuaZup: Clónico con AMD/Phenom II X4 965 (4 cores@3400), 8 Gb de RAM y nvidia GTS550.
- dv7: HP Pavillion dv7-1280es. Portátil con Core2duo T6400 (2 cores@2000), 4 Gb de RAM y nvidia 9600M GT.
La configuración de memoria usada en la Raspberry Pi ha sido de 192 megas en la GPU. Para igualar las cosas con los tests en PC, se ha utilizado Puppy Linux 5.5 (slacko) sin PAE. Primero se han compilado nbench e ioquake, y después se han probado en todos los equipos. En aquellos que necesitaban drivers (nvidia), se han instalado los drivers.
La metodología es la siguiente. Lo primero de todo se han compilado nbench e ioquake3 en todas las plataformas. Una vez obtenidos los programas de tests, se ha hecho esta prueba.
Se ha ejecuta un script que hace las siguientes acciones:
- Mide temperatura de la Raspberry.
- Ejecuta nbench.
- Ejecuta ioquake3 durante 5 minutos. Durante este tiempo, ioquake ha estado ejecutando la demo "four" en loop, para mantener entretenidos a los equipos.
- Mide otra vez la temperatura de la Raspberry.
Por último, se ejecuta otra vez ioquake3 y se usa timedemo para comprobar el rendimiento de ioquake. Entre prueba y prueba se apaga el equipo y se deja descansar un tiempo para que los componentes se enfríen.
NOTA 1: nbench únicamente mide el rendimiento de un núcleo, en sistemas multinúcleo no muestra todo el potencial de cálculo.
NOTA 2: Puppy Linux es una distribución de 32 bits, los micros de 64 bits tampoco han salido beneficiados.
NOTA 3: Se han usado estos programas porque funcionan (más o menos) en todos los equipos.
FASE 1: El rendimiento en números
| Equipo:| | Quake 3:| | Memory:| | Integer:| | FPoint: | OLTP: | CPU: |
| Viejo | 14,9 | 2,100 | 2,841 | 0,224 | -- | -- |
| Base | 20,2 | 2,447 | 3,091 | 2,026 | 389 | 512.7791s |
| Normal | 21,7 | 2,444 | 3,094 | 2,046 | 5131 | 514.1827s |
| Medio | 24,3 | 3,057 | 3,955 | 2,527 | 5516 | 397.0525s |
| Turbo | 33,8 | 3,652 | 4,525 | 3,014 | 6898 | 352.3676s |
| Pi 2 | 66,5 | 4,344 | 5,659 | 4,789 | 11944 | 74.5870s |
En este test se pueden comprobar una serie de cosas:
- La elección de Debian/armel como distribución de salida para la Raspberry Pi fue bastante desafortunada. Aunque el rendimiento es ligeramente inferior en enteros, el hecho de que no se aproveche de la coma flotante por hardware hace que su rendimiento sea pésimo. Pierde casi un 90% de rendimiento en cálculo y en la vida real (Quake) pierde más del 25%.
- En términos de tests sintéticos, no hay mucha diferencia de rendimiento entre la versión 1.0 (con 256 megas) y la versión 2.0 (con 512 megas). En Quake 3, quizás si que se haya hecho notar la memoria extra, con una subida de rendimiento del 7%.
- Overclockeando la Raspberry se obtiene bastante beneficio. En nivel medio (que es bastante estable sin refrigeración extra), se obtiene una ganancia del 20% en Quake y de alrededor del 25 al 30% en los tests de nbench. Es más que suficiente para que muchas de las cosas que cojean algo empiecen a ir bien.
- Si fuerzas la pobre Raspberry al modo Turbo, las cosas se disparan. En este modo, se sube la frecuencia del core al doble (además de subir un 42% la de CPU). Traducido al castellano: el rendimiento aumenta un 67% en Quake, y entre el 45 y el 50% en el resto de apartados. Eso sí, el modo Turbo es muy inestable (en algunos casos se ha informado de corrupción de las tarjetas SD) y, como se verá luego, la refrigeración va a jugar un papel crítico en este caso. Existe otro modo intermedio entre el medio y el turbo que es más estable y podría ser suficiente para la mayoría de usos.
- Si echamos una ojeada en la tabla de resultados de nbench, en cálculo de enteros nuestra Raspberry Pi (sin overclockear) se situaría cerca de un Pentium III a 900 Mhz o procesadores AMD a 600~700 MHz, siendo más lenta tanto en operaciones con la memoria (¿por la caché?) y mucho más lenta en coma flotante. No tiene ningún equivalente directo, en algunos apartados la Raspberry rinde mejor y en otros peor.
- Si usáramos Quake 3 como benchmark, descubriríamos que la Raspberry Pi machacaría a equipos teóricamente mucho mejores en cálculo. Hay que recordar que la GPU de este bicho es bastante potente y, aunque no sea un rival para equipos recientes, está a un nivel bastante alto... lo suficientemente alto como para correr Quake 3 a 1920x1080 a 20 fps.
FASE 2: La cosa se pone calentita
Hablemos de temperaturas. Las Raspberry no son demasiado propensas a calentarse, y por ello no se incluye ningún tipo de refrigeración adicional de serie. El problema es cuando vas a hacer algo de overclocking porque el rendimiento no te es suficiente. En ese caso, las temperaturas pueden elevarse rápidamente y quizás quieras tener a mano refrigeración extra. Existen juegos de radiadores que se conectan en los tres chips más propensos a calentarse: el SOC, el chip ethernet y el regulador de tensión. En la siguiente tabla podemos ver cómo están de calentitas las cosas:
| Modo: | Text| | Tini| | Tfin| | Text*| | Tini*| | Tfin*| |
| Normal | 21.5º | 36.9º | 54.6º | 22.5º | 33.6º | 53.0º |
| Medio | 21.5º | 35.2º | 58.4º | 21.5º | 30.9º | 53.5º |
| Turbo | 22.0º | 34.2º | 64.8º | 21.5º | 30.9º | 60.0º |
Las temperaturas indicadas en la tabla son las siguientes:
- Text: Temperatura exterior. Está medida con un reloj-termómetro en las proximidades de la Raspberry Pi. La precisión en el display es de medio grado. Esta medida se ofrece como referencia.
- Tini: Temperatura de la Raspberry al iniciar el benchmark. Se ha medido usando el comando /opt/vc/vcgencmd measure_temp y se ofrece como referencia.
- Tfin: Temperatura de la Raspberry al finalizar el benchmark, medida con el mismo comando que la anterior.
Las medidas marcadas con asterisco son iguales que las anteriores, pero han sido hechas después de instalar un kit de refrigeradores a la Raspberry. El objetivo era verificar cuánto pueden ayudar estos kits en caso de overclocking.
Hay dos fallos en estos tests, y es que los he hecho por la vía rápida (soy un poco ansioso por probar cosas nuevas en mis juguetitos). El primer fallo es que la temperatura inicial (en reposo) se ha tomado nada más arrancar la Raspberry, lo que hace que no sea muy de fiar (después de un rato la temperatura se estabiliza y debería haberla medido). El segundo fallo es que quizás se podría haber dejado bastante más tiempo corriendo ioquake. En el caso de la Raspberry Pi sin refrigeración en modo Turbo no quería fastidiar el SOC, así que he optado por hacer un "sprint" y medir antes de quemar algo. Según algunos artículos, la temperatura máxima recomendable es de 85º en el BCM2835... pero a saber cuándo deja de ser estable del todo.
En cualquier caso, se puede ver que la Raspberry se ha beneficiado bastante del nuevo juego de radiadores. Bastante quiere decir como 3 o 4 grados menos de temperatura en todos los modos, lo que sin duda aportará algo de estabilidad cuando se fuercen las frecuencias... y no olvidemos que parece ser que el estado natural de una Raspberry Pi parece ser con algo de overclocking.
FASE 3: Contra los PCs:
Se ha comparado el rendimiento entre varios PCs y la Raspberry. Los resultados son los siquientes:
| Equipo: | ioquake3: | Memory: | Integer: | FPoint: | OLTP: | CPU: | Observaciones: |
| RPi@700 | 39,1 | 2,444 | 3,094 | 2,046 | 5131 | 514.1827s | Raspberry Pi sin overclock |
| RPi@900 | 49,5 | 3,057 | 3,955 | 2,527 | 5516 | 397.0525s | Raspberry Pi con overclock medio |
| RPi@1000 | 59,8 | 3,652 | 4,525 | 3,014 | 6898 | 352.3676s | Raspberry Pi con overclock turbo |
| RPi2@900 | 95,1 | 4,344 | 5,659 | 4,789 | 11944 | 74.5870s | Raspberry Pi 2 |
| Fujitsu | 0,3 | 4,945 | 3,930 | 8,408 | 6913 | 92.8005s | Puntuación en Windows: 21,4 fps |
| Probook | 687,0 | 26,862 | 21,213 | 40,305 | -- | -- | --- |
| ilunator | 973,7 | 20,336 | 15,458 | 25,140 | 257551 | 3.0906s | --- |
| QuaZup | 1000,8 | 26,580 | 24,892 | 43,126 | 343783 | 4,0756s | Puntuación de ioquake3 en Windows: 951,7 fps |
| dv7 | 945,9 | 15,926 | 13,237 | 27,723 | 116347 | 7,1482s | --- |
Unos comentarios:
- La perdedora en potencia de cálculo es claramente la Raspberry Pi... a menos que le apliquemos overclock. Por otra parte, su coste es una fracción del resto de los equipos (salvo los más viejos).
- Esta vez se ha usado Quake 3 ejecutado a 640x480 (no todas las tarjetas de la prueba llegarían hasta los 1920x1080). Se ha utilizado una configuración optimizada para la Raspberry (ver más abajo) en todos los equipos. Eso debería igualar los resultados ya que la versión de ioquake3 para Raspberry y la de Puppy linux no usaban los mismos ajustes.
- Los dos equipos con tarjetas gráficas Intel han dado resultados muy pobres en ioquake3, posiblemente porque los drivers de las tarjetas Intel en Linux no son muy buenos. En ambos casos, ejecutar ioquake3 bajo Windows ha aumentado el rendimiento espectacularmente. Malas noticias para los que tengan tarjeta gráfica integrada. En ambos casos he puesto el resultado de ioquake3 bajo Windows, aunque no es directamente comparable a los de Linux (eso sí, es bonito ver que la Raspberry Pi es casi tan rápida como un i5
). También incluyo el resultado de uno de los equipos de sobremesa, para comparar.- Intel sigue sin saber hacer tarjetas gráficas decentes. La HD4000 se ha quedado incluso por detrás del dv7 (también portátil, con menos micro y memoria, y varios añitos a sus espaldas).
- La configuración específica para Raspberry mejora un montón el rendimiento (ver la primera tabla, sin optimizar), pero no usa capacidades más avanzadas de las tarjetas gráficas. Como resultado, la Raspberry ha triplicado sus resultados normales en Quake (aunque la diferencia entre los modos 640x480 y 1920x1080 no es tan grande, posiblemente debido a algún antialiasing activo) y los PCs también han subido de rendimiento respecto a configuraciones por defecto. La subida ha sido de un 20% en los sobremesas (tarjetas gráficas muy buenas), y el HP dv7 ha duplicado su rendimiento (está claro que algún efecto se le atragantaba). Curiosamente, los Intel no se han movido de sus sitios.
- Los resultados de nbench pueden parecer "descolocados", con los micros de 4 cores plantando batalla al de 6. Como ya se ha mencionado, nbench mide los resultados de un único core (lo que, por cierto, puede dar idea de lo optimizados que están unos cores en relación a otros). Una aproximación sería multiplicar los resultados por el número de cores. Esto no es muy científico (a fin de cuentas, el diseño de placa, chipset y CPU hará que se pierda más o menos rendimiento cuando los cores procesan en paralelo), pero da una idea general de la potencia de unos micros en relación a otros. Si alguien tiene sugerencias de algún otro benchmark que se pueda usar para multicores, que lo mencione.
P.D.: Que alguien me cuente cómo se definen borde y anchura en las tablas, que estas me han quedado penosas.
