Pregunta

He estado buscando en el marco Acelerar que se hizo disponible en iOS 4. En concreto, he hecho algunos intentos de utilizar las rutinas Cblas en mi biblioteca de álgebra lineal en C. Ahora bien, no se puede obtener el uso de estas funciones darme ninguna ganancia de rendimiento sobre las rutinas básicas. Específicamente, el caso de la multiplicación de la matriz 4x4. Dondequiera que yo no podía hacer uso de afín o propiedades homogéneas de las matrices, he estado usando esta rutina (abreviada):

float *mat4SetMat4Mult(const float *m0, const float *m1, float *target) {
    target[0] = m0[0] * m1[0] + m0[4] * m1[1] + m0[8] * m1[2] + m0[12] * m1[3];
    target[1] = ...etc...
    ...
    target[15] = m0[3] * m1[12] + m0[7] * m1[13] + m0[11] * m1[14] + m0[15] * m1[15];
    return target;
}

La llamada de función equivalente para Cblas es:

cblas_sgemm(CblasColMajor, CblasNoTrans, CblasNoTrans,
   4, 4, 4, 1.f, m0, 4, m1, 4, 0.f, target, 4);

La comparación de los dos, al hacer correr a través de un gran número de matrices pre-calculada llenos de números aleatorios (cada función obtiene la misma entrada exacto cada vez), las preformas de rutina Cblas sobre 4x más lento, cuando temporizado con el reloj C () función.

Esto no me parece correcto, y yo me quedo con la sensación de que estoy haciendo algo mal en alguna parte. ¿Tengo que permitirá a la unidad NEON del dispositivo y la funcionalidad SIMD de alguna manera? O no debería esperar un mejor rendimiento con tan pequeñas matrices?

Muy muy apreciado,

Bastiaan

¿Fue útil?

Solución

Las bibliotecas BLAS y LAPACK están diseñados para su uso con lo que consideraría "medianas y grandes matrices" (de decenas a decenas de miles en un lado). Se entregará resultados correctos para las matrices más pequeñas, pero el rendimiento no será tan buena como podría ser.

Hay varias razones para esto:

  • Para entregar las operaciones de rendimiento superior, 3x3 y 4x4 matriz debe ser inline, no en una biblioteca; la sobrecarga de hacer una llamada a la función es simplemente demasiado grande para superar cuando hay tan poco trabajo por hacer.
  • es necesario un tipo completamente diferente conjunto de interfaces para ofrecer el máximo rendimiento. La interfaz BLAS para la matriz toma multiplican las variables para especificar los tamaños y principales dimensiones de las matrices que intervienen en el cálculo, por no mencionar si o no de transponer las matrices y la disposición de almacenamiento. Todos estos parámetros hacen que la biblioteca de gran alcance, y no hacen daño rendimiento para grandes matrices. Sin embargo, en el momento en que haya terminado la determinación de que está haciendo un cálculo 4x4, una función dedicada a hacer operaciones con matrices 4x4 y nada más ya está terminado.

Lo que esto significa para usted:. Si le gustaría tener pequeñas operaciones de matriz dedicados proporcionados, por favor vaya a bugreport.apple.com y abra una incidencia solicitando esta función

Otros consejos

Las presentaciones de Apple WWDC2010 dicen que aceleran aún debe dar un aumento de velocidad, incluso para una operación de matriz de 3x3, por lo que habría dado por hecho que debería ver una ligera mejora de 4x4. Pero algo que tienes que tener en cuenta es que aceleran y NEON están diseñados para acelerar en gran medida las operaciones de enteros pero las operaciones de punto flotante no necesariamente. Usted no ha mencionado su procesador de la CPU, y parece que aceleran usarían parches de neón o VFP para las operaciones de punto flotante en función de su CPU. Si se utiliza instrucciones NEON para las operaciones de flotación de 32 bits, entonces debe correr rápido, pero si se utiliza VFP de flotación de 32 bits o de las operaciones dobles de 64 bits, entonces se ejecutará muy lentamente (desde VFP no es en realidad SIMD). Por lo que debe asegurarse de que está utilizando las operaciones de flotación de 32 bits con Acelerar, y asegúrese de que utilizará NEON en lugar de VFP.

Y otro problema es que, incluso si lo hace el uso de neón, no hay ninguna garantía de que su compilador C generará código NEON más rápido que su función C sencilla hace sin instrucciones neón, porque los compiladores de C tales como GCC menudo genera código SIMD terribles, potencialmente corriendo más lento que el código estándar. Es por eso que siempre es importante probar la velocidad del código generado, y, posiblemente, a la mirada de forma manual en el código ensamblador generado para ver si su compilador genera código incorrecto.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top