确实没有必要追求“完全没有循环依赖”

循环依赖最简单的形式是单函数的递归，简单的递归等效于简单的循环，也就是说你写个循环就是有循环依赖了
问题来了，你能不能不写循环 ...

你随便找个编译器看看代码就知道这玩意的所有特点都是 GPU 所需求的反面 ...

... Wine?

我现在觉得 Topic 比 Trending 好玩，Trending 确实没啥意思了
For You 和 Trending 理论来说应该不冲突，至少现在都是挺鸡肋的东西

自己读起来会比较麻烦，你可以写个程序帮你读。然后找个云租个几十核服务器跑一跑去睡觉，做个梦你就是精通 Linux 源码的人了

什么堆啊栈啊的，C 标准里面压根没这俩词儿，JS 标准里面也没汇编里的栈。

说实在的，开源和 Mac 独占这两条貌似有点矛盾。我在 GitHub 上想找些 Mac App 源码看看，结果发现做得像样的非常少。可以说被同站点隔壁的 C#+XAML 生态螺旋完爆。

Intel 盘只有黑壳的 Optane 看上去有“新”的感觉 :)

我觉得这个"out of"其实是"from"的意思 ...

我也很爱 Monaco ，这个之前看到过，但是没看到有 License ，猜测应该是直接拿 Monaco 改的，所以没有用

可以说存在，也可以说不存在。

对于一个黑盒的软件成品来说，“无默认行为”by definition 是不可能的，因为这个软件设计的“功能”就是“行为”的一部分。“无默认行为”等于“无默认功能”，追求完全的自定义，最后都会扩大化到从 mian 函数重写整个软件。

另一方面，很多软件是可以拿到源代码并自己编译的，可以不必“从 mian 函数重写整个软件”，而是在已有源代码上魔改，从这个角度上来讲这些软件确实“无默认行为”，毕竟你可以通过源码的方式修改所有行为。

罗马人做的 Pike and Shot: Campaigns, Field of Glory: Medieval, Field of Glory II
各种 4X 类，比如 Shadow Empire

挖出个老贴 /t/62637

上面是 load ，不知道楼主打算怎么做 store 。现代 CPU 中单独的 store 指令比 load 更 cheap ，因为只需要往 store buffer 里面压一压，不会造成新的依赖。
按照拼的思路，你得做两次 load+两次 store ，本来一个 store 解决的事情，至于么 ...
直接存的话有和 load 一样的问题

另外根据 https://travisdowns.github.io/blog/2019/06/11/speed-limits.html#load-split-cache-lines ，在 Zen 系列上不仅跨 64 byte 边界的访问会影响性能，跨 32 byte 也有可能

第一，进行内存对齐的一般是编程语言的*实现*，不是编程语言

然后，就 x86 来说，一般编程语言的实现取 a ，b ，c 的方法是 mov ax, [s]; mov rbx, [a+8]; mov cx, [a+16]，按照你那种紧凑的布局无非就是变成了 mov ax, [s]; mov rbx, [a+2]; mov cx, [a+10]，都是三次
也就是说一般根本不会先整个 word size 读过来再拼接，拼来拼去的做法在 SIMD 里倒是比较常见

就算按照楼主的说法，不对齐，先取，再拼，省了一个 load ，多了几个位运算，不一定划算
楼主可能认为 load 很 costly ，其实大多数 load 都还好，只有 cache miss 的 load 才 costly

现代 x86 实现里面，非对齐的访问一般是不会有性能损失的，但是仅限于在一个 cache line 里面，如果跨了 cache line 就相当于 CPU 要帮你自动做两次+拼接，要是跨了页就更好玩了。对于在 L1D$里的数据，在对齐的情况下，每次 load 的延迟和占用的资源基本都是确定且最小的，而如果出现了跨 cacheline 或跨页，就会出现有些 load 和对齐的没区别，有些 load 则非常慢的情况，平均下来是降低了性能的
这个在 GPR 操作上影响还算小的，如果涉及到 SIMD ，连续 load 一串数据，对于 XMM load ，四分之一会出现跨 cache line ，对于 YMM 是二分之一，对于 ZMM 是百分百 ...

有没有需要紧凑布局的情况呢？当然也有，就是真的需要“节省内存空间”的时候，比如大量并行+数据量大的情况下如果你的算法不能优化到 cache 里面，DRAM 喂不饱 CPU 很正常，这时需要尽量利用内存带宽，而 ALU 运算就基本无所谓了，不仅 padding 可以不用，bitfield 也可以用上

这个每次蓝屏大概都是同一个原因，你把这个“原因”找到并解决了，就从经常蓝屏变成零蓝屏了
要是写过程序就能理解，程序里面大部分的 bug ，有个触发条件，满足这个条件必复现，解决方法有二，要么修掉 bug ，要么回避掉条件
主题里面这个故障，描述只反映出了系统不正常，系统简单分三层，应用软件层，OS 层，硬件层。OS 应该隔离掉应用软件的问题不影响整个系统，所以应用软件层不用管。OS 层其实可以再细分成通用的 OS 和硬件自定义的所谓“驱动”，这几个里面目前原则上不好确定是谁的问题。

这时候就要引入一些经验结果了，社区上对 Windows 11 的评价不统一，但有多少人是一天蓝屏好几次的？一个广泛使用的商业性质的基础软件的稳定版本，有多大可能出现如此严重的缺陷。有没有一种可能，所谓“蓝屏死机概率”，对于五成人基本可以忽略，对于三成人是百分之一，对于一成人是百分之十，对于楼主是百分百？
我暂时的推论是“windows 11 的蓝屏死机概率是不是大幅提高了”这个问题和楼主的故障根本就没有关系。就算 Windows 11 蓝屏概率提高了十倍，楼主把自己系统的那个具体的问题修复掉之后，照样稳如老狗。

> 可能的远因是什么，微软有表态吗？
这个也是经验结果，一般新东西确实比老东西更“不稳定”，然而这是完全正常的现象，微软没有必要“表态”。

替代方案：给你所提到的那些软件提 PR 把你遇到的问题修好 ...
我用 Linux 就时不时这么干，虽然一般不会提 PR ，因为要么就是启用一些 experimental 的功能，要么基本都是些很 dirty 的 hack

说正经的，snippet 工具我一般不用，但是就文档这个功能来说肯定还是嵌入某种实现的 WebView 更方便，但是不一定非要全上 Electron ，因为只有文档显示需要 WebView ，软件的其他部分理论上可以完全 Web-free （ snippet 的高亮应该也可以用 native 方案解决）。
而且在文档方面的话，我觉得文档内容和用来显示文档的壳同等重要。比如我也用 DevDocs ，但是有些东西的文档似乎是由于 license 之类的原因官方不提供，现成的文档有些也不是很方便。所以如果是想做新东西的话也可以在这方面下点功夫。

想起来零几年的时候就看过不少笔记本的广告，有很多就是预装 DOS 或者 Linux 的，也不知道那时候预装的 Linux 是啥，到底该怎么用 ...

"国内的游戏氛围真的太差了"
"国内的*日系（？）*游戏氛围真的太差了"
之所以加个问号是因为我也没听说过楼主讲得都是什么东西，因此无法做出准确的总结 ...

形象地来说，这就好比说“中国的玛雅语氛围真的太差了”“新几内亚的汉语氛围真的太差了”，问题是为什么每个中国人都要学玛雅语，为什么每个新几内亚人都要学汉语？我倒是觉得氛围差才是正常
还不如说“中国的吐火罗语氛围太差了”，至少中国真的有过吐火罗语 ...

之所以会有这种想法是因为十几年来我亲眼目睹我所关注的游戏细分领域随着我这一代人成长起来，从关键技术基本被洋人垄断到中国人贡献半壁江山。其实我和楼主的案例，都是更大世界的一个角落而已，人很容易只看到一小部分，不在意其他的东西，只能说还是得多学习一个。

另外自称“高手”的不说 114%，至少得有 57%是傻逼