IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

x86 32-bits / 64-bits Assembleur Discussion :

Comparaison de 2 codes Assembleur


Sujet :

x86 32-bits / 64-bits Assembleur

  1. #1
    Membre chevronné Avatar de Astraya
    Homme Profil pro
    Consommateur de café
    Inscrit en
    mai 2007
    Messages
    959
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France

    Informations professionnelles :
    Activité : Consommateur de café
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mai 2007
    Messages : 959
    Points : 1 868
    Points
    1 868
    Par défaut Comparaison de 2 codes Assembleur
    Bonjour,

    Je souhaiterais avoir votre avis sur 2 codes assembleur générés par le compilateur MSVC 19 en x86 32 bits.
    Selon vous, pour réalisé une post-incrémentation atomique incrémenté laquelle serait la plus rapide?

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    mov eax, 1
    mov ecx, OFFSET atom<int> b
    lock xadd DWORD PTR[ecx], eax
    ret 0
    Ou bien
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    mov eax, 1
    lock xadd DWORD PTR std::atomic<int> at, eax
    inc eax
    dec eax
    ret 0
    Note: la première version utilise le builtin _InterlockedExchangeAdd et la seconde utilise le builtin _InterlockedIncrement puis décrémente la valeur récupéré.

    Avez vous un avis? Lequel préféreriez vous et pourquoi?

    J'aurais tendance à dire que la première version utilise un mov avec un lecture en mémoire ce qui est plus lent qu'un dec sur registre, mais le xadd de la seconde version doit bien faire un mov aussi non?... Je ne suis pas encore très à l'aise avec l'asm

    Je vous remercie,
    Homer J. Simpson


  2. #2
    Expert éminent
    Avatar de Kannagi
    Homme Profil pro
    cyber-paléontologue
    Inscrit en
    mai 2010
    Messages
    3 066
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : cyber-paléontologue

    Informations forums :
    Inscription : mai 2010
    Messages : 3 066
    Points : 9 596
    Points
    9 596
    Par défaut
    J'ai envie de dire le second semble plus "rapide" , mais vraiment c'est impossible à prédire.

    Le soucis c'est que le x86 actuel sont des processeurs Superscalaire Out of Order et leur implémentation sont relativement complexe (comparé à un ARM comme le M1).
    Et donc les instructions écrit par le programmeur (ou le compilo) et ce que fait réellement le processeur ,ben y'a un énorme gouffre qui fait presque dire que l'ISA du x86 est une interface "haut niveau" à coté ^^'

    La meilleurs moyen de le savoir ,c'est de faire une mesure (on peut mesurer aux cycle pres , y'a des instructions pour ça ).

  3. #3
    Expert confirmé

    Inscrit en
    août 2006
    Messages
    3 856
    Détails du profil
    Informations forums :
    Inscription : août 2006
    Messages : 3 856
    Points : 5 444
    Points
    5 444
    Par défaut
    Bonjour,
    Citation Envoyé par Kannagi Voir le message
    La meilleurs moyen de le savoir ,c'est de faire une mesure (on peut mesurer aux cycle pres , y'a des instructions pour ça ).
    Et encore...

    ... car le programme en question est loin d'être seul, il y a beaucoup de choses bien plus prioritaires, qui vont probablement intervenir, et le multi cœur ne facilite rien pour prévoir ce qui va se passer.

    "Mon pied droit est jaloux de mon pied gauche.
    Quand l'un avance, l'autre veut le dépasser.
    Et moi, comme un imbécile, je marche !"
    [Raymond Devos]

  4. #4
    Expert éminent
    Avatar de Kannagi
    Homme Profil pro
    cyber-paléontologue
    Inscrit en
    mai 2010
    Messages
    3 066
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : cyber-paléontologue

    Informations forums :
    Inscription : mai 2010
    Messages : 3 066
    Points : 9 596
    Points
    9 596
    Par défaut
    Citation Envoyé par droggo Voir le message
    Bonjour,
    ... car le programme en question est loin d'être seul, il y a beaucoup de choses bien plus prioritaires, qui vont probablement intervenir, et le multi cœur ne facilite rien pour prévoir ce qui va se passer.
    C'est vrai !
    Pour cela il faut le faire 1 millions de fois et que tu fais une moyenne , et tu as une vision assez précise de combien ça prend

    J'avais fait ça pour mesure combien prend une multiplication matricielle via les instruction SIMD , ça varié de 26 à 80 cycles (suivent le processeurs , mais le 26 cycles est détenu par un ryzen ).

  5. #5
    Membre chevronné Avatar de Astraya
    Homme Profil pro
    Consommateur de café
    Inscrit en
    mai 2007
    Messages
    959
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France

    Informations professionnelles :
    Activité : Consommateur de café
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mai 2007
    Messages : 959
    Points : 1 868
    Points
    1 868
    Par défaut
    Ok merci tous les 2.

    Donc, en gros, si je résume, c'est bien kiff kiff

    Je ne vois pas de différence notable, encore que... la seconde version utilise un dec supplémentaire et donc une dépendance avec le résultat du inc...
    Pour le cas du xadd sur register ou mémoire... bas dans tous les cas il doit y avoir un mov sur mémoire...

    Merci quand même, je vais garder la première version pour la simple raison que le code C++ dans la première est juste un fetch_add(1) et pas une fonction "increment" spécifique Windows.

    Je vous remercie
    Homer J. Simpson


  6. #6
    Expert éminent
    Avatar de Kannagi
    Homme Profil pro
    cyber-paléontologue
    Inscrit en
    mai 2010
    Messages
    3 066
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : cyber-paléontologue

    Informations forums :
    Inscription : mai 2010
    Messages : 3 066
    Points : 9 596
    Points
    9 596
    Par défaut
    Citation Envoyé par Astraya Voir le message
    Pour le cas du xadd sur register ou mémoire... bas dans tous les cas il doit y avoir un mov sur mémoire...
    Il faut savoir qu'il y'a un cache , donc cache ou registre, c'est presque kif-kif
    Donc l'instruction peut se faire sur "1 cycle"

    la seconde version utilise un dec supplémentaire et donc une dépendance avec le résultat du inc...
    Des dépendance , y'en a plein sur le x86 , mais il faut savoir qu'il fait du renommage de registre en interne et les processeurs actuels ont un buffer de 200 instructions donc les dépendance de ce type là sont facilement résolu

    Franchement si le processeur bloquait sur une tel dépendance , on ferait des processeur in order comme le RasPi 3

Discussions similaires

  1. [ST6] Besoin d'aide code assembleur
    Par doutsie dans le forum Autres architectures
    Réponses: 16
    Dernier message: 06/02/2006, 16h30
  2. Editer/colorer syntaxiquement du code assembleur
    Par gnogno dans le forum Langage
    Réponses: 8
    Dernier message: 26/09/2005, 22h34
  3. Réponses: 5
    Dernier message: 21/12/2004, 18h12
  4. Outils d'analyse statique de code assembleur ?
    Par atomic dans le forum Assembleur
    Réponses: 4
    Dernier message: 11/06/2004, 11h42
  5. Peut-on faire du son juste avec du code assembleur ?
    Par Rick1602 dans le forum Assembleur
    Réponses: 7
    Dernier message: 26/03/2004, 17h39

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo