L'opérateur ternaire est deux fois plus lent qu'un bloc if-else?


246

J'ai lu partout que l'opérateur ternaire est censé être plus rapide que, ou au moins le même que son équivalent if-else bloc.

Cependant, j'ai fait le test suivant et j'ai découvert que ce n'était pas le cas:

Random r = new Random();
int[] array = new int[20000000];
for(int i = 0; i < array.Length; i++)
{
    array[i] = r.Next(int.MinValue, int.MaxValue);
}
Array.Sort(array);

long value = 0;
DateTime begin = DateTime.UtcNow;

foreach (int i in array)
{
    if (i > 0)
    {
        value += 2;
    }
    else
    {
        value += 3;
    }
    // if-else block above takes on average 85 ms

    // OR I can use a ternary operator:
    // value += i > 0 ? 2 : 3; // takes 157 ms
}
DateTime end = DateTime.UtcNow;
MessageBox.Show("Measured time: " + (end-begin).TotalMilliseconds + " ms.\r\nResult = " + value.ToString());

Mon ordinateur a mis 85 ms pour exécuter le code ci-dessus. Mais si je commente le if- elsemorceau et décommente la ligne d'opérateur ternaire, cela prendra environ 157 ms.

Pourquoi cela arrive-t-il?


96
Première chose à corriger: ne pas utiliser DateTimepour mesurer les performances. Utilisez Stopwatch. Ensuite, le temps est plus long - c'est un temps très court pour mesurer.
Jon Skeet

49
Utilisez une graine lorsque vous créez l' Randomobjet, afin qu'il donne toujours la même séquence. Si vous testez un code différent avec des données différentes, vous pouvez très bien voir les différences de performances.
Guffa

12
Avez-vous également essayé de le compiler / l'exécuter en mode de publication avec les optimisations du compilateur activées et sans le débogueur attaché?
Chris Sinclair

7
@ LarryOBrien: Prise intéressante. Je viens de faire un test LINQPad rapide et d'obtenir des résultats très différents avec le tableau trié ou non. En fait, avec elle triée je reproduis la même différence de vitesse rapportée. La suppression du tri supprime également le décalage horaire.
Chris Sinclair

39
Le point ici est que les microoptimisations de tests de performances sont difficiles . Pratiquement toutes les choses que vous observez dans votre résultat sont liées à des bogues dans votre code de test, et non à des différences dans le code significatif. Lorsque vous corrigerez ceux énumérés ici, il y en aura plus, je peux vous l'assurer. La morale de l'histoire, ne vous embêtez pas avec des microoptimisations ou essayez de les tester en premier lieu. Si le code est réellement difficile à mesurer, cela signifie qu'il n'est pas assez lent pour être un goulot d'étranglement; ignorez-le.
Servy

Réponses:


376

Pour répondre à cette question, nous examinerons le code assembleur produit par les JIT X86 et X64 pour chacun de ces cas.

X86, si / alors

    32:                 foreach (int i in array)
0000007c 33 D2                xor         edx,edx 
0000007e 83 7E 04 00          cmp         dword ptr [esi+4],0 
00000082 7E 1C                jle         000000A0 
00000084 8B 44 96 08          mov         eax,dword ptr [esi+edx*4+8] 
    33:                 {
    34:                     if (i > 0)
00000088 85 C0                test        eax,eax 
0000008a 7E 08                jle         00000094 
    35:                     {
    36:                         value += 2;
0000008c 83 C3 02             add         ebx,2 
0000008f 83 D7 00             adc         edi,0 
00000092 EB 06                jmp         0000009A 
    37:                     }
    38:                     else
    39:                     {
    40:                         value += 3;
00000094 83 C3 03             add         ebx,3 
00000097 83 D7 00             adc         edi,0 
0000009a 42                   inc         edx 
    32:                 foreach (int i in array)
0000009b 39 56 04             cmp         dword ptr [esi+4],edx 
0000009e 7F E4                jg          00000084 
    30:             for (int x = 0; x < iterations; x++)
000000a0 41                   inc         ecx 
000000a1 3B 4D F0             cmp         ecx,dword ptr [ebp-10h] 
000000a4 7C D6                jl          0000007C 

X86, ternaire

    59:                 foreach (int i in array)
00000075 33 F6                xor         esi,esi 
00000077 83 7F 04 00          cmp         dword ptr [edi+4],0 
0000007b 7E 2D                jle         000000AA 
0000007d 8B 44 B7 08          mov         eax,dword ptr [edi+esi*4+8] 
    60:                 {
    61:                     value += i > 0 ? 2 : 3;
00000081 85 C0                test        eax,eax 
00000083 7F 07                jg          0000008C 
00000085 BA 03 00 00 00       mov         edx,3 
0000008a EB 05                jmp         00000091 
0000008c BA 02 00 00 00       mov         edx,2 
00000091 8B C3                mov         eax,ebx 
00000093 8B 4D EC             mov         ecx,dword ptr [ebp-14h] 
00000096 8B DA                mov         ebx,edx 
00000098 C1 FB 1F             sar         ebx,1Fh 
0000009b 03 C2                add         eax,edx 
0000009d 13 CB                adc         ecx,ebx 
0000009f 89 4D EC             mov         dword ptr [ebp-14h],ecx 
000000a2 8B D8                mov         ebx,eax 
000000a4 46                   inc         esi 
    59:                 foreach (int i in array)
000000a5 39 77 04             cmp         dword ptr [edi+4],esi 
000000a8 7F D3                jg          0000007D 
    57:             for (int x = 0; x < iterations; x++)
000000aa FF 45 E4             inc         dword ptr [ebp-1Ch] 
000000ad 8B 45 E4             mov         eax,dword ptr [ebp-1Ch] 
000000b0 3B 45 F0             cmp         eax,dword ptr [ebp-10h] 
000000b3 7C C0                jl          00000075 

X64, si / alors

    32:                 foreach (int i in array)
00000059 4C 8B 4F 08          mov         r9,qword ptr [rdi+8] 
0000005d 0F 1F 00             nop         dword ptr [rax] 
00000060 45 85 C9             test        r9d,r9d 
00000063 7E 2B                jle         0000000000000090 
00000065 33 D2                xor         edx,edx 
00000067 45 33 C0             xor         r8d,r8d 
0000006a 4C 8B 57 08          mov         r10,qword ptr [rdi+8] 
0000006e 66 90                xchg        ax,ax 
00000070 42 8B 44 07 10       mov         eax,dword ptr [rdi+r8+10h] 
    33:                 {
    34:                     if (i > 0)
00000075 85 C0                test        eax,eax 
00000077 7E 07                jle         0000000000000080 
    35:                     {
    36:                         value += 2;
00000079 48 83 C5 02          add         rbp,2 
0000007d EB 05                jmp         0000000000000084 
0000007f 90                   nop 
    37:                     }
    38:                     else
    39:                     {
    40:                         value += 3;
00000080 48 83 C5 03          add         rbp,3 
00000084 FF C2                inc         edx 
00000086 49 83 C0 04          add         r8,4 
    32:                 foreach (int i in array)
0000008a 41 3B D2             cmp         edx,r10d 
0000008d 7C E1                jl          0000000000000070 
0000008f 90                   nop 
    30:             for (int x = 0; x < iterations; x++)
00000090 FF C1                inc         ecx 
00000092 41 3B CC             cmp         ecx,r12d 
00000095 7C C9                jl          0000000000000060 

X64, ternaire

    59:                 foreach (int i in array)
00000044 4C 8B 4F 08          mov         r9,qword ptr [rdi+8] 
00000048 45 85 C9             test        r9d,r9d 
0000004b 7E 2F                jle         000000000000007C 
0000004d 45 33 C0             xor         r8d,r8d 
00000050 33 D2                xor         edx,edx 
00000052 4C 8B 57 08          mov         r10,qword ptr [rdi+8] 
00000056 8B 44 17 10          mov         eax,dword ptr [rdi+rdx+10h] 
    60:                 {
    61:                     value += i > 0 ? 2 : 3;
0000005a 85 C0                test        eax,eax 
0000005c 7F 07                jg          0000000000000065 
0000005e B8 03 00 00 00       mov         eax,3 
00000063 EB 05                jmp         000000000000006A 
00000065 B8 02 00 00 00       mov         eax,2 
0000006a 48 63 C0             movsxd      rax,eax 
0000006d 4C 03 E0             add         r12,rax 
00000070 41 FF C0             inc         r8d 
00000073 48 83 C2 04          add         rdx,4 
    59:                 foreach (int i in array)
00000077 45 3B C2             cmp         r8d,r10d 
0000007a 7C DA                jl          0000000000000056 
    57:             for (int x = 0; x < iterations; x++)
0000007c FF C1                inc         ecx 
0000007e 3B CD                cmp         ecx,ebp 
00000080 7C C6                jl          0000000000000048 

Premièrement: pourquoi le code X86 tellement plus lent que X64?

Cela est dû aux caractéristiques suivantes du code:

  1. X64 a plusieurs registres supplémentaires disponibles, et chaque registre est de 64 bits. Cela permet au JIT X64 d'effectuer la boucle interne entièrement en utilisant des registres en plus du chargement à ipartir de la matrice, tandis que le JIT X86 place plusieurs opérations de pile (accès mémoire) dans la boucle.
  2. valueest un entier 64 bits, qui nécessite 2 instructions machine sur X86 ( addsuivies de adc) mais seulement 1 sur X64 ( add).

Deuxièmement: pourquoi l'opérateur ternaire est-il plus lent sur X86 et X64?

Cela est dû à une différence subtile dans l'ordre des opérations impactant l'optimiseur du JIT. Pour JIT l'opérateur ternaire, plutôt que de coder directement 2et 3dans les addinstructions de la machine elles-mêmes, le JIT crée une variable intermédiaire (dans un registre) pour contenir le résultat. Ce registre est ensuite étendu de 32 bits à 64 bits avant d'être ajouté à value. Étant donné que tout cela est effectué dans les registres pour X64, malgré l'augmentation significative de la complexité pour l'opérateur ternaire, l'impact net est quelque peu minimisé.

D'un autre côté, le X86 JIT est impacté car l'ajout d'une nouvelle valeur intermédiaire dans la boucle interne le fait "déborder" d'une autre valeur, ce qui entraîne au moins 2 accès mémoire supplémentaires dans la boucle interne (voir les accès pour [ebp-14h]le code ternaire X86).


18
Le compilateur pourrait tout aussi bien développer le ternaire en un if-else.
dezfowler

13
Notez que x86 n'est plus lent que lorsque vous utilisez ternaire - il est aussi rapide que x64 lorsque vous utilisez if / else . La question à laquelle répondre est donc: "pourquoi le code X86 est-il tellement plus lent que X64 lors de l'utilisation de l'opérateur ternaire?".
Eren Ersönmez

18
Il n'y a sûrement pas de bonne raison à cela et MS devrait le «réparer» - car Ternary n'est en fait qu'une syntaxe plus courte pour if / else?! Vous ne vous attendriez certainement pas à payer une pénalité de performance de toute façon.
niico

6
@niico il n'y a rien à «corriger» sur l'opérateur ternaire. son utilisation dans ce cas se produit juste pour provoquer une allocation de registre différente. Dans un autre cas, cela pourrait être plus rapide que si / sinon, comme j'ai essayé de l'expliquer dans ma réponse.
Eren Ersönmez

6
@ ErenErsönmez: Bien sûr, il y a quelque chose à réparer. L'équipe d'optimisation peut analyser soigneusement les deux cas et trouver un moyen de faire en sorte que l'opérateur ternaire, dans ce cas, soit aussi rapide que si autrement. Bien sûr, une telle solution peut être irréalisable ou trop coûteuse.
Brian

63

EDIT: Tout change ... voir ci-dessous.

Je ne peux pas reproduire vos résultats sur le x64 CLR, mais je peux le faire sur x86. Sur x64, je peux voir un petit différence (moins de 10%) entre l'opérateur conditionnel et le if / else, mais il est beaucoup plus petit que ce que vous voyez.

J'ai apporté les modifications potentielles suivantes:

  • Exécuter dans une application console
  • Construisez avec /o+ /debug-, et exécutez en dehors du débogueur
  • Exécutez les deux morceaux de code une fois pour les JIT, puis plusieurs fois pour plus de précision
  • Utilisation Stopwatch

Résultats avec /platform:x64(sans les lignes "ignorer"):

if/else with 1 iterations: 17ms
conditional with 1 iterations: 19ms
if/else with 1000 iterations: 17875ms
conditional with 1000 iterations: 19089ms

Résultats avec /platform:x86(sans les lignes "ignorer"):

if/else with 1 iterations: 18ms
conditional with 1 iterations: 49ms
if/else with 1000 iterations: 17901ms
conditional with 1000 iterations: 47710ms

Détails de mon système:

  • Processeur x64 i7-2720QM à 2,20 GHz
  • Windows 8 64 bits
  • .NET 4.5

Donc , contrairement à avant, je pense que vous êtes voyez une réelle différence - et il est tout à voir avec le x86 JIT. Je ne voudrais pas dire exactement quoi cause la différence - je pourrais mettre à jour le message plus tard avec plus de détails si je peux me donner la peine d'aller dans cordbg :)

Fait intéressant, sans trier d'abord le tableau, je me retrouve avec des tests qui prennent environ 4,5 fois plus longtemps, au moins sur x64. Je suppose que cela a à voir avec la prédiction de branche.

Code:

using System;
using System.Diagnostics;

class Test
{
    static void Main()
    {
        Random r = new Random(0);
        int[] array = new int[20000000];
        for(int i = 0; i < array.Length; i++)
        {
            array[i] = r.Next(int.MinValue, int.MaxValue);
        }
        Array.Sort(array);
        // JIT everything...
        RunIfElse(array, 1);
        RunConditional(array, 1);
        // Now really time it
        RunIfElse(array, 1000);
        RunConditional(array, 1000);
    }

    static void RunIfElse(int[] array, int iterations)
    {        
        long value = 0;
        Stopwatch sw = Stopwatch.StartNew();

        for (int x = 0; x < iterations; x++)
        {
            foreach (int i in array)
            {
                if (i > 0)
                {
                    value += 2;
                }
                else
                {
                    value += 3;
                }
            }
        }
        sw.Stop();
        Console.WriteLine("if/else with {0} iterations: {1}ms",
                          iterations,
                          sw.ElapsedMilliseconds);
        // Just to avoid optimizing everything away
        Console.WriteLine("Value (ignore): {0}", value);
    }

    static void RunConditional(int[] array, int iterations)
    {        
        long value = 0;
        Stopwatch sw = Stopwatch.StartNew();

        for (int x = 0; x < iterations; x++)
        {
            foreach (int i in array)
            {
                value += i > 0 ? 2 : 3;
            }
        }
        sw.Stop();
        Console.WriteLine("conditional with {0} iterations: {1}ms",
                          iterations,
                          sw.ElapsedMilliseconds);
        // Just to avoid optimizing everything away
        Console.WriteLine("Value (ignore): {0}", value);
    }
}

31
Donc, la question que tout le monde meurt d'envie de savoir, c'est pourquoi il y a même une toute petite différence.
Brad M

1
@BradM: Eh bien, l'IL sera différent, et toute différence pourrait faire toutes sortes de choses au moment où il est compilé en JIT, puis le CPU lui-même a fait des choses désagréables.
Jon Skeet

4
@JonSkeet FYI. a exécuté votre code, exactement comme vous l'avez expliqué. 19s contre 52s en x86, et 19s contre 21s en x64.
Eren Ersönmez

5
@ user1032613: Je peux maintenant reproduire vos résultats. Voir mon montage. Toutes mes excuses pour avoir douté de vous avant - c'est incroyable la différence qu'un changement d'architecture peut faire ...
Jon Skeet

3
@ BЈовић: En effet. Il a commencé par ne pas pouvoir le reproduire du tout, mais a évolué avec le temps. Cela ne donne pas la raison, mais je pensais que c'était toujours des informations utiles (par exemple la différence x64 vs x86), c'est pourquoi je l'ai laissé de côté.
Jon Skeet

43

La différence n'a vraiment pas grand-chose à voir avec if / else vs ternaire.

En regardant les démontages jitted (je ne vais pas répéter ici, veuillez voir la réponse de @ 280Z28), il s'avère que vous comparez des pommes et des oranges . Dans un cas, vous créez deux +=opérations différentes avec des valeurs constantes et celle que vous choisissez dépend d'une condition, et dans l'autre cas, vous créez un +=où la valeur à ajouter dépend d'une condition.

Si vous voulez vraiment comparer if / else vs ternaire, ce serait une comparaison plus juste (maintenant les deux seront également "lents", ou on pourrait même dire que le ternaire est un peu plus rapide):

int diff;
if (i > 0) 
    diff = 2;
else 
    diff = 3;
value += diff;

contre.

value += i > 0 ? 2 : 3;

Maintenant, le démontage du if/elsedevient comme indiqué ci-dessous. Notez que c'est un peu pire que le cas ternaire, car il a également cessé d'utiliser les registres pour la variable de boucle ( i).

                if (i > 0)
0000009d  cmp         dword ptr [ebp-20h],0 
000000a1  jle         000000AD 
                {
                    diff = 2;
000000a3  mov         dword ptr [ebp-24h],2 
000000aa  nop 
000000ab  jmp         000000B4 
                }
                else
                {
                    diff = 3;
000000ad  mov         dword ptr [ebp-24h],3 
                }
                value += diff;
000000b4  mov         eax,dword ptr [ebp-18h] 
000000b7  mov         edx,dword ptr [ebp-14h] 
000000ba  mov         ecx,dword ptr [ebp-24h] 
000000bd  mov         ebx,ecx 
000000bf  sar         ebx,1Fh 
000000c2  add         eax,ecx 
000000c4  adc         edx,ebx 
000000c6  mov         dword ptr [ebp-18h],eax 
000000c9  mov         dword ptr [ebp-14h],edx 
000000cc  inc         dword ptr [ebp-28h] 

5
Que diriez-vous de mettre l'accent sur la comparaison des pommes et des oranges ?
Ken Kin

6
Eh bien, je ne dirais pas vraiment que cela compare des pommes et des oranges. Les deux variantes ont la même sémantique , afin que l'optimiseur puisse essayer les deux variantes d'optimisation et choisir celle qui est la plus efficace dans les deux cas.
Vlad

J'ai fait le test comme vous l'avez suggéré: introduit une autre variable diff, mais ternaire est encore beaucoup plus lent - pas du tout ce que vous avez dit. Avez-vous fait l'expérience avant de poster cette "réponse"?
user1032613

9

Éditer:

Ajout d'un exemple qui peut être fait avec l'instruction if-else mais pas l'opérateur conditionnel.


Avant la réponse, veuillez jeter un œil à [ Quel est le plus rapide? ] sur le blog de M. Lippert. Et je pense que la réponse de M. Ersönmez est la plus juste ici.

J'essaie de mentionner quelque chose que nous devons garder à l'esprit avec un langage de programmation de haut niveau.

Tout d'abord, je n'ai jamais entendu dire que l'opérateur conditionnel est censé être plus rapide ou la même performance avec l'instruction if-else en C♯ .

La raison est simple: que faire s'il n'y a pas d'opération avec l'instruction if-else:

if (i > 0)
{
    value += 2;
}
else
{
}

L'exigence de l'opérateur conditionnel est qu'il doit y avoir une valeur de chaque côté, et en C♯, il faut également que les deux côtés de :aient le même type. Cela le rend juste différent de l'instruction if-else. Ainsi, votre question devient une question demandant comment l'instruction du code machine est générée pour que la différence de performance.

Avec l'opérateur conditionnel, sémantiquement c'est:

Quelle que soit l'expression évaluée, il y a une valeur.

Mais avec l'instruction if-else:

Si l'expression est évaluée à true, faites quelque chose; sinon, faites autre chose.

Une valeur n'est pas nécessairement impliquée dans l'instruction if-else. Votre hypothèse n'est possible qu'avec l'optimisation.

Un autre exemple pour démontrer la différence entre eux serait le suivant:

var array1=new[] { 1, 2, 3 };
var array2=new[] { 5, 6, 7 };

if(i>0)
    array1[1]=4;
else
    array2[2]=4;

le code ci-dessus compile, cependant, remplace l'instruction if-else par l'opérateur conditionnel ne compilera tout simplement pas:

var array1=new[] { 1, 2, 3 };
var array2=new[] { 5, 6, 7 };
(i>0?array1[1]:array2[2])=4; // incorrect usage 

L'opérateur conditionnel et les instructions if-else sont conceptuellement les mêmes lorsque vous faites la même chose, cela peut même être plus rapide avec l'opérateur conditionnel en C , car C est plus proche de l'assemblage de la plate-forme.


Pour le code d'origine que vous avez fourni, l'opérateur conditionnel est utilisé dans une boucle foreach, ce qui gâcherait les choses pour voir la différence entre eux. Je propose donc le code suivant:

public static class TestClass {
    public static void TestConditionalOperator(int i) {
        long value=0;
        value+=i>0?2:3;
    }

    public static void TestIfElse(int i) {
        long value=0;

        if(i>0) {
            value+=2;
        }
        else {
            value+=3;
        }
    }

    public static void TestMethod() {
        TestConditionalOperator(0);
        TestIfElse(0);
    }
}

et ce qui suit sont deux versions de l'IL optimisé et non. Puisqu'ils sont longs, j'utilise une image pour montrer, le côté droit est optimisé:

(Cliquez pour voir l'image en taille réelle.) hSN6s.png

Dans les deux versions de code, l'IL de l'opérateur conditionnel semble plus court que l'instruction if-else, et il existe toujours un doute sur le code machine finalement généré. Voici les instructions des deux méthodes, et l'ancienne image n'est pas optimisée, la dernière est optimisée:

  • Instructions non optimisées: (Cliquez pour voir l'image en taille réelle.) ybhgM.png

  • Instructions optimisées: (Cliquez pour voir l'image en taille réelle.) 6kgzJ.png

Dans ce dernier, le bloc jaune est le code exécuté uniquement si i<=0, et le bloc bleu est quand i>0. Dans l'une ou l'autre version des instructions, l'instruction if-else est plus courte.

Notez que, pour des instructions différentes, le [ CPI ] n'est pas nécessairement le même. Logiquement, pour une instruction identique, plus d'instructions coûtent un cycle plus long. Mais si le temps de récupération des instructions et le canal / cache étaient également pris en compte, le temps total réel d'exécution dépend du processeur. Le processeur peut également prédire les branches.

Les processeurs modernes ont encore plus de cœurs, les choses peuvent être plus complexes avec cela. Si vous étiez un utilisateur de processeur Intel, vous voudrez peut-être consulter le [ Manuel de référence de l'optimisation des architectures Intel® 64 et IA-32 ].

Je ne sais pas s'il y avait un CLR implémenté par le matériel, mais si oui, vous obtenez probablement plus rapidement avec l'opérateur conditionnel car l'IL est évidemment moindre.

Remarque: Tous les codes machine sont de x86.


7

J'ai fait ce que Jon Skeet a fait et j'ai effectué 1 itération et 1 000 itérations et j'ai obtenu un résultat différent à la fois pour OP et Jon. Dans le mien, le ternaire est légèrement plus rapide. Voici le code exact:

static void runIfElse(int[] array, int iterations)
    {
        long value = 0;
        Stopwatch ifElse = new Stopwatch();
        ifElse.Start();
        for (int c = 0; c < iterations; c++)
        {
            foreach (int i in array)
            {
                if (i > 0)
                {
                    value += 2;
                }
                else
                {
                    value += 3;
                }
            }
        }
        ifElse.Stop();
        Console.WriteLine(String.Format("Elapsed time for If-Else: {0}", ifElse.Elapsed));
    }

    static void runTernary(int[] array, int iterations)
    {
        long value = 0;
        Stopwatch ternary = new Stopwatch();
        ternary.Start();
        for (int c = 0; c < iterations; c++)
        {
            foreach (int i in array)
            {
                value += i > 0 ? 2 : 3;
            }
        }
        ternary.Stop();


        Console.WriteLine(String.Format("Elapsed time for Ternary: {0}", ternary.Elapsed));
    }

    static void Main(string[] args)
    {
        Random r = new Random();
        int[] array = new int[20000000];
        for (int i = 0; i < array.Length; i++)
        {
            array[i] = r.Next(int.MinValue, int.MaxValue);
        }
        Array.Sort(array);

        long value = 0;

        runIfElse(array, 1);
        runTernary(array, 1);
        runIfElse(array, 1000);
        runTernary(array, 1000);
        
        Console.ReadLine();
    }

La sortie de mon programme:

Temps écoulé pour If-Else: 00: 00: 00.0140543

Temps écoulé pour Ternary: 00: 00: 00.0136723

Temps écoulé pour If-Else: 00: 00: 14.0167870

Temps écoulé pour Ternary: 00: 00: 13.9418520

Une autre course en millisecondes:

Temps écoulé pour If-Else: 20

Temps écoulé pour Ternary: 19

Temps écoulé pour If-Else: 13854

Temps écoulé pour Ternary: 13610

Cela fonctionne sous XP 64 bits, et j'ai couru sans débogage.

Édition - Exécution en x86:

Il y a une grande différence avec x86. Cela a été fait sans débogage sur et sur la même machine xp 64 bits qu'avant, mais conçu pour les processeurs x86. Cela ressemble plus à des OP.

Temps écoulé pour If-Else: 18

Temps écoulé pour Ternary: 35

Temps écoulé pour If-Else: 20512

Temps écoulé pour Ternary: 32673


Pourriez-vous s'il vous plaît l'essayer sur x86? Merci.
user1032613

@ user1032613 Je pense qu'il peut y avoir une grande différence si vous exécutez sans débogage vs avec débogage.
CodeCamper

@ user1032613 Je viens de modifier mon article avec des données de x86. Il ressemble plus au vôtre, où le ternaire est 2x plus lent.
Shaz

5

Le code assembleur généré racontera l'histoire:

a = (b > c) ? 1 : 0;

Génère:

mov  edx, DWORD PTR a[rip]
mov  eax, DWORD PTR b[rip]
cmp  edx, eax
setg al

Tandis que:

if (a > b) printf("a");
else printf("b");

Génère:

mov edx, DWORD PTR a[rip]
mov eax, DWORD PTR b[rip]
cmp edx, eax
jle .L4
    ;printf a
jmp .L5
.L4:
    ;printf b
.L5:

Ainsi, le ternaire peut être plus court et plus rapide simplement en raison de l'utilisation de moins d'instructions et d'aucun saut si vous recherchez vrai / faux. Si vous utilisez des valeurs autres que 1 et 0, vous obtiendrez le même code qu'un if / else, par exemple:

a = (b > c) ? 2 : 3;

Génère:

mov edx, DWORD PTR b[rip]
mov eax, DWORD PTR c[rip]
cmp edx, eax
jle .L6
    mov eax, 2
jmp .L7
.L6:
    mov eax, 3
.L7:

Ce qui est le même que le if / else.


4

Exécuter sans déboguer ctrl + F5, il semble que le débogueur ralentisse significativement ifs et ternaire, mais il semble qu'il ralentisse beaucoup plus l'opérateur ternaire.

Lorsque j'exécute le code suivant, voici mes résultats. Je pense que la petite différence de millisecondes est causée par le compilateur optimisant le max = max et le supprimant, mais ne fait probablement pas cette optimisation pour l'opérateur ternaire. Si quelqu'un pouvait vérifier l'assemblage et le confirmer, ce serait génial.

--Run #1--
Type   | Milliseconds
Ternary 706
If     704
%: .9972
--Run #2--
Type   | Milliseconds
Ternary 707
If     704
%: .9958
--Run #3--
Type   | Milliseconds
Ternary 706
If     704
%: .9972

Code

  for (int t = 1; t != 10; t++)
        {
            var s = new System.Diagnostics.Stopwatch();
            var r = new Random(123456789);   //r
            int[] randomSet = new int[1000]; //a
            for (int i = 0; i < 1000; i++)   //n
                randomSet[i] = r.Next();     //dom
            long _ternary = 0; //store
            long _if = 0;      //time
            int max = 0; //result
            s.Start();
            for (int q = 0; q < 1000000; q++)
            {
                for (int i = 0; i < 1000; i++)
                    max = max > randomSet[i] ? max : randomSet[i];
            }
            s.Stop();
            _ternary = s.ElapsedMilliseconds;
            max = 0;
            s = new System.Diagnostics.Stopwatch();
            s.Start();
            for (int q = 0; q < 1000000; q++)
            {
                for (int i = 0; i < 1000; i++)
                    if (max > randomSet[i])
                        max = max; // I think the compiler may remove this but not for the ternary causing the speed difference.
                    else
                        max = randomSet[i];
            }

            s.Stop();
            _if = s.ElapsedMilliseconds;
            Console.WriteLine("--Run #" + t+"--");
            Console.WriteLine("Type   | Milliseconds\nTernary {0}\nIf     {1}\n%: {2}", _ternary, _if,((decimal)_if/(decimal)_ternary).ToString("#.####"));
        }

4

En regardant l'IL généré, il y a 16 opérations de moins dans cela que dans l'instruction if / else (copier et coller le code de @ JonSkeet). Cependant, cela ne signifie pas que ce devrait être un processus plus rapide!

Pour résumer les différences dans IL, la méthode if / else se traduit à peu près de la même manière que le code C # lit (effectuant l'ajout dans la branche) tandis que le code conditionnel charge 2 ou 3 sur la pile (selon la valeur) et l'ajoute ensuite à la valeur en dehors du conditionnel.

L'autre différence est l'instruction de branchement utilisée. La méthode if / else utilise une brtrue (branch if true) pour sauter par-dessus la première condition, et une branche inconditionnelle pour sauter de la première sortie de l'instruction if. Le code conditionnel utilise un bgt (branche si supérieur à) au lieu d'un brtrue, ce qui pourrait éventuellement être une comparaison plus lente.

De plus (après avoir simplement lu sur la prédiction de branche), il peut y avoir une pénalité de performance pour la branche plus petite. La branche conditionnelle a seulement 1 instruction dans la branche mais le if / else en a 7. Cela expliquerait également pourquoi il y a une différence entre utiliser long et int, car le passage à un int réduit le nombre d'instructions dans les branches if / else de 1 (réduisant la lecture anticipée)


1

Dans le code suivant, if / else semble être environ 1,4 fois plus rapide que l'opérateur ternaire. Cependant, j'ai trouvé que l'introduction d'une variable temporaire diminue le temps d'exécution de l'opérateur ternaire d'environ 1,4 fois:

Si / Sinon: 98 ms

Ternaire: 141 ms

Ternaire avec var. Temp: 100 ms

using System;
using System.Diagnostics;

namespace ConsoleApplicationTestIfElseVsTernaryOperator
{
    class Program
    {
        static void Main(string[] args)
        {
            Random r = new Random(0);
            int[] array = new int[20000000];
            for (int i = 0; i < array.Length; i++)
            {
                array[i] = r.Next(int.MinValue, int.MaxValue);
            }
            Array.Sort(array);
            long value;
            Stopwatch stopwatch = new Stopwatch();

            value = 0;
            stopwatch.Restart();
            foreach (int i in array)
            {
                if (i > 0)
                {
                    value += 2;
                }
                else
                {
                    value += 3;
                }
                // 98 ms
            }
            stopwatch.Stop();
            Console.WriteLine("If/Else: " + stopwatch.ElapsedMilliseconds.ToString() + " ms");

            value = 0;
            stopwatch.Restart();
            foreach (int i in array)
            {
                value += (i > 0) ? 2 : 3; 
                // 141 ms
            }

            stopwatch.Stop();
            Console.WriteLine("Ternary: " + stopwatch.ElapsedMilliseconds.ToString() + " ms");

            value = 0;
            int tempVar = 0;
            stopwatch.Restart();
            foreach (int i in array)
            {
                tempVar = (i > 0) ? 2 : 3;
                value += tempVar; 
                // 100ms
            }
            stopwatch.Stop();
            Console.WriteLine("Ternary with temp var: " + stopwatch.ElapsedMilliseconds.ToString() + " ms");

            Console.ReadKey(true);
        }
    }
}

0

Trop de bonnes réponses mais j'ai trouvé quelque chose d'intéressant, des changements très simples font l'impact. Après avoir effectué le changement ci-dessous, pour exécuter l'opérateur if-else et ternaire, cela prendra le même temps.

au lieu d'écrire sous la ligne

value +=  i > 0 ? 2 : 3;

J'ai utilisé ça,

int a =  i > 0 ? 2 : 3;
value += a;

L'une des réponses ci-dessous mentionne également que ce qui est une mauvaise façon d'écrire un opérateur ternaire.

J'espère que cela vous aidera à écrire l'opérateur ternaire, au lieu de penser à celui qui est le meilleur.

Opérateur ternaire imbriqué: J'ai trouvé un opérateur ternaire imbriqué et plusieurs blocs if else prendront également le même temps pour s'exécuter.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.