|
马上注册,结交更多好友,享用更多功能,让你轻松玩转社区
您需要 登录 才可以下载或查看,没有账号?立即注册
×
CPI 其实就是个统计的活……你跑一段Benchmark(找点知名的,比如CoreMark或者Dhrystone之类),然后用处理器自带的PMU(Performance Monitor Unit)计算下某段函数实际跑了多少指令周期,然后除以这段函数有多少条指令。这就计算出来了。原理很简单,操作起来可能有点费劲。
而且,一个程序不同位置的CPI是变化的,甚至同一段程序的CPI也有可能是变化的,这里面干扰因素主要来源于存储器的延时,prefetch,cache policy等等。
是否可以dual issue的判断是流水线硬件来完成的,对compiler是透明的。当然,ARM Compiler在明确知道目标处理器是Cortex-M7的情况下,甚至会交换某些指令的顺序(保证逻辑等效的情况下),以最大限度的保证更多的指令可以被dual-issue。
最后我要说一下,依赖compiler是不靠谱的……要想最大程度的利用dual-issue,还是要程序员写代码的时候有所注意。简单举个例子,比如C语言中全局变量或者寄存器,往往都有volatile修饰。这保证了逻辑的正确性,却阻断了compiler优化的可能。另外,volatile的使用,使得函数内,每一个对变量的访问都要实际进行Load/Store操作,这就导致大量的Load/Store操作密集存在于同一段代码中,这些密集存在的读写操作会导致大量的Structural Hazard,从而妨害dual issue的进行。另外对volatile变量的数值运算,也会由于运算指令和Load/Store指令存在依赖关系而无法dual issue。所以,针对这种情况我们要在函数需要优化的地方,通过局部变量人为的进行“读、改、写”操作——也就是先用局部变量保存volatile变量的值,然后后续运算全部针对这个局部变量,最后再把计算结果保存回去——这是一个例子。具体软件优化方法,取决于编译器、你掌握的目标处理器的信息以及C语言的各类技巧。内容太大,这里就不方便展开了。 |
|