依据实际项目的规模和编译设置可能会差出很多。

即使假设多线程编译不会导致问题，能够很好的利用上全部核心。对于规模不是很大的项目编译（ e.g. ffmpeg ），时间也主要花在了吃单核的 lto 过程上，这种情况下单核性能就非常重要。如果不开 lto 、或者项目规模非常大的话，可能多核性能才会体现出比较明显的优势，

@jjx 马上就变成 A 面正中大联想标了，丑到极致🤣

今年的 X1C 还是可以的，相比于前两年的垃圾要可用很多了。重点偏重全接口超轻，在这个细分市场内还是无敌的。但是因为做超轻和 tp 自己摆烂的原因，实际在性能、电池上的体验会比主流价位更差。

不过今年这机子整体涨价，超出你这里的预算空间了啊。

@zhiqiang404 华为自带的电脑管家或控制面板里有对应触摸板/音频/摄像头这些外设的设置

@zhiqiang404 马达肯定不可禁用，毕竟 Force Touch 禁用马达就成一块硬板了。灵敏度在自带华为软件里可调

@maggch97 测试过了，把这四个选项都关掉也不会影响拖拽处理的。如果不是我猜测的姿势导致的断触问题的话还是建议售后。

@maggch97 是的
https://i.imgur.com/P6YanT0.png

@maggch97 这个操作以前用 mac 的时候我也习惯不按下，直接触摸双击拖动，所以体验可能不是很准确

不过我试了十几次下来并没有感觉到这个问题，具体操作就是按下拖拽之后松开力度，已经能感受到松开力度后的回弹，并且反复按下、松开的时候也能感受到和正常点击一样的力度反馈。这个过程中只要一直保持触摸就不会断掉拖拽。触摸板设置就是和上面说的一样敏感度高强度中、手势全开（不过这个应该不会有影响吧）。

但在测试过程中，如果中间断触了的话（比如只用指尖触摸，然后指甲区域碰到了触摸板导致断触），就会立即断掉拖拽。我的猜测是 mac 上做了优化，偶尔断触也会保持之前的手势一小段时间。而在华为这边是直接按照是否触摸判定的。感觉可以向华为反映一下这个问题，固件上应该是可以优化的。

如果正常触摸面积也会断的话，那可能就是硬件品控问题了，毕竟这个触摸板也是新东西。

今年估计是为了卡 1kg 内，把电机砍成单马达了。
延迟的话把灵敏度调到高倒是感觉还行。但震动强度最好是中，因为调成强之后不但震动反馈没多好，反而延迟明显增加了……
以前的触摸板在硬件上是能说追赶 Mac 的，这次就差多了，不过就这还能继续算是 win 阵营内最好的体验，整个市场也是真的摆（

区域截图确实没什么好办法，只能拿全屏截图的 png 裁剪了，反正 jxr 的共享也很不方便。
不过常用的区域截图场景里，除了触发了 HDR 后的浏览器基本都是 SDR 吧，整体影响不是很大。

@me221 “被认为可以用于”，这不是个纯技术问题......

@villivateur 你这暴露在公网的 VPN 被扫出来、被认为可以用于回国的意思。
P.S. 你要是只会质疑别人水平那也没必要再回复了

@villivateur 回国查的比出去都严的……

uncore 应该很久以前就是独立的电压了，所以电压同步并不影响 uncore 功耗太高的问题（扩展性堆得太多了，制程又不够，这两代应该没啥办法）。并且即使是现在同电压的情况下，小核的能耗比也是足够优秀的，非要频率拉高达到大核性能（且不说能不能实现同等级的性能）去比功耗是完全没有道理的，这种强行拉过甜点方法会让任何芯片的能耗比都变得非常难看。

与其考虑大部分机型上都不可行的关小核，不如直接限制性能（功耗）。目前的评测来看，x86 两家在相同离电性能下表现出的续航是类似的（比如天选 3 ，Intel 的 uncore 问题和稍高的离电性能会让它有所落后）。也已经有不少机型（战 66 、荣耀等）证明了只要愿意限制离电性能，ADL-P 的续航也能到接近 RMB 的程度。

@huang119412 很好奇你有没有用过（任何平台的） 12 代酷睿，能说出“小核纯刷分，很难满载”这种言论。。。

@1054850490 那感觉还是硬件 /软件区别导致无效了。。。我之前 HDMI 输出方向这个设置是能起效的，如果是新一点的一加的话可能是因为 ColorOS 不够原生所以不起效？

@1054850490
SecondScreen ，之前接便携显示器的时候用这个调过竖屏，需要 root 。不过不知道你硬件条件下会不会有问题。
https://play.google.com/store/apps/details?id=com.farmerbb.secondscreen.free

@learningman 即使相比于代码修正、文档在技术层面问题上的修正，typo fix 对项目的贡献更低。typo 始终是一个已存在的问题，这类 PR 不应当被认为是无意义的。

@learningman 这个文章和你的论点毫无关系，修复 typo 并不属于文中提出的任何问题（既没有违背 coding style，对注释的更改也不会产生任何影响 compile 的行为，一般来说对变量的更名也不会产生程序行为上的任何变化，GitHub 在 PR 方面也比传统的 mailing list 更加友好）
这类 PR 对项目本身以及开源社区的意义我认为上面 ayase252 也已经说的非常清楚了。