CES 2012: Las pruebas donde ahora Medfield es superior a NVIDIA Tegra 2

CES 2012: Las pruebas donde ahora Medfield es superior a NVIDIA Tegra 2

por

Pese a que en la aplicación BenchmarkPi Medfield salió mal parado frente a la competencia, en otras pruebas relacionadas a la navegación web ahora se da un festín.

Ya vimos hace pocas horas atrás una prueba donde la aplicación BenchmarkPi mostraba números desfavorables para la nueva plataforma Intel Medfield destinada a los móviles, estrenada hace un par de días en la feria tecnológica CES 2012. Sin embargo, otros tests demuestran lo contrario a lo visto con anterioridad y dejan muy bien parado a Medfield incluso frente a Tegra 2, cambiando el panorama que teníamos más temprano el día de hoy.

Se hizo una comparación entre los siguientes teléfonos móviles:

  • Samsung Galaxy Nexus con un chipset TI OMAP 4460, procesador central Cortex-A9 dual-core a 1.2GHz y chip gráfico PowerVR SGX540.
  • Motorola Droid Razr con TI OMAP 4430, CPU Cortex-A9 doble núcleo a 1.2GHz y GPU PowerVR SGX540.
  • Apple iPhone 4S  con Apple A5, CPU Cortex-A9 doble núcleo a 800MHz y GPU PowerVR SGX 543MP2.
  • Samsung Galaxy S II con Exynos 4210, CPU Cortex-A9 doble núcleo a 1.2GHz y GPU ARM Mali-400.

Y por supuesto, las dos plataformas de la discordia:

  • Motorola Droid X2 con NVIDIA Tegra 2, CPU doble núcleo a 1GHz y GPU ULP GeForce.
  • Intel Medfield, CPU Atom Z2460 de un sólo núcleo con HyperThreading a 1.6GHz y GPU PowerVR SGX 540 (Más detalles de su composición a fondo en este artículo).

¿Los resultados? En SunSpider Javascript Benchmark 0.9.1 y en la prueba BrowserMark, ambas relacionadas al desempeño en la navegación web, pasó lo siguiente:

¿Por qué ganó Medfield en todo y a todos? La verdad es que una explicación concreta a este rendimiento no hay, dándole paliza a móviles con más núcleos y utilizando sistema operativo Android 4.0 Ice Cream Sandwich, en comparación a la versión más desactualizada que usa Medfield en estas pruebas: Android 2.3 Gingerbread.

Según dice Intel, hay muchísimos factores que contribuyen a estos resultados, sin embargo, se destaca que en relación a la plataforma ARM Cortex-A9, la que tiene procesadores centrales muy capaces, Medfield es superior en el ámbito de la interface de memoria, con A9 haciendo cuellos de botella con todo lo que esté fuera de la memoria cache L2 del procesador, lo que hace que Intel logre mejores números cuando se mide el ancho de banda y por consiguiente, la velocidad de la transferencia de datos a nivel de CPU, logrando un flujo más expedito.

Esto es algo que Cortex-A9 no puede arreglar por motivos de arquitectura, y por lo tanto, ARM tendrá que esperar hasta Cortex-A15 para solucionar este problema, lo cual ya está diseñado pero aún no se fabrica a nivel masivo para reemplazar a la actual generación de móviles en el mercado.

¿Qué hay del ámbito del software? ¿Que Android sea para ARM afectó a Medfield, que es x86? Recordemos que Android está siendo lanzado tanto para ARM como para x86 según un acuerdo que Intel y Google hicieron hace un año atrás, por lo que Medfield corre esa versión x86 de Android. El problema serían las aplicaciones y su compatibilidad, pues pese a que los desarrolladores ya están conscientes hace tiempo de Android x86 y las herramientas para la compatibilidad Google ya las puso a disposición, puede que aún hayan aplicaciones antiguas que no se hayan actualizado a este cambio y soporte adicional.

De todas formas, las aplicaciones en x86 corren sobre una máquina virtual, lo que hace indiferente sobre qué arquitectura se haga, siempre y cuando estas apps no llamen librerías que estén escritas en forma nativa para ARM, donde la máquina virtual no tiene nada que hacer. Eso sí, se calcula que un 75% de todas las herramientas en la tienda de aplicaciones de Android no hacen llamados a estas librerías ARM, por lo que las posibilidades están a favor y además, se sabe que aplicaciones de uso intensivo, como juegos 3D, son quienes llaman estas librerías especiales.

¿Y qué pasa entonces cuando toca una app dentro del 25% que sí llama librerías nativas escritas para ARM? Recién aquí es cuando el rendimiento se ve afectado, porque Intel utiliza un sistema llamado binary translation que efectivamente, traduce código ARM hacia x86, única instancia donde esto ocurre y por consiguiente, la única forma para degradar la velocidad del sistema.

Así, podemos suponer entonces que el ámbito del software no habría sido tan determinante para explicar los malos resultados de Medfield en BenchmarkPi, aunque habría que investigar si esta aplicación hace llamados a librerías ARM, lo que sería la respuesta perfecta para entender esas magras cifras y además, compararlas con los excelentes resultados logrados en SunSpider y BrowserMark, donde seguramente no hubo traducción de ARM a x86 y por consiguiente, se obtuvo gran velocidad, muy por encima de NVIDIA Tegra 2. Si no, la otra respuesta es simplemente el tema de hardware y ancho de banda explicado al comienzo.

Link: Intel’s Medfield & Atom Z2460 Arrive for Smartphones: It’s Finally Here (AnandTech)

También pueden comentar esta noticia en nuestros foros.