被 windows 的系统调度逻辑破大防

[andyJado]

事情是这样的：

代码本身很简单，thread：：spawn （）多线程跑点累活儿。

因为结果很多就花了两周时间写后处理。

回过头来再跑累活儿发现 CPU 占用 33%怎么也上不去了。

认为自己重构代码时候引入了 bug 。

checkout install run,checkout install run..

嘿，最早的可运行版本现在也只能用 33%

才想起来自己以前开 cmd 都是管理员选项卡。

果然，管理员 cmd 才能跑 sync 代码到 90%

胸口发紧。

对不起，搞错了一个事情，不是管理员权限问题，而是直接通过 cmd 调用 exe 跑不起来 cpu ，但用 windows terminal 的 cmd 选项卡可以。

在任务管理器中，cmd 直接调用会出现野生 pid ，terminal 调用则是子 pid 。

[opengps]

没看到到底因为啥，仅仅是因为管理员身份变化就能改变 cpu 的利用率？真没听过这个说法

[andyJado]

@opengps 累活儿里调用了别的大型计算软件。

[cnbatch]

看起来，用的似乎是大小核
我这普通核 CPU 并未遇到过这种怪事

不过 OP 也可以进一步测试（如果想测的话），用 ffmpeg 做个转码（只用 CPU ），看看 conhost 和 Windows Terminal 的运行情况是否一致

[kenvix]

怎么听起来像是你大量往控制台打印东西，导致阻塞了

[kenvix]

印象中 conhost 没有硬件渲染加速而 wt 有，往控制台打印东西太快就会阻塞住，所以产生了 wt 比 conhost 快的现象

[mmdsun]

为啥 CMD 和 Windows Terminal 性能有这么大差异？
难道输出太多？ your-command > NUL 试试看

[afirefish]

大小核调度问题。33%看看不是小核跑满了，大核心在摸鱼。

[afirefish]

@afirefish 猜测

[andyJado]

@kenvix
按 @mmdsun 的方法测试了，还是 33%就按住了。

我觉得还是野生进程和有爹进程的区别。wt 开的话是有爹版，wt 可以用满 cpu 。野生进程和任务管理器在任务管理器中是同级的，可能被调度卡了。

[kwanzaa]

ryzen 无大小核同样的情况。