Recalcul multithread dans Excel (traduction automatique)

Article
09/24/2014

Dernière modification : mercredi 25 novembre 2009

S’applique à : Excel 2010 | Office 2010 | VBA | Visual Studio

Dans cet article
Vue d'ensemble des MTR Excel
Les éléments et ne fait pas Thread Safe par Excel
Inscription des XLL fonctionne en tant que Thread Safe
Contention de mémoire
Exemples d'Applications de MTR
Considérations relatives à des Services Excel

Important

Cet article a été traduit automatiquement, voir l’avertissement. Vous pouvez consulter la version en anglais de cet article ici.

Microsoft Office Excel 2007 a été la première version d’Excel à utiliser le recalcul multithread des feuilles de calcul. Vous pouvez configurer Excel de façon à utiliser jusqu’à 1024 threads simultanés pour le recalcul, indépendamment du nombre de processeurs ou de cœurs de processeur sur l’ordinateur.

Notes

Il existe un système d'exploitation surcharge associé à chaque thread, afin que vous ne devez pas configurer Excel pour utiliser des threads supplémentaires que vous avez besoin.

Si l'ordinateur possède plusieurs processeurs ou noyaux de processeur, le système d'exploitation assume la responsabilité de l'allocation des threads pour les processeurs les plus efficacement possible.

Vue d'ensemble des MTR Excel

Excel essaie d'identifier les parties de la chaîne de calcul qui peuvent être recalculées simultanément sur différents threads. L'arborescence de très simple suivant (où y ← x signifie qu'y dépend uniquement de x) affiche un exemple de cela.

Figure 1. Calcul simultanément sur différents threads

Calcul simultané sur des threads différents

Après le calcul du A1, A2 et A3 peuvent être calculé sur un thread, tandis que B1 et C1 peuvent être calculée sur un autre, en supposant que toutes les cellules sont thread-safe.

Notes

Le terme thread-safe cellule signifie une cellule qui contient uniquement des fonctions de thread-safe. Les éléments et ne sont pas thread-safe sont détaillée Les éléments et ne fait pas Thread Safe par Excel.

Classeurs plus pratiques contiennent des arborescences de dépendances beaucoup plus complexes que cet exemple. En outre, la durée de recalcul d'une cellule ne peut pas être connue jusqu'à ce qu'un calcul est effectué et peut varier considérablement selon les arguments des fonctions. Pour obtenir les meilleurs résultats, Excel tente d'améliorer l'ordre de calcul sur chaque calcul jusqu'à ce qu'aucune autre optimisation n'est possible.

Excel utilise un seul thread principal pour exécuter ou exécutez la commande suivante :

Commandes intégrées
Commandes XLL
Fonctions d'interface du Gestionnaire de compléments XLL (fonction xlAutoOpen et ainsi de suite)
Microsoft Visual Basic pour Applications les commandes de défini par l'utilisateur (VBA) (souvent appelés macros)
Fonctions définies par l'utilisateur VBA
Fonctions de feuille de calcul d'unsafe thread intégrés (voir la section suivante pour obtenir la liste)
Feuille macro XLM-commandes définies par l'utilisateur et les fonctions
Fonctions et commandes relatives aux compléments COM
Fonctions et des opérateurs dans les expressions de mise en forme conditionnelles
Fonctions et des opérateurs dans des définitions de nom défini utilisées dans les formules de feuille de calcul
L'évaluation d'une expression dans la zone d'édition de la formule à l'aide de la touche F9 forcée

Toutes les formules de feuille de calcul, indépendamment de si les fonctions sont thread-safe ou non, sont évaluées sur le thread principal, sauf si Excel est configuré pour utiliser plusieurs threads. Lorsque l'utilisateur spécifie que plusieurs threads doivent être utilisées, les threads supplémentaires sont utilisés pour les cellules de thread-safe. Notez que le thread principal peut toujours être utilisé pour les cellules de thread-safe lorsqu'il est judicieux d'équilibrage de charge point de vue.

Il est important de réitérant que Excel ne s'exécute pas plus d'une commande à la fois, vous n'avez pas besoin d'utiliser les mêmes précautions que lorsque vous écrivez des fonctions de thread-safe, telles que l'utilisation de la mémoire locale de thread et les sections critiques.

Les éléments et ne fait pas Thread Safe par Excel

Excel considère uniquement les éléments suivants en tant que thread sans échec :

Tous les opérateurs unaires et binaires dans Excel.
Presque toutes les fonctions de feuille de calcul intégrées commençant dans Excel 2007 (voir la liste des exceptions)
Complément fonctions XLL qui ont été enregistrées de manière explicite en tant que thread-safe.

Les fonctions de feuille de calcul intégrées qui ne sont pas thread-safe sont :

PHONETIC
CELL lors de l'argument « adresse » ou « format » est utilisé
INDIRECT
GETPIVOTDATA
CUBEMEMBER
CUBEVALUE
CUBEMEMBERPROPERTY
CUBESET
CUBERANKEDMEMBER
CUBEKPIMEMBER
CUBESETCOUNT
ADDRESS où figure le cinquième paramètre (sheet_name)
N'importe quelle fonction de base de données (DSUM, DAVERAGE, etc.) qui fait référence à un tableau croisé dynamique
ERROR.TYPE
Hyperlink

Pour être explicite, les éléments suivants sont considérés comme dangereux :

Fonctions définies par l'utilisateur VBA
COM add-in-fonctions utilisateur
Fonctions de défini par l'utilisateur de feuille macro XLM
Fonctions macro complémentaire XLL pas explicitement enregistrement en tant que thread-safe

Les implications sont que les opérations et les fonctions suivantes ne sont pas thread-safe et échouent si elles sont appelées à partir d'une fonction XLL inscrite en tant que thread-safe :

Appels aux fonctions d'informations XLM, par exemple, xlfGetCell (GET.CELL).
Les appels à xlfSetName (SET.NAME) pour définir ou supprimer des noms internes à XLL.
Appels aux fonctions non sécurisées de threads défini par l'utilisateur à l'aide de xlUDF.
Les appels à la fonction xlfEvaluate (traduction automatique) pour les expressions qui contiennent des fonctions non sécurisées de threads ou qui contiennent des noms définis dont les définitions contiennent des fonctions non sécurisées de threads.
Appels à la fonction xlAbort (traduction automatique) pour effacer une condition d'interruption.
Appels à la fonction xlCoerce (traduction automatique) pour obtenir la valeur d'une référence de cellule non calculées.

Notes

Fonctions de feuille de calcul XLL ne sont pas autorisées à appeler des commandes API C, par exemple, xlcSave, indépendamment de si elles ont été enregistrés en tant que thread-safe ou non.

Étant donné que les fonctions XLL déclaré comme thread-safe ne peut pas appeler des fonctions d'informations XLM ou référencer des cellules non calculées, Excel n'autorise pas les fonctions XLL qui sont inscrits comme équivalents de feuille macro à enregistrer en tant que thread-safe. Par conséquent la tentative obtenir la valeur d'une référence de cellule non calculées à l'aide de xlCoerce échoue avec une erreur xlretUncalced. Fonction d'informations appelant un XLM échoue avec une erreur xlretFailed. Les autres points répertoriés précédemment échouent avec un code d'erreur introduit dans l'API C Excel : xlretNotThreadSafe.

Les fonctions de rappel uniquement API C sont toutes les thread-safe :

xlCoerce (sauf bien que la référence de contrainte des cellules non calculées échoue)
xlFree
xlStack
xlSheetId
xlSheetNm
xlAbort (à l'exception des cas d'utilisation pour effacer une condition d'interruption)
xlGetInst
xlGetHwnd
xlGetBinaryName
xlDefineBinaryName

La seule exception est la fonction xlSet, qui est, en tout cas, un équivalent de la commande et donc ne peut pas être appelées à partir de n'importe quelle fonction de feuille de calcul.

Une fonction de feuille de calcul XLL peut être inscrits avec Excel en tant que thread-safe. Cette option indique à Excel que la fonction peut être appelée en toute sécurité et simultanément sur plusieurs threads, même si vous devez vous assurer que c'est vraiment le cas. Vous pouvez éventuellement déstabiliser Excel si une fonction enregistrée en tant que thread-safe puis se comporte la.

Inscription des XLL fonctionne en tant que Thread Safe

Les règles un développeur doit respecter lors de l'écriture de fonctions de thread-safe sont les suivantes :

N'appelez pas de ressources dans d'autres DLL n'est peut-être pas thread-safe.
Ne faites pas les appels threads non sécurisés via l'API c ou COM.
Protéger les ressources qui pourraient être utilisées simultanément par plusieurs threads à l'aide de sections critiques.
Utilisez mémoire locale de thread pour le stockage de thread spécifique, en remplaçant les variables statiques dans les fonctions variables locales de thread.

Excel impose une restriction supplémentaire : fonctions thread-safe ne peut pas être enregistrées comme équivalents de feuille macro et par conséquent ne peut pas appeler des fonctions d'informations XLM ou obtenir les valeurs de cellules un-recalculated.

Contention de mémoire

Systèmes multithread doivent résoudre deux problèmes fondamentaux :

Comment protéger la mémoire qui doit être lu ou écrite, par plusieurs threads.
Comment créer et accéder à la mémoire qui est associé et donc privé pour le thread en cours d'exécution.

Le système d'exploitation Windows et le Kit de développement logiciel (SDK) Windows fournissent des outils pour ces deux éléments : les sections critiques et l'API de stockage local des threads (TLS) respectivement. Pour plus d'informations, consultez Gestion de la mémoire dans Excel (traduction automatique).

Le premier problème peut se produire, par exemple, lorsque deux fonctions de feuille de calcul (ou les deux instances simultanément en cours d'exécution de la même fonction) est nécessaire accéder ou modifier une variable globale dans un projet DLL. N'oubliez pas qu'une telle variable globale peut être masquée dans une instance d'un objet de classe globalement accessible.

Le deuxième problème peut se produire, par exemple, lorsqu'une fonction de feuille de calcul déclare une variable statique ou un objet dans le code du corps de fonction. Le compilateur C/C++ crée uniquement un seul exemplaire qui utilisent tous les threads. Cela signifie une seule instance de la fonction peut modifier la valeur, tandis que, en supposant un autre sur un thread différent peut être que la valeur est qu'elle préalablement définie.

Exemples d'Applications de MTR

Tout XLL qui exporte les fonctions de feuille de calcul peut tirer parti de recalcul multithread (MTR) dans Excel, sous réserve que ces fonctions est inutile d'effectuer des actions non sécurisées de threads. Cela permet à Excel de recalculer les classeurs qui en dépendent aussi rapidement que possible et n'est donc souhaitable quelle que soit l'application.

Plus précisément, MTR a un impact énorme sur la durée de recalcul de classeurs qui appellent des fonctions définies par l'utilisateur (UDF) qu'eux-mêmes appellent des processus externes pour obtenir le résultat souhaité. En particulier, pensez à un fichier UDF qui appelle un serveur distant qui peut traiter un grand nombre de demandes simultanément et un classeur contenant de nombreux appels à cette fonction. Si le recalcul du classeur est mono-thread, chaque appel à la FDU et donc pour le serveur distant, doit effectuer avant celle qui suit peut être effectuée. Cela fait perdre la capacité du serveur pour traiter le grand nombre d'appels à la fois. Si le recalcul du classeur est multithread, Excel peut effectuer plusieurs appels en même temps ou en succession rapide.

Si Excel est configuré pour utiliser le même nombre de threads que le serveur — appelez-la N — et il permet à la topologie de l'arborescence des dépendances du classeur, la durée de recalcul total peut être réduite à un semblant de 1/N du temps de calcul monothread. Ceci est vrai même lorsque l'ordinateur client (sur lequel s'exécute le classeur) a uniquement un seul processeur, en particulier où le temps nécessaire pour effectuer l'appel vers le serveur est petit par rapport à la durée que nécessaire au serveur de processus de l'appel.

Système d'exploitation overhead étant pour chaque thread supplémentaire. Par conséquent, certaines expérimentations peuvent être requises pour un classeur donné et un serveur donné et un ordinateur client pour trouver le nombre optimal de threads Qu'excel doit être informé à utiliser.

Par exemple, considérez un ordinateur à processeur unique fonctionnant sous Excel et un classeur qui contient 1 000 cellules. Il appelle un fichier UDF, qui à son tour appelle un ou plusieurs serveurs distants. Supposons que les 1 000 cellules ne dépendent pas mutuellement, afin que Microsoft Excel n'a pas à attendre un appel soit terminé avant d'appeler l'autre. (Certains relaxation de cette contrainte est possible sans affecter cet exemple.) Si les serveurs peuvent traiter 100 requêtes simultanément, et Excel est configuré pour utiliser 100 threads, la durée d'exécution peut être réduite à aussi peu que 1/100th de celui dans lequel un seul thread est utilisé. La surcharge associée avec Excel allocation des appels à chaque thread et le système d'exploitation, gestion des 100 threads signifie que, dans la pratique, la réduction sera pas tout à fait ce formidable. Il existe également une hypothèse implicite ici que le serveur est évolutif et lui demande de traiter 100 tâches simultanément n'affecte pas les temps d'exécution des tâches individuelles considérablement.

Une application pratique dans laquelle cette technique peut avoir un avantage important est celui de méthodes de Monte-Carlo, ainsi que d'autres tâches numériquement intensives qui peuvent être divisées en sous-tâches plus petits, qui peuvent être d'élevage serveurs.

Considérations relatives à des Services Excel

Excel Services prend en charge le chargement, calcul et le rendu des feuilles de calcul Excel sur un serveur. Les utilisateurs peuvent ensuite accéder et interagir avec les feuilles de calcul à l'aide des outils de navigateur standard.

Excel Services UDF sont créés à l'aide de Microsoft.NET Framework du code managé et mis à disposition via un.NET externe. XLL ne sont pas pris en charge par Excel Services. Un serveur de code managé ressource UDF peut appeler un XLL accéder à ses fonctionnalités, afin que l'utilisateur peut avoir la même fonctionnalité avec un classeur chargé de serveur à l'instar d'un classeur chargé de client.

Pour rendre les fonctions d'un XLL disponibles de cette manière, ils doivent par conséquent encapsulés dans un.NET qui convertit les arguments et les valeurs de retour à partir des données natives types à la.NET Framework managés des types de données, et qui appelle les fonctions XLL. Le fichier.NET wrapper suffit d'exporter un seul serveur UDF pour chaque fonction XLL accédée. Une exigence supplémentaire est que toutes les fonctions XLL appelées de cette façon doivent être thread-safe. Dans la mesure où les fonctions XLL ne sont pas enregistrées dans la façon dont ils sont avec Excel, le serveur client et le.NET wrapper n'ont aucun moyen de l'application qu'ils sont thread-safe. Il incombe au développeur XLL pour s'en assurer.

Notes

Avertissement traduction automatique : cet article a été traduit par un ordinateur, sans intervention humaine. Microsoft propose cette traduction automatique pour offrir aux personnes ne maîtrisant pas l’anglais l’accès au contenu relatif aux produits, services et technologies Microsoft. Comme cet article a été traduit automatiquement, il risque de contenir des erreurs de grammaire, de syntaxe ou de terminologie.