一个典型的例子是 Haskell 的 GHC 编译器，这货（所编译出的程序）在版本 8 之后就是开局分配 1TB 的虚拟内存空间。这是对应的 tracker：gitlab.haskell.org/ghc/ghc/-/issues/9706 #9706: New block-structured heap organization for 64-bit · Issues · Glasgow Haskell Compiler / GHC · GitLab
根据这个 issue 的描述，在之前，GHC 的 allocator 会首先向 OS 申请叫做 megablock 的较大块内存，然后再分成叫做 block 的较小块内存，之后在 block 中处理具体的分配请求。而现在不需要 megablock 这个概念了（或者说只有一个全局的 1TB megablock ），大大简化了实现。

这么做最明显的好处之一是，由于 GHC 使用 tracing GC ，在 GC 时需要检查一个指针是否指向堆中的数据（ gitlab.haskell.org/ghc/ghc/-/wikis/commentary/rts/storage/heap-alloced heap alloced · Wiki · Glasgow Haskell Compiler / GHC · GitLab ），因为可能有许多个 megablock ，这个检查在之前是非常麻烦的——他们实现了一套 cache 机制，我觉得很像软件层的 TLB ，先用 tag 去找，找不到再去到表里面搜。而现在只有一个 megablock ，只需要一个全局变量记录它的地址，直接检查是不是在它的 1TB 范围内就可以了（这个应该还可以继续优化，因为理论上你可以向 OS 提出特定的对齐要求，这样直接一个 bitwise-and 搞定）。实现者声称在一些 benchmark 上获得了 8%+ 的提升。注意这个不是靠减少 syscall 得到的。
当然，由于没有了 megablock 的概念，malloc 和 free 的过程也被简化了。

当然，这个 trick 首先需要地址空间足够大，所以只能在 64 位环境下使用。
另外在 Windows 上的实现有些不同，因为 Windows 的 memory overcommitment 似乎和 Linux 上不太一样。

之所以要提 Windows 不只是因为原 issue 上重点关照了这方面，还是因为之前我关注到网络上的一些言论，说最好不要彻底关闭 Windows 的 pagefile ，会导致很多软件出问题，甚至包括 MSFT 官方的一些软件。我一直都很好奇，按理说有没有 pagefile/swap 并不是软件应该关心的问题，如果我 8GB DRAM+8GB pagefile 能正常工作，16GB DRAM 不带 pagefile 不应该更差。看到这个问题就觉得可能跟这个有关系。我的推测是 Windows 下的很多程序可能比较喜欢以当前系统的 DRAM 大小为系数来预分配内存，这样所有程序想要分配的内存总大小很容易超过 DRAM 大小，就必须要 pagefile 来兜个底。但是网上的建议是你哪怕开几 MB 的 pagefile 创建一下全国文明系统都不要彻底关掉，如果真的只有几 MB 的话就没啥作用了。不过 Windows 默认的 pagefile 设置是“系统自动管理”，不够的时候会自动扩容（虽然最多只能 3x DRAM 大小），并且 NTFS 还支持 Sparse file 。另一个因素是现在 Windows 主流软件几乎全员或多或少都要 GPU 加速，而 DRAM 和 VRAM 之间的数据传输也需要 memory map 。还有一个则是根据官方文档，Windows 的 CreateFileMappingW(INVALID_HANDLE_VALUE, ... （类似 MAP_ANON ）是"backed by the system paging file"，而在 Linux/BSD 上直接出来就是 anonymous page ，但是 Raymond Chen 澄清过（ bytepointer.com/resources/old_new_thing/20130301_058_the_source_of_much_confusion_backed_by_the_system_paging_file.htm The source of much confusion: "backed by the system paging file" ）这个有很多误会，"backed"是指"page out 的时候会扔到 pagefile 去"，这样得到的内存空间其实和 Heap­Allocate/Virtual­Alloc() 是一样的，也就是说基本是一句废话。目前我没有时间或者没有方法来验证这些猜测，所以这个问题到现在还没搞明白，不知道 V 友有没有清楚具体原因的。

Windows 下还有更加生草的问题——和楼上所关心的“操作系统付出的代价”密切相关。由于 GHC 采用了这种新的内存管理模式，在老版 WSL 上会莫名奇妙地慢到不可用：github.com/microsoft/WSL/issues/1671 `stack ghc` painfully slow · Issue #1671 · microsoft/WSL · GitHub 这个问题后来貌似被修复了，不过可见虚拟内存大小并非在所有情况下都无所谓。上面有人说开发板也可以跑，前提也是开发板的软件是比较成熟的。

此外 Google 的 Go 实现在某些版本似乎也有类似的机制。至于 Chrome 这个事情，https://unix.stackexchange.com/a/741548 Why Google Chrome is reserving Terabytes scale virtual memory? 这个回答指出这和 V8 引擎在近年实现的一个新的安全功能有关。V8 中的一些 bug 可能允许攻击者利用 V8 内部代码实现内存读写，因此这个新的机制会预先分配 1TB 的虚拟地址空间，并将 JS 程序的数据全都分配在这里面，地址则使用 40-bit 数存储。这样就把类似攻击的影响面限制在了这 1TB 范围之内。

最后必须批评类似话题常见的一种风气——对你没有影响就不用管，这属于问了 Y ，然后回答者自作主张去回答 X 。典型是这个帖子：reddit.com/r/linuxquestions/comments/w4im5m/chrome_using_11_terabytes_of_virtual_memory 这里很明显这个 sub 的平均技术水平一般——不清楚虚拟地址空间概念的比比皆是，不过鉴于本身就是 /r/linuxquestions 倒也没啥奇怪的。但是就算虚拟地址空间占用对用户没有什么意义，为什么别的进程都很正常，就你 Chrome 搞特殊呢？这本身就是个很有趣的问题。

西方的社交网络也在开倒车，看看 Twitter 和 Reddit ...
还是多多关注联邦式平台之类的吧

> 因为网上总有很多喷子杠精，去翻你的历史，一字一句的分析，然后跑来莫名其妙的攻击你，很烦
你会发现匿名了也会有“人”说你这么牛逼为啥匿名 :)

建议不要只看“源码”。
可以使用 git blame 和 commit message 搜索找到如下几个 commit：
github.com/codemirror/state/commit/76d8735feb5821848fa9af551eb39c0dd0ad60b9 Use 1e9 instead of 2e9 for big integers · codemirror/state@76d8735
github.com/codemirror/view/commit/b5aa501bab1675221553780cd071b93eedb387f2 Use 1e9 instead of 2e9 for big integers · codemirror/view@b5aa501

可见这个数以前是 2e9 。作者给出的理由只有一句话：
> Several engines apparently store only 31 bits in smallints
smallint 可能是指 SQL 里的那个，但是鉴于 CodeMirror 和 SQL 除了一个编辑支持之外就没啥关系，并且“engine”加上“several”和“store”指的应该是一个实现层级的东西而非 SQL 这种接口层级的。那个人猜测应该是指 JS 引擎里的 small integer 优化，这对于实现 Uniform Representation （ https://v2ex.com/t/632869#r_8401400 ）是必要的。
假设一个 32 位的 Uniform Representation ，其中一位用于区分 pointer 类型和 small integer 类型，用于存储 integer 的就只有 31 位，再加一个符号位的话一个 small integer 的绝对值最大就是 2^30 ，差不多就是 1e9 。
楼主给的 StackOverflow 链接中大多数的数字似乎是关于“某个编辑器在特定环境下可以打开某个大小的文件”的，和“某个编辑器理论上可以打开文件大小的最大值”关系甚微。也就一个 EmEditor 的数字“up to a 248 GB limit (or 2.1 billion lines)”算得上一个理论值，这个大概是 EmEditor 用了 signed 32-bit integer 存储行数。

顺便我觉得“开源”只开放“源码”是不完全的。很多信息都隐藏在 VCS history ，issue tracker 和 code review 的过程中。源码只是个成品，它本身很难回答“为什么”的问题。社区驱动的中大型开源项目的源码反而会比较易读，就是因为这些源码之外的信息比较丰富，并且更难出现类似本主题这样的代码质量问题。毕竟这种项目里面，你想改任何的代码，都需要以书面形式说服社区 a) 你为什么要改？ b) 你为什么要这么改？

这个主题颇有 The Old New Thing 的观感

新的 Teams joke ...

感受：楼主的描述与我的刻板印象相冲突

一般来说，前端才是喜欢折腾“雅”的，后端就喜欢硬糊

首先目前 Gamedev “开源”的实践典型是，引擎代码 GPL ，美术音乐素材专有。IMNAL ，不过我觉得有个问题是 GPL 要求发布的东西是“all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work”，它关心的一直在 executable 层次，也就是说它明确保证的只有：你能 build 出 executable ，你能修改代码之后再 build 出（改过的） executable 。GPL 原文并没有定义什么是“executable”，而从技术层面理解的话这个词对不同场合的 applicability 是有区别的，比如天然最适合 C/C++ 等编译型语言。

从 executable 到一个完整的游戏（产品）中间是有很大的空间的，这中间包括但不限于素材，本地化文本，关卡地图，脚本等。很多简单的 mod 就是改个素材或者改个数值，从软件开发的角度理解，这些属于“配置”或者“输入数据”的范围，我 GPL 了我的网站前后端源码，但是几乎没人 GPL 数据库里的用户数据。这个是可以理解的。

但是作为程序员都知道，“代码”和“数据”并没有明确的分界线，所以这里我觉得是个灰色地带。就算配置不具备图灵完全的能力，一些比较复杂的配置也能“模拟”简单程序的效果，我该不该开源我的“配置”？

以上是主要从游戏的角度出发来分析，因为游戏里面，除引擎核心之外的东西实在是数量巨大种类繁多，因此我觉得这个问题是比较复杂的。传统的软件产品反倒是比较单纯，我比较了解的一个是 Blender ，Blender 本身是 GPL 的，而因为它是个用户群很大的 DCC ，它的第三方二次开发社区也很活跃。其中有一个做插件商店的网站 BlenderMarket ，算是圈内有一定影响力的。在该网站上发布内容需要选择 license ，网站只提供有限的选项：support.blendermarket.com/article/54-available-licensing-options 其中对“asset”类和“code”类是分开处理的，“code”类只允许选择 GPL 或 MIT license 。能用 MIT 应该是因为 MIT 是 GPL-compatible 的（可以直接 relicense 成 GPL ），但是具体的原因网站也并没有给出解释，我觉得区别大概在于用 MIT 的话，其他和 Blender 无关的非 FOSS 项目也可以引用其中的代码。（最神奇的是这些东西虽然法律上是开源的但是还是很多人去付费）
类似的项目还有很多比如 WordPress ，不过这些项目的具体情况我就不怎么了解了。
（现在又出现了新的风暴了：AI 模型的权重、数据集等 ...）

另外就是建议不要仅仅停留在 x86 上，可以看看 ARM 之类的，现在资源也丰富起来了，以及一些资料较少，但是也很有意思的较新的架构比如 RISC-V ，甚至是已经淡出主流的架构比如 Alpha ，很多设计上的选择很有启发性（也包括传统 CPU 和其他处理器比如 GPU 的架构设计也有很有趣的区别）

学习任何东西最好的办法是实践，就好像学英语要坚持有效的输入输出
当然怎么实践有学问，比如学 C#，可以先拿 C# 刷几道 LeetCode 熟悉基本用法，写几个小工具之类的，但是到后面取决于你要做什么，搞 Web 服务，做 Windows 程序开发，做游戏等涉及到的库和知识体系是有很大不同的
汇编也一样，如果你是想操作硬件那就试着写个 bootloader ，研究开源 OS 中一些 Arch-specific 的设计和实现，做安全就去解 crackme
我一开始学汇编是想着搞点逆向，后来是研究编程语言语义的实现，再后来是做程序优化，结果都搞了个半吊子，现在 jl je jnz 都分不清楚，但是干活勉强够用

@secondwtq 贴错了，倒数第二个 URL 是这个： https://www.v2ex.com/t/845257

硬件实现整数除法具体的算法我不清楚，但是网上大致也可以查到，比如这个
stackoverflow.com/questions/71420116/why-is-there-only-little-difference-in-integer-division-throughput-with-larger-v performance - Why is there only little difference in integer division throughput with larger values on AMD Zen? - Stack Overflow
但是总的来说整数除法比乘法的算法要复杂得多，并且似乎只能一点点算，所以不同长度有可能有可见的区别，并且一般较老的硬件问题更严重：
https://uops.info/table.html?search=idiv%20r&cb_lat=on&cb_tp=on&cb_uops=on&cb_ports=on&cb_SKL=on&cb_ADLP=on&cb_ADLE=on&cb_ZEN2=on&cb_ZEN3=on&cb_measurements=on&cb_doc=on&cb_base=on
另一个相关的问题是浮点 SIMD 除法，部分硬件上性能也可能和向量长度相关（很少有架构提供 SIMD 整除指令，一般都是用软件实现）：
https://uops.info/table.html?search=vdivp&cb_lat=on&cb_tp=on&cb_uops=on&cb_ports=on&cb_SKL=on&cb_ADLP=on&cb_ADLE=on&cb_ZEN2=on&cb_ZEN3=on&cb_ZEN4=on&cb_measurements=on&cb_doc=on&cb_base=on&cb_avx=on&cb_avx2=on&cb_avx512=on

一个特例是除数为整数的整数除法，编译器会做优化，避免使用硬件除法器：
https://v2ex.com/t/933790#r_12971302
如果楼主的程序是这种情况一般性能会更好。不过我没有研究过这个在不同长度下的性能表现，楼主可以写个小 case 扔进 uiCA/llvm-mca 里面试试

当然最吼的还是都 profile 试试，这个除法操作是不是瓶颈：
https://v2ex.com/t/933790 https://v2ex.com/t/828141

大概是学校自己编的 C 语言教材，花了一周看了一遍从不怎么会编程到勉强会编程
再也没有单独的一本书能做到如此大幅度的提高了 ...

那段时间还把酷壳所有能勉强看个热闹的文章刷了一遍
R.I.P.

@424778940 你的阅读理解也不太到位的样子

> 先是在 forum 里，又在 V 站阴阳怪气人家，真心显得有点小家子气。

我觉得你有点小家子气不是针对你明面上在 PR 中后半部分的回复，而是你在 PR 之外，背后针对 dissent1 的言论。
有人点赞不代表是完全合理的，美国这两次大选两党都有一半人支持呢。我也没有说过没人支持你。

> 我作为一个用户在使用 stable/release 版本的时候遇到了这个问题, 导致我的设备无法正确重启, 你漏读了这个关键信息
我当然知道这是个 stable 版本中的恶性 bug ，但是按照正常的软件开发流程，他们就算 revert 了也必须等到下一个 release 才能修复最终用户的问题——这不是 OpenWrt 自己专属的规则，绝大多数软件都是这么搞的。当然你可以出个 KB 或者紧急 hotfix 之类的，但是限定到开源项目，基本是没有这个机制的，hotfix 基本只在个别情况下用在严重的问题上。
而 OpenWrt 的情况是它支持的环境很多，每一个环境都可能有问题，在这种情况下，你这个硬件的问题再严重，从全局来看也只是个 corner case ，不值得专门出个 release 。要是每个类似的问题都单独一个 release ，走一遍流程（ https://openwrt.org/docs/guide-developer/releases/release-process ），反倒是对开发资源的严重浪费。这和有没有现成解决方案根本无关——假设一个有人提 issue 但没有解决方案的场景，修复问题的成本是寻找解决方案的成本 + release 的成本，现在有解决方案只是把前面一部分省掉了，后面的一直都有，非必要情况下都是要有很多个 commit 把 release 成本摊平。而在 release 之前，他们是有一段时间研究问题的。

你是站在用户的角度上，认为要尽量满足用户端的需求。但是现实中无论什么软件，实际都会表现出用户需求和开发进度的一种平衡。就算是商业软件，也是关键大客户能拿到更高的优先级和专门修复问题的内部 build ，普通用户只能在 forum 里面打嘴炮。我觉得区别只是商业软件相对于开源软件这个平衡会更倾向用户一点而已（这也是商业软件比开源软件更适合普通用户使用的原因之一）。
你如果因为这个对 OpenWrt 失望的话，那大概没有几个软件的开发流程是像样的了。大多数软件都是攒若干个 commit 再发版的模式，每个 commit 都可能针对一个或几个 corner case ，难道都要拆出来？就算是滚动更新模式也没有一个 commit 一版的说法。

我觉得你和社区的根本分歧可能是在这个问题是个绝对严重的 blocker ，还是个 corner case （我认为它是个 corner case ，只是触发时很严重）。这个可能没有在 PR 里被显式地讨论过，而是变成了双方默认的 assumption 。
诚然 OpenWrt ，或者开源社区整体在这方面的流程有可以改进的空间，但是很大概率这会引入额外的成本。开源社区可能只是选择了（他们认为）能够更高效利用开发资源的一种方式，而对用户选择保证“最终一致性”。还是那句话，一般商业软件用户重一些，开源软件开发者重一些，这并不能滑坡为开源社区对用户的态度差。

不到 4G 内存 2G 多的 hugepage

热榜看到的来挖个坟

#19 提到的社区问题，我本来想说的是个人开源社区相对会比较乱，相比来说大公司开源社区至少表面上会更和谐——成员部分代表公司形象，真闹出事情是可能要出 PR 问题的。点进去看了一点发现这个角度根本不适用，因为这个例子就是正常任何开源项目都有的日常扯皮——或者说是任何社会都有的日常扯皮。

当然我只看了几楼，因为 #19 所说的“PR 原作者” dissent1@GitHub 在 issue 里只是在开头发了有限的几个回复就脱离了，后面都是其他的调试过程。dissent1 基本上只是表达了“WAR over WAR”的观点，以及提供了一些 fix 问题的附加信息。并没有感觉到 dissent1 的态度比 #19 要差，也没有出现 #19 回复中“你干嘛碰我代码?”和感叹号这种强烈的情绪表达。但是看得出来双方都跟社区主流开发者不太合拍。
整个 thread 中的感叹号只会出现在两种场景："Thanks!" 和 shebang 。总体氛围还是非常亲切友好的。

解释一下这个"WAR over WAR"：“WAR”似乎是某种黑话，是 Workaround 的意思。这黑话可能是 OpenWrt 社区专属的，但我觉得更像是 dissent1 个人的，从没在其他地方见过。不过英语 native 普遍喜欢 TLA (Three-Letter Acronym) 是真的，我在单位的 acronym 数据库里面真找到了这个用法 ... 虽然真没见有人用过。
情况大概是 dissent1 原本的 patch 是有问题的——没有解决任何问题反而引入了新的问题（这个 patch 本身似乎是以一种“WAR”的方式试图解决问题，但是这个 WAR 本身又没做对）。#19 希望将其 revert （"WAR over WAR"）。而包括 dissent1 在内的社区开发者则认为不着急 revert ，而应该以“proper”的方式来 fix 。（另外这种和硬件（或其他具体环境）相关的项目的一个现实问题是经常出现开发者不具备特定的条件所以测试比较麻烦的情况）

社区的理由是原 patch 已经进了 release 很长时间，而在一个没人会日常用的允许不稳定的 dev 分支里，相对于直接 revert ，不如去“proper”地 fix——除非在下一次大版本发布之前找不到一个“proper”的方法。社区开发者 981213 和 ynezz ，在要求 #19 提供规定所需的签名后，主动把 Revert 加到了 OpenWrt 18.06.3 的小版本更新分支里面了（上一个版本 OpenWrt 18.06.2 是 1 月发布的，18.06.3 是 7 月发布的，楼主的 PR 是 5 月提的，revert 进分支是 6 月的事）。
然后 TA 们试了半天似乎找不出个“proper”的方法，所以暂时只能 revert 。（很长时间后似乎有人解决了个相关的问题，是不是彻底把问题解决了就不清楚了）

从我个人的角度我认为双方都是有一定道理的。有些项目确实 patch 出问题就要直接 revert ，部分是因为开发工作严重依赖全自动的测试，然后就有测试结果全 clean 的追求，只要 break 了测试的 patch ，哪怕是在 dev 分支，也会给别人造成麻烦。但是如果社区认为问题不对开发工作造成障碍的话，跳过 revert 而优先寻找解决方案也是可以理解的。

我觉得这个事情就是不同的社区的规矩和习惯不一样而已。倒是 #19 难以接受其他人与其观点不同，先是在 forum 里，又在 V 站阴阳怪气人家，真心显得有点小家子气。
至少从这个 issue 而言整体还是比较平等的，用户不熟悉规矩，开发者会耐心地解释（开发者的长度基本都和 #19 类似或更长，甚至有个别长篇大论），用户也会帮助开发者测试。要真说成熟的多方平等合作的开源社区有啥问题的话，大概就是没有一言堂，没人说了算（甚至这种项目会出现开发者求用户帮着测试的情况），没有领导按着你头说必须怎么干，所以大家都不知道该怎么干，扯皮出的解决方案总免不了有人看着有问题，然后自己又没能力改变，还不能给自己一个“老板已经拍板了”的接口当安慰剂。

当然这仅限于“多方平等合作”的项目，开源项目的开发工作本质上是垄断的——垄断成本很低，你自己 fork 一个就是（有没有人用两说了）。我开始说大公司至少表面上会比较友好，另一面嘛 ... 举个例子，我前两天说过的 ROCm ，https://github.com/RadeonOpenCompute/ROCm/issues/887 这个 issue 里面 Rmalavally 代表官方给出了最“友好”的回复，大家的反应友不友好就不好说了。

无线网卡有些牌子支持差，有线网卡还没被坑过。
浏览器视频硬解可能是个坑。

感觉更像测试的问题捏

说一个未来的，人类的灭亡，可能不是“劲往一处使，心往一处想”，但是每个人都会参与。