@jfcherng 是，但是还是不如 array_fill 快

@Features 占用区别不大，implode 之前一共也就占 3G ，implode 又吃掉 2G

你这个把 array 的空间在一开始用 array_fill 就分配好可以快不少
虽然这样还是要花上很长时间分配（很可能比后面的 loop 还长），可能是一堆 page fault 导致的。

另外建议把 implode 和写入分开算时间，写入阶段在同样的机器上能差出一两秒

既然没有办法获知真正的具体实现细节（当然现在有一些开源 CPU 代码可以看），那要想更好的理解 spec （不管是一个特定架构的还是不限于特定架构或平台的，general 的 memory ordering 的 idea ）只能建立一个尽可能细致的思维模型来逼近真正的实现，这个模型并不需要与实现相同，它只需要能够自洽地解释“spec 为什么会这么写”的问题就行了。也就是说楼主想要的其实正是 spec 所 “imply” 的那部分。

就特定硬件的实现细节来说，国外也有一些人在做比这个更细节的事，从猜测 die shot ，测量 OoO 结构参数，到研究 microcode 和未公开的接口和优化。甚至还有人翻各种专利加一堆 microbenchmark 凑出来一个 350 页的 M1 分析。猜出来的东西真能和实现对上么？不一定。但是这不重要，有总比没有好。

@dahakawang 楼主问的是“多核 CPU”中 memory ordering 问题的成因，也就是问的就是实现层次的东西。文章并没有特指是哪一个 CPU 。也并没有“假想”“一个”架构，而是在前半部分通过“假想”了“若干”个架构，讲 memory ordering 问题是怎么出现的，后半部分从内存模型的层面（这就不是实现层面了）分析了从 Alpha 到 x86 等若干实际存在的架构，基本套路讲明白了。
要是真就只看一个特定架构的话那倒简单了，直接看 spec 就可以。但是 spec 只是 spec ，不会给你讲什么缓存啊 MESI 啊，根本就没必要关心究竟是怎么执行的，现在重新看一下主题中最后一句话，楼主这个问题的意义在哪里？

去把《 Memory Barriers: a Hardware View for Software Hackers 》这篇文章看一遍

炒股实盘亏了的话就先格局着，然后模拟仓开他个几百万“消费”一下

我也有类似的需求，比如说表情包管理，我存了以 GB 为单位的表情包，光熊猫头可能就有好几千个，远远超过了任何 IM 所支持的上限，并且根本没法索引。
比如我碰到了这么一个表情：
https://i4.hoopchina.com.cn/hupuapp/bbs/201499495486058/thread_201499495486058_20191027002530_s_30528_w_300_h_450_51958.jpg?x-oss-process=image/resize,w_365
我希望能加到统一的表情数据库里，OCR 出文字供搜索，然后 AI “人”脸识别出“熊猫头”打个 tag 。

再比如，各大平台多少都有个“收藏”功能，视频平台有，音乐平台有，购物平台有，连 GitHub 和 V 站都有。现在有一种我正在学习的技术 X ，我在 YouTube 上收藏了一些相关的 talk ，在手机里面找了几集相关的 Podcast ，豆瓣上有几本书，GitHub 上也有相关的仓库，甚至 V 站也可以收藏相关的主题。现在问题来了，问你“如何学习 X”，我得挨个去翻一遍 ... 更糟糕的是，这些平台的“收藏”功能通常都很简陋，连搜索的功能都不一定有，别说什么正则查找 /结构化查找，标签，归类，数据迁移了。所以现在这些功能我都基本不用的。

我还有个生词表，每个单词可能有多个例句，都是平常遇到摘下来的。我不记意思，就看例句记用法。但是就这么简单一个模式也有细节上的问题：同一个例句可能会出现多个生词，我是要在每个生词后面冗余存储一遍这个例句么？我现在想给例句加上来源又怎么办呢？

这些都不是简单的“note”能解决的，也不在通常意义的“PIM”范围之内。

我觉得“多端同步”，至少在目前的条件下，对个人使用是个累赘。所有 2C 的支持“多端同步”的软件基本都希望把这个过程尽量隐藏起来，结果是我已经不止一次遇到“一开始有个项目 A => 在设备 α 上编辑成 A1 => 在设备 β 上，同步完成之前编辑成 A2 => 过两天发现最后给我同步的结果是 A1 或 A2 ，另一份丢失了”这种情况了。所以我压根不打算做同步，就一份数据放服务器上，连不上就不能改。

Chrome 的 Web Inspector 里面有一个 Memory Tab ，可以分析内存占用。

试了一下：
const l = 1000000, data = {}
for (let i = 0; i < l; i++) data[i.toString().padStart(36, '0')] = Date.now()+i;

key 约占 48MB ，也就是说一个 string 48 字节，value 占 12MB ，一个 number 12 字节，再加上外面约 25MB ，一个键值对应该是 24 字节差不多

@moonjourney 没有想到第一居然是 nix

幻影坦克警告

@weyou 是因为大多数数都不是素数，所以外层循环的几乎每个 iteration ，内层循环都要跑大约 sqrt(c) 次，外层循环占得可能不到 1%。

@BrettD
> 我觉得热点显示的 mov %rdx,%rax 这一行是在等上一条 divq 指令的 rdx 余数结果出来

这是数据采集机制导致的误差，关键词 "skid"

这问题在这扯过了 https://v2ex.com/t/828141

@wangtong868 应该叫“犯了一些错误，走了一些弯路”？就是一开始某小而美里看到有张 A4 纸在传说要封两天做核酸，那时候就应该开始屯。但是我当时有个披萨还有几包方便面，想两天应该不成问题。结果两天完了之后说要等结果出来才能解封，这一等又是两天，这两天基本就只有方便面吃了。解了还没一天稍微补了点东西就又开始 2+2 ，直到上周看数据好像“打断”了指数级上升趋势，感觉坏了你沪草台这次可能玩儿脱了。参考其他城市至少得来个 3-5 周。
问题是当时不仅手上没啥东西，方便面也快吃完了，小区也不太可能解封。其实一直到昨天之前有一些外卖是能用的，价格也正常。只是当初觉得没必要动而已。所以转换策略，开始想办法积极屯东西，以适合保存的为主，能吃外卖就吃外卖（这样不会消耗储备），外卖也订冗余量屯起来，能苟一天是一天。
至于到底为什么会有一开始这个预期，这好像就不是本贴讨论的内容了 ...

在浦西某重点区域被封半个月了，因为社恐所以群不多，但是初步总结出了点抢菜套路，刚抢完一单每日优鲜。
我之前也用叮咚，这些线上买菜平台下单基本流程是加购物车 => 下单 => 选择配送时间 => 支付。但是在现在特殊情况下，“选择配送时间”很明显是多余的，因为我 TM 根本不 care 你具体啥时候送到（何况现在这个时间也经常不准时），我只要你未来两天内能到给我补仓就行。
现在每个平台都有自己的开放时间，每个地区可能不一样，这个首先要记住了，然后提前加购物车到点开始演猴戏。
下单失败有可能是多种原因，比如库存没了，运力没了（对于被封的人来说这俩其实没区别），服务器负载过大之类的。
库存没了的话有的 App 会给你自动删掉。可以考虑在购物车中配置不同品牌、不同品种的同一类商品，减少完全买不到这类物品的概率。当然好像猪肉之类的太火爆确实不好抢也没办法，我现在都是用牛肉鸡肉代替的。
运力没了也很常见，个人体验在开放下单之后半小时都有机会抢到配送时间槽，当然一开始比较容易，后面越来越难。需要注意下单的时候他说一个时间槽满了，甚至全天都满了不一定就没机会了，可能下一秒就又可以选了。可能是有人下单失败了之类的原因。
如果他说服务器负载过大的话就更简单，你只需要重复发请求，继续增加他的负载就行了，叫你傲娇~

现在美团买菜玩的最溜，因为这东西的 App 有一个特点就是下单的时候无论出了什么问题随便点就能跳过，不知道是不是无心插柳的结果。只需要每天早上六点打开购物车无脑点击右下角的“结算 /支付”按钮，他会给你弹 N 个服务器忙的 popup ，不过无所谓只要继续点同一个位置就会关上重试，进入结算页面之后还需要选择配送时间，你不需要去点上面去选择，因为继续点支付就可以弹出配送时间列表，而支付按钮的那个位置正巧有个时间，没满的话继续点就可以，选择配送时间也不是百分百成功，依然会有 N 个服务器忙的错误，但是无所谓，继续点同一个位置重试，直到成功锁单进入支付界面。可见整个流程中唯一的工作就是“不断点击手机屏幕右下角”，不断重试请求，越快成功率就越高——而这个动作对于长期单身的年轻男性来说是很友好的。

叮咚的“选择配送时间”这一步有点迷惑，暂时没搞懂他的逻辑。每日优鲜是需要稍高的手眼协调能力来快速完成选择配送时间的操作。大润发在运力满的时候按钮直接是灰的，感觉不太好搞。这几个一般是运力紧张，其次是库存。盒马每次看总是缺货，而且并不是所有地方都能送货。

因为第一周没怎么准备被饿出了 PTSD ，所以现在只要价格合理有机会就下单。最近两天成功率还蛮高，也许是因为这边封久了稳定之后抢菜的客观难度下降了。
现在问题是冰箱塞不下了 ...

“透过 Rust 探索系统的本原：泛型” 这个链接错了吧

大陆北方网友提着酱油瓶路过