Question

我正在仔细阅读cpufreq_governor.h中的一些内核源代码，并看到了：

/*
 * The polling frequency depends on the capability of the processor. Default
 * polling frequency is 1000 times the transition latency of the processor. The
 * governor will work on any processor with transition latency <= 10ms, using
 * appropriate sampling rate.
 *
 * For CPUs with transition latency > 10ms (mostly drivers with CPUFREQ_ETERNAL)
 * this governor will not work. All times here are in us (micro seconds).
 */
#define MIN_SAMPLING_RATE_RATIO         (2)
#define LATENCY_MULTIPLIER          (1000)
#define MIN_LATENCY_MULTIPLIER          (20)
#define TRANSITION_LATENCY_LIMIT        (10 * 1000 * 1000)

将最后一行更改为以下内容是否会更有效：

#define TRANSITION_LATENCY_LIMIT        (10000000) /* (10 * 1000 * 1000) */

Answer 1

将最后一行更改为以下内容是否会更有效：
#define TRANSITION_LATENCY_LIMIT        (10000000) /* (10 * 1000 * 1000) */

很可能不会有任何改变。

任何体面的编译器都应该能够在编译时计算10 * 1000 * 1000。

Answer 2

问问自己：

您的建议中有多少个零（或者，数字是多少）

#define TRANSITION_LATENCY_LIMIT (10000000)

累人的任务。这更加直观，容易（并且易于维护）：

#define TRANSITION_LATENCY_LIMIT (10 * 1000 * 1000)

此外，(10 * 1000 * 1000)是表示10微秒（每秒1百万分之一（1000 * 1000）的10倍）的更方便的方法

此外，这里的效率无关紧要，因为它将由编译器计算。

Answer 3

毫无疑问，您进行了更改并获得了更高效的代码，因为与加法和减法相比，乘法需要更多的CPU周期，但是您却失去了源代码的可读性。但是请不要担心，当今的编译器是如此智能，可以在编译时完成它，这一过程称为代码优化。

使用C＃定义中的常量公式是否会影响效率？

3 个答案: