1. 这种能“较好预测LLC miss”的场景是否有很多？基于DRAM的数据库是一个好场景，但是还有没有更普遍的？

Ling：不仅仅是数据库，根据我们计算CPI的公式显示，作为数据中心服务器的workload的瓶颈主要来自于L2 指令和数据的缺失，数据显示访问L3命中的延迟和缺失导致的内存访问延迟各占据CPI的30%，共有60%

2. 本质上相当于在线程内部构建了一个状态机，并发处理多个请求，而这不用协程也是可以实现的（参考上面的论文）。用协程只是让编程更好看，还能得到不错的性能。

Ling：不可以，虽然之前没有看过这篇论文，但是我们也考虑过用相同的方案，因为缓存（L2/L3)缺失与运行的软硬件环境紧密相关,随机性很大，如果使用静态的prefetch然后切换的方案，会做出很多无用的操作，尤其在云的需要不断迁移部署环境下。
--
修改:MaLing FROM 42.120.75.*
FROM 42.120.75.*

: 理解了你的意思，还是希望硬件动态做预测，多谢解释。不过主要挑战应该会在这个预测器上，如果基于PC好预测的话，那么大概率这个信息在静态也能得到；
Ling: 正如上面说的到的数据是否在缓存与动态运行的软硬件环境相关，这个与跳转预测（也是基于指令地址）的引入基本一致，大量取决于运行状态，而其主流也是用硬件完成,下面的三篇文章也都是使用硬件预测load-address 以及 cache Hit-Miss。文章《Load value prediction via path-based address prediction: avoiding mispredictions due to conflicting stores》和 《Correlated Load-Address Predictors》中预测load-address的准确率超过99%， 同样《Bloom Filtering Cache Misses for Accurate Data Speculation and Prefetching》使用load-address预测数据是否在缓存的准确率也超高99%，因此我们可以说在本文中的第一阶段预测，也就是通过指令地址预测数据是否在缓存中,理想情况下的准确率能接近达到 98%（0.99 * 0.99), 第二阶段通过地址预测准确率就可以达到99%。
  
“如果是基于访存地址的bloom filter, 需要设计一种在cache evcition时能从bloom filter中“去掉一个项”这样的操作。”
Ling：《Bloom Filtering Cache Misses for Accurate Data Speculation and Prefetching》相关内容文章中都有提到
  
当然只有通过真实的仿真才能有可靠的结论，这方面我们需要进行验证。
【 在 winfredsu 的大作中提到: 】
: 理解了你的意思，还是希望硬件动态做预测，多谢解释。不过主要挑战应该会在这个预测器上，如果基于PC好预测的话，那么大概率这个信息在静态也能得到；如果是基于访存地址的bloom filter, 需要设计一种在cache evcition时能从bloom filter中“去掉一个项”这样的操作。
:
--
FROM 47.99.111.*

可惜协程只能一个核。我这个计算力必须多核才能满足时间……
【 在 MaLing 的大作中提到: 】
: 协程之间的切换是一个物理线程/进程内部，用户态进行上下文之间的切换。通常协程上下文用使用双向链表链接，其个数由程序员决定。协程切换（设定为yield_thread函数)的代价+ 跳转延迟大约在20个周期左右，L2 延迟在 12个周期，L3延迟基本在50个周期，内存延迟在100ns（3GHZ，300个
: ..................

发自「今日水木 on iPhone XR」
--
FROM 101.206.168.*

那问题来了……你怎么证明经过系统调度的多核协程就一定好于多线程……
【 在 hgoldfish 的大作中提到: 】
: 协程不一定一个核哦。  
:  
: 可以手动调度也可以由语言（框架）自动调度。  
: --  
: 灭绝人性啊

发自「今日水木 on iPhone XR」
--
FROM 101.206.168.*

求详解文章或对应库
【 在 hgoldfish 的大作中提到: 】
:  
: 是手动调度，不是系统调度。  
:
: 比较可以根据业务情况，先看看某个核心的繁忙程度，决定把协程调度给哪个核心。  
: --  
: 灭绝人性啊  
:
:

发自「今日水木 on iPhone XR」
--
FROM 124.126.137.*