水木社区手机版
- 主题:基于协程的异步化内存访问优化
- L2 miss的没见过，协程优化LLC miss的工作17年开始在VLDB上出现过，原理大概和你说的一样，发一个prefetch之后就yield, 可以参考这篇文章：https://infoscience.epfl.ch/record/231318
这个方法对于几个GB的树结构访问情景，LLC miss概率较大，可以有明显收益；但是我感觉有两个问题：
1. 这种能“较好预测LLC miss”的场景是否有很多？基于DRAM的数据库是一个好场景，但是还有没有更普遍的？
2. 本质上相当于在线程内部构建了一个状态机，并发处理多个请求，而这不用协程也是可以实现的（参考上面的论文）。用协程只是让编程更好看，还能得到不错的性能。
--
FROM 119.8.242.* - 这些优点是异步IO场景里，的确也是协程的本意。但是楼主这里讨论的是更细粒度的cache miss（把访存也看成异步的）能否用协程解决，是在拓展协程的使用场景。
我上面说的是在这种细粒度的场景下，是否就不涉及到闭包和内存分配的优势了? 我硬件做得多，对异步编程模型了解不深
【 在 hgoldfish 的大作中提到: 】
: 你们太小看协程了。
: 协程自然是让异步编程变得更好看。还有更多的好处：
: 仅从语法角度看，协程避免了异步编程中到处乱飞的 closure, context 变量，可以非常有效地减少编程错误。让数据的生命周期变得简单明了。
: ...................
--
FROM 103.218.216.* - 理解了你的意思，还是希望硬件动态做预测，多谢解释。不过主要挑战应该会在这个预测器上，如果基于PC好预测的话，那么大概率这个信息在静态也能得到；如果是基于访存地址的bloom filter, 需要设计一种在cache evcition时能从bloom filter中“去掉一个项”这样的操作。
【 在 MaLing 的大作中提到: 】
: 1. 这种能“较好预测LLC miss”的场景是否有很多？基于DRAM的数据库是一个好场景，但是还有没有更普遍的？
: Ling：不仅仅是数据库，根据我们计算CPI的公式显示，作为数据中心服务器的workload的瓶颈主要来自于L2 指令和数据的缺失，数据显示访问L3命中的延迟和缺失导致的内存访问延迟各占据CPI的30%，共有60%
: 2. 本质上相当于在线程内部构建了一个状态机，并发处理多个请求，而这不用协程也是可以实现的（参考上面的论文）。用协程只是让编程更好看，还能得到不错的性能。
: ...................
--
FROM 219.134.218.*