wraparound_counter & operator ++() {
m_count = (m_count + 1) % upper_limit;
/*if (upper == m_count)
m_count = lower;
++m_count;*/
return *this;
}
据我所知,在某些系统上使用余数运算符技巧会更快,但在其他系统上条件会更快。有没有办法弄清楚哪些在编译时(或运行时)会更快?
答案 0 :(得分:2)
除非您需要对程序进行交叉编译,否则可以将基准测试作为构建过程的一部分。根据结果,您可以选择特定的实现并继续编译您的应用程序。
答案 1 :(得分:2)
对于大多数平台,您可以假设条件更快。这是因为分支错误预测昂贵的大多数现代架构都具有某种形式的条件移动指令,编译器将利用该指令来执行所请求的检查&分配。例如,我的gcc翻译了这个:
n++; if (n==1234) n=0;
为x86_64(和x86):
addl $1, %esi ; %esi=n
cmpl $1234, %esi
cmove %edx, %esi ; %edx contains 0
(自PentiumPro以来可以使用cmove。)
这是针对ARM-thumb的:
add r3, r3, #1
cmp r3, r1
moveq r3, #0 ; <- conditional move
所有 ARM都有条件执行。
等等。包装起来:你需要一个带
的架构最终将模数技巧作为最快的。 **如果*有这样的架构,那么请告诉我它。我总是对这些事情感兴趣。
答案 2 :(得分:1)
在循环中运行数百万次?
答案 3 :(得分:1)
你需要对它进行基准测试。
由于分支错误预测,条件限制可能很昂贵。
另一方面,分区比许多处理器上的简单比较贵。
它可以基于您运行的平台,运行的循环类型,上限有多大,编译器执行的优化等等。
答案 4 :(得分:1)
从技术上讲,如果不同时做到这一点,就不可能确定哪个更快。就调用代码来执行工作而言,当您需要执行其中一个选项时,为时已晚。您可以在应用程序初始化阶段使用一个例程来对两个示例例程进行基准测试,然后设置一个标志。但这引入了一个全新的测试,增加了每个目标调用的开销。归结为:
除非您正在构建嵌入式系统或具有非常具体的性能调整要求,否则#4是您最好的选择。