硬件实现整数除法具体的算法我不清楚，但是网上大致也可以查到，比如这个
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 代表官方给出了最“友好”的回复，大家的反应友不友好就不好说了。

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

感觉更像测试的问题捏

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

@ysc3839 AMD 最大的问题不是跑不跑得了，是人家根本就没把个人消费者当人看
你要是不管其他条件光是要跑 ROCm 肯定是能跑的，但是 ROCm 到现在不支持 Windows ，虽然我自己天天用 Linux ，几个人真会为这个装 Linux 啊（你别说，貌似还真有 A 卡用户这么干）？这就好比给你一个小目标，但是要强制你带着钞票去一个屁都没有连网都不通的海岛上面去 ...

我刚上去最上面还挂了个新 issue： https://github.com/RadeonOpenCompute/ROCm/issues/2128 Will the RX7900 series be supported? 要知道 7000 系 technically 是去年的卡，然后 ROCm 是自己的软件不存在什么开源社区项目要 review 不能进的问题，现在还没消息就离谱

然后 AMD 你能解释下这个迷之文档页面是怎么回事么？ https://docs.amd.com/category/ROCm%E2%84%A2%20v5.x 为什么 5.5 没有“Getting Started Guide”，而且 5.4 里面该文档的 href 是“//”？
不过我觉得不需要解释，因为点进去就能看到“GPU requirement”只有有限的 Instinct 和 Radeon Pro 型号。反正大客户有问题都是直接一个邮件过去就行，公开页面随便摆烂得了呗？
实际上这问题早就给撕烂了 https://github.com/RadeonOpenCompute/ROCm/issues/887 可能不存在一个人类个体完整地了解 ROCm 究竟支持什么硬件 https://github.com/RadeonOpenCompute/ROCm/issues/1714

作为对比，CUDA 基本从一开始就是随便 N 卡（ G80 之后）什么系统都能用（虽然严格上并不是，因为 NVIDIA 官方提供了 FreeBSD 的驱动，但是并没有提供 FreeBSD 的 CUDA Toolkit ，不过想在 FreeBSD 上用 CUDA 的怕是比 Windows 用户为了用 ROCm 切 Linux 的还要少 😅 而且 FreeBSD 本身有 Linux compatibility 功能，然后根据一些最近的信息好像经过一堆 hack 之后还真他娘的能用 😅😅 https://github.com/verm/freebsd-stable-diffusion 虽然 NV 官方对这问题好像也是一直摆烂）。Intel oneAPI 直接把 N 和 A 的支持也做了。

有小道消息说 ROCm 的 Windows 支持要出来了，但是 ChatGPT 都火了半年了，现在还没出来真就突出一个慢热。这不是一个单独的问题，AMD 整体都这样，X670 皇帝吊死在二仙桥上才几年哪，忘啦！

大概还有给 Martin Odersky 的学生刷 paper 吧 ...

似乎很多人把“疯狂”和“好”划等号
我觉得现在也挺疯狂的

类似的问题 NGA 讨论过了 nga.178.com/read.php?tid=35867636
选择的问题 NGA 也讨论过了 nga.178.com/read.php?tid=35174425

就 3.5-turbo 的效果来说，我觉得它更适合的用法是 Prompt 中给出一些信息，然后让 LLM 基于这些信息构造或转换成另一种形式的信息（中间可能涉及一定的推理）。
比如自然语言写代码就是一类，还有一个我在探索的做法是把自然语言的 etymology 描述转换成结构化的描述： https://gist.github.com/secondwtq/d00ea3a0d88c6098a57b0dba04054466 注意这里面的 etymology 数据是我自己事先从 wiktionary 里面抄下来给它的，你直接问它 etymology 它也知道，但是结果就不那么可靠。Changelog 推过一篇文章把 LLM 比作“calculator for words”我觉得很形象：simonwillison.net/2023/Apr/2/calculator-for-words Think of language models like ChatGPT as a “calculator for words”

当作“搜索引擎”就不太好，反而应该尽量限制它使用 Prompt 之外的信息（当然你可能很享受自己 fact check 这个学习的过程）。主要是 hallucination 太严重了，让它原文引用点东西都是很难的事情，比如这是我拿它搜陆游的诗的结果：

> 《秋夜将晓出篱门迎凉有感》：“三万里河东入海，五千仞岳上摩天。遗民泪尽胡尘里，南望王师又一年。已是悬崖百丈冰，犹有花枝俏冒春。梦得楼台声啾啾，昨夜风雨过后天。”
>《钗头凤·世情薄》世情薄，人情恶，雨送黄昏花易落。晓风干，泪痕残，欲笺心事，独语斜阑。难，难，难！人成各，今非昨，病魂常似秋千索。角声寒，夜阑珊，怕人寻问，咽泪装欢。瞒，瞒，瞒！
> 《卜算子·咏梅》：“风雨送春归，飞雪迎春到。已是悬崖百丈冰，犹有花枝俏。”

鉴定为不如百度。

这可能是 GitHub 的一个灰度更改，我浅度使用下来只能说和原来的比各有千秋
你可以点头像下面的 Feature preview 禁掉

@xitek #9 你正好只 fact check 了一半

大 M 给 CPU 分的是等效 2xLPDDR5-6400 ，正好我回贴的这个机子也超到了 2xDDR5-6400 ，你就算超到 8400 也并不能翻倍。

点阵字体大多感觉在 HiDPI 屏幕上没内味了

楼主想找的可能是类似打字机的字体： https://tug.org/FontCatalogue/typewriterfonts.html

对于这个 case 来说，现代 C/C++/Fortran 编译器对于整数的 div/mod 操作，当除数是整数时是可以直接优化掉的
https://godbolt.org/z/Eo8T56hn5

相对于“字节”来说，“字”的概念貌似不那么绝对
比如现代 CPU 通过 SIMD 能访问 16/32/64 字节的数据，也没人说它是 512 位 CPU
相对来说我更喜欢把重点放在寄存器大小和地址大小上，虽然一般这俩和“字”在数值上是一样的