¿Es esta una comparación válida de la velocidad de la CPU del teléfono inteligente frente a la de la computadora de escritorio (Android G1 frente al escritorio antiguo de Pentium 4)?

7

Estoy tratando de estimar las diferencias de velocidad al crear un código en mi PC de escritorio que se transferirá a los teléfonos Android. No necesito ser exacto, pero una buena estimación me ayudará a evitar que cree un código que es extremadamente lento en un teléfono con Android. Quiero ser compatible con el Android G1, así que lo uso como mi "línea de base".

Así es como actualmente estoy realizando mis cálculos utilizando Dhrystone MIPS utilizando un viejo Pentium 4 para comparación, que será la unidad de prueba para las pruebas de velocidad rápida. De acuerdo con este documento, un G1 que utiliza una CPU ARM Qualcomm MSM72xx es de aproximadamente 1 MIPS por Mhz:

enlace

Las búsquedas en la web arrojaron comentarios de usuarios que indican que la CPU del G1 viene en stock a unos 350 Mhz y no a los 523 Mhz que se muestran en las especificaciones del chip, por lo que estoy asignando una calificación de MIPS de 350 MIPS para el G1, de manera correcta o incorrecta.

Esta página de Wikipedia muestra la edición de Pentium 4 Extreme clasificada en aproximadamente 9700 MIPS:

enlace

Esto hace que el Pentium 4 sea aproximadamente 27 veces más rápido que el G1. Dado ese multiplicador, si durante una de las operaciones que consumen más tiempo mi código tarda 1 segundo en el Pentium 4, estimaría que tomaría 27 segundos en un G1.

¿Mi lógica es correcta? Espero que no sea porque eso significa que tendré que hacer algunas optimizaciones realmente dolorosas al código para hacer que las cosas se puedan vivir en el G1. Si mi lógica no es correcta y hay un mejor algoritmo para este cálculo, hágamelo saber.

- Roschler

    
pregunta Robert Oschler 13.07.2011 - 04:46

2 respuestas

11

Sí, tu escritorio P4 será mucho más rápido que un teléfono celular.

Solía trabajar en un sistema operativo de teléfono celular. Esto fue hace algunos años, y estábamos usando las CPU XScale y OMAP ARM, y también teníamos un simulador de escritorio que ejecutaba el mismo código compilado para x86. Nunca lo medí, pero 27x es ciertamente plausible.

Hay un montón de factores involucrados además de la velocidad de reloj de CPU sin procesar, principalmente relacionados con el hardware. Los periféricos, la memoria, la velocidad del bus y la arquitectura son grandes. Otra es cómo se construye la CPU del silicio; Las CPU ARM son generalmente más sencillas y no tienen características que mejoren el rendimiento en los chips x86 que aumentan los requisitos de potencia y el tamaño del troquel de chips.

En última instancia, necesitas hacer mediciones. Y sí, este tipo de trabajo integrado a menudo implica "optimizaciones dolorosas al código para hacer que las cosas sean más fáciles de usar" para los usuarios finales. Esa es una razón importante por la que los desarrolladores de ARM con experiencia tienen una gran demanda en Silicon Valley en este momento. Si ya tiene esas habilidades de optimización especializadas, muchas personas lo necesitan.

Voy a agregar un comentario sobre la "optimización prematura" del código del teléfono inteligente.

Cuando está haciendo cualquier tipo de trabajo de sistemas integrados, necesita escribir su código con optimización en el fondo de su mente. No es que todo el código que escriba tenga que optimizarse de inmediato, pero debe tener una buena idea de dónde es probable que tenga problemas y no pintarse en una esquina en cuanto al diseño.

Por lo general, los archivos ejecutables incorporados se crean en un escritorio y se transfieren al dispositivo, por lo que su ciclo de compilación / prueba es al menos un orden de magnitud mayor que en un escritorio; ver los resultados del cambio de código más pequeño puede tomar minutos. Además, las herramientas de creación de perfiles de código en los dispositivos integrados realmente apestan, si es que existen.

Por lo tanto, simplemente no desea dejar el ajuste de rendimiento hasta el último en dispositivos integrados. Si lo hace, y tiene una fecha límite, se encontrará con muchas personas que pasan toda la noche, y tal vez un fracaso total del proyecto. En los dispositivos integrados, las pruebas de rendimiento son como las pruebas unitarias: deben aprobarse la primera vez y hay que seguir probándolas para que el rendimiento no retroceda.

    
respondido por el Bob Murphy 13.07.2011 - 05:24
5

El rendimiento es mucho más que el poder de procesamiento de números de CPU sin procesar, incluso en algoritmos vinculados a la CPU. La eficiencia del compilador (y la implementación de JVM si está trabajando con Java, que es probable que esté realizando en un teléfono Android), la cantidad de memoria disponible y el tamaño del bus, el tamaño de las memorias caché del procesador, etc todo el factor en él.

Si realmente desea saber qué tan rápido se ejecutará el código, intente probarlo con el código real. Escriba un algoritmo que consuma mucho tiempo (el ordenamiento de burbujas en un conjunto de datos grande funciona bien) y compile exactamente el mismo código en ambas plataformas, luego pruebe el tiempo de ejecución. Para obtener una imagen más completa, pruebe varios algoritmos diferentes que ejercerán diferentes conjuntos de funciones.

    
respondido por el Mason Wheeler 13.07.2011 - 05:09

Lea otras preguntas en las etiquetas