条件控制与条件传送详解

条件控制与条件传送详解

提要

CSAPP3e中文译本 3.6.5 用条件控制来实现条件分支 3.6.6 用条件传送来实现条件分支

CSAPP3e第三章前面主要是介绍了机器级代码的二进制形式和汇编形式、反汇编、x86汇编的基础指令、条件码及其访问方式等。

在介绍到汇编语言的条件分支时分了两小节(3.6.5,3.6.6)分别介绍实现条件分支的两种形式:

  1. 用控制的条件转移实现(结合有条件和无条件跳转)
  2. 用数据的条件转移实现

并对这两种方式的适用场景,哪种在哪些场景下效率更高进行了说明,以及一些可能会造成的错误。

笔者在这里要首先指出的是,如果使用C语言编程遇到条件分支(当时几乎是肯定会遇到啦^^),大可以直接按照我们熟悉的if-else模板编写代码即可,

if (test-expr){
    then-statement;
}
else{
    else-statement;
}

无论我们的C语言代码是按照哪种方式编写的,聪明的编译器会在保证安全的前提下自动优化条件分支的实现方式,将我们的C代码用最合适的分支方式编译为汇编代码。本文内容是为了从机器级代码汇编和现代CPU工作原理的层次,来帮助理解分支程序的性能,也反过来更好地理解现代计算机系统的工作原理

以下笔者以计算两个整型值的差的绝对值的程序为例,分析条件控制和条件传送的区别和关系。

条件控制

要实现算两个整型值的差的绝对值,我想大多数人的第一反应是以下程序:

int abs_diff(int x, int y)
{
    if(x < y)
        return y - x;
    else
        return x - y;
}

先判断两个值哪个较大,然后用较大的减较小的,这个代码完全没有问题,这种条件分支的实现形式称为条件控制

然后我们来编译以下这个代码gcc -Og -S abs_diff.c -o abs_diff.s,注意这里的-Og参数是关闭编译器的自动优化,使得编译器忠实地编译我们的C代码。这里笔者把abs_diff.s文件的关键部分复制出来:

abs_diff:
.LFB0:
	.cfi_startproc
	cmpl	%esi, %edi
	jl	.L4
	movl	%edi, %eax
	subl	%esi, %eax
	ret
.L4:
	movl	%esi, %eax
	subl	%edi, %eax
	ret
	.cfi_endproc

笔者注:可以认为x保存在寄存器%edi中,y保存在寄存器%esi中。

可以看到,编译器确实忠实地按照我们编写的C代码结构进行了编译,比较两个寄存器中的参数值,然后返回较大的值减去较小的值的结果。将这种条件控制的条件分支实现形式用C语法来表达应该是这样的:

int goto_absdiff(int x, int y){
    if (x > y){
        goto x_ge_y;
    }
    return y - x;
    x_ge_y:
        return x - y;
}

当然,所有C语言老师都会要求大家不要使用goto,因为它会是的程序非常难以阅读和调试,还容易出错。我们这里使用goto是为了模拟汇编中的JMP类指令的行为。看到这里,想必读者应该能明白上面所谓的结合有条件和无条件跳转是什么意思了,在汇编语言中,需要结合有条件和无条件跳转,才能利用JMP类命令实现在两个分支(then-statementelse-statement)中必有一个被执行。

条件传送

上述函数的条件传送的实现形式如下:

int abs_diff(int x, int y){
    int result_0 = x - y;
    int result_1 = y - x;
    if (x < y){
        return result_1;
    }
    else{
        return result_0;
    }
}

可以看到,条件传送的分支实现方式是先将两种分支的值都算出来,然后再比较哪个参数较大,返回对应的结果。编译上述代码gcc -Og -S abs_diff_1.c -o abs_diff_1.s,得到的关键汇编代码如下:

abs_diff:
.LFB0:
	.cfi_startproc
	movl	%edi, %eax
	subl	%esi, %eax
	movl	%esi, %edx
	subl	%edi, %edx
	cmpl	%esi, %edi
	jl	.L3
.L1:
	rep ret
.L3:
	movl	%edx, %eax
	jmp	.L1
	.cfi_endproc

没有问题,编译器同样忠实地编译了我们的C代码结构。

那么,这两种条件分支的实现方式到底有什么区别呢?为什么说在保证随机输入的情况下,第二种的运行速度是比第一种要快的。

条件控制和条件分支的效率

我们放开编译器的优化选项,即让编译器自己去优化我们的C代码,来编译第一种实现方式条件控制

gcc -S -O1 abs_diff.c -o abs_diff_opt.s,注意这里开启O1级别的编译器优化-O1。得到的abs_diff_opt.s的关键汇编代码如下:

abs_diff:
.LFB0:
	.cfi_startproc
	movl	%esi, %edx
	subl	%edi, %edx
	movl	%edi, %eax
	subl	%esi, %eax
	cmpl	%esi, %edi
	cmovl	%edx, %eax
	ret
	.cfi_endproc

大家可以对比一下上面条件传送中得到的汇编代码,几乎是一样的。所以说,在编译器优化之后,这段汇编代码实际上执行的是条件传送的条件分支实现方式。也就是说,编译器认为,在保证安全的前提下,这段代码使用条件传送来实现比使用条件控制来实现要更加高效

原理

以下内容摘自CSAPP3e中文译本 Page 146

为了理解为什么基于条件数据传送的代码会比基于条件控制转移的代码性能要好,我们必须了解一些关于现代处理器如何运行的知识。正如我们在第4章和第5章中看到的,处理器通过流水线(pipelining)来获得高性能,在流水线中,一条指令的处理要经过一些列的阶段,每个阶段执行所需操作的一小部分(例如,从内存取指令,确定指令类型,从内存读数据,执行算术运算,向内存写数据,以及更新程序计数器)。这种方法通过重叠连续指令的步骤来获得高性能,例如,在取一条命令的同时,执行它前面一条指令的算术运算。要做到这一点,要求能够事先确定要执行的指令序列,这样才能保持流水线中充满了待执行的指令。当机器要到条件跳转(也称为“分支”)时,只有当分支条件求值完成后,才能决定分支往哪边走,处理器采用非常精密的分支预测逻辑来猜测每条跳转指令是否会执行。只要它的猜测还比较可靠(现代微处理器设计试图达到90%以上的成功率),指令流水线就会充满着指令。另一方面,错误预测一个跳转,要求处理器丢掉它为该跳转指令后所有指令已做的工作,然后再开始从正确位置其实的指令取填充流水线,正如我们会看到的,这样一个错误预测会招致很严重的处罚,浪费大约15~30个时钟周期,导致程序性能严重下降。

可以看到,当输入比较随机的情况下,CPU是很难在条件控制方式下精准地预测哪条分支会被执行的,而错误预测将付出高昂的代价(原书中有具体的错误预测代价计算方式,有兴趣可自查),这时,我们通过条件传送的实现方式,则会获得相对更优、更稳定的性能。

条件传送相当于把原本可能浪费在跳转的时间用在了计算另外一条分支上,所获得的性能提升取决于跳转所浪费的时间和计算另外一条分支的时间对比。不过从另一点来看,由于只有最后返回之前才进行条件的判断,条件传送更有利于流水线一直处于满的状态,运行时间更加稳定。

条件传送并不总是可行的

那有人可能就要问了,既然如此,我们把所有条件分支都实现为条件传送的方式岂不是最优,那还要条件控制的方式做什么呢?事实上恰恰相反,条件传送的可行情况是十分受限的,大部分情况下,编译器会将条件分支实现为条件控制的形式。比如下面这个C程序(同样来CSAPP):

long cread(long *xp){
    return (xp ? *xp : 0);
}

当指针结果为空时返回0,否则返回指针所指向的值。貌似很适合实现为条件传送:

cread:
	movq (%rdi), %rax
	testq %rdi, %rdi
	movl $0, %edx
	cmov %rdx, %rax
	ret

但实际上这个实现是非法的,因为即使当测试为假时,movq指令对xp的见解引用还是发生了,这将导致一个间接引用空指针的错误。所以,必须用条件控制分支方式来编译这段C代码。

使用条件传送指令,也不总是会提高代码的效率。因为毕竟要先计算出then-statemntelse-statement的结果,如果这些计算比较复杂,而最终有没有被执行,那很多计算就被白费了。因此,编译器必须考虑浪费的计算和由于分支预测错误所早晨改的性能处罚之间的相对性能。根据CSAPP原书的说明,只有当两个表达式都是很容易的计算时,例如都只是一条加法指令,编译器才会使用条件传送,而通常情况下,即使许多分支预测错误的开销会超过更复杂的计算,编译器还是会使用条件控制转移。笔者理解,编译器还是相对比较保守的。

__bulitin_expect

最后再说明一下,本文内容是为了从机器级代码汇编和现代CPU工作原理的层次,来帮助理解分支程序的性能,也反过来更好地理解现代计算机系统的工作原理。而在日常的代码编写中,按照正常的逻辑来编写程序即可,即使有优化的需求,现代编译器都会帮你进行优化。

当然,如果你非常确定哪一条分支大概率会被执行,你也可以通过\_\_builtin_except来告诉编译器。使用\_\_bulitin_expect这个宏来告诉编译器这个if更有可能会选择哪一个分支,从而让编译器生成出跳转可能比较小的汇编代码。

Ref:

https://blog.csdn.net/qq_33113661/article/details/90750145?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522163081410616780366559662%2522%252C%2522scm%2522%253A%252220140713.130102334…%2522%257D&request_id=163081410616780366559662&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2allsobaiduend~default-1-90750145.pc_search_insert_download&utm_term=%E6%9D%A1%E4%BB%B6%E6%8E%A7%E5%88%B6%EF%BC%8C%E6%9D%A1%E4%BB%B6%E4%BC%A0%E9%80%81%E4%B8%8E__builtin_expect&spm=1018.2226.3001.4187

CSAPP3e

  • 10
    点赞
  • 13
    收藏
    觉得还不错? 一键收藏
  • 4
    评论
Allegro约束条件是一种用于线性规划问题的优化方法。在线性规划中,我们通常面对一组线性约束条件和一个目标函数,寻找使目标函数取得最优值的变量取值。而Allegro约束条件的目的是进一步优化这个过程。 Allegro约束条件主要有两个方面的作用。首先,它用于降低误差的影响,使得最终的结果更加准确。在线性规划中,存在着模型误差、测量误差等各种误差来源,这些误差会导致最终的结果与真实值之间存在一定的差距。通过使用Allegro约束条件,我们可以将这些误差纳入考虑,从而对结果进行更精确的修正。 其次,Allegro约束条件还能够提高计算效率,加快求解过程。线性规划问题通常涉及大量的变量和约束条件,传统的求解方法可能需要耗费大量的时间和计算资源。而使用Allegro约束条件,可以对求解过程进行优化,减少计算的复杂性,从而提高求解的效率。 Allegro约束条件的具体实现方法比较复杂,一般需要借助算法和数学模型来进行求解。它涉及到诸多数学和统计的概念与方法,例如误差修正、优化算法等等。不同的问题可能需要不同的算法和模型,所以在实际应用中需要根据具体情况进行选择。 总之,Allegro约束条件是一种优化线性规划问题求解过程的方法。它能够提高求解的准确性和效率,对于涉及大量数据和约束条件的问题尤为适用。然而,Allegro约束条件不是万能的,它仍然需要根据具体问题进行合理的应用和调整。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 4
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值