Problemas de tiempo de ejecución de Android x86
Lo siguiente es un extracto:
ABI Research, una organización de investigación externa, utilizó los puntos de referencia de AnTuTu para elogiar al procesador Intel Atom por superar a Qualcomm y Samsung. En realidad, esto sucedió a mediados de mayo, y la publicación del blog de hoy en EETimes habla de ello nuevamente. La evaluación de ABI Research sobre el rendimiento de los procesadores Intel Atom es algo arbitraria. Citó otros resultados de la evaluación como refutación, creyendo que el cambio en el mecanismo de puntuación de AnTuTu de la versión 2.9.3 a la versión 3.x resultó en un aumento significativo en las puntuaciones de. Procesadores Intel. Dándole así una ventaja.
Inesperadamente, este asunto aún no ha terminado, porque el foco de la disputa entre las dos partes es el software AnTuTu. En el foro de Anandtech, un internauta de Aizhen (probablemente un programador o desarrollador) analizó el software AnTuTu. Los resultados son muy sorprendentes, cree que AnTuTu optimizó deliberadamente los procesadores Intel e incluso utilizó métodos de puntuación injustos para ARM.
Si esto es cierto, AnTuTu sufrirá un gran dolor.
El siguiente es su análisis.
¿Qué tipo de programa es AnTuTu?
El primer paso es descomprimir el programa AnTuTu. El programa APK es en realidad un archivo ZIP estándar, por lo que este paso no es difícil. Después de descomprimirlo, encontré los directorios X86 y ARM-v7a en la biblioteca, que corresponden a los procesadores Intel y ARM respectivamente. Luego, para descomprimir el archivo libabenchmark.so, utilizó el software objump.
Echemos un vistazo al origen del software objump. El autor del artículo original descubrió a partir del archivo descomprimido que objump es en realidad nbench, porque las funciones de los dos pueden ser las mismas. Cabe decir que las pruebas de punto flotante y enteros de CPU de objump se basan en nbench, la dirección del código fuente de este último está en http://www.tux.org/~mayer/linux/bmark.html. (Resulta que la parte de prueba de AnTuTu no se desarrolló de forma independiente, sino que también fue realizada por un programa de código abierto)
Ahora continuamos con nuestro propósito y revelamos por qué la puntuación del procesador Intel de la prueba AnTuTu 3.x es tan alta. razón alta. La razón cuestionada en un artículo anterior de EETimes es que después de actualizar de la versión 2.9.3 a 3.0, la puntuación general del procesador Atom y la prueba de memoria mejoraron en un 122% y 292% respectivamente, mientras que el Samsung Galaxy S4 solo mejoró en un 53% y 59%. %, la diferencia es intrigante.
El culpable de la puntuación súper alta de Atom es el compilador.
El primer culpable en descubrirlo es el compilador Rabbit utiliza el compilador ICC en X86, que se reconoce como una vectorización de alta calidad. compilador, y la vectorización es exactamente en lo que el procesador ARM no es bueno, porque este último carece de instrucciones NEON enteras e instrucciones NEON enteras.
Antabbit utiliza el compilador GCC para procesadores ARM. No es compatible con las instrucciones NEON de ARM porque hay casos en los que los primeros procesadores, como Tegra 2, no son compatibles con las instrucciones NEON. Sin embargo, este no es el caso ahora. Esta es la razón por la que no es difícil admitir instrucciones NEON usando código independiente en el NDK, que también es la documentación estándar de Google para desarrollar ejemplos.
Curiosamente, AnTuTu no sigue el paradigma de desarrollo de Google para admitir las funciones que debería admitir, sino que prefiere utilizar el compilador ICC, que no forma parte del soporte estándar del NDK.
El problema del compilador es solo el comienzo, y habrá más problemas "excelentes" que el compilador en el futuro.
El segundo culpable: la optimización del código
La prueba Nbench comprobará cómo la CPU realiza operaciones de bits simples como desplazamiento, y-añadir, o-o, etc. Para hacer esto, carga una serie de bits en la memoria uno por uno, como se muestra en el siguiente código:
Mira ARM y X86 en acción.
Código ejecutado por el procesador ARM
Código ejecutado por el X86
Lo que hace el código del X86 es ejecutar los 32 bits completos como 0 o 1, donde f64c3 y f64c6 son claves. Reemplaza 32 iteraciones en el bucle ARM con estas dos instrucciones. El efecto de esto es evidente, X86 aumenta la velocidad de carrera más de diez veces de esta manera.
Este enfoque destruye todo el proceso de prueba. Si bien el compilador pretende mejorar el rendimiento de un programa de prueba haciendo ciertas cosas que el programa de prueba determina que son correctas, en realidad no está realizando la verdadera función del programa de prueba. Ejemplos típicos de esto son que guarda código si el resultado no se lee, o que reduce el tiempo de ejecución al tiempo de compilación cuando los datos de entrada se tratan como una constante.
En este caso, Intel definitivamente afirmará que se trata solo de una optimización legal suya, pero el autor del artículo original no está de acuerdo. Cree que esta optimización difícilmente puede considerarse un código normal y tiene un efecto limitado. Porque nadie utilizará este tipo de ejecución de código. Este truco debería considerarse más como una trampa, ya que puede ser incluso más lento cuando la longitud del recorrido no es muy grande.
Más importante aún, esta optimización solo apareció en ICC en la última versión actualizada. El autor no cree que hayan descubierto el valor de esta optimización recientemente. Es más probable que hayan descubierto que esta optimización puede aumentar el AnTuTu. puntuar varias veces, o esto también puede explicar por qué el procesador Atom de próxima generación de 1,1 GHz recientemente expuesto puede superar al procesador de 2,3 GHz, 40.000 segundos más que el Snapdragon 800 de 2,3 GHz.
Resumamos brevemente las opiniones y argumentos del autor: Hay dos razones para la alta puntuación del procesador Atom. Una es que el compilador ICC utilizado por X86 está muy bien optimizado, mientras que el compilador ICC utilizado. por ARM El compilador GCC ni siquiera puede soportar las instrucciones NEON de ARM. La segunda razón es que el código Rabbit está "optimizado" para usar solo 2 instrucciones para completar las 32 iteraciones requeridas por el procesador ARM cuando ejecuta el programa de prueba. Vamos, esta es una anomalía bastante interesante.
El artículo original finalmente rechazó a Rabbit por aceptar esta mejora de rendimiento y sugerir que Rabbit pudo haber tenido un costo que de otro modo no explicaría estas anomalías.
Intel y ARM se presentan
La traducción del texto original está básicamente completada. Dado que es un artículo técnico, algunas frases pueden no ser precisas, pero ya conocemos el general. significado. Se puede ver que este artículo se publicó en Weibo tan temprano. De hecho, la persona que publicó este enlace fue el gerente de marketing móvil de ARM, Wang Junchao EW. Hubo respuestas poco después de su publicación en Weibo. Del Instituto de Investigación Intel China Wu Gansha, se puede ver que Intel todavía está muy preocupado por ARM. Esto recuerda a la gente lo que dijo Qian Zhongshu: A veces, extrañar a un rival amoroso es mejor que el apego entre amantes. También hay mucho apego entre los amantes.