“切换”比“ if”快吗？

是一种switch说法实际上比更快的if声明？

我在带有/Ox标记的Visual Studio 2010的x64 C ++编译器上运行了以下代码：

#include <stdlib.h>
#include <stdio.h>
#include <time.h>

#define MAX_COUNT (1 << 29)
size_t counter = 0;

size_t testSwitch()
{
    clock_t start = clock();
    size_t i;
    for (i = 0; i < MAX_COUNT; i++)
    {
        switch (counter % 4 + 1)
        {
            case 1: counter += 4; break;
            case 2: counter += 3; break;
            case 3: counter += 2; break;
            case 4: counter += 1; break;
        }
    }
    return 1000 * (clock() - start) / CLOCKS_PER_SEC;
}

size_t testIf()
{
    clock_t start = clock();
    size_t i;
    for (i = 0; i < MAX_COUNT; i++)
    {
        const size_t c = counter % 4 + 1;
        if (c == 1) { counter += 4; }
        else if (c == 2) { counter += 3; }
        else if (c == 3) { counter += 2; }
        else if (c == 4) { counter += 1; }
    }
    return 1000 * (clock() - start) / CLOCKS_PER_SEC;
}

int main()
{
    printf("Starting...\n");
    printf("Switch statement: %u ms\n", testSwitch());
    printf("If     statement: %u ms\n", testIf());
}

并得到以下结果：

切换语句：5261 ms
如果语句：5196 ms

据我了解，switch语句显然使用跳转表来优化分支。

问题：

1. 在x86或x64中，基本的跳转表是什么样的？

2. 此代码是否使用跳转表？

3. 为什么在此示例中没有性能差异？有没有在其中有什么情况是一个显著的性能差异？

拆卸代码：

testIf:

13FE81B10 sub  rsp,48h 
13FE81B14 call qword ptr [__imp_clock (13FE81128h)] 
13FE81B1A mov  dword ptr [start],eax 
13FE81B1E mov  qword ptr [i],0 
13FE81B27 jmp  testIf+26h (13FE81B36h) 
13FE81B29 mov  rax,qword ptr [i] 
13FE81B2E inc  rax  
13FE81B31 mov  qword ptr [i],rax 
13FE81B36 cmp  qword ptr [i],20000000h 
13FE81B3F jae  testIf+0C3h (13FE81BD3h) 
13FE81B45 xor  edx,edx 
13FE81B47 mov  rax,qword ptr [counter (13FE835D0h)] 
13FE81B4E mov  ecx,4 
13FE81B53 div  rax,rcx 
13FE81B56 mov  rax,rdx 
13FE81B59 inc  rax  
13FE81B5C mov  qword ptr [c],rax 
13FE81B61 cmp  qword ptr [c],1 
13FE81B67 jne  testIf+6Dh (13FE81B7Dh) 
13FE81B69 mov  rax,qword ptr [counter (13FE835D0h)] 
13FE81B70 add  rax,4 
13FE81B74 mov  qword ptr [counter (13FE835D0h)],rax 
13FE81B7B jmp  testIf+0BEh (13FE81BCEh) 
13FE81B7D cmp  qword ptr [c],2 
13FE81B83 jne  testIf+89h (13FE81B99h) 
13FE81B85 mov  rax,qword ptr [counter (13FE835D0h)] 
13FE81B8C add  rax,3 
13FE81B90 mov  qword ptr [counter (13FE835D0h)],rax 
13FE81B97 jmp  testIf+0BEh (13FE81BCEh) 
13FE81B99 cmp  qword ptr [c],3 
13FE81B9F jne  testIf+0A5h (13FE81BB5h) 
13FE81BA1 mov  rax,qword ptr [counter (13FE835D0h)] 
13FE81BA8 add  rax,2 
13FE81BAC mov  qword ptr [counter (13FE835D0h)],rax 
13FE81BB3 jmp  testIf+0BEh (13FE81BCEh) 
13FE81BB5 cmp  qword ptr [c],4 
13FE81BBB jne  testIf+0BEh (13FE81BCEh) 
13FE81BBD mov  rax,qword ptr [counter (13FE835D0h)] 
13FE81BC4 inc  rax  
13FE81BC7 mov  qword ptr [counter (13FE835D0h)],rax 
13FE81BCE jmp  testIf+19h (13FE81B29h) 
13FE81BD3 call qword ptr [__imp_clock (13FE81128h)] 
13FE81BD9 sub  eax,dword ptr [start] 
13FE81BDD imul eax,eax,3E8h 
13FE81BE3 cdq       
13FE81BE4 mov  ecx,3E8h 
13FE81BE9 idiv eax,ecx 
13FE81BEB cdqe      
13FE81BED add  rsp,48h 
13FE81BF1 ret       

testSwitch:

13FE81C00 sub  rsp,48h 
13FE81C04 call qword ptr [__imp_clock (13FE81128h)] 
13FE81C0A mov  dword ptr [start],eax 
13FE81C0E mov  qword ptr [i],0 
13FE81C17 jmp  testSwitch+26h (13FE81C26h) 
13FE81C19 mov  rax,qword ptr [i] 
13FE81C1E inc  rax  
13FE81C21 mov  qword ptr [i],rax 
13FE81C26 cmp  qword ptr [i],20000000h 
13FE81C2F jae  testSwitch+0C5h (13FE81CC5h) 
13FE81C35 xor  edx,edx 
13FE81C37 mov  rax,qword ptr [counter (13FE835D0h)] 
13FE81C3E mov  ecx,4 
13FE81C43 div  rax,rcx 
13FE81C46 mov  rax,rdx 
13FE81C49 inc  rax  
13FE81C4C mov  qword ptr [rsp+30h],rax 
13FE81C51 cmp  qword ptr [rsp+30h],1 
13FE81C57 je   testSwitch+73h (13FE81C73h) 
13FE81C59 cmp  qword ptr [rsp+30h],2 
13FE81C5F je   testSwitch+87h (13FE81C87h) 
13FE81C61 cmp  qword ptr [rsp+30h],3 
13FE81C67 je   testSwitch+9Bh (13FE81C9Bh) 
13FE81C69 cmp  qword ptr [rsp+30h],4 
13FE81C6F je   testSwitch+0AFh (13FE81CAFh) 
13FE81C71 jmp  testSwitch+0C0h (13FE81CC0h) 
13FE81C73 mov  rax,qword ptr [counter (13FE835D0h)] 
13FE81C7A add  rax,4 
13FE81C7E mov  qword ptr [counter (13FE835D0h)],rax 
13FE81C85 jmp  testSwitch+0C0h (13FE81CC0h) 
13FE81C87 mov  rax,qword ptr [counter (13FE835D0h)] 
13FE81C8E add  rax,3 
13FE81C92 mov  qword ptr [counter (13FE835D0h)],rax 
13FE81C99 jmp  testSwitch+0C0h (13FE81CC0h) 
13FE81C9B mov  rax,qword ptr [counter (13FE835D0h)] 
13FE81CA2 add  rax,2 
13FE81CA6 mov  qword ptr [counter (13FE835D0h)],rax 
13FE81CAD jmp  testSwitch+0C0h (13FE81CC0h) 
13FE81CAF mov  rax,qword ptr [counter (13FE835D0h)] 
13FE81CB6 inc  rax  
13FE81CB9 mov  qword ptr [counter (13FE835D0h)],rax 
13FE81CC0 jmp  testSwitch+19h (13FE81C19h) 
13FE81CC5 call qword ptr [__imp_clock (13FE81128h)] 
13FE81CCB sub  eax,dword ptr [start] 
13FE81CCF imul eax,eax,3E8h 
13FE81CD5 cdq       
13FE81CD6 mov  ecx,3E8h 
13FE81CDB idiv eax,ecx 
13FE81CDD cdqe      
13FE81CDF add  rsp,48h 
13FE81CE3 ret       

更新：

这里有趣的结果。不过，不知道为什么一个更快，一个为什么慢。

编译器可以对开关进行几种优化。我不认为经常提到的“跳转表”是一个非常有用的表，因为它仅在可以某种方式限制输入时才起作用。

用于“跳转表”的C伪代码将类似于以下内容 -请注意，实际上，编译器需要在表周围插入某种形式的if测试，以确保输入在表中有效。还要注意，它仅在输入是连续数字的特定情况下才有效。

如果开关中的分支数量非常多，则编译器可以执行一些操作，例如对开关的值使用二进制搜索，（在我看来）这将是非常有用的优化，因为它确实可以显着提高某些应用程序的性能。场景，就像开关一样，不会导致生成的代码更大。但是要看到，您的测试代码将需要更多的分支才能看到任何区别。

要回答您的特定问题：

1. Clang生成一个看起来像这样的代码：

   test_switch(char):                       # @test_switch(char)
           movl    %edi, %eax
           cmpl    $19, %edi
           jbe     .LBB0_1
           retq
   .LBB0_1:
           jmpq    *.LJTI0_0(,%rax,8)
           jmp     void call<0u>()         # TAILCALL
           jmp     void call<1u>()         # TAILCALL
           jmp     void call<2u>()         # TAILCALL
           jmp     void call<3u>()         # TAILCALL
           jmp     void call<4u>()         # TAILCALL
           jmp     void call<5u>()         # TAILCALL
           jmp     void call<6u>()         # TAILCALL
           jmp     void call<7u>()         # TAILCALL
           jmp     void call<8u>()         # TAILCALL
           jmp     void call<9u>()         # TAILCALL
           jmp     void call<10u>()        # TAILCALL
           jmp     void call<11u>()        # TAILCALL
           jmp     void call<12u>()        # TAILCALL
           jmp     void call<13u>()        # TAILCALL
           jmp     void call<14u>()        # TAILCALL
           jmp     void call<15u>()        # TAILCALL
           jmp     void call<16u>()        # TAILCALL
           jmp     void call<17u>()        # TAILCALL
           jmp     void call<18u>()        # TAILCALL
           jmp     void call<19u>()        # TAILCALL
   .LJTI0_0:
           .quad   .LBB0_2
           .quad   .LBB0_3
           .quad   .LBB0_4
           .quad   .LBB0_5
           .quad   .LBB0_6
           .quad   .LBB0_7
           .quad   .LBB0_8
           .quad   .LBB0_9
           .quad   .LBB0_10
           .quad   .LBB0_11
           .quad   .LBB0_12
           .quad   .LBB0_13
           .quad   .LBB0_14
           .quad   .LBB0_15
           .quad   .LBB0_16
           .quad   .LBB0_17
           .quad   .LBB0_18
           .quad   .LBB0_19
           .quad   .LBB0_20
           .quad   .LBB0_21

2. 我可以说它没有使用跳转表-清晰可见4条比较指令：

   13FE81C51 cmp  qword ptr [rsp+30h],1 
   13FE81C57 je   testSwitch+73h (13FE81C73h) 
   13FE81C59 cmp  qword ptr [rsp+30h],2 
   13FE81C5F je   testSwitch+87h (13FE81C87h) 
   13FE81C61 cmp  qword ptr [rsp+30h],3 
   13FE81C67 je   testSwitch+9Bh (13FE81C9Bh) 
   13FE81C69 cmp  qword ptr [rsp+30h],4 
   13FE81C6F je   testSwitch+0AFh (13FE81CAFh) 

   基于跳转表的解决方案根本不使用比较。

3. 要么分支不足导致编译器生成跳转表，要么编译器根本不生成跳转表。我不确定是哪个。

EDIT 2014：熟悉LLVM优化器的人在其他地方进行了一些讨论，他们说跳转表优化在许多情况下都非常重要。例如，在存在具有许多值的枚举的情况下，以及针对所述枚举中的值的许多情况下。也就是说，我坚持我在2011年所说的话-我经常看到人们在想“如果我做出改变，无论我有多少案件，都是同一时间”-这完全是错误的。即使有了跳转表，您也可以获取间接跳转成本，并且需要为每种情况在表中支付条目。内存带宽是现代硬件上的大事。

编写代码以提高可读性。任何值得付出代价的编译器都会看到if / else if阶梯，并将其转换为等效的开关，反之亦然，如果这样做会更快。

对你的问题：

1，在x86或x64中基本跳转表是什么样的？

跳转表是内存地址，它以类似数组结构的形式保存指向标签的指针。以下示例将帮助您了解跳转表的布局方式

00B14538  D8 09 AB 00 D8 09 AB 00 D8 09 AB 00 D8 09 AB 00  Ø.«.Ø.«.Ø.«.Ø.«.
00B14548  D8 09 AB 00 D8 09 AB 00 D8 09 AB 00 00 00 00 00  Ø.«.Ø.«.Ø.«.....
00B14558  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00B14568  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

其中00B14538是指向Jump表的指针，而D8 09 AB 00之类的值表示标签指针。

2.此代码是否使用跳转表？ 在这种情况下不可以。

3，为什么这个例子没有性能差异？

由于两种情况的指令看起来相同，没有跳转表，因此没有性能差异。

4.是否存在性能差异显着的情况？

如果您有很长的if检查序列，那么在这种情况下，使用跳转表可以提高性能（如果分支/ jmp指令无法完美预测，则它们会很昂贵），但会带来内存成本。

所有比较指令的代码也具有一定的大小，因此，特别是对于32位指针或偏移量，单个跳转表查找可能不会在可执行文件中花费更多的大小。

结论：编译器足够聪明，可以处理这种情况并生成适当的指令:)

编译器可以自由地将switch语句编译为与if语句等效的代码，也可以创建跳转表。它可能会根据执行速度最快或生成最小代码的方式来选择另一个，具体取决于您在编译器选项中指定的内容-因此，最坏的情况是它与if语句的速度相同

我相信编译器会做出最佳选择，并专注于使代码更具可读性的方面。

如果案例数变得非常大，跳转表将比一系列if快得多。但是，如果值之间的步长很大，则跳转表可能会很大，并且编译器可能选择不生成一个。

您怎么知道您的计算机在切换测试循环中没有执行与测试无关的某些任务，而在if测试循环中没有执行更少的任务？您的测试结果未显示以下任何内容：

1. 差别很小
2. 只有一个结果，而不是一系列结果
3. 案例太少

我的结果：

我补充说：

printf("counter: %u\n", counter);

到最后，这样就不会优化循环，因为在您的示例中从未使用过计数器，那么为什么编译器会执行循环？立即，即使有了这样的微基准测试，切换始终是成功的。

您的代码的另一个问题是：

switch (counter % 4 + 1)

在您的切换循环中，

const size_t c = counter % 4 + 1; 

在您的if循环中。如果您解决此问题，将会有很大的不同。我认为，将语句放入switch语句会引起编译器将值直接发送到CPU寄存器中，而不是先将其放在堆栈中。因此，这有利于switch语句，而不是均衡的测试。

哦，我认为您还应该在两次测试之间重置计数器。实际上，您可能应该使用某种随机数而不是+ 1，+ 2，+ 3等，因为它可能会在那里优化某些内容。例如，所谓随机数，是指基于当前时间的数字。否则，编译器可能会将您的两个函数都变成一个冗长的数学运算，甚至不会打扰任何循环。

我已经对Ryan的代码进行了足够的修改，以确保编译器在代码运行之前无法弄清楚：

#include <stdlib.h>
#include <stdio.h>
#include <time.h>

#define MAX_COUNT (1 << 26)
size_t counter = 0;

long long testSwitch()
{
    clock_t start = clock();
    size_t i;
    for (i = 0; i < MAX_COUNT; i++)
    {
        const size_t c = rand() % 20 + 1;

        switch (c)
        {
                case 1: counter += 20; break;
                case 2: counter += 33; break;
                case 3: counter += 62; break;
                case 4: counter += 15; break;
                case 5: counter += 416; break;
                case 6: counter += 3545; break;
                case 7: counter += 23; break;
                case 8: counter += 81; break;
                case 9: counter += 256; break;
                case 10: counter += 15865; break;
                case 11: counter += 3234; break;
                case 12: counter += 22345; break;
                case 13: counter += 1242; break;
                case 14: counter += 12341; break;
                case 15: counter += 41; break;
                case 16: counter += 34321; break;
                case 17: counter += 232; break;
                case 18: counter += 144231; break;
                case 19: counter += 32; break;
                case 20: counter += 1231; break;
        }
    }
    return 1000 * (long long)(clock() - start) / CLOCKS_PER_SEC;
}

long long testIf()
{
    clock_t start = clock();
    size_t i;
    for (i = 0; i < MAX_COUNT; i++)
    {
        const size_t c = rand() % 20 + 1;
        if (c == 1) { counter += 20; }
        else if (c == 2) { counter += 33; }
        else if (c == 3) { counter += 62; }
        else if (c == 4) { counter += 15; }
        else if (c == 5) { counter += 416; }
        else if (c == 6) { counter += 3545; }
        else if (c == 7) { counter += 23; }
        else if (c == 8) { counter += 81; }
        else if (c == 9) { counter += 256; }
        else if (c == 10) { counter += 15865; }
        else if (c == 11) { counter += 3234; }
        else if (c == 12) { counter += 22345; }
        else if (c == 13) { counter += 1242; }
        else if (c == 14) { counter += 12341; }
        else if (c == 15) { counter += 41; }
        else if (c == 16) { counter += 34321; }
        else if (c == 17) { counter += 232; }
        else if (c == 18) { counter += 144231; }
        else if (c == 19) { counter += 32; }
        else if (c == 20) { counter += 1231; }
    }
    return 1000 * (long long)(clock() - start) / CLOCKS_PER_SEC;
}

int main()
{
    srand(time(NULL));
    printf("Starting...\n");
    printf("Switch statement: %lld ms\n", testSwitch()); fflush(stdout);
    printf("counter: %d\n", counter);
    counter = 0;
    srand(time(NULL));
    printf("If     statement: %lld ms\n", testIf()); fflush(stdout);
    printf("counter: %d\n", counter);
} 

开关：3740
如果：3980

（多次尝试的结果相似）

我还将案例/条件的数量减少到5，并且仍然可以使用切换功能。

一个好的优化编译器（例如MSVC）可以生成：

1. 一个简单的跳转表（如果案件安排在很长的范围内）
2. 如果有很多空白，则为稀疏（两级）跳转表
3. 一系列if，如果案例数少或值不接近
4. 如果情况代表几组间隔较近的范围，则使用上述方法的组合。

简而言之，如果该开关看起来比一系列ifs慢，则编译器可能会将其转换为一个。而且可能不仅是每种情况的比较序列，而且是二叉搜索树。请参阅此处的示例。

我将回答2）并提出一些一般性意见。2）不，您发布的汇编代码中没有跳转表。跳转表是跳转目标的表，是一条或两条指令直接从表跳转到索引位置的表。当有许多可能的切换目标时，跳转表会更有意义。除非目的地的数量大于某个阈值，否则优化器可能知道简单的逻辑，否则逻辑会更快。以20种可能性（而不是4种）再次尝试您的示例。

我很感兴趣，看了一下我可以对您的示例进行哪些更改，以使其更快地运行switch语句。

如果达到40条if语句并添加0大小写，则if块的运行将比等效的switch语句慢。我在这里得到结果：https : //www.ideone.com/KZeCz。

删除0大小写的效果可以在这里看到：https : //www.ideone.com/LFnrX。

以下是旧的（现在很难找到）bench ++基准测试的一些结果：

Test Name:   F000003                         Class Name:  Style
CPU Time:       0.781  nanoseconds           plus or minus     0.0715
Wall/CPU:        1.00  ratio.                Iteration Count:  1677721600
Test Description:
 Time to test a global using a 2-way if/else if statement
 compare this test with F000004

Test Name:   F000004                         Class Name:  Style
CPU Time:        1.53  nanoseconds           plus or minus     0.0767
Wall/CPU:        1.00  ratio.                Iteration Count:  1677721600
Test Description:
 Time to test a global using a 2-way switch statement
 compare this test with F000003

Test Name:   F000005                         Class Name:  Style
CPU Time:        7.70  nanoseconds           plus or minus      0.385
Wall/CPU:        1.00  ratio.                Iteration Count:  1677721600
Test Description:
 Time to test a global using a 10-way if/else if statement
 compare this test with F000006

Test Name:   F000006                         Class Name:  Style
CPU Time:        2.00  nanoseconds           plus or minus     0.0999
Wall/CPU:        1.00  ratio.                Iteration Count:  1677721600
Test Description:
 Time to test a global using a 10-way switch statement
 compare this test with F000005

Test Name:   F000007                         Class Name:  Style
CPU Time:        3.41  nanoseconds           plus or minus      0.171
Wall/CPU:        1.00  ratio.                Iteration Count:  1677721600
Test Description:
 Time to test a global using a 10-way sparse switch statement
 compare this test with F000005 and F000006

我们可以看到的是（在此计算机上，使用此编译器VC ++ 9.0 x64），每个if测试大约需要0.7纳秒。随着测试数量的增加，时间几乎完美地线性扩展。

使用switch语句时，只要值密集，则2路和10路测试之间的速度几乎没有差异。具有稀疏值的10向测试的时间大约是具有密集值的10向测试的时间的1.6倍-但是即使具有稀疏值，仍然比10维if/ 的速度快两倍else if。

底线：只使用了4路测试将不能真正告诉你很多关于性能switchVS if/ else。如果从这个代码从数字上看，这是很容易插了一个事实，一个4路测试，我们预计这两个产生非常相似的结果（〜2.8纳秒为if/ else，〜2.0 switch）。

请注意，当未将开关编译到跳转表时，您通常可以编写if，其效率要比开关高。

（1）如果案例是有序的，而不是针对所有N进行最坏情况的测试，则可以编写if来测试是在上半部分还是下半部分中进行测试，然后在每半部分中使用二进制搜索样式...导致最坏的情况是logN而不是N

（2）如果某些案例/组比其他案例更频繁，那么设计您的if来首先隔离那些案例可以加快平均时间

不，如果跳转，则跳转；否则，则跳转...跳转表将具有地址表或使用哈希或类似的内容。

快慢是主观的。例如，您可能将案例1放在最后而不是放在第一位，并且如果您的测试程序或真实程序在大多数情况下都使用案例1，则此实现会使代码变慢。因此，仅根据实施情况重新排列案例列表，就可以带来很大的不同。

如果您使用的是0-3而不是1-4，那么编译器可能已经使用了跳转表，那么编译器应该已经想出了删除+1的方法。也许是少数项目。例如，如果您将其设置为0-15或0-31，则可能是通过表实现的，或者使用了其他快捷方式。只要编译器满足源代码的功能，它就可以自由选择实现方式。这涉及到编译器差异，版本差异和优化差异。如果要跳转表，请创建一个跳转表，如果要使用if-then-else树，请创建一个if-then-else树。如果要由编译器决定，请使用switch / case语句。

不过，不知道为什么一个更快，一个更快。

实际上，这并不太难解释...如果您还记得错误预测的分支比正确预测的分支要贵数十到数百倍。

在该% 20版本中，第一种情况/如果始终是命中的情况。现代的CPU“学习”通常采用哪些分支，哪些不采用，因此它们可以轻松预测该分支在循环的几乎每次迭代中的行为。这就解释了为什么“ if”版本会流行；它不需要在第一次测试之后执行任何操作，并且（正确地）预测了大多数迭代的测试结果。显然，“开关”的实现略有不同-甚至是跳转表，由于计算出的分支，执行起来可能很慢。

在该% 21版本中，分支基本上是随机的。因此，它们中的许多不仅会在每次迭代中执行，而且CPU无法猜测它们将采用哪种方式。在这种情况下，跳转表（或其他“开关”优化）可能会有所帮助。

很难预测一段代码在现代编译器和CPU中的执行情况，并且每一代都会变得越来越困难。最好的建议是“甚至不要费劲尝试；始终进行配置”。该建议会越来越好-可以成功忽略它的人群每年都会减少。

所有这些都是说我在上面的解释在很大程度上是猜测。:-)

没有。在大多数特殊情况下，您进入汇编器并进行实际性能评估时，您的问题就是错误的。对于给定的示例，您的想法肯定太短了，因为

counter += (4 - counter % 4);

在我看来，这是您应该使用的正确增量表达式。