为何同一简单C程序在Ubuntu与Windows下CPU使用率存在差异？

程序本身的运行上限 #

这段C代码是纯单线程串行程序，全程没有创建任何独立线程，所有变量自增、分支判断、循环跳转逻辑都在同一个执行流里完成。这类程序的物理上限就是最多占满1个CPU核心的全部算力，根本不存在跨核心占满多个CPU的可能。你在两个系统上看到的CPU使用率数值差异，首先来自系统统计口径的不同，不是程序真的消耗了更多算力：

• 你的Ubuntu设备是双核CPU，Linux桌面环境（比如GNOME自带的系统监视器）默认的CPU使用率统计，取所有核心中的单核心峰值占用——只要把其中一个核心的算力吃满，监视器就直接显示100%的总占用，不会按全核心平均折算。
• 你用来测试的Windows设备CPU性能更强，意味着核心/线程数比你的双核Ubuntu多一倍以上。而Windows任务管理器默认显示的是全系统所有核心的平均占用率，把所有核心的占用值加总除以核心总数后，单线程占满1个核心的折算值自然比Ubuntu的显示值低，你看到的50%只是这个统计口径换算后的结果，不代表程序占用的CPU资源更多。

程序的性能瓶颈根本不在CPU算力上 #

这段代码的循环逻辑等价于从1开始逐行打印数字，直到打印到1亿，全程要执行近1亿次printf调用，产生数GB的文本输出。这种场景下，CPU执行自增、判断的计算耗时，连程序总运行时长的1%都不到，99%以上的运行时间都在等输出接口把文本渲染到终端上，是典型的IO密集型程序，和CPU算力强不强没有直接关系：

• Ubuntu下的终端模拟器、C标准库的stdio缓冲实现，对逐行刷出的文本处理效率更高，程序等待IO阻塞的时间更短，CPU有足够多的时间执行循环逻辑，自然就把单个核心跑满，看起来CPU使用率很高。
• Windows的控制台渲染机制本身开销更重，不管是传统cmd、PowerShell还是Windows Terminal，逐行渲染上亿行文本的速度都比Linux下慢数倍。程序绝大多数时间都处于阻塞等待控制台响应的状态，根本没有执行CPU指令的机会，自然CPU使用率上不去、整体运行速度更慢——哪怕你的Windows CPU纸面性能强很多，也因为瓶颈不在CPU，完全发挥不出来性能优势。

系统策略的叠加影响 #

• Ubuntu如果开启了高性能电源模式，CPU会一直维持最高睿频运行，哪怕是程序等待IO的间隙，CPU频率也不会主动下降，从外部观测就会显得CPU处于满负载状态。
• Windows默认通常启用平衡电源模式，当程序长时间处于IO等待状态时，CPU会主动降低运行频率，进一步拉低资源占用率，也会让整体运行速度更慢。

补充：当前这个程序根本不适合用来测试CPU性能。如果要做纯CPU算力测试，可以把循环里的printf删掉，只做计数运算，最后循环结束后只输出一次最终结果，这样才能真正跑满计算核心，测出不同CPU的实际性能差异。

内容的提问来源于stack exchange，提问作者Gab