w***g
发帖数: 5958 | 1 昨天借着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。 |
L****8
发帖数: 3938 | 2 c++怎么生成np array？
你用的啥gpu？
【在 w***g 的大作中提到】
: 昨天借着python的讨论，终于把这个代码写出来了。
: 最近半年突然客户需求就从图像转到各种乱七八糟的东西了。
: 比较难搞的是三维医学图像和三维点云。数据量大，CPU负载
: 重，如果不能CPU/GPU并行，训练效率会明显降低。
: 这种数据python自身的局限非常明显。就是multiprocessing
: 默认是用pickle。所以网上包括tf在内的各种python包，
: 都是用pickle进行进程间通信。全都在内存里的东西，通过
: pickle走一边，简直比穿雨衣洗澡还难受。必须干掉。
: 关键：1. C++多线程预处理。每个线程占用一个CPU，完成
: 数据读入和augmentation等预处理，最后生成np::ndarray
|
w***g
发帖数: 5958 | 3 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。
【在 L****8 的大作中提到】
: c++怎么生成np array？
: 你用的啥gpu？
|
L****8
发帖数: 3938 | 4 V100 32G 估计也不够
得用8个XP串联
【在 w***g 的大作中提到】
: 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。
|
w***g
发帖数: 5958 | 5 小作坊买不起。到时候就只能先调通了然后出钱上云训练了。
【在 L****8 的大作中提到】
: V100 32G 估计也不够
: 得用8个XP串联
|
g*******0
发帖数: 127 | 6 问个问题，GPU，象titan这类的，最快的数据吞吐量throughput是多少，是否就是受限
于PCIE的速度，还有其他方法输入数据吗（从PC或者从外部设备输入）？
【在 w***g 的大作中提到】
: 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。
|
g*******0
发帖数: 127 | 7 请问8个XP串联怎么搞？是安装在8条PCIE上吗（这是并联吧）？
【在 L****8 的大作中提到】
: V100 32G 估计也不够
: 得用8个XP串联
|
x**********i
发帖数: 658 | 8 请问代码您发GitHub了吗？菜鸟处理点云，确实发现python挺慢的，谢谢指教
【在 w***g 的大作中提到】
: 昨天借着python的讨论，终于把这个代码写出来了。
: 最近半年突然客户需求就从图像转到各种乱七八糟的东西了。
: 比较难搞的是三维医学图像和三维点云。数据量大，CPU负载
: 重，如果不能CPU/GPU并行，训练效率会明显降低。
: 这种数据python自身的局限非常明显。就是multiprocessing
: 默认是用pickle。所以网上包括tf在内的各种python包，
: 都是用pickle进行进程间通信。全都在内存里的东西，通过
: pickle走一边，简直比穿雨衣洗澡还难受。必须干掉。
: 关键：1. C++多线程预处理。每个线程占用一个CPU，完成
: 数据读入和augmentation等预处理，最后生成np::ndarray
|
w***g
发帖数: 5958 | 9 我帖子里就那个链接。
点往三维格子里分这步python搞不了。
接下来数据增强也打算用C++了。voxelnet有一步按box做augmentation
的骚操作。还要判断box augment了会不会互相碰上。这个感觉也是
用C++写更顺手。
有个PCL，不过都是传统套路，不知道有没有用。
顺路问下，路面识别有没有啥公认比较好的办法？
【在 x**********i 的大作中提到】
: 请问代码您发GitHub了吗？菜鸟处理点云，确实发现python挺慢的，谢谢指教
|
w*****r
发帖数: 197 | 10 靠，这方面，我专家啊~
: 我帖子里就那个链接。
: 点往三维格子里分这步python搞不了。
: 接下来数据增强也打算用C 了。voxelnet有一步按box做augmentation
: 的骚操作。还要判断box augment了会不会互相碰上。这个感觉也是
: 用C 写更顺手。
: 有个PCL，不过都是传统套路，不知道有没有用。
: 顺路问下，路面识别有没有啥公认比较好的办法？
【在 w***g 的大作中提到】
: 我帖子里就那个链接。
: 点往三维格子里分这步python搞不了。
: 接下来数据增强也打算用C++了。voxelnet有一步按box做augmentation
: 的骚操作。还要判断box augment了会不会互相碰上。这个感觉也是
: 用C++写更顺手。
: 有个PCL，不过都是传统套路，不知道有没有用。
: 顺路问下，路面识别有没有啥公认比较好的办法？
|
|
|
w***g
发帖数: 5958 | 11 C++有啥轮子可以用的？
【在 w*****r 的大作中提到】
: 靠，这方面，我专家啊~
:
:
: 我帖子里就那个链接。
:
: 点往三维格子里分这步python搞不了。
:
: 接下来数据增强也打算用C 了。voxelnet有一步按box做augmentation
:
: 的骚操作。还要判断box augment了会不会互相碰上。这个感觉也是
:
: 用C 写更顺手。
:
: 有个PCL，不过都是传统套路，不知道有没有用。
:
: 顺路问下，路面识别有没有啥公认比较好的办法？
:
|
n*****3
发帖数: 1584 | 12 try DASK?
https://dask.org/
or
https://rise.cs.berkeley.edu/blog/pandas-on-ray/
【在 w***g 的大作中提到】
: 昨天借着python的讨论，终于把这个代码写出来了。
: 最近半年突然客户需求就从图像转到各种乱七八糟的东西了。
: 比较难搞的是三维医学图像和三维点云。数据量大，CPU负载
: 重，如果不能CPU/GPU并行，训练效率会明显降低。
: 这种数据python自身的局限非常明显。就是multiprocessing
: 默认是用pickle。所以网上包括tf在内的各种python包，
: 都是用pickle进行进程间通信。全都在内存里的东西，通过
: pickle走一边，简直比穿雨衣洗澡还难受。必须干掉。
: 关键：1. C++多线程预处理。每个线程占用一个CPU，完成
: 数据读入和augmentation等预处理，最后生成np::ndarray
|
n*****3
发帖数: 1584 | 13 try DASK?
https://dask.org/
or
https://rise.cs.berkeley.edu/blog/pandas-on-ray/
【在 w***g 的大作中提到】
: 昨天借着python的讨论，终于把这个代码写出来了。
: 最近半年突然客户需求就从图像转到各种乱七八糟的东西了。
: 比较难搞的是三维医学图像和三维点云。数据量大，CPU负载
: 重，如果不能CPU/GPU并行，训练效率会明显降低。
: 这种数据python自身的局限非常明显。就是multiprocessing
: 默认是用pickle。所以网上包括tf在内的各种python包，
: 都是用pickle进行进程间通信。全都在内存里的东西，通过
: pickle走一边，简直比穿雨衣洗澡还难受。必须干掉。
: 关键：1. C++多线程预处理。每个线程占用一个CPU，完成
: 数据读入和augmentation等预处理，最后生成np::ndarray
|
s*****V
发帖数: 21731 | 14 python这个multiprocess确实很难用，稍微复杂点的就pickle不了，不知道你们是怎么
折腾的。牢靠点的还是上google proto buffer自己写serialize和de-serialize
【在 w***g 的大作中提到】
: 昨天借着python的讨论，终于把这个代码写出来了。
: 最近半年突然客户需求就从图像转到各种乱七八糟的东西了。
: 比较难搞的是三维医学图像和三维点云。数据量大，CPU负载
: 重，如果不能CPU/GPU并行，训练效率会明显降低。
: 这种数据python自身的局限非常明显。就是multiprocessing
: 默认是用pickle。所以网上包括tf在内的各种python包，
: 都是用pickle进行进程间通信。全都在内存里的东西，通过
: pickle走一边，简直比穿雨衣洗澡还难受。必须干掉。
: 关键：1. C++多线程预处理。每个线程占用一个CPU，完成
: 数据读入和augmentation等预处理，最后生成np::ndarray
|
r****t
发帖数: 10904 | 15 用 copyreg
【在 s*****V 的大作中提到】
: python这个multiprocess确实很难用，稍微复杂点的就pickle不了，不知道你们是怎么
: 折腾的。牢靠点的还是上google proto buffer自己写serialize和de-serialize
|
a***6
发帖数: 44 | 16 好奇问一下，h5是如何比np.save高效率的？
【在 w***g 的大作中提到】
: 昨天借着python的讨论，终于把这个代码写出来了。
: 最近半年突然客户需求就从图像转到各种乱七八糟的东西了。
: 比较难搞的是三维医学图像和三维点云。数据量大，CPU负载
: 重，如果不能CPU/GPU并行，训练效率会明显降低。
: 这种数据python自身的局限非常明显。就是multiprocessing
: 默认是用pickle。所以网上包括tf在内的各种python包，
: 都是用pickle进行进程间通信。全都在内存里的东西，通过
: pickle走一边，简直比穿雨衣洗澡还难受。必须干掉。
: 关键：1. C++多线程预处理。每个线程占用一个CPU，完成
: 数据读入和augmentation等预处理，最后生成np::ndarray
|
x****u
发帖数: 44466 | 17 为什么不用python的多线程？
虽然语言本身有gil，但io和线性代数部分是可以并发的
python跑深度学习，瓶颈不在python语言本身，gil性能问题可以忽略
【在 w***g 的大作中提到】
: 昨天借着python的讨论，终于把这个代码写出来了。
: 最近半年突然客户需求就从图像转到各种乱七八糟的东西了。
: 比较难搞的是三维医学图像和三维点云。数据量大，CPU负载
: 重，如果不能CPU/GPU并行，训练效率会明显降低。
: 这种数据python自身的局限非常明显。就是multiprocessing
: 默认是用pickle。所以网上包括tf在内的各种python包，
: 都是用pickle进行进程间通信。全都在内存里的东西，通过
: pickle走一边，简直比穿雨衣洗澡还难受。必须干掉。
: 关键：1. C++多线程预处理。每个线程占用一个CPU，完成
: 数据读入和augmentation等预处理，最后生成np::ndarray
|
w*****r
发帖数: 197 | 18 rapids.ai的那套东西可能就是你未来的ecosystem
【在 w***g 的大作中提到】
: 昨天借着python的讨论，终于把这个代码写出来了。
: 最近半年突然客户需求就从图像转到各种乱七八糟的东西了。
: 比较难搞的是三维医学图像和三维点云。数据量大，CPU负载
: 重，如果不能CPU/GPU并行，训练效率会明显降低。
: 这种数据python自身的局限非常明显。就是multiprocessing
: 默认是用pickle。所以网上包括tf在内的各种python包，
: 都是用pickle进行进程间通信。全都在内存里的东西，通过
: pickle走一边，简直比穿雨衣洗澡还难受。必须干掉。
: 关键：1. C++多线程预处理。每个线程占用一个CPU，完成
: 数据读入和augmentation等预处理，最后生成np::ndarray
|
