Created by: helinwang

无论是否重写parameter server，我们都需要一个清晰的parameter server接口：

• 如果不重写，可以保证修改现有代码不会让可维护性降得更低。以后要重写只用保持接口不变，更换实现即可。
• 如果重写，也需要一个清晰的接口，保证代码质量。

目前parameter server只需要支持：异步SGD，不带动量的优化算法（传统SGD），dense更新。 不需要支持：同步SGD，各种带动量的优化算法，sparse更新。 接口需要涵盖目前不需要支持的功能，不需要实现不支持的功能。

据我理解，design doc需要以下几块接口的定义：

• 运行parameter server的命令行参数是什么： 比如： --port 8000 --save-period 60

• RPC Server接口伪代码： 我想象的，举个例子：

  int update(string method, list of dense gradients);
  int download(pointer to list of dense gradients);
  int updateSparse(string method, xxx);
  int downloadSparse(xxx);
  int saveModel(string path);

• RPC client API，python and C/C++ 出于性能考虑update和download貌似只能是C/C++ API (不然数据类型需要经过python中转）。

  • C/C++ API（C或者C++都行，只要表达了意思就好）。如果要用golang重写，实现的时候需要C API： 我想象的，举个例子：

  int update(string method, list of dense gradients);
  int download(pointer to list of dense gradients);
  int updateSparse(string method, xxx);
  int downloadSparse(xxx);
  int saveModel(string path);
  int wait(int t);
  
  // e.g.,
  // update(...);
  // int errorCode = wait(download(...));

  • python API（是否只需要保存模型的API？）

• 把parameter server 主干部分（参数存储，更新部分，除去RPC以及使用etcd做service announcement的部分）当作一个库，库的API。 定义库API可以把RPC代码与主干部分清晰分开。以后保持接口，更换实现会很方便。另外有可能用golang写主程序，编译时候链接这个库。