小而美之外，设计上有哪些考虑？

[stonehuang1024]

小而美之外，设计上有哪些考虑？

[zhangyafeikimi]

试着回答几个问题.

1. pb的问题是存在版本兼容性, 微信内部几年前可能到现在都处于pb2到3的切换阵痛期, 而我们的系统在微信内部有广泛使用, 设计阶段就规避了这个问题. 除此之外, 要把性能优化到极致, pb没法实现零拷贝.
2. 大规模稀疏场景的模型在GPU上跑可能会更慢, 瓶颈主要是两个: embedding的网络通信, 特征和embedding到第一个dense tensor的计算. 如果想把项目做的更通用, 是必须要支持异构计算的, 但不是我们目前的主要工作方向了.
3. 计算方面, 代码里面可以看到我们做了一个sage2的高性能计算库, 通过编译参数打开, 这里并没有开源, 未来打算开源. sage2的核心代码用汇编完成, 也混了jit技术, 实现的大部分操作都比eigen快(包括我们自己实现的sgemm), 相当多操作的实现也比MKL快. sage2做了一个适配层, 针对每个操作和当前CPU平台, 择速度更快的实现(我们自己的实现, MKL, openblas等).
4. op恐怕比tf的代码量小多了啊, 只有100多个op. 其实这里不是很明白你意思, 可以说的更具体点.

[zhangyafeikimi]

libhdfs.so的考虑也可以探讨一下.

微信内部的环境, 有hadoop 2.2.0和2.6.0, 这两个版本的libhdfs.so是不同的, 不能混用. 所以把libhdfs以静态库的方式链接进去不是一个很好的方案.

libhdfs.so的使用是dlopen的方式, 也不是链接进去的. 相当于是, 有so则hdfs可用, so的版本是什么都可以. 保持了相当的灵活性.

[stonehuang1024]

感谢亚霏大神的回答，也想继续探讨下
1.op相比tf粒度比较粗，很多op是可以通过细粒度的op组装起来的，是想了解这方面的考虑点
2.关于异构计算方面，目前测试GPU在serving（ONNX）上有比较大的收益，方便透露下deep_core后续异构计算会考虑哪些方向？
3.编译工具是否会考虑用blade（广点通开源的工具）
4.特征sign设计方面，前16位分配给slot，是否会有些浪费？导致hash部分冲突率比较高，目前推搜广特征动不动就千亿
5.还想探讨下，deep_core设计灵感（血统）的来源，Caffe、tf、mxnet、abcus感觉都不太像，更接近于angel？

[zhangyafeikimi]

op有粗粒度也有细粒度的, 各有优缺点, 粗的倾向于把多个常用操作融合到一起, 节省框架的开销, 细的更有灵活性, 可以随意搭积木.

[zhangyafeikimi]

没有计划做异构计算

[zhangyafeikimi]

https://github.com/Tencent/deepx_core/tree/master/mmsearchgateway
是为bazel写的编译文件, 移植到blade很容易.

[zhangyafeikimi]

2的48次方是562949953421312, 千亿几乎无冲突的.

[zhangyafeikimi]

参考过tensorflow和mxnet, 别的框架没看过.

[stonehuang1024]

get~ 感谢大神的回答