@dayeye2006199 #17 我印象中 ARM 版本的 numpy ，是有用 ARMPL 做底层库编译了的，替代了 MKL 来编译 BLAS

@nothingistrue #11 这位同学……你在说啥啊，你这说法感觉你根本就不懂 Hypervisor 和 Container 的基本原理和区别

Windows 用 Docker 需要虚拟机，是因为 Docker 依赖 Linux Kernel 的 namespace 和 cgroup 啊😂Windows 自己又没有容器能力。另外

我印象中，docker 是没有调用 VMX/EL2 的，这本身就是一个跑在 Kernel 之上的一个应用层，根本不需要翻译啥指令，现在 cgroup 本身就是一个 arch 不敏感的东西。

我建议你如果想细致学习的话，可以读一下 cgroup v2 v3 两个 patch ，然后再看看 Intel 的 IA32/64 3C 卷的 VMX 章节，基本上就清楚容器技术和虚拟化技术的本质区别了……

@nothingistrue #6 ARM 的容器和 KVM 非常的成熟，不存在 ARM 模拟 X86 的这种用法。。。

另外，docker 依赖容器技术，基本上和虚拟化是两码事儿

如果只是数据分析，那基本感知不到太大的区别

ARM 和 X86 服务器的差异越靠近上层越不明显

一定要选 12 代的……目前实用肉测，性能提升比纸面数据的感受更强

@mrzhu #128 举几个例子

CXL 、CCIX 、Intel 的 Optane 系列，这些都是操作系统和体系研究领域的成果

然后类似 PSI 、OOMD ，都是 Facebook （现在叫 Meta ）开源出来的内部项目，还有现在容器的鼻祖 cgroup 和基座 cgroup v2 ，都是 Google 开源的成果。这块基本是系统的软件部分

这些都是 C 语言垒出来的教堂

过来人的经验之谈：

做 C 的话，务必确认是写业务软件还是写系统软件

如果是业务软件的话，除非写高性能中间件，要不然基础的嵌入式开发没啥意思的

如果是做系统软件的话，尽量避开写驱动这种调参工程师的工作，能深入芯片、操作系统甚至新的体系结构是最好的

C 语言作为主力语言，做操作系统和体系结构研究，职业寿命和职业回报真的巨长无比，我最近两年和我司内部的一些系统专家打交道，有的人真的是几十年沉浸在这个领域深耕，完全没有任何职业寿命的危机感，基本上只有自己主动跳去新的领域，没有说被企业给优化掉的说法……

12 代的轻薄本大品牌任选都好，不太推荐 AMD 的 CPU 和显卡，I 和 N 家的驱动在 Linux 上是很全的，尤其是得益于矿老板们折腾，比较新的 N 卡的稳定性问题基本处理的差不多了

@nicksors #15 那种塌陷的软肯定不行的，一般比较好的床垫睡上去会有承托感，可以去线下试试

舒达的乳胶+弹簧的一款，睡下去全身被承托的感觉太妙了

@Goooooos #7 赞同，如果和汽车一样保险法规配满，那就怎么着都行

@Damn #23 管内的水应该不影响滚筒内吧，强排式的都可以保证桶内是排干净的

@shanghai1943 #15 你这个烘干次数太少了，例如被套、羊绒外套、羽绒被这类多层的纺织物，一体式的机器内筒决定了它就是烘不干


@mwVYYA6 #16 你这揣测的……我在买烘干机之前差不多把 1W-5W 档的一体机和烘干机都看了一圈，可能比很多人都了解一体机和分体机的差异。

而且我之前和我朋友试过，同款 2m 的被套，我用分体式的烘干机，1 个小时左右就烘干了，整体褶皱很少。他买的一体机，洗完之后，烘了两个半小时，被套被裹成了一个球不说，中心还是湿的。而且一体式的机器，除了少量的那几款热泵式的型号，内筒针对烘干做了改进，其余都是优先为了洗衣设计的，天生就是烘不好，没啥好质疑的

至于烘得好的一体机也不是没有，美诺和东芝都有 11KG 的那种，但是那个价格太贵了，性价比陡降

@Damn #12 额……我之前用的松下的，现在用的美诺的，都没遇到上排水排不出去的情况，相反主动排水可以适配更多下水的设计。至于胶圈老化的问题，那款老松下到现在已经 10 年了，还是没漏水过

@shanghai1943 #9 烘不干+烘不好，而且一体式烘干机由于内筒是为了洗设计的，所以烘的容量一般只有洗的一半。

美诺 东芝也出过热泵的机器，但是 8KG+8KG 的机器，比同级别分体式贵了快 1W ，性价比又降低很多了

@Damn #6 滚筒洗净比比波轮普遍高，而且一般都是主动排水，另外漏水是啥情况……


@shanghai1943 #1 洗烘一体很难用，没有条件就直接普通洗衣机就行了，千万别一体。。。

@beijiaoff #48 是的，除了 SSD 磨损导致的性能下降，CPU 和内存按照个人使用强度……还轮不到感知到老化，其实就是现在的软件和系统占用的资源更多了而已

其实使用卡顿的问题，想解释得非常清楚是挺挑战的

例如 LZ 这个配置：处理器 2.9 GHz 双核 Intel Core i5 内存 16 GB 1867 MHz DDR3 图形卡 Intel Iris Graphics 6100 1536 MB

我查了一下，CPU 是 5257U ，LLC 3M ，然后带的 6100 最大能跑 1.5G 。
内存就是 DDR3 时代的 1866 的典型低压 DDR

那么基于这几个关键的配置。首先因为 LLC 实在太小，所以 CPU 的数据会经常从内存获取，被动占据了一定内存带宽

然后低压 U 的总线设计应该有一些共享（这款的话不熟悉，纯猜测），再加上内存属于上上代的低压内存，本身带宽又不大，因此大幅影响了时延

再一个方面，集显占用了总线和内存，随着前端技术和图形技术的发展，集显算力和吞吐量也在上浮，进一步恶化了整个系统的整体压力

最后再叠加一下长尾时延导致的雪崩效应，系统自然就会出现各种各样的卡顿了

而且 LZ 举的例子，都是高压力冲击的场景：
1. 点击浏览器链接，感觉有迟钝；——数据加载的时候，内存集显 IO 负载都瞬间拉高。
2. 打开 IDEA 明显很慢；——这个不说了，各路主流 IDE 都是 IO 怪
3. 多开几个 IDEA ，输入都卡。——系统内延迟太高，输入本身就是一个中断+二次中断处理的过程