Quel est le code d'assemblage X86 le plus rapide pour synchroniser l'accès à un tableau en mémoire?
Pour être plus précis: nous avons une région à pages monocommandée continue de Malloc'ed en mémoire et le système d'exploitation ne sera pas de page de page de cette région pendant toute la durée de notre expérience. Un thread va écrire sur la matrice, un thread va lire de la matrice. La matrice est petite, mais plus grande que la capacité d'écriture atomique de votre CPU (de sorte qu'un verrou séparé est requis de manière acutale)
"le plus rapide": la vitesse effective: ne supposez pas que la longueur du bytecode est significative mais prend en compte le comportement de la mise en cache du comportement de verrouillage et de ramification concernant le code environnant.
Il doit fonctionner sur x86-32 et / ou x86-64
Il doit fonctionner sur haut (ou descendants de) fenêtres depuis XP, Linux depuis le noyau 2.2 ou maxos x (en mode utilisateur).
S'il vous plaît non "Cela dépend" -Responses: si cela dépend de tout ce que je n'ai pas spécifié ici, il suffit de créer votre propre exemple (s) et d'indiquer ce qui est le plus rapide dans ce cas / ces cas.
Code postal! (Ceci est pour prévenir les descriptions vagues)
Poster non seulement votre verrouillage Si vous le souhaitez, expliquez vos modifications pour le cache-optimalité et comment éviter les erreurs de branche si la cible de la branche dépend de (1) si vous obtenez la serrure ou non (2) ce que le premier octet d'un plus grand lire est.
Si vous aimez la distinction entre le multiprofessionnement et la commutation des tâches: comment votre code sera-t-il effectué si les threads ne sont pas effectués sur 2 processeurs mais obtenez-en une? + + CMPXCHG Comparer et échanger, mais montre-nous comment vous l'intégrez avec les instructions de lecture dans le thread et les instructions d'écriture dans le fichier autre.
3 Réponses :
Je ne comprends pas. Verrouillage de bus (verrouillage préfixe ou XCHG MEM, instruction REG) et la vitesse ont peu à voir les unes avec les autres. Il s'agit de synchroniser physiquement la CPU avec le dispositif actif le plus lent de votre système - ce qui pourrait être connecté via le PCI de 33 MHz ou de ce type - et vous pouvez parier qu'il sera beaucoup plus lent qu'un accès RAM qui n'était pas dans le cache. Attendez-vous donc à 300-3000 cycles d'horloge CPU en fonction de la durée pendant laquelle vous devez attendre l'appareil. Si aucun périphérique n'est actif, vous devez toujours attendre que les bus respectifs reconnaissent la serrure.
Le code le plus rapide? Oublie. Vous devez soit accepter d'accepter qu'il s'agit de la manière dont les serrures de bus fonctionnent ou trouvent d'autres moyens de synchroniser qui ne nécessitent pas de verrouillage de bus.
Si la performance de verrouillage est importante, vous faites quelque chose de mal.
Oui, je suis surtout d'accord. Si les morceaux de travail sont assez gros, il amortit le coût de verrouillage.
Vraiment, la réponse est "Cela dépend". Quel est le modèle d'utilisation de votre tableau? Est-ce que c'est lu principalement? Est-ce la mise à jour - surtout et vous pouvez vous éloigner des résultats imprécis en lecture (à l'aide de tableaux PER-CPU)? Les mises à jour sont si peu fréquentes que la RCU donnerait de graves améliorations de performance?
Il y a beaucoup de compromis ici, voir le livre de Paul McKenney: La programmation parallèle est-elle difficile et, si oui, que pouvez-vous faire à ce sujet?
@Ken White: haha drôle. Ou êtes-vous sérieux? Si oui: Jetez un coup d'œil à la terminologie que j'utilise et les questions que j'ai répondues.
@Ken - Je serais très intéressé par l'école qui attribue ce type de question comme devoirs.
@eznme, j'ai lu la terminologie utilisée. Cela ressemble à quelque chose d'un manuel. "Postez non seulement votre 2 lignes ... mais montrez". Aucune infraction prévue - cela n'a pas ressemblait à quelque chose qu'une question typique contiendrait. @ Linuxuser27, avez-vous consulté l'un des cours avancés au MIT ou à RIT?
@Ken White: Je suppose que comme un compliment ;-)
@Ken - Je suis allé à Rit (classe de 2007). Quant à mit, non. Mais je vais vérifier leur site de cours.
@eznme, tu devrais. :) Comme je l'ai dit, aucune infraction n'était destinée. En fait, c'est assez impressionnant. :) Je vais laisser mon commentaire original, comme je ne me cache pas quand j'ai été stupide en public. +1 Pour la question, aussi, avec mes excuses.
@Ken White: Pas besoin d'excuses, c'est tout à fait compréhensible et drôle. Merci beaucoup pour votre +1, j'espère que cela rend certains experts montrent leurs compétences.
@eznme: Vous réalisez que vous réalisez qu'il existe énormes différences dans la mise en cache, l'exécution de l'instruction et, par conséquent, la vitesse des différents processeurs X86, n'est-ce pas?
@thkala: Absolument, c'est pourquoi j'ai inclus mon "cela dépend" -Suggestion. Êtes-vous un expert sur le terrain? Si oui, veuillez poster votre solution; Je détesterais poster mon code comme première réponse.
Ceci est sur le territoire «pas une vraie question». Si c'était une vraie question, vous nous demandez de décider des exigences. Si c'était une vraie question, ce serait une question plutôt que 5 ou 6.
@David Heffernan: Si vous voyez des questions "5 ou 6" ici, répondez-en à un, c'est précisément le "Cela dépend" -cases que j'aimerais entendre parler.
Vous avez donc déjà une solution que vous pensez résoudre le problème, mais plutôt que de le poster pour l'examen et l'amélioration possible, vous nous défiez de proposer nos propres solutions? Si rien d'autre, cette question devrait avoir la balise "Code Golf". Mais je pense que ce n'est pas une vraie question.
La question est "Quel est le code d'assemblage le plus rapide x86 pour synchroniser l'accès à un tableau en mémoire?" Si je pensais que mon code viendrait de près, je ne passerai certainement pas tout ce problème.
Vous aurez une meilleure réponse si vous publiez votre code et demandez des critiques.
Vous devriez lire cet excellent article avec le code inclus: codeproject.com/kb/threads/critsectex. ASPX . Il utilise intrisics pour effectuer un verrouillage efficace, mais je suis sûr que vous êtes capable de traduire cela en ASM X86 / X64 si vous posez une telle question (désolé, Windows uniquement)