@takato 我使用了 TF 的一个高手魔改 API 版本终于复现了 state of the art，可见 TF 本身功能是没什么问题，但的确存在很多脑残设计。

@takato 就是因为 PyTorch 的那个项目（不是 PyTorch 本身）复现有瑕疵才问的，奈何作者跑路中

@iBaoger 阁下是？

@lihongjie0209 @Weny 第一、你们用过 Tensorflow 吗？第二、你们用过 TF 的 API 更深的地方吗？

@yangyaofei 说得再详细一点，AttentionWrapper 内部本身封装了一个 decoder RNN，但论文里的 decoder RNN 是需要自己设计的，没法子只能 AttentionWrapper 外面再做一个 decoder，但是我们还需要把 decoder 的输出反馈到 encoder 端，形成闭环，但是 AttentionWrapper 阻止了这种灵活性，只能把反馈接到 decoder 的输入端。总之无法严格实现论文的架构，所以只能把整个 Attention 类拷过来，打散自己搭建。

@yangyaofei https://github.com/keithito/tacotron/issues/170#issuecomment-389766623
说来话长，AttentionWrapper 简直是个 bug 设计。这些都是实践中总结对比出来的，可验证的。一下子我的训练数据少了很多，收敛也快了很多。

@v2lf 你认错人了吧？我可是一度吹捧 Linus 的

@huanghaofu86 我没有 DB 开发经验，全是业余作品

@fcten 就是上层的缓存啊，底层（包括我的 cache ）指的是落地用的

@fcten 行级锁那是上层概念，底层怎么可能每一条记录上锁？

@fcten 没听说过一条记录一把锁的，底层只关注 node，你是不是没搞清楚概念？

@fcten
1、cache 数目跟线程数目有关系吗？ 1W 个线程引用 cache A，只会用一把锁互斥啊
2、cache A 的锁又不会给 cache B 上锁，这在分裂新节点情况下是不存在竞态的。

@fcten 不同 cache 对应的 node 如果不存在引用关系，那么就不存在竞态问题和互斥处理

@fcten 不是吧，一个 cache 对应一个 node 啊，只是在操作内部引用 cache 的时候才上锁。全局锁指的是整个 tree 用一把锁，这才是对 CRUD 操作上锁。

@svenFeng 对于我目前实现的 B+树来说，实现插入 /查询的并发并非什么难事，我一共只用到 MIN_CACHE_NUM=5 个内存映射 node cache，对每一个 cache 加锁就可以了。

@svenFeng 粗略浏览了一下 B-link，传说中的分布式索引？有文章证明了插入和查询线程之间的并发正确性，那是因为插入只会分裂新的节点，新分裂的节点不存在引用关系，故而可以避免竞态。而删除则会导致合并，对于已存在引用关系的节点，则必然导致竞态。故而只能用全局锁，对每一个 CRUD 操作加锁，就会损失性能，是这个意思吧？我很好奇如果没有删除，那么废弃的 key 怎么处理？

@svenFeng 删除和插入本质都是一样的写操作而已，怎么并发就不能实现了？

@rogerchen 我没有小视任何人啊，包括年轻人，我的意思是说，当年轻人对这些基础软件没有归属感的时候，你如何期望他们兢兢业业打好补丁？老家伙是不一样的，这些软件是他们亲手打造，自然愿意用生命来守护啊

@nicevar 由俭入奢易，由奢入俭难啊