使用Rust开发并行随机梯度下降中遇到的问题
解决方案
1. Futures
2. Nalgebra
3. Tokio
其中Tokio负责异步IO，Futures负责并行计算，Nalgebra负责矩阵等数学对象的抽象。
主要遇到的问题
1. 生命周期以及所有权的问题
当数据结构在闭包和线程之间被使用的时候，很容易遇到变量的所有权被move的问题，以及变量的ref lifetime不足以保证在某个位置还有效的问题。通过使用Arc和Box等智能指针的形式来进行引用传递，在不同的闭包里clone一个有所有权的指针来解决这个问题，也带来了一些复杂度，并发的安全性由这些指针的封装来保证，当然这些封装里边也存在大量的unsafe代码，不过是经过大量测试过的，安全性可以被信赖。
另外由于有些代码比如as_slice会造成所有权的转移，因此代码很多的精力都放在感受所有权的转移身上，数据在传递给闭包要先clone，传递进去的数据要被转移了，接下来就不能使用了，fighting with the compiler.
2. 线程池的成熟程度
Futures包的0.3版本目前只是alpha阶段，只能在nightly的版本中使用，而nightly的版本极其不稳定，经常没有rls可用，代码编写都是个问题。
后来考虑使用Tokio自己的线程池来替代，基于Futures 0.1版本的包所封装的线程池实现，在stable版本中可用，最终出乎意料的顺利
3. Channel 的使用
管道同样有所有权和运行的问题，因为通过管道发送数据本身就是一种Future，如果需要在当前线程中运行，只需要block住该future，而在Futures 0.3版本中，没有好用的api。
最终使用的是标准库里边的mpsc，通过在线程池的某个线程中将结果send出去，在主线程阻塞receive结果并更新参数。
结论
最终实现的sgd在一万行数据，每行一万个feature 的情况下，
没有使用lapack加速，纯粹依赖rust的计算，大概执行时间是150秒，比直接在spark集群上还要快同时消耗内存也小很多;
开启lapack支持，速度并没有明显提升，也许和mac系统的lapack 优化有关，在linux下同样的性能会好很多
对于feature比较少的情况，速度提升更明显，当只有几十个feature的时候一万行数据只需要3秒左右的时间即可收敛到接近最优解。
