协程之间的切换是一个物理线程/进程内部，用户态进行上下文之间的切换。通常协程上下文用使用双向链表链接，其个数由程序员决定。协程切换（设定为yield_thread函数)的代价+ 跳转延迟大约在20个周期左右，L2 延迟在 12个周期，L3延迟基本在50个周期，内存延迟在100ns（3GHZ，300个周期 ）， 所以我们在一个进程内部引入多个协程，例如15个协程？（15 *20 周期等于内存访问 300个周期）

数据会由于三种原因执行 yield_thread函数：
1. 在取指令之后，根据指令地址预测是否产生数据L2缓存缺失，如果预测缺失，允许当前指令继续运行，但是对于内存的操作改为prefetch, 协程再切回来后重新执行该指令。

2. 在执行过程中，当得到内存地址之后，此时有更准确的预测能力，使用类似bloom filter的方式，开始做第二次预测，如果预测L2缺失，前端对yeild_thread函数再次取指，同时将内存操作变为prefetch,等到协程切回来再重新执行。

3. 若虽然预测命中，在发现L2缓存缺失的时候，前端对yeild_thread函数取指进行协程的上下文切换，同时不再等待指令返回，等效于跳转预测失败，再次切换回来时重新执行对应指令。

指令会由于二种原因执行 yield_thread函数：
1. 在取指令过程中，当得到指令地址之后，开始做第一次预测，如果预测L2缺失，前端对yeild_thread函数取指，保存上下文,等到协程切回来再重新执行。

2. 指令若预测命中，在发现L2缓存缺失的时候，前端对yeild_thread函数取指进行协程的上下文切换，同时不再等待指令返回，再次切换回来时重新执行对应指令。

注：无论数据还是指令产生的切换，当再次切回来时，默认指令/数据已经在缓存，除非发现真实缺失再做切换。

- 来自 水木社区APP v3.4.2
--
修改:MaLing FROM 42.120.75.*
FROM 42.120.75.*

“看着有点蒙，你这是把协当线程用了？”
Ling：嗯，因为超线程需要引入硬件代价，且数目受到控制，在这里引入协程，以缓存缺失作为切换事件。

1. 进入yield时 寄存器保存的细节。随时打断的方式下，寄存器得全部保存吧？
Ling: 是，15个寄存器（不包含simd寄存器）
2. 如果协程持锁时因为cache miss被打断了，会怎么样？
Ling：可以进入不被打断模式
3. 很多协程yield出去的时候是要传递参数的，比如generator模式。
Ling：没有，本质上与Linux kernel的 schedule(void)函数相同

【 在 kirbyzhou 的大作中提到: 】
: 看着有点蒙，你这是把协当线程用了？
: Yield从用户显式调用变成了随时打断。
: 几个问题
: ...................
--
修改:MaLing FROM 42.120.75.*
FROM 42.120.75.*

这是在一个In-order core上用的吗？
感觉如果在Out-of-order core的话，每次L2 miss就切协程，相比一次性把一个thread内连续的多个访存指令全发射出去，性能会恶化地比较厉害。

【 在 MaLing 的大作中提到: 】
: 协程之间的切换是一个物理线程/进程内部，用户态进行上下文之间的切换。通常协程上下文用使用双向链表链接，其个数由程序员决定。协程切换（设定为yield_thread函数)的代价+ 跳转延迟大约在20个周期左右，L2 延迟在 12个周期，L3延迟基本在50个周期，内存延迟在100ns（3GHZ，300个周期 ）， 所以我们在一个进程内部引入多个协程，例如15个协程？（15 *20 周期等于内存访问 300个周期）
: 数据会由于三种原因执行 yield_thread函数：
: 1. 在取指令之后，根据指令地址预测是否产生数据L2缓存缺失，如果预测缺失，允许当前指令继续运行，但是对于内存的操作改为prefetch, 协程再切回来后重新执行该指令。
: ...................
--
FROM 66.42.53.*

【 在 MegaStone 的大作中提到: 】
: 这是在一个In-order core上用的吗？
Ling:乱序也可以
: 感觉如果在Out-of-order core的话，每次L2 miss就切协程，相比一次性把一个thread内连续的多个访存指令全发射出去，性能会恶化地比较厉害。
Ling：是的，如果有这种场景避免切换就好，例如大量simd指令的向量计算
:
--
修改:MaLing FROM 42.120.75.*
FROM 47.251.4.*

你们太小看协程了。

协程自然是让异步编程变得更好看。还有更多的好处：

仅从语法角度看，协程避免了异步编程中到处乱飞的 closure, context 变量，可以非常有效地减少编程错误。让数据的生命周期变得简单明了。

对于 c/c++ 而言，还能额外获得效率的提升。协程代码一般局部性更强，分配变量时可以更多地分配在栈上面以减少内存复制开销，说不定带来更低的 cache miss. 如果有对协程特别支持的语言，还可以考虑协程运行过程中申请的内存都延迟到协程结束的时候释放，代替开销巨大的 gc 和 malloc/free.

介绍一下我的协程库: https://qtng.org/

【 在 winfredsu (winfredsu) 的大作中提到: 】
: L2 miss的没见过，协程优化LLC miss的工作17年开始在VLDB上出现过，原理大概和你说的一样，发一个prefetch之后就yield, 可以参考这篇文章：https://infoscience.epfl.ch/record/231318
: 这个方法对于几个GB的树结构访问情景，LLC miss概率较大，可以有明显收益；但是我感觉有两个问题：
: 1. 这种能“较好预测LLC miss”的场景是否有很多？基于DRAM的数据库是一个好场景，但是还有没有更普遍的？
: ...................
--
修改:hgoldfish FROM 110.81.41.*
FROM 112.47.122.*