¿Qué técnicas estándar existen para usar las características específicas de la CPU en las DLL?

Question

Versión corta: me pregunto si es posible y cuál es la mejor manera de utilizar CPU específica instrucciones dentro de una DLL?

Versión ligeramente más larga: Al descargar archivos DLL (32 bits) de, por ejemplo, Microsoft, parece que una talla para todos los procesadores.

¿Esto significa que están estrictamente construidos para el mínimo común denominador (es decir, el plataforma mínima compatible con el sistema operativo)? ¿O hay alguna técnica que se utiliza para exportar una única interfaz dentro de la DLL pero utiliza ¿Código específico de CPU detrás de escena para obtener un rendimiento óptimo? Y si es así, ¿cómo se hace?

Answer 1

No conozco ninguna técnica estándar pero si tuviera que hacer algo así, escribiría un código en la función DllMain () para detectar el tipo de CPU y llenar una tabla de salto con punteros de función a versiones optimizadas para CPU de cada función.

También debería existir una función de mínimo común denominador para cuando se desconoce el tipo de CPU.

Puede encontrar información actual de la CPU en el registro aquí:

HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor

Answer 2

Se espera que la DLL funcione en todas las computadoras en las que se ejecuta WIN32, por lo que está atascado en el conjunto de instrucciones i386 en general. No existe un método oficial para exponer la funcionalidad / código para conjuntos de instrucciones específicos. Tienes que hacerlo a mano y de forma transparente.

La técnica utilizada básicamente es la siguiente:  - determinar características de la CPU como MMX, SSE en tiempo de ejecución  - si están presentes, utilícelos, si no, tenga listo el código de respaldo

Debido a que no puede permitir que su compilador se optimice para otra cosa que no sea i386, tendrá que escribir el código utilizando los conjuntos de instrucciones específicos en el ensamblador en línea. No sé si hay kits de herramientas de idiomas superiores para esto. Determinar las características de la CPU es sencillo, pero también podría ser necesario hacerlo en ensamblador.

Answer 3

Una manera fácil de obtener las optimizaciones SSE / SSE2 es simplemente usar el argumento / arch para MSVC. No me preocuparía por el retroceso: no hay ninguna razón para admitir nada por debajo de eso, a menos que tenga una aplicación muy específica.

http://msdn.microsoft.com/en-us/library /7t5yh4fd.aspx

Creo que gcc / g ++ tiene banderas equivalentes.

Answer 4

El ICC de Intel puede compilar código dos veces, para diferentes arquitecturas. De esa manera, puedes tener tu pastel y comértelo. (OK, obtienes dos tortas, tu DLL será más grande). E incluso MSVC2005 puede hacerlo para casos muy específicos (por ejemplo, memcpy () puede usar SSE4)

Hay muchas formas de cambiar entre diferentes versiones. Se carga una DLL, porque el proceso de carga necesita funciones de ella. Los nombres de las funciones se convierten en direcciones. Una solución es dejar que esta búsqueda dependa no solo del nombre de la función, sino también de las características del procesador. Otro método utiliza el hecho de que la función de nombre a dirección utiliza una tabla de punteros en un paso intermedio; puedes cambiar toda la mesa. O incluso podría tener una rama dentro de funciones críticas; entonces foo () llama a foo__sse4 cuando es más rápido.

Answer 5

Las DLL que descarga de Microsoft están destinadas a la arquitectura genérica x86 por la sencilla razón de que tiene que funcionar en toda la multitud de máquinas que existen.

Hasta el período de tiempo de Visual Studio 6.0 (no sé si ha cambiado) Microsoft solía optimizar sus DLL para el tamaño en lugar de la velocidad. Esto se debe a que la reducción en el tamaño general de la DLL dio un aumento de rendimiento más alto que cualquier otra optimización que el compilador podría generar. Esto se debe a que las aceleraciones de la micro optimización serían decididamente bajas en comparación con las aceleraciones por no tener la CPU esperando la memoria. Las verdaderas mejoras en la velocidad provienen de la reducción de E / S o de la mejora del algoritmo base.

Solo unos pocos bucles críticos que se ejecutan en el corazón del programa podrían beneficiarse de las micro optimizaciones simplemente por la gran cantidad de veces que se invocan. Solo alrededor del 5-10% de su código puede caer en esta categoría. Puede estar seguro de que los ingenieros de software de Microsoft ya habrían optimizado dichos bucles críticos en el ensamblador hasta cierto punto y no dejarían mucho para que el compilador los encuentre. (Sé que está esperando demasiado, pero espero que hagan esto)

Como puede ver, solo habría inconvenientes con el aumento del código DLL que incluye versiones adicionales de código que se ajustan para diferentes arquitecturas cuando la mayoría de este código rara vez se usa / nunca es parte del código crítico que consume la mayor parte sus ciclos de CPU.