找女朋友好难

昨天借着python的讨论，终于把这个代码写出来了。
最近半年突然客户需求就从图像转到各种乱七八糟的东西了。
比较难搞的是三维医学图像和三维点云。数据量大，CPU负载
重，如果不能CPU/GPU并行，训练效率会明显降低。

这种数据python自身的局限非常明显。就是multiprocessing
默认是用pickle。所以网上包括tf在内的各种python包，
都是用pickle进行进程间通信。全都在内存里的东西，通过
pickle走一边，简直比穿雨衣洗澡还难受。必须干掉。

关键：1. C++多线程预处理。每个线程占用一个CPU，完成
数据读入和augmentation等预处理，最后生成np::ndarray
返回。 2. 所有涉及到py::object和np::ndarray的操作，
哪怕是py::object的拷贝构造，全都需要用python那套多线程
机制保护起来。因为python的多线程其实是单线程，所以其实是
所有python相关的数据构造操作，本质上全都是单线程的。
但是np::dnarray建起来以后，对其内存的那部分操作可以并行化。
3. 为了避免不小心碰到各种构造函数，py::object一律都用
指针。拷贝指针不会搞死python。

所有可以线下完成的预处理需要尽可能多地先用python完成，
然后把中间结果用h5存成文件。h5在效率上吊打np.save。

想通了，其实就一百多行代码。

最大的遗憾，要并行部分预处理代码只能C++写了。多线程
这块，python确实完全不如lua。

c++怎么生成np array？
你用的啥gpu？
【 在 wdong (万事休) 的大作中提到: 】
: 昨天借着python的讨论，终于把这个代码写出来了。
: 最近半年突然客户需求就从图像转到各种乱七八糟的东西了。
: 比较难搞的是三维医学图像和三维点云。数据量大，CPU负载
: 重，如果不能CPU/GPU并行，训练效率会明显降低。
: 这种数据python自身的局限非常明显。就是multiprocessing
: 默认是用pickle。所以网上包括tf在内的各种python包，
: 都是用pickle进行进程间通信。全都在内存里的东西，通过
: pickle走一边，简直比穿雨衣洗澡还难受。必须干掉。
: 关键：1. C++多线程预处理。每个线程占用一个CPU，完成
: 数据读入和augmentation等预处理，最后生成np::ndarray
: ...................

boost::python::numpy 比较原始就是了。

看这个https://github.com/aaalgo/kitti_dl/blob/master/python-api.cpp
我正在把这个project的训练流程改成帖子里说的。

我手上最好的是titan xp。底下1080 ti, 1080, 1070 ti, 1060都有。
对于小数据，比如心电图之类的，其实1060就够了。
对于大数据，像CT volume这种，titan xp 12G也不够。只能拿算法拼人大内存。
最近大家都在上titan v，我有可能能再搞到几块淘汰下来的titan xp。

【 在 Liber8 (Space-Time continuum) 的大作中提到: 】
: c++怎么生成np array？
: 你用的啥gpu？

V100 32G 估计也不够
得用8个XP串联
【 在 wdong (万事休) 的大作中提到: 】
: boost::python::numpy 比较原始就是了。
: 看这个https://github.com/aaalgo/kitti_dl/blob/master/python-api.cpp
: 我正在把这个project的训练流程改成帖子里说的。
: 我手上最好的是titan xp。底下1080 ti, 1080, 1070 ti, 1060都有。
: 对于小数据，比如心电图之类的，其实1060就够了。
: 对于大数据，像CT volume这种，titan xp 12G也不够。只能拿算法拼人大内存。
: 最近大家都在上titan v，我有可能能再搞到几块淘汰下来的titan xp。

小作坊买不起。到时候就只能先调通了然后出钱上云训练了。

【 在 Liber8 (Space-Time continuum) 的大作中提到: 】
: V100 32G 估计也不够
: 得用8个XP串联

问个问题，GPU，象titan这类的，最快的数据吞吐量throughput是多少，是否就是受限于PCIE的速度，还有其他方法输入数据吗（从PC或者从外部设备输入）？

【 在 wdong (万事休) 的大作中提到: 】
: boost::python::numpy 比较原始就是了。
: 看这个https://github.com/aaalgo/kitti_dl/blob/master/python-api.cpp
: 我正在把这个project的训练流程改成帖子里说的。
: 我手上最好的是titan xp。底下1080 ti, 1080, 1070 ti, 1060都有。
: 对于小数据，比如心电图之类的，其实1060就够了。
: 对于大数据，像CT volume这种，titan xp 12G也不够。只能拿算法拼人大内存。
: 最近大家都在上titan v，我有可能能再搞到几块淘汰下来的titan xp。

请问8个XP串联怎么搞？是安装在8条PCIE上吗（这是并联吧）？

【 在 Liber8 (Space-Time continuum) 的大作中提到: 】
: V100 32G 估计也不够
: 得用8个XP串联

请问代码您发GitHub了吗？菜鸟处理点云，确实发现python挺慢的，谢谢指教

【 在 wdong (万事休) 的大作中提到: 】
: 昨天借着python的讨论，终于把这个代码写出来了。
: 最近半年突然客户需求就从图像转到各种乱七八糟的东西了。
: 比较难搞的是三维医学图像和三维点云。数据量大，CPU负载
: 重，如果不能CPU/GPU并行，训练效率会明显降低。
: 这种数据python自身的局限非常明显。就是multiprocessing
: 默认是用pickle。所以网上包括tf在内的各种python包，
: 都是用pickle进行进程间通信。全都在内存里的东西，通过
: pickle走一边，简直比穿雨衣洗澡还难受。必须干掉。
: 关键：1. C++多线程预处理。每个线程占用一个CPU，完成
: 数据读入和augmentation等预处理，最后生成np::ndarray
: ...................

我帖子里就那个链接。
点往三维格子里分这步python搞不了。
接下来数据增强也打算用C++了。voxelnet有一步按box做augmentation
的骚操作。还要判断box augment了会不会互相碰上。这个感觉也是
用C++写更顺手。

有个PCL，不过都是传统套路，不知道有没有用。
顺路问下，路面识别有没有啥公认比较好的办法？

【 在 xunzhaocunzi (rushgoon poj lc，cd) 的大作中提到: 】
: 请问代码您发GitHub了吗？菜鸟处理点云，确实发现python挺慢的，谢谢指教

靠，这方面，我专家啊~

【 在 wdong(万事休) 的大作中提到: 】

: 我帖子里就那个链接。

: 点往三维格子里分这步python搞不了。

: 接下来数据增强也打算用C 了。voxelnet有一步按box做augmentation

: 的骚操作。还要判断box augment了会不会互相碰上。这个感觉也是

: 用C 写更顺手。

: 有个PCL，不过都是传统套路，不知道有没有用。

: 顺路问下，路面识别有没有啥公认比较好的办法？

C++有啥轮子可以用的？

【 在 wflower (流) 的大作中提到: 】
: 靠，这方面，我专家啊~
:
: 我帖子里就那个链接。
:
: 点往三维格子里分这步python搞不了。
:
: 接下来数据增强也打算用C 了。voxelnet有一步按box做augmentation
:
: 的骚操作。还要判断box augment了会不会互相碰上。这个感觉也是
:
: 用C 写更顺手。
:
: 有个PCL，不过都是传统套路，不知道有没有用。
:
: 顺路问下，路面识别有没有啥公认比较好的办法？
:

try DASK?https://dask.org/

or https://rise.cs.berkeley.edu/blog/pandas-on-ray/

【 在 wdong (万事休) 的大作中提到: 】
: 昨天借着python的讨论，终于把这个代码写出来了。
: 最近半年突然客户需求就从图像转到各种乱七八糟的东西了。
: 比较难搞的是三维医学图像和三维点云。数据量大，CPU负载
: 重，如果不能CPU/GPU并行，训练效率会明显降低。
: 这种数据python自身的局限非常明显。就是multiprocessing
: 默认是用pickle。所以网上包括tf在内的各种python包，
: 都是用pickle进行进程间通信。全都在内存里的东西，通过
: pickle走一边，简直比穿雨衣洗澡还难受。必须干掉。
: 关键：1. C++多线程预处理。每个线程占用一个CPU，完成
: 数据读入和augmentation等预处理，最后生成np::ndarray
: ...................

try DASK?https://dask.org/

or https://rise.cs.berkeley.edu/blog/pandas-on-ray/

【 在 wdong (万事休) 的大作中提到: 】
: 昨天借着python的讨论，终于把这个代码写出来了。
: 最近半年突然客户需求就从图像转到各种乱七八糟的东西了。
: 比较难搞的是三维医学图像和三维点云。数据量大，CPU负载
: 重，如果不能CPU/GPU并行，训练效率会明显降低。
: 这种数据python自身的局限非常明显。就是multiprocessing
: 默认是用pickle。所以网上包括tf在内的各种python包，
: 都是用pickle进行进程间通信。全都在内存里的东西，通过
: pickle走一边，简直比穿雨衣洗澡还难受。必须干掉。
: 关键：1. C++多线程预处理。每个线程占用一个CPU，完成
: 数据读入和augmentation等预处理，最后生成np::ndarray
: ...................

python这个multiprocess确实很难用，稍微复杂点的就pickle不了，不知道你们是怎么折腾的。牢靠点的还是上google proto buffer自己写serialize和de-serialize

【 在 wdong (万事休) 的大作中提到: 】
: 昨天借着python的讨论，终于把这个代码写出来了。
: 最近半年突然客户需求就从图像转到各种乱七八糟的东西了。
: 比较难搞的是三维医学图像和三维点云。数据量大，CPU负载
: 重，如果不能CPU/GPU并行，训练效率会明显降低。
: 这种数据python自身的局限非常明显。就是multiprocessing
: 默认是用pickle。所以网上包括tf在内的各种python包，
: 都是用pickle进行进程间通信。全都在内存里的东西，通过
: pickle走一边，简直比穿雨衣洗澡还难受。必须干掉。
: 关键：1. C++多线程预处理。每个线程占用一个CPU，完成
: 数据读入和augmentation等预处理，最后生成np::ndarray
: ...................

用 copyreg

【 在 saturnV (土星五号) 的大作中提到: 】
: python这个multiprocess确实很难用，稍微复杂点的就pickle不了，不知道你们是怎么
: 折腾的。牢靠点的还是上google proto buffer自己写serialize和de-serialize

好奇问一下，h5是如何比np.save高效率的？

【 在 wdong (万事休) 的大作中提到: 】
: 昨天借着python的讨论，终于把这个代码写出来了。
: 最近半年突然客户需求就从图像转到各种乱七八糟的东西了。
: 比较难搞的是三维医学图像和三维点云。数据量大，CPU负载
: 重，如果不能CPU/GPU并行，训练效率会明显降低。
: 这种数据python自身的局限非常明显。就是multiprocessing
: 默认是用pickle。所以网上包括tf在内的各种python包，
: 都是用pickle进行进程间通信。全都在内存里的东西，通过
: pickle走一边，简直比穿雨衣洗澡还难受。必须干掉。
: 关键：1. C++多线程预处理。每个线程占用一个CPU，完成
: 数据读入和augmentation等预处理，最后生成np::ndarray
: ...................

为什么不用python的多线程？

虽然语言本身有gil，但io和线性代数部分是可以并发的

python跑深度学习，瓶颈不在python语言本身，gil性能问题可以忽略

【 在 wdong (万事休) 的大作中提到: 】
: 昨天借着python的讨论，终于把这个代码写出来了。
: 最近半年突然客户需求就从图像转到各种乱七八糟的东西了。
: 比较难搞的是三维医学图像和三维点云。数据量大，CPU负载
: 重，如果不能CPU/GPU并行，训练效率会明显降低。
: 这种数据python自身的局限非常明显。就是multiprocessing
: 默认是用pickle。所以网上包括tf在内的各种python包，
: 都是用pickle进行进程间通信。全都在内存里的东西，通过
: pickle走一边，简直比穿雨衣洗澡还难受。必须干掉。
: 关键：1. C++多线程预处理。每个线程占用一个CPU，完成
: 数据读入和augmentation等预处理，最后生成np::ndarray
: ...................