performance - ¿Problemas con el código ARM NEON de doble núcleo de Qualcomm Scorpion?

assembly multicore

Question

Estoy desarrollando una biblioteca nativa para Android en la que utilizo optimizaciones de ensamblaje ARM y multihebra para obtener el máximo rendimiento en el chipset ARM de doble núcleo MSM8660. Al hacer algunas mediciones noté lo siguiente:

1. La biblioteca de subproceso único con optimizaciones NEON es más rápida que la biblioteca de subproceso único con optimizaciones ARMv6 (como se esperaba).
2. La biblioteca multiproceso con optimizaciones ARMv6 es más rápida que la biblioteca de subproceso único con optimizaciones ARMv6 (como se esperaba).
3. La biblioteca de subprocesos múltiples con optimizaciones de NEON es más lenta que la biblioteca de subproceso único con optimizaciones de NEON (¡definitivamente no esperado!).

He intentado buscar en toda la red una explicación de por qué es esto, pero hasta ahora no he encontrado ninguno. Casi parece que todos los núcleos comparten la misma línea de NEON o algo así, pero todos los esquemas parecen indicar que cada núcleo debe tener su propia unidad NEON. ¿Alguien sabe por qué ocurre esto?

Answer 1

Probablemente sea por falta de memoria caché. Es difícil de decir sin más información.

Answer 2

Supongo que se debe a la penalización adicional del ciclo involucrada en el lavado de la tubería NEON. La tubería NEON está detrás del resto del núcleo, por lo que puede ver una penalización de ciclo extra por ramas perdidas, etc.

Si los hilos tienen que sincronizarse con bastante frecuencia, o si tienes muchos bloqueos, creo que vas a ver grandes penalizaciones con NEON.

La única forma en que va a aprovechar NEON para obtener una ganancia general en rendimiento con código de subprocesos múltiples es si el código es vergonzosamente paralelo y hay muy poca y poca comunicación entre los subprocesos.

Answer 3

Antes que nada, ¿qué biblioteca estás usando?

Estás en lo cierto, cada núcleo tiene su propia unidad NEON. Sin embargo, es su propia unidad ''VeNum'' patentada y no se proporciona mucha información al respecto, fue diseñada para el Scorpion basado en Cortex-A8 en 8x50 y fue bastante mejor que ARM propia implementación de NEON SIMD, sin embargo un buen alivio es que ellos (qcom) diseñan su hardware de manera que sea compatible con el diseño de referencia base, por lo que la mayoría del código para un cortex-A8 funcionará bien con Scorpion aunque con cierto rendimiento. a un posible tiempo de instrucción diferente.

Si está utilizando "softfp" para compilar su programa, tendrá una sobrecarga de aproximadamente 20 ciclos por cada función que llame que use argumentos de coma flotante y / o use la unidad NEON como transferencia de datos de registro desde el núcleo ARM a la unidad Neon y viceversa, es bastante lento y, a veces, puede estancar el núcleo durante muchos ciclos, esperando que la tubería se vacíe.

También para un programa enhebrado que usa unidad de coma flotante, el kernel tiene que guardar los registros FP durante un cambio de contexto, de modo que incurre en una penalización adicional para los hilos ya que sabemos que mover registros de neón a brazo es lento y se sabe que detiene la tubería.

Además, muchos otros factores pueden llevar a esto, como una mala optimización del compilador, falta de caché, no utilizar la función de doble problema de Scorpion, mala programación de instrucciones y el cambio de su hilo de un núcleo a otro repetidamente.