nlzy

> Debian 11 的 ISO 自带的内核是 5.10, 当时安装的时候就发现不对劲，Wi-Fi 不工作；一番搜索之后才发现我的笔记本网卡是 MT7921 ，要从 5.15 内核才支持。

Debian 有 backports 源，目前 Debian 11 backports 中的内核版本是 5.16

-Werror=vla

@chanlk 上完整代码

直接给结论：如果语句 4 执行了，4 一定能保证读到 a 的值是 42 。A 和 B 线程的执行顺序不影响这个结论。

反对楼上说法的说法：“Happens Before 原则，只提到同一个线程内的连续上下文，并没有提跨方法、跨线程的问题。”

Java 8 语言规范 Threads and Locks 那一章对 Happens-before Order 的第一句介绍偏偏就是：“Two actions can be ordered by a happens-before relationship.”。而 action 一词在那章规范中就专指跨线程：“We will usually refer to inter-thread actions more succinctly as simply actions.”

“这种重排是不可能发生的”，“CPU 某个核心上的指令重排现象”。我认为此处“重排”楼主意指内存乱序。

“多核 CPU 也是可以对指令进行重排的”，“CPU 是可以把指令重排成如下顺序”。我认为此处“重排”楼主意指乱序执行。

仅仅是“重排”这一词的使用就出现了混乱，主楼的其他部分就更不值得细细推敲了。我以为此处的混乱，正是楼主感到迷惑的根源：即使没有乱序执行，store buffer 就足以导致写读乱序。即使指令集架构保证读读连贯，也不能说明微架构没有投机加载。这两个东西就是风马牛不相及。更何况内存顺序是指令集架构定义的，而乱序执行是微架构的具体特性，连抽象层面甚至都不是一个层级。把两个根本不相干的事物混淆在一起，不感到迷惑才奇怪呢！不仅迷惑了自己也迷惑了读者，所以也不怪楼下有老哥留下“一顿胡扯”，“看着头大”的暴躁回复。

一个混乱的问题真的很难去回答，建议楼主可以把自己帖子里的“重排”一词，换成指代更清晰的“编译器重排”、“乱序执行”或“内存乱序”后再重新提问。同时诚挚向楼主安利《 A Primer on Memory Consistency and Cache Coherence, Second Edition 》一书以正视听。

@LeeReamond 外层循环的运行次数肯定少于内层循环。这也是没考虑 sqrt() 对性能的影响的原因，它们的运行次数都远远少于那两个表达式。

看了眼源码，是用试除法计算素数。那汇编都不用细看了，只要编译器不作妖，程序的瓶颈肯定是 l <= t 和 if (c % l == 0) 这两句。和缓存、访存关系都不大了。

虽然有一个 if ，但是这个分支比较好预测：即使是静态预测，每个不同的 c 也只会预测失败一次，所以和分支也没什么关系。循环条件同理。

同一个 c 的每一轮试除，l 是循环变量，而 c 和 t 是不变的，所以上述良好的分支预测再加上投机执行，是可以掩盖掉他们的延迟的，所以程序的瓶颈大概就是 l <= t 和 c % l 这两句的吞吐了。前者是整型转浮点然后比较，后者是一个除法。

上网查资料，zen2 的 div 吞吐率倒数是 13-44 ，zen3 是 7-12 。而 cvtsi2sd 和 comisd 在 zen2 和 zen3 上都是 1 。瓶颈在前者，后者可以忽略掉，而前者在 zen2 和 zen3 的性能差距正好大约是三倍。（浮点和整数除法的执行单元应该不冲突吧）

这大概就是楼主想要的答案了。

至于 mov %rdx, %rax ，寄存器重命名阶段就已经处理掉了，不会是瓶颈。

（唉，我为什么要大半夜不睡觉去分析这种编译器优化都没开，代码也没有仔细写的程序呢）

https://zh.cppreference.com/w/cpp/language/return

自动从局部变量和形参移动

这题也可以看成是 DFA 的典型例题，就像 #15 说的：“作业基本都是这种东西”。而 DFA 和正则表达式可以互相转换，所以构造出 DFA 再一步步转成正则就可以做出来了。

我做了做，得到了 ^(0(11)*0)*(1|01(11)*0)(0(11)*0)*((1|01(11)*0)(0(11)*0)*(1|01(11)*0)(0(11)*0)*)*$

最后的结果我自己也看不懂，这只是我机械地套用公式得到的，所以楼主没必要为看不懂这些正则而灰心丧气啦。