Quelles techniques standard existe-t-il pour utiliser des fonctionnalités spécifiques à un processeur dans les DLL?

Question

Version courte: Je me demande s’il est possible, et quel est le meilleur, d’utiliser un processeur spécifique instructions dans une DLL?

Version légèrement plus longue: Lors du téléchargement de DLL (32 bits) depuis, disons, Microsoft, il semble qu'une taille unique convient à tous les processeurs.

Cela signifie-t-il qu'ils sont strictement construits pour le plus petit dénominateur commun (c'est-à-dire le plate-forme minimale supportée par le système d'exploitation)? Ou existe-t-il une technique permettant d’exporter une seule interface dans la DLL mais d’utiliser Un code spécifique au processeur en coulisse pour obtenir des performances optimales? Et si oui, comment fait-on?

Answer 1

Je ne connais aucune technique standard , mais si je devais le faire, j'écrirais du code dans la fonction DllMain () pour détecter le type de CPU et remplir une table de saut. avec des pointeurs de fonction vers les versions optimisées pour le processeur de chaque fonction.

Il faudrait également une fonction de plus petit dénominateur commun lorsque le type de CPU est inconnu.

Vous pouvez trouver les informations actuelles sur la CPU dans le registre ici:

HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor

Answer 2

La DLL est censée fonctionner sur tous les ordinateurs sur lesquels WIN32 s'exécute. Vous devez donc vous en tenir à l'ensemble d'instructions i386. Il n'y a pas de méthode officielle pour exposer les fonctionnalités / codes pour des jeux d'instructions spécifiques Vous devez le faire à la main et de manière transparente.

La technique utilisée est essentiellement la suivante:  - Déterminer les caractéristiques du processeur telles que MMX, SSE en exécution  - si elles sont présentes, utilisez-les, sinon, ayez le code de secours prêt

Etant donné que vous ne pouvez pas optimiser votre compilateur pour autre chose que i386, vous devrez écrire le code à l'aide des jeux d'instructions spécifiques dans inline assembler. Je ne sais pas s'il existe des boîtes à outils de langue supérieure pour cela. Déterminer les caractéristiques du processeur est simple, mais pourrait également être fait en assembleur.

Answer 3

Un moyen simple d'obtenir les optimisations SSE / SSE2 consiste simplement à utiliser l'argument / arch pour MSVC. Je ne voudrais pas m'inquiéter de la solution de rechange - il n'y a aucune raison de soutenir quoi que ce soit en dessous de cela sauf si vous avez une application très spécialisée.

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

Je pense que gcc / g ++ a des drapeaux équivalents.

Answer 4

L'ICC d'Intel peut compiler le code deux fois, pour différentes architectures. De cette façon, vous pouvez avoir votre gâteau et le manger. (OK, vous obtenez deux gâteaux - votre DLL sera plus grande). Et même MSVC2005 peut le faire pour des cas très spécifiques (par exemple, memcpy () peut utiliser SSE4)

Il existe de nombreuses façons de basculer entre les différentes versions. Une DLL est chargée car le processus de chargement a besoin de fonctions. Les noms de fonction sont convertis en adresses. Une solution consiste à laisser cette recherche dépendre non seulement du nom de la fonction, mais également des caractéristiques du processeur. Une autre méthode utilise le fait que la fonction name to address utilise une table de pointeurs dans une étape intermédiaire; vous pouvez changer la table entière. Ou vous pourriez même avoir une branche dans les fonctions critiques; alors foo () appelle foo__sse4 quand c'est plus rapide.

Answer 5

Les DLL que vous téléchargez de Microsoft sont destinées à l’architecture générique x86 pour la simple raison qu’elle doit fonctionner sur toute la multitude de machines qui existent.

Jusqu'à la période de temps Visual Studio 6.0 (je ne sais pas s'il a été modifié) Microsoft utilisait pour optimiser ses DLL en fonction de la taille plutôt que de la vitesse. En effet, la réduction de la taille globale de la DLL a entraîné une amélioration des performances supérieure à toute autre optimisation que le compilateur pourrait générer. Cela est dû au fait que les accélérations résultant de l'optimisation micro-graphique seraient résolument faibles comparées aux accélérations dues au fait que le processeur n'attend pas la mémoire. L'amélioration réelle de la vitesse provient de la réduction des E / S ou de l'amélioration de l'algorithme de base.

Seules quelques boucles critiques exécutées au cœur du programme pourraient bénéficier des micro-optimisations simplement en raison du grand nombre de fois où elles sont invoquées. Seulement environ 5 à 10% de votre code peuvent entrer dans cette catégorie. Vous pouvez être assurés que de telles boucles critiques seraient déjà optimisées en assembleur par les ingénieurs en logiciels de Microsoft à un certain niveau et ne laisseraient pas beaucoup de choses pour le compilateur. (Je sais qu'il attend trop, mais j'espère qu'ils le feront)

Comme vous pouvez le constater, l'augmentation du code de la DLL, qui inclut des versions supplémentaires de code adaptées à différentes architectures, ne présenterait que des inconvénients, lorsque la majeure partie de ce code est rarement utilisée / ne fait jamais partie du code critique qui en absorbe le plus vos cycles de processeur.