Le langage d'assemblage en ligne est-il plus lent que le code C ++ natif?

J'ai essayé de comparer les performances du langage d'assemblage en ligne et du code C ++, j'ai donc écrit une fonction qui ajoute deux tableaux de taille 2000 pour 100000 fois. Voici le code:

#define TIMES 100000
void calcuC(int *x,int *y,int length)
{
    for(int i = 0; i < TIMES; i++)
    {
        for(int j = 0; j < length; j++)
            x[j] += y[j];
    }
}


void calcuAsm(int *x,int *y,int lengthOfArray)
{
    __asm
    {
        mov edi,TIMES
        start:
        mov esi,0
        mov ecx,lengthOfArray
        label:
        mov edx,x
        push edx
        mov eax,DWORD PTR [edx + esi*4]
        mov edx,y
        mov ebx,DWORD PTR [edx + esi*4]
        add eax,ebx
        pop edx
        mov [edx + esi*4],eax
        inc esi
        loop label
        dec edi
        cmp edi,0
        jnz start
    };
}

Voici main():

int main() {
    bool errorOccured = false;
    setbuf(stdout,NULL);
    int *xC,*xAsm,*yC,*yAsm;
    xC = new int[2000];
    xAsm = new int[2000];
    yC = new int[2000];
    yAsm = new int[2000];
    for(int i = 0; i < 2000; i++)
    {
        xC[i] = 0;
        xAsm[i] = 0;
        yC[i] = i;
        yAsm[i] = i;
    }
    time_t start = clock();
    calcuC(xC,yC,2000);

    //    calcuAsm(xAsm,yAsm,2000);
    //    for(int i = 0; i < 2000; i++)
    //    {
    //        if(xC[i] != xAsm[i])
    //        {
    //            cout<<"xC["<<i<<"]="<<xC[i]<<" "<<"xAsm["<<i<<"]="<<xAsm[i]<<endl;
    //            errorOccured = true;
    //            break;
    //        }
    //    }
    //    if(errorOccured)
    //        cout<<"Error occurs!"<<endl;
    //    else
    //        cout<<"Works fine!"<<endl;

    time_t end = clock();

    //    cout<<"time = "<<(float)(end - start) / CLOCKS_PER_SEC<<"\n";

    cout<<"time = "<<end - start<<endl;
    return 0;
}

Ensuite, j'exécute le programme cinq fois pour obtenir les cycles de processeur, ce qui pourrait être considéré comme du temps. Chaque fois que j'appelle une des fonctions mentionnées ci-dessus uniquement.

Et voici le résultat.

Fonction de la version d'assemblage:

Debug   Release
---------------
732        668
733        680
659        672
667        675
684        694
Average:   677

Fonction de la version C ++:

Debug     Release
-----------------
1068      168
 999      166
1072      231
1002      166
1114      183
Average:  182

Le code C ++ en mode version est presque 3,7 fois plus rapide que le code d'assembly. Pourquoi?

Je suppose que le code d'assemblage que j'ai écrit n'est pas aussi efficace que ceux générés par GCC. Il est difficile pour un programmeur commun comme moi d'écrire du code plus rapidement que son adversaire généré par un compilateur, cela signifie-t-il que je ne devrais pas faire confiance aux performances du langage assembleur écrit par mes mains, me concentrer sur C ++ et oublier le langage assembleur?

Oui, la plupart du temps.

Tout d'abord, vous partez de l'hypothèse erronée qu'un langage de bas niveau (assembly dans ce cas) produira toujours du code plus rapide qu'un langage de haut niveau (C ++ et C dans ce cas). Ce n'est pas vrai. Le code C est-il toujours plus rapide que le code Java? Non car il y a une autre variable: programmeur. La façon dont vous écrivez le code et la connaissance des détails de l'architecture influencent grandement les performances (comme vous l'avez vu dans ce cas).

Vous pouvez toujours produire un exemple où le code d'assemblage fait à la main est meilleur que le code compilé, mais il s'agit généralement d'un exemple fictif ou d'une seule routine pas un vrai programme de plus de 500 000 lignes de code C ++). Je pense que les compilateurs produiront un meilleur code d'assemblage 95% fois et parfois, seulement quelques rares fois, vous devrez peut-être écrire du code d'assemblage pour quelques routines courtes, très utilisées et critiques pour les performances ou lorsque vous devez accéder à des fonctionnalités de votre langage de haut niveau préféré n'expose pas. Voulez-vous une touche de cette complexité? Lisez cette réponse géniale ici sur SO.

Pourquoi ça?

Tout d'abord parce que les compilateurs peuvent faire des optimisations que nous ne pouvons même pas imaginer (voir cette courte liste ) et ils les feront en quelques secondes (lorsque nous aurons besoin de jours ).

Lorsque vous codez dans l'assembly, vous devez créer des fonctions bien définies avec une interface d'appel bien définie. Cependant, ils peuvent prendre en compte l'optimisation de l'ensemble du programme et l' optimisation inter-procédurale telles que l' allocation de registres , la propagation constante , l'élimination de sous-expressions communes , l' ordonnancement d'instructions et d'autres optimisations complexes et non évidentes ( modèle Polytope , par exemple). Sur l' architecture RISC , les gars ont cessé de s'inquiéter à ce sujet il y a de nombreuses années (la planification des instructions, par exemple, est très difficile à régler manuellement ) et les processeurs CISC modernes ont de très longs pipelines aussi.

Pour certains microcontrôleurs complexes, même les bibliothèques système sont écrites en C au lieu d'être assemblées car leurs compilateurs produisent un meilleur code final (et facile à entretenir).

Les compilateurs peuvent parfois utiliser automatiquement certaines instructions MMX / SIMDx par eux-mêmes, et si vous ne les utilisez pas, vous ne pouvez tout simplement pas comparer (d'autres réponses ont déjà très bien examiné votre code d'assemblage). Juste pour les boucles, voici une courte liste d'optimisations de boucle de ce qui est couramment vérifié par un compilateur (pensez-vous que vous pourriez le faire vous-même lorsque votre planning a été décidé pour un programme C #?) Si vous écrivez quelque chose en assembly, je pense que vous devez envisager au moins quelques optimisations simples . L'exemple de livre scolaire pour les tableaux consiste à dérouler le cycle (sa taille est connue au moment de la compilation). Faites-le et relancez votre test.

De nos jours, il est également très rare d'avoir besoin d'utiliser le langage d'assemblage pour une autre raison: la pléthore de processeurs différents . Voulez-vous tous les soutenir? Chacun a une microarchitecture spécifique et des jeux d'instructions spécifiques . Ils ont un nombre différent d'unités fonctionnelles et une notice de montage doivent être organisées pour les garder tous occupés . Si vous écrivez en C, vous pouvez utiliser PGO mais en assemblage, vous aurez alors besoin d'une grande connaissance de cette architecture spécifique (et repenser et tout refaire pour une autre architecture ). Pour les petites tâches du compilateur généralement fait mieux, et pour des tâches complexes habituellement le travail n'est pas remboursé (etcompilateur peut faire mieux de toute façon).

Si vous vous asseyez et que vous regardez votre code, vous verrez probablement que vous gagnerez plus à refondre votre algorithme qu'à traduire en assemblage (lisez cet excellent article ici sur SO ), il y a des optimisations de haut niveau (et conseils au compilateur) que vous pouvez appliquer efficacement avant de recourir au langage d'assemblage. Il vaut probablement la peine de mentionner que souvent, en utilisant des éléments intrinsèques, vous obtiendrez un gain de performances que vous recherchez et le compilateur pourra toujours effectuer la plupart de ses optimisations.

Cela dit, même si vous pouvez produire un code d'assemblage 5 à 10 fois plus rapide, vous devriez demander à vos clients s'ils préfèrent payer une semaine de votre temps ou acheter un processeur 50 $ plus rapide . L'optimisation extrême le plus souvent (et en particulier dans les applications LOB) n'est tout simplement pas requise de la plupart d'entre nous.

Votre code d'assemblage est sous-optimal et peut être amélioré:

• Vous poussez et sautez un registre ( EDX ) dans votre boucle intérieure. Cela devrait être retiré de la boucle.
• Vous rechargez les pointeurs de tableau à chaque itération de la boucle. Cela devrait sortir de la boucle.
• Vous utilisez l' loopinstruction, qui est connue pour être extrêmement lente sur la plupart des processeurs modernes (probablement en raison de l'utilisation d'un ancien livre d'assemblage *)
• Vous ne tirez aucun avantage du déroulement manuel des boucles.
• Vous n'utilisez pas les instructions SIMD disponibles .

Donc, à moins que vous n'amélioriez considérablement vos compétences en assembleur, cela n'a pas de sens pour vous d'écrire du code assembleur pour les performances.

* Bien sûr, je ne sais pas si vous avez vraiment reçu les loopinstructions d'un ancien livre de montage. Mais vous ne le voyez presque jamais dans le code du monde réel, car chaque compilateur est assez intelligent pour ne pas émettre loop, vous ne le voyez que dans des livres mauvais et obsolètes à mon humble avis.

Même avant de plonger dans l'assemblage, il existe des transformations de code qui existent à un niveau supérieur.

static int const TIMES = 100000;

void calcuC(int *x, int *y, int length) {
  for (int i = 0; i < TIMES; i++) {
    for (int j = 0; j < length; j++) {
      x[j] += y[j];
    }
  }
}

peut être transformé en via Loop Rotation :

static int const TIMES = 100000;

void calcuC(int *x, int *y, int length) {
    for (int j = 0; j < length; ++j) {
      for (int i = 0; i < TIMES; ++i) {
        x[j] += y[j];
      }
    }
}

ce qui est bien meilleur en ce qui concerne la localité mémoire.

Cela pourrait être optimisé davantage, faire a += bX fois équivaut à le faire a += X * b, nous obtenons:

static int const TIMES = 100000;

void calcuC(int *x, int *y, int length) {
    for (int j = 0; j < length; ++j) {
      x[j] += TIMES * y[j];
    }
}

cependant, il semble que mon optimiseur préféré (LLVM) n'effectue pas cette transformation.

[modifier] J'ai trouvé que la transformation est effectuée si nous avions le restrictqualificatif à xet y. En effet sans cette restriction, x[j]et y[j]pourrait alias au même emplacement ce qui rend cette transformation erronée. [fin de la modification]

, En tout cas c'est, je pense, la version optimisée C. C'est déjà beaucoup plus simple. Sur cette base, voici ma fissure chez ASM (je laisse Clang la générer, je suis inutile):

calcuAsm:                               # @calcuAsm
.Ltmp0:
    .cfi_startproc
# BB#0:
    testl   %edx, %edx
    jle .LBB0_2
    .align  16, 0x90
.LBB0_1:                                # %.lr.ph
                                        # =>This Inner Loop Header: Depth=1
    imull   $100000, (%rsi), %eax   # imm = 0x186A0
    addl    %eax, (%rdi)
    addq    $4, %rsi
    addq    $4, %rdi
    decl    %edx
    jne .LBB0_1
.LBB0_2:                                # %._crit_edge
    ret
.Ltmp1:
    .size   calcuAsm, .Ltmp1-calcuAsm
.Ltmp2:
    .cfi_endproc

J'ai peur de ne pas comprendre d'où viennent toutes ces instructions, mais vous pouvez toujours vous amuser et essayer de voir comment cela se compare ... mais j'utiliserais toujours la version optimisée C plutôt que l'assemblage, dans le code, beaucoup plus portable.

Réponse courte: oui.

Réponse longue: oui, à moins que vous ne sachiez vraiment ce que vous faites et que vous ayez une raison de le faire.

J'ai corrigé mon code asm:

  __asm
{   
    mov ebx,TIMES
 start:
    mov ecx,lengthOfArray
    mov esi,x
    shr ecx,1
    mov edi,y
label:
    movq mm0,QWORD PTR[esi]
    paddd mm0,QWORD PTR[edi]
    add edi,8
    movq QWORD PTR[esi],mm0
    add esi,8
    dec ecx 
    jnz label
    dec ebx
    jnz start
};

Résultats pour la version Release:

 Function of assembly version: 81
 Function of C++ version: 161

Le code d'assemblage en mode version est presque 2 fois plus rapide que le C ++.

Cela signifie-t-il que je ne devrais pas faire confiance aux performances du langage d'assemblage écrit par mes mains

Oui, c'est exactement ce que cela signifie, et c'est vrai pour toutes les langues. Si vous ne savez pas comment écrire du code efficace dans le langage X, vous ne devriez pas faire confiance à votre capacité à écrire du code efficace en X. Et donc, si vous voulez du code efficace, vous devriez utiliser un autre langage.

L'assemblage est particulièrement sensible à cela, car, eh bien, ce que vous voyez est ce que vous obtenez. Vous écrivez les instructions spécifiques que vous souhaitez que la CPU exécute. Avec les langages de haut niveau, il existe un compilateur entre deux, qui peut transformer votre code et supprimer de nombreuses inefficacités. Avec l'assemblage, vous êtes seul.

La seule raison d'utiliser le langage assembleur de nos jours est d'utiliser certaines fonctionnalités non accessibles par le langage.

Ceci s'applique à:

• Programmation du noyau qui a besoin d'accéder à certaines fonctionnalités matérielles telles que la MMU
• Programmation haute performance qui utilise des instructions vectorielles ou multimédias très spécifiques non prises en charge par votre compilateur.

Mais les compilateurs actuels sont assez intelligents, ils peuvent même remplacer deux instructions séparées comme d = a / b; r = a % b;par une seule instruction qui calcule la division et le reste en une seule fois si elle est disponible, même si C n'a pas un tel opérateur.

Il est vrai qu'un compilateur moderne fait un travail incroyable dans l'optimisation du code, mais je vous encourage tout de même à continuer à apprendre l'assemblage.

Tout d'abord, vous n'êtes clairement pas intimidé par cela , c'est un grand, un grand plus, ensuite - vous êtes sur la bonne voie en profilant afin de valider ou de rejeter vos hypothèses de vitesse , vous demandez l' avis de personnes expérimentées , et vous ont le plus grand outil d'optimisation connu de l'humanité: un cerveau .

Au fur et à mesure que votre expérience augmente, vous apprendrez quand et où l'utiliser (généralement les boucles les plus étroites et les plus internes de votre code, une fois que vous l'avez profondément optimisée au niveau algorithmique).

Pour vous inspirer, je vous recommande de consulter les articles de Michael Abrash (si vous n'avez pas entendu parler de lui, c'est un gourou de l'optimisation; il a même collaboré avec John Carmack dans l'optimisation du logiciel de rendu Quake!)

"le code le plus rapide n'existe pas" - Michael Abrash

J'ai changé le code asm:

 __asm
{ 
    mov ebx,TIMES
 start:
    mov ecx,lengthOfArray
    mov esi,x
    shr ecx,2
    mov edi,y
label:
    mov eax,DWORD PTR [esi]
    add eax,DWORD PTR [edi]
    add edi,4   
    dec ecx 
    mov DWORD PTR [esi],eax
    add esi,4
    test ecx,ecx
    jnz label
    dec ebx
    test ebx,ebx
    jnz start
};

Résultats pour la version Release:

 Function of assembly version: 41
 Function of C++ version: 161

Le code d'assemblage en mode version est presque 4 fois plus rapide que le C ++. IMHo, la vitesse du code d'assemblage dépend du programmeur

c'est un sujet très intéressant!
J'ai changé le MMX par SSE dans le code de Sasha
Voici mes résultats:

Function of C++ version:      315
Function of assembly(simply): 312
Function of assembly  (MMX):  136
Function of assembly  (SSE):  62

Le code d'assemblage avec SSE est 5 fois plus rapide que le C ++

La plupart des compilateurs de langages de haut niveau sont très optimisés et savent ce qu'ils font. Vous pouvez essayer de vider le code de désassemblage et le comparer avec votre assembly natif. Je crois que vous verrez quelques astuces intéressantes que votre compilateur utilise.

Juste par exemple, même si je ne suis plus sûr que ce soit juste :):

Faire:

mov eax,0

coûte plus de cycles que

xor eax,eax

qui fait la même chose.

Le compilateur connaît toutes ces astuces et les utilise.

Le compilateur vous a battu. Je vais essayer, mais je ne donnerai aucune garantie. Je suppose que la "multiplication" par TIMES est censée en faire un test de performance plus pertinent, qui yet xsont alignés sur 16, et c'est lengthun multiple non nul de 4. C'est probablement tout vrai de toute façon.

  mov ecx,length
  lea esi,[y+4*ecx]
  lea edi,[x+4*ecx]
  neg ecx
loop:
  movdqa xmm0,[esi+4*ecx]
  paddd xmm0,[edi+4*ecx]
  movdqa [edi+4*ecx],xmm0
  add ecx,4
  jnz loop

Comme je l'ai dit, je ne donne aucune garantie. Mais je serai surpris si cela peut être fait beaucoup plus rapidement - le goulot d'étranglement ici est le débit mémoire même si tout est un hit L1.

L'implémentation aveugle du même algorithme, instruction par instruction, dans l'assemblage est garantie d'être plus lente que ce que le compilateur peut faire.

C'est parce que même la plus petite optimisation faite par le compilateur est meilleure que votre code rigide sans aucune optimisation.

Bien sûr, il est possible de battre le compilateur, surtout s'il s'agit d'une petite partie localisée du code, j'ai même dû le faire moi-même pour obtenir un env. Vitesse 4x, mais dans ce cas, nous devons fortement nous fier à une bonne connaissance du matériel et à de nombreuses astuces apparemment contre-intuitives.

En tant que compilateur, je remplacerais une boucle de taille fixe pour de nombreuses tâches d'exécution.

int a = 10;
for (int i = 0; i < 3; i += 1) {
    a = a + i;
}

produira

int a = 10;
a = a + 0;
a = a + 1;
a = a + 2;

et finalement il saura que "a = a + 0;" est inutile donc il supprimera cette ligne. Espérons que quelque chose dans votre tête est maintenant prêt à joindre des options d'optimisation en commentaire. Toutes ces optimisations très efficaces rendront le langage compilé plus rapide.

C'est exactement ce que cela signifie. Laissez les micro-optimisations au compilateur.

J'adore cet exemple car il illustre une leçon importante sur le code de bas niveau. Oui, vous pouvez écrire un assembly aussi rapide que votre code C. C'est tautologiquement vrai, mais cela ne veut pas nécessairement dire quoi que ce soit. Il est clair que quelqu'un le peut, sinon l'assembleur ne connaîtrait pas les optimisations appropriées.

De même, le même principe s'applique lorsque vous montez dans la hiérarchie de l'abstraction du langage. Oui, vous pouvez écrire un analyseur en C aussi rapide qu'un script perl rapide et sale, et beaucoup de gens le font. Mais cela ne veut pas dire que parce que vous avez utilisé C, votre code sera rapide. Dans de nombreux cas, les langages de niveau supérieur effectuent des optimisations que vous n'avez peut-être même jamais envisagées.

Dans de nombreux cas, la manière optimale d'exécuter une tâche peut dépendre du contexte dans lequel la tâche est exécutée. Si une routine est écrite en langage d'assemblage, il ne sera généralement pas possible de faire varier la séquence d'instructions en fonction du contexte. À titre d'exemple simple, considérons la méthode simple suivante:

inline void set_port_high(void)
{
  (*((volatile unsigned char*)0x40001204) = 0xFF);
}

Un compilateur pour le code ARM 32 bits, étant donné ce qui précède, le rendrait probablement comme quelque chose comme:

ldr  r0,=0x40001204
mov  r1,#0
strb r1,[r0]
[a fourth word somewhere holding the constant 0x40001204]

ou peut-être

ldr  r0,=0x40001000  ; Some assemblers like to round pointer loads to multiples of 4096
mov  r1,#0
strb r1,[r0+0x204]
[a fourth word somewhere holding the constant 0x40001000]

Cela pourrait être légèrement optimisé dans un code assemblé à la main, comme:

ldr  r0,=0x400011FF
strb r0,[r0+5]
[a third word somewhere holding the constant 0x400011FF]

ou

mvn  r0,#0xC0       ; Load with 0x3FFFFFFF
add  r0,r0,#0x1200  ; Add 0x1200, yielding 0x400011FF
strb r0,[r0+5]

Les deux approches assemblées manuellement nécessiteraient 12 octets d'espace de code au lieu de 16; ce dernier remplacerait un "load" par un "add", qui sur un ARM7-TDMI exécuterait deux cycles plus rapidement. Si le code devait être exécuté dans un contexte où r0 était ne sait pas / ne se soucie pas, les versions en langage assembleur seraient donc un peu meilleures que la version compilée. D'un autre côté, supposons que le compilateur sache qu'un certain registre [par exemple r5] allait contenir une valeur qui était à moins de 2047 octets de l'adresse désirée 0x40001204 [par exemple 0x40001000], et savait en outre qu'un autre registre [par exemple r7] allait pour contenir une valeur dont les bits faibles étaient 0xFF. Dans ce cas, un compilateur pourrait optimiser la version C du code pour simplement:

strb r7,[r5+0x204]

Beaucoup plus court et plus rapide que même le code d'assemblage optimisé à la main. De plus, supposons que set_port_high se soit produit dans le contexte:

int temp = function1();
set_port_high();
function2(temp); // Assume temp is not used after this

Pas du tout invraisemblable lors du codage pour un système embarqué. Si set_port_highest écrit en code d'assemblage, le compilateur devrait déplacer r0 (qui contient la valeur de retour de function1) ailleurs avant d'appeler le code d'assemblage, puis déplacer cette valeur vers r0 par la suite (car function2attendra son premier paramètre dans r0), le code d'assemblage "optimisé" aurait donc besoin de cinq instructions. Même si le compilateur ne connaissait aucun registre contenant l'adresse ou la valeur à stocker, sa version à quatre instructions (qu'il pourrait adapter pour utiliser tous les registres disponibles - pas nécessairement r0 et r1) battrait l'assemblage "optimisé" -version linguistique. Si le compilateur avait l'adresse et les données nécessaires dans r5 et r7 comme décrit précédemment, instruction -function1 ne modifierait pas ces registres et pourrait donc remplacerset_port_highavec quatre instructions plus petites et plus rapides que le code d'assemblage «optimisé à la main».strb

Notez que le code d'assemblage optimisé à la main peut souvent surpasser un compilateur dans les cas où le programmeur connaît le déroulement précis du programme, mais les compilateurs brillent dans les cas où un morceau de code est écrit avant que son contexte ne soit connu, ou où un morceau de code source peut être invoqué à partir de plusieurs contextes [s'il set_port_highest utilisé à cinquante endroits différents dans le code, le compilateur pourrait décider indépendamment pour chacun de ceux-ci de la meilleure façon de l'étendre].

En général, je suggérerais que le langage assembleur est susceptible d'apporter les plus grandes améliorations de performances dans les cas où chaque morceau de code peut être approché à partir d'un nombre très limité de contextes, et est susceptible d'être préjudiciable aux performances dans les endroits où un morceau de le code peut être abordé dans de nombreux contextes différents. Fait intéressant (et pratique), les cas où l'assemblage est le plus bénéfique pour les performances sont souvent ceux où le code est le plus simple et le plus facile à lire. Les endroits où le code en langage assembleur se transformerait en un gâchis gluant sont souvent ceux où l'écriture en assembleur offrirait le plus petit avantage en termes de performances.

[Note mineure: il y a des endroits où le code d'assemblage peut être utilisé pour produire un désordre gluant hyper-optimisé; par exemple, un morceau de code que j'ai créé pour l'ARM avait besoin de récupérer un mot de la RAM et d'exécuter l'une des douze routines environ basées sur les six bits supérieurs de la valeur (de nombreuses valeurs mappées sur la même routine). Je pense que j'ai optimisé ce code pour quelque chose comme:

ldrh  r0,[r1],#2! ; Fetch with post-increment
ldrb  r1,[r8,r0 asr #10]
sub   pc,r8,r1,asl #2

Le registre r8 contenait toujours l'adresse de la table de répartition principale (dans la boucle où le code passe 98% de son temps, rien ne l'a jamais utilisé à d'autres fins); les 64 entrées se référaient à des adresses dans les 256 octets qui la précédaient. Étant donné que la boucle primaire avait dans la plupart des cas une limite de temps d'exécution stricte d'environ 60 cycles, la récupération et l'envoi de neuf cycles ont été très utiles pour atteindre cet objectif. Utiliser une table de 256 adresses 32 bits aurait été un cycle plus rapide, mais aurait englouti 1 Ko de RAM très précieuse [le flash aurait ajouté plus d'un état d'attente]. Utiliser 64 adresses 32 bits aurait nécessité l'ajout d'une instruction pour masquer certains bits du mot récupéré, et aurait encore englouti 192 octets de plus que la table que j'ai réellement utilisée. L'utilisation du tableau des décalages 8 bits a donné un code très compact et rapide, mais ce n'est pas quelque chose que j'attendrais d'un compilateur; Je ne m'attendrais pas non plus à ce qu'un compilateur consacre un registre «à plein temps» à la tenue de l'adresse de la table.

Le code ci-dessus a été conçu pour fonctionner comme un système autonome; il pouvait périodiquement appeler du code C, mais seulement à certains moments où le matériel avec lequel il communiquait pouvait être mis en toute sécurité dans un état «inactif» pendant deux intervalles d'environ une milliseconde toutes les 16 ms.

Ces derniers temps, toutes les optimisations de vitesse que j'ai faites remplaçaient le code lent endommagé par le cerveau par du code juste raisonnable. Mais pour les choses où la vitesse était vraiment critique et que je faisais de gros efforts pour faire quelque chose rapidement, le résultat était toujours un processus itératif, où chaque itération donnait plus d'informations sur le problème, trouvant des moyens de résoudre le problème avec moins d'opérations. La vitesse finale dépendait toujours de la compréhension que j'avais du problème. Si à un moment donné j'avais utilisé du code d'assemblage ou du code C suroptimisé, le processus de recherche d'une meilleure solution aurait souffert et le résultat final serait plus lent.

C ++ est plus rapide à moins que vous n'utilisiez le langage assembleur avec des connaissances plus approfondies de la manière correcte.

Lorsque je code dans ASM, je réorganise les instructions manuellement afin que le CPU puisse en exécuter davantage en parallèle lorsque cela est logiquement possible. J'utilise à peine la RAM lorsque je code en ASM, par exemple: il pourrait y avoir plus de 20000 lignes de code dans ASM et je n'ai jamais utilisé push / pop.

Vous pourriez potentiellement sauter au milieu de l'opcode pour auto-modifier le code et le comportement sans la pénalité possible d'un code auto-modifiable. L'accès aux registres prend 1 tick (prend parfois 0,25 ticks) du CPU. L'accès à la RAM peut prendre des centaines.

Pour ma dernière aventure ASM, je n'ai jamais utilisé la RAM pour stocker une variable (pour des milliers de lignes d'ASM). ASM pourrait être potentiellement inimaginablement plus rapide que C ++. Mais cela dépend de nombreux facteurs variables tels que:

1. I was writing my apps to run on the bare metal.
2. I was writing my own boot loader that was starting my programs in ASM so there was no OS management in the middle.

J'apprends maintenant C # et C ++ parce que j'ai réalisé que la productivité est importante !! Vous pouvez essayer de faire les programmes les plus rapides imaginables en utilisant l'ASM pur seul pendant le temps libre. Mais pour produire quelque chose, utilisez un langage de haut niveau.

Par exemple, le dernier programme que j'ai codé utilisait JS et GLSL et je n'ai jamais remarqué de problème de performance, même en parlant de JS qui est lent. En effet, le simple concept de programmation du GPU pour la 3D rend la vitesse du langage qui envoie les commandes au GPU presque sans importance.

La rapidité de l'assembleur seul sur le métal nu est irréfutable. Cela pourrait-il être encore plus lent en C ++? - Cela peut être dû au fait que vous écrivez du code d'assembly avec un compilateur n'utilisant pas d'assembleur pour commencer.

Mon conseil personnel est de ne jamais écrire de code d'assemblage si vous pouvez l'éviter, même si j'aime l'assemblage.

Toutes les réponses ici semblent exclure un aspect: parfois, nous n'écrivons pas de code pour atteindre un objectif spécifique, mais pour le simple plaisir . Il n'est peut-être pas économique d'investir du temps pour le faire, mais il n'y a sans doute pas de plus grande satisfaction que de battre l'extrait de code optimisé pour le compilateur le plus rapide en vitesse avec une alternative asm roulée manuellement.

Un compilateur C ++, après optimisation au niveau organisationnel, produirait du code qui utiliserait les fonctions intégrées du processeur ciblé. HLL ne dépassera ou ne surpassera jamais l'assembleur pour plusieurs raisons; 1.) HLL sera compilé et sorti avec le code Accessor, la vérification des limites et éventuellement intégré dans le ramasse-miettes (anciennement adressant la portée dans le maniérisme POO) nécessitant tous des cycles (flips et flops). HLL fait un excellent travail ces jours-ci (y compris le C ++ plus récent et d'autres comme GO), mais s'ils surpassent l'assembleur (à savoir votre code), vous devez consulter la documentation du processeur - les comparaisons avec du code bâclé sont très certainement peu concluantes et les langs compilés comme l'assembleur résolvent tous jusqu'au code opérationnel HLL fait abstraction des détails et ne les élimine pas, sinon votre application ne fonctionnera pas si elle est même reconnue par le système d'exploitation hôte.

La plupart du code assembleur (principalement des objets) sont générés en tant que «headless» pour être inclus dans d'autres formats exécutables avec beaucoup moins de traitement requis, donc il sera beaucoup plus rapide, mais beaucoup plus non sécurisé; si un exécutable est sorti par l'assembleur (NAsm, YAsm, etc.), il fonctionnera toujours plus rapidement jusqu'à ce qu'il corresponde complètement au code HLL dans la fonctionnalité, les résultats peuvent être pesés avec précision.

L'appel d'un objet de code basé sur l'assembleur à partir de HLL dans n'importe quel format ajoutera intrinsèquement une surcharge de traitement en plus des appels d'espace mémoire en utilisant la mémoire allouée globalement pour les types de données variables / constantes (cela s'applique à la fois à LLL et HLL). Rappelez-vous que la sortie finale utilise le CPU en fin de compte comme api et abi par rapport au matériel (opcode) et que les assembleurs et les "compilateurs HLL" sont essentiellement / fondamentalement identiques, la seule vraie exception étant la lisibilité (grammaticale).

L'application Hello world console dans l'assembleur utilisant FAsm fait 1,5 Ko (et c'est encore plus petit sous Windows sous FreeBSD et Linux) et surpasse tout ce que GCC peut lancer à son meilleur jour; les raisons sont le remplissage implicite avec nops, la validation d'accès et la vérification des limites pour n'en nommer que quelques-uns. Le véritable objectif est de nettoyer les bibliothèques HLL et un compilateur optimisable qui cible un processeur de manière "hardcore" et la plupart le font ces jours-ci (enfin). GCC n'est pas meilleur que YAsm - ce sont les pratiques de codage et la compréhension du développeur qui sont en question et «l'optimisation» vient après l'exploration novice et la formation et l'expérience intérimaires.

Les compilateurs doivent lier et assembler pour la sortie dans le même opcode qu'un assembleur parce que ces codes sont tout ce qu'un processeur fera à l'exception (CISC ou RISC [PIC aussi]). YAsm a beaucoup optimisé et nettoyé une grande partie des premiers NAsm, ce qui a finalement accéléré toutes les sorties de cet assembleur, mais même dans ce cas, YAsm, comme NAsm, produit des exécutables avec des dépendances externes ciblant les bibliothèques de système d'exploitation au nom du développeur, de sorte que le kilométrage peut varier. En conclusion, C ++ est à un point incroyable et beaucoup plus sûr que l'assembleur pour plus de 80%, en particulier dans le secteur commercial ...

L'assembly peut être plus rapide si votre compilateur génère beaucoup de code de support OO .

Éditer:

Aux votants négatifs: l'OP a écrit "dois-je ... me concentrer sur C ++ et oublier le langage assembleur?" et je maintiens ma réponse. Vous devez toujours garder un œil sur le code généré par OO, en particulier lors de l'utilisation de méthodes. Ne pas oublier le langage d'assemblage signifie que vous passerez périodiquement en revue l'assemblage généré par votre code OO, ce qui, à mon avis, est indispensable pour écrire des logiciels performants.

En fait, cela concerne tout le code compilable, pas seulement OO.