7.4G 的数据量，即便不考虑内存不够的情况，也有可能是内存性能 bounded 的原因，不妨试试比较用 cache 大小的数据量进行多轮 benchmark ？

最近刚做了爸爸，真是看不得这样的事情，楼主节哀。。

哈哈，睡太晚了发觉居然把文章名字搞混了，我上面是说《 Memory Barriers: a Hardware View for Software Hackers 》另一篇不少人推荐的教程... 但是结论不变 :-)

看见很多同学推荐了 A Primer on Memory Consistency and Cache Coherence 。这是个很好的教程，但是它可能不能直接用来回答 OP 的问题。因为全文是基于一个假想的 CPU 架构（或者说，至少实现上不见得是和任何一种现实的 CPU 完全一致的），一个例子是随着教程引入了 store buffer 和 invalidate queue 的概念之后，在文中所述的架构中，例子代码需要添加两个 barrier 才能确保正确(section 4.3)，然而在 x86 下那两个 barrier 并不是必要的，因特尔关于他们内存模型的白皮书中有过一样的例子。。。

所以除非 OP 真的只是在讨论某一个教程中的架构，如果我们要讨论任何一个真实的架构的话，就回到我之前的观点了，对于 OP 的问题解答，我们很难去诉诸某个架构的某个 specific implementation （ store buffer 也好，invalidate queue 也罢），因为外人很难知道 CPU vendor 具体的实现是啥。唯一公开的只有前文提到的那个约定， 或者叫它某个 CPU 架构的内存一致性模型，OP 的问题可能只能诉诸于具体某个架构实现的某种一致性模型。（当然，模型反过来也某种程度上 imply 了实现）

这个和缓存的一致性协议(e.g. MESI)没有关系，主要是和 x86 的内存一致性模型的约定有关。

为了实现的简便，或者优化的方便，计算机领域一个非常重要的 trick 就是[as if rule]( https://en.wikipedia.org/wiki/As-if_rule)。编译器和硬件可以不按照实际的程序 /指令执行，只要最终不会产生**软件可以观察到**的差异就行了。

具体来看，如果我们更多的在聊 Intel 的话，x86-TSO 的内存一致性模型主要有下面这么几个约定，而 OP 的例子正是很多人用来说明第 4 点的比较常用的例子：
1. Loads are not reordered with other loads.
2. Stores are not reordered with other stores.
3. Stores are not reordered with older loads.
4. Loads may be reordered with older stores to different locations but not with older stores to the same location.

仔细想想，这样的约定正是尽量较少软件可观察的差异体现。作为软件，我们期待写一个变量下一次读出同样的值，所以约定 Store/Load 在同一个内存地址不会有 reorder 。与此同时，写一个变量然后读取另一个变量会有 reorder ，这似乎对软件产生的麻烦就小很多。


最后，为啥非要 reorder ？那当然是硬件那边优化和实现的考虑了，CPU 一般会通过[store buffer]( https://en.wikipedia.org/wiki/Write_buffer)来批量写内存提升效率，不难想象，Store/Load reorder 的存在，不就是顺理成章的事情了嘛。当然，这里对为什么这么约定的解释，更多只是举一个例子的意思，没人真正知道这是不是 Intel 选择上述约定的动机或者唯一动机，重要的只是这个约定是啥样，和我们如何用这个约定解释程序行为。

https://bford.info/pub/net/p2pnat/index.html -- see "TCP Hole Punching"

and this is by far the most interesting thing. wit

想起了之前也有类似的案例： https://www.zhihu.com/question/308203318

这里的都试过么？
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options

是不是在 tmux 之类的 multiplexer 里面？

最近发生好几次了
https://help.aliyun.com/noticelist/articleid/20505354.html?spm=5176.789004748.n2.11.SIwiJl
https://help.aliyun.com/noticelist/articleid/20547657.html?spm=5176.789004748.n2.19.SIwiJl

工作组间多休息，搞个番茄工作法，定时提醒提来走动。当然要得根除得坚持锻炼，实在没空在家里跟着 app 做些基本动作也成。

以前挺喜欢用 notenote，后来觉得封闭的格式不太好掌控，于是转向了 markdown。现在好多基于 markdown 的笔记 app，既支持图片表格公式之类的东西，也支持代码高亮，流程图什么的，还是挺方便的。

最主要是格式透明，用着比较放心，偶尔还能根据自己的需求折腾一些脚本啥的。这种核心功能和周边功能分离的模式挺适合一些人的，例如多平台同步、笔记版本控制，渲染风格之类的需求，选择余地也自由些。

放到头文件中定义的成员函数被include之后，在main.o和vtkOBJWriter.o中的确会有两个同名符号vtkOBJWriter::writeMtllib，但此种情况下，vtkOBJWriter::writeMtllib会被编译器置为weak symbol，所以后来linker看到两个同样的名字不会报错，只是随便选一个。

同样在头文件中被include的template实现也有类似的机制。