你这个把 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 》这篇文章看一遍

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

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 探索系统的本原：泛型” 这个链接错了吧

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

我国是社会主义市场经济国家啦，不能随便强迫的
说实话只是体制内的话，理论上可以不用微信的，有资源搞国产 Linux ，搞个猴（增）版（强）微信应该不难

百度 CHH 清零哥 ...