我在某个论坛中遇到过这段代码：
if ( a * b * c * d == 0 ) ....
并且所有者声称这比
快一点 if (a == 0 || b == 0 || c == 0 || d == 0)
这些变量定义为：
int a, b, c, d;
它们的绝对值保证小于或等于100.（所以我们可以忽略溢出的可能性）
如果我们忽略readability而只关注效果，声明是否真的正确？
在我看来，第二种方法可能实际上更快，因为你有时可以利用“短路”。但那么，我知道什么？！
答案 0 :(得分：9)
C标准没有提及性能。是否
的问题if ( a * b * c * d == 0 )
比
快if (a == 0 || b == 0 || c == 0 || d == 0)
在特定编译器的上下文中是有意义的 ，生成在特定计算机上运行的代码。比较它们的唯一真正方法是衡量您自己的系统或您感兴趣的任何系统的性能。
尽管如此，我们仍可以猜测性能可能是什么。
正如您所说，a，b，c和d是int类型的对象。你还说它们在[-100，+ 100]的范围内 - 但是编译器不一定知道。
编译器可以使用执行相同操作的代码替换任何表达式。
乘法是一种相对复杂的操作，并且可能比添加或比较慢。如果四个变量中的任何一个具有值0，则编译器可以识别出第一个条件为真，并将乘法替换为更快的变量。但是编译器执行的每个优化都必须由编译器的开发人员明确编程，并且这种特定的模式不太可能足以让它值得识别它。
你说这些值足够小，溢出不是问题。事实上，你不能移植做出这个假设; INT_MAX可以与32767一样小。但编译器知道int在它生成代码的系统上有多大。尽管如此，除非它有关于a，b，c和d的值的信息，否则它不能假设不会有溢出。
除了是，实际上，可以做出这个假设。有符号整数溢出的行为未定义。这给了一个优化编译器的权限，可以假设不会发生溢出（如果有的话，程序展示的任何行为无论如何都是有效的。）
所以是的，编译器可以用更简单的东西替换乘法，但它不太可能这样做。
至于另一个表达式a == 0 || b == 0 || c == 0 || d == 0，||运算符具有短路语义;如果左操作数为真（非零），则不评估右操作数。由于CPU管道问题，这种条件代码可能会产生性能问题。由于没有任何子表达式具有副作用（假设没有变量被声明为volatile），编译器可以评估所有四个子表达式，可能是并行的，如果它更快。
快速实验表明x86的gcc -O3不会执行 优化。对于第一个表达式，它生成执行三次乘法的代码。对于第二个，它生成条件分支，实现规范的短路评估（我不知道是否避免更快或更快）。
最好的办法是编写尽可能简单的合理代码，因为它可以使您的源代码更易于阅读和维护，并且因为它可能为编译器提供更好的识别模式和执行优化的机会。如果您尝试在源代码中进行精确的微优化，则可能会妨碍编译器的优化，因为您需要提供帮助。
不要过分担心代码的速度，除非你已经测量过它并发现它太慢了。如果您需要更快的代码，首先要专注于改进的算法和数据结构。只有在失败的情况下，才考虑源级微优化。
程序优化的第一条规则：不要这样做。程序优化的第二条规则（仅限专家！）：不要这样做。
答案 1 :(得分：8)
这两者并不相同。例如，在我的机器上（32位x86 MSVC），如果a，b，c和d都等于0x100，那么第一个测试将通过，但第二个条件不会。
另请注意，乘法是一项代价高昂的操作，因此第一个版本不一定会更快。
编辑：为第一个版本生成的代码：
00401000 8B 44 24 04 mov eax,dword ptr [esp+4]
00401004 0F AF 44 24 08 imul eax,dword ptr [esp+8]
00401009 0F AF 44 24 0C imul eax,dword ptr [esp+0Ch]
0040100E 0F AF 44 24 10 imul eax,dword ptr [esp+10h]
00401013 85 C0 test eax,eax
00401015 75 07 jne f1+1Eh (40101Eh)
00401017 ...
为第二个版本生成的代码：
00401020 83 7C 24 04 00 cmp dword ptr [esp+4],0
00401025 74 15 je f2+1Ch (40103Ch)
00401027 83 7C 24 08 00 cmp dword ptr [esp+8],0
0040102C 74 0E je f2+1Ch (40103Ch)
0040102E 83 7C 24 0C 00 cmp dword ptr [esp+0Ch],0
00401033 74 07 je f2+1Ch (40103Ch)
00401035 83 7C 24 10 00 cmp dword ptr [esp+10h],0
0040103A 75 07 jne f2+23h (401043h)
0040103C ...
我的机器上的基准测试（以纳秒为单位）：第一个版本在大约1.83 ns内运行，第二个版本在大约1.39 ns内运行。 a，b，c和d的值在每次运行期间没有变化，因此显然分支预测器可以预测100％的分支。
答案 2 :(得分：1)
与往常一样，更快的问题是，到目前为止你尝试了什么？你编译和反汇编，看看会发生什么？
unsigned int mfun ( unsigned int a, unsigned int b, unsigned int c, unsigned int d )
{
if ( a * b * c * d == 0 ) return(7);
else return(11);
}
unsigned int ofun ( unsigned int a, unsigned int b, unsigned int c, unsigned int d )
{
if (a == 0 || b == 0 || c == 0 || d == 0) return(7);
else return(11);
}
for arm one编译器给出了这个
00000000 <mfun>:
0: e0010190 mul r1, r0, r1
4: e0020291 mul r2, r1, r2
8: e0110293 muls r1, r3, r2
c: 13a0000b movne r0, #11
10: 03a00007 moveq r0, #7
14: e12fff1e bx lr
00000018 <ofun>:
18: e3500000 cmp r0, #0
1c: 13510000 cmpne r1, #0
20: 0a000004 beq 38 <ofun+0x20>
24: e3520000 cmp r2, #0
28: 13530000 cmpne r3, #0
2c: 13a0000b movne r0, #11
30: 03a00007 moveq r0, #7
34: e12fff1e bx lr
38: e3a00007 mov r0, #7
3c: e12fff1e bx lr
因此等于和等于短路（这本身就很昂贵）但是最差的路径需要更长的时间，因此性能不稳定，乘法性能更具确定性且不那么不稳定。通过检查，上述代码的乘法解决方案应该更快。
mips给了我这个
00000000 <mfun>:
0: 00a40018 mult a1,a0
4: 00002012 mflo a0
...
10: 00860018 mult a0,a2
14: 00002012 mflo a0
...
20: 00870018 mult a0,a3
24: 00002012 mflo a0
28: 10800003 beqz a0,38 <mfun+0x38>
2c: 00000000 nop
30: 03e00008 jr ra
34: 2402000b li v0,11
38: 03e00008 jr ra
3c: 24020007 li v0,7
00000040 <ofun>:
40: 10800009 beqz a0,68 <ofun+0x28>
44: 00000000 nop
48: 10a00007 beqz a1,68 <ofun+0x28>
4c: 00000000 nop
50: 10c00005 beqz a2,68 <ofun+0x28>
54: 00000000 nop
58: 10e00003 beqz a3,68 <ofun+0x28>
5c: 00000000 nop
60: 03e00008 jr ra
64: 2402000b li v0,11
68: 03e00008 jr ra
6c: 24020007 li v0,7
除非分支机构成本太高，否则等于和现在看起来更快。
Openrisc 32
00000000 <mfun>:
0: e0 64 1b 06 l.mul r3,r4,r3
4: e0 a3 2b 06 l.mul r5,r3,r5
8: e0 c5 33 06 l.mul r6,r5,r6
c: bc 26 00 00 l.sfnei r6,0x0
10: 0c 00 00 04 l.bnf 20 <mfun+0x20>
14: 9d 60 00 0b l.addi r11,r0,0xb
18: 44 00 48 00 l.jr r9
1c: 15 00 00 00 l.nop 0x0
20: 44 00 48 00 l.jr r9
24: 9d 60 00 07 l.addi r11,r0,0x7
00000028 <ofun>:
28: e0 e0 20 02 l.sub r7,r0,r4
2c: e0 87 20 04 l.or r4,r7,r4
30: bd 64 00 00 l.sfgesi r4,0x0
34: 10 00 00 10 l.bf 74 <ofun+0x4c>
38: e0 80 18 02 l.sub r4,r0,r3
3c: e0 64 18 04 l.or r3,r4,r3
40: bd 63 00 00 l.sfgesi r3,0x0
44: 10 00 00 0c l.bf 74 <ofun+0x4c>
48: e0 60 30 02 l.sub r3,r0,r6
4c: e0 c3 30 04 l.or r6,r3,r6
50: bd 66 00 00 l.sfgesi r6,0x0
54: 10 00 00 08 l.bf 74 <ofun+0x4c>
58: e0 60 28 02 l.sub r3,r0,r5
5c: e0 a3 28 04 l.or r5,r3,r5
60: bd 85 00 00 l.sfltsi r5,0x0
64: 0c 00 00 04 l.bnf 74 <ofun+0x4c>
68: 9d 60 00 0b l.addi r11,r0,0xb
6c: 44 00 48 00 l.jr r9
70: 15 00 00 00 l.nop 0x0
74: 44 00 48 00 l.jr r9
78: 9d 60 00 07 l.addi r11,r0,0x7
这取决于乘法的实现，如果它是一个时钟，那么乘法就有它。
如果你的硬件不支持乘法，那么你必须打电话让它模拟
00000000 <mfun>:
0: 0b 12 push r11
2: 0a 12 push r10
4: 09 12 push r9
6: 09 4d mov r13, r9
8: 0b 4c mov r12, r11
a: 0a 4e mov r14, r10
c: 0c 4f mov r15, r12
e: b0 12 00 00 call #0x0000
12: 0a 4e mov r14, r10
14: 0c 49 mov r9, r12
16: b0 12 00 00 call #0x0000
1a: 0a 4e mov r14, r10
1c: 0c 4b mov r11, r12
1e: b0 12 00 00 call #0x0000
22: 0e 93 tst r14
24: 06 24 jz $+14 ;abs 0x32
26: 3f 40 0b 00 mov #11, r15 ;#0x000b
2a: 39 41 pop r9
2c: 3a 41 pop r10
2e: 3b 41 pop r11
30: 30 41 ret
32: 3f 40 07 00 mov #7, r15 ;#0x0007
36: 39 41 pop r9
38: 3a 41 pop r10
3a: 3b 41 pop r11
3c: 30 41 ret
0000003e <ofun>:
3e: 0f 93 tst r15
40: 09 24 jz $+20 ;abs 0x54
42: 0e 93 tst r14
44: 07 24 jz $+16 ;abs 0x54
46: 0d 93 tst r13
48: 05 24 jz $+12 ;abs 0x54
4a: 0c 93 tst r12
4c: 03 24 jz $+8 ;abs 0x54
4e: 3f 40 0b 00 mov #11, r15 ;#0x000b
52: 30 41 ret
54: 3f 40 07 00 mov #7, r15 ;#0x0007
58: 30 41
你希望这两者是等价的，并且从纯粹的数学意义来看，他们应该得到乘法的结果为零，一个操作数必须为零。问题是这是处理器的软件，你可以很容易地在乘法上溢出并且具有非零操作数并且仍然为零，以便正确地实现代码必须发生的乘法。
由于mul的成本和特别是你应该在你的软件中尽可能地避免它们，在这种情况下你的多个解决方案对于两个解决方案是等效的，需要更多的代码来检测或防止溢出情况这可能导致误报。是的，许多处理器在一个时钟内执行mul，并且也是分开的，你之所以没有看到鸿沟，有时候看不到mul在指令集中实现的原因是因为需要芯片空间，现在的费用是功率，热量，因此，mul和鸿沟仍然很昂贵，当然不限于这些，但它们确实在帐篷中产生了长杆，关于部件的性能，时钟频率，人们希望单时钟操作没有实现一个指令可能会降低整个芯片的速度，使其成为多时钟可能提高整体时钟速率。这么多东西都是帐篷里的长杆，所以去掉mul可能不会改变性能，这一切都取决于......
答案 3 :(得分：0)
是，在这种情况下，我们在第二条指令中执行at most 4 comparisons (Operations)，对于第一条指令，我们始终执行4 operations。
编辑：说明
第二条if指令总是比第一条指令快：
假设：a = 1，b = 2，c = 0且d = 4，在这种情况下：
对于第一条指令：我们有3次乘法和一次比较= 4次操作
对于第二条if指令：我们将a与0（结果KO）进行比较，然后将b与0（再次为KO）和c与0（OK）= 3次运算进行比较。
这是一个输出这2条指令的执行时间的简单程序，你可以修改a，b，c和d并将指令的编号作为参数传递。
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
/* This is a test program to demonstrate that the second if is faster always than the first one*/
int main(int argc, char **argv)
{
int i;
int a = 1;
int b = 2;
int c = 0;
int d = 4;
int instruction_number;
clock_t begin, end;
double time_spent;
begin = clock();
if (argc != 2)
{
fprintf(stderr, "Usage : ./a.out if_instruction_number (1 or 2)\n");
exit(EXIT_FAILURE);
}
instruction_number = atoi(argv[1]);
for (i = 1; i < 100000; i++)
{
switch (instruction_number)
{
case 1:
fprintf(stdout, "First if instruction : \n");
if (a * b * c * d == 0)
fprintf(stdout, "1st instruction\n");
break;
case 2:
fprintf(stdout, "Second if instruction : \n");
if (a == 0 || b == 0 || c == 0 || d == 0)
fprintf(stdout, "2nd instruction\n");
break;
default:
break;
}
}
end = clock();
time_spent = (double)(end - begin) / CLOCKS_PER_SEC;
fprintf(stdout, "Time to accomplish %d instruction ---> %f\n", instruction_number, time_spent);
return 0;
}
希望得到这个帮助。
问候。
答案 4 :(得分：0)
if ( a * b * c * d == 0 )编译（无优化）
movl 16(%esp), %eax
imull 20(%esp), %eax
imull 24(%esp), %eax
imull 28(%esp), %eax
testl %eax, %eax
jne .L3
和if (a == 0 || b == 0 || c == 0 || d == 0)编译为
cmpl $0, 16(%esp)
je .L2
cmpl $0, 20(%esp)
je .L2
cmpl $0, 24(%esp)
je .L2
cmpl $0, 28(%esp)
jne .L4