logo
Redian新闻
>未名空间
>Programming - 葵花宝典
>
深学数据预处理新流程
avatar
深学数据预处理新流程# Programming - 葵花宝典
j*s
1 楼
我老EB2，08年二月的PD，12月8号的RD，今天收到FP的通知，一看，NND，怕什么来什
么。我老一月要回国出差一周，FP的预约时间正好是那一周的周一。现在已经把FP通知
打了个叉寄回去了，还附了封信请人家帮忙重新约个时间。
请问过来的各位，重新约时间大概多长时间能收到通知？
多谢多谢！
avatar
w*g
2 楼
昨天借着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。
avatar
U*S
3 楼
You should try early walk in first.

【在 j******s 的大作中提到】
: 我老EB2，08年二月的PD，12月8号的RD，今天收到FP的通知，一看，NND，怕什么来什
: 么。我老一月要回国出差一周，FP的预约时间正好是那一周的周一。现在已经把FP通知
: 打了个叉寄回去了，还附了封信请人家帮忙重新约个时间。
: 请问过来的各位，重新约时间大概多长时间能收到通知？
: 多谢多谢！
avatar
L*8
4 楼
c++怎么生成np array？
你用的啥gpu？

【在 w***g 的大作中提到】
: 昨天借着python的讨论，终于把这个代码写出来了。
: 最近半年突然客户需求就从图像转到各种乱七八糟的东西了。
: 比较难搞的是三维医学图像和三维点云。数据量大，CPU负载
: 重，如果不能CPU/GPU并行，训练效率会明显降低。
: 这种数据python自身的局限非常明显。就是multiprocessing
: 默认是用pickle。所以网上包括tf在内的各种python包，
: 都是用pickle进行进程间通信。全都在内存里的东西，通过
: pickle走一边，简直比穿雨衣洗澡还难受。必须干掉。
: 关键：1. C++多线程预处理。每个线程占用一个CPU，完成
: 数据读入和augmentation等预处理，最后生成np::ndarray
avatar
j*s
5 楼
Damn....
avatar
w*g
6 楼
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？
avatar
m*U
7 楼
You can go to Fingerprint earlier with the notice. I did that before, and it
is OK.
avatar
L*8
8 楼
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。
avatar
j*s
9 楼
晕……这样也可以啊。我已经寄回去申请重新安排时间了。
新的通知大概多久能收到？
avatar
w*g
10 楼
小作坊买不起。到时候就只能先调通了然后出钱上云训练了。

【在 L****8 的大作中提到】
: V100 32G 估计也不够
: 得用8个XP串联
avatar
p*1
11 楼
我跟你一样，也老实地寄出去了。
应该有一周多了，还没收到回音。
avatar
g*0
12 楼
问个问题，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。
avatar
s*e
13 楼
What center did you submit your 485? I am still waiting for the finger print
notice. Has anyone recived it from NSC?
Thanks.
NSC EB2
PD: Feb. 2008
RD: Dec, 2, 2011
ND: Dec. 7, 2011
NRD: Dec. 9, 2011.
avatar
g*0
14 楼
请问8个XP串联怎么搞？是安装在8条PCIE上吗（这是并联吧）？

【在 L****8 的大作中提到】
: V100 32G 估计也不够
: 得用8个XP串联
avatar
j*s
15 楼
TSC。
avatar
x*i
16 楼
请问代码您发GitHub了吗？菜鸟处理点云，确实发现python挺慢的，谢谢指教

【在 w***g 的大作中提到】
: 昨天借着python的讨论，终于把这个代码写出来了。
: 最近半年突然客户需求就从图像转到各种乱七八糟的东西了。
: 比较难搞的是三维医学图像和三维点云。数据量大，CPU负载
: 重，如果不能CPU/GPU并行，训练效率会明显降低。
: 这种数据python自身的局限非常明显。就是multiprocessing
: 默认是用pickle。所以网上包括tf在内的各种python包，
: 都是用pickle进行进程间通信。全都在内存里的东西，通过
: pickle走一边，简直比穿雨衣洗澡还难受。必须干掉。
: 关键：1. C++多线程预处理。每个线程占用一个CPU，完成
: 数据读入和augmentation等预处理，最后生成np::ndarray
avatar
j*s
17 楼
有没有人知道这么改一下会耽误多少时间？
avatar
w*g
18 楼
我帖子里就那个链接。
点往三维格子里分这步python搞不了。
接下来数据增强也打算用C++了。voxelnet有一步按box做augmentation
的骚操作。还要判断box augment了会不会互相碰上。这个感觉也是
用C++写更顺手。
有个PCL，不过都是传统套路，不知道有没有用。
顺路问下，路面识别有没有啥公认比较好的办法？

【在 x**********i 的大作中提到】
: 请问代码您发GitHub了吗？菜鸟处理点云，确实发现python挺慢的，谢谢指教
avatar
s*e
19 楼
Thanks.

【在 j******s 的大作中提到】
: TSC。
avatar
w*r
20 楼
靠，这方面，我专家啊~


: 我帖子里就那个链接。

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

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

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

: 用C 写更顺手。

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

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



【在 w***g 的大作中提到】
: 我帖子里就那个链接。
: 点往三维格子里分这步python搞不了。
: 接下来数据增强也打算用C++了。voxelnet有一步按box做augmentation
: 的骚操作。还要判断box augment了会不会互相碰上。这个感觉也是
: 用C++写更顺手。
: 有个PCL，不过都是传统套路，不知道有没有用。
: 顺路问下，路面识别有没有啥公认比较好的办法？
avatar
n*n
21 楼
我也想改时间的，跑到Field Office一问，reschedule至少要延迟8个星期，唉。
我在小地方，本周移民不多。
avatar
w*g
22 楼
C++有啥轮子可以用的？

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

avatar
T*r
23 楼
多来这里逛逛, 为以后作准备少走弯路.

【在 j******s 的大作中提到】
: 晕……这样也可以啊。我已经寄回去申请重新安排时间了。
: 新的通知大概多久能收到？
avatar
n*3
24 楼
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
avatar
j*s
25 楼
艹，八个星期啊……
还好我不急着用EAD和AP。

【在 n**********n 的大作中提到】
: 我也想改时间的，跑到Field Office一问，reschedule至少要延迟8个星期，唉。
: 我在小地方，本周移民不多。
avatar
n*3
26 楼
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
avatar
j*s
27 楼
我昨天来这里搜了来着，没找到什么相关的。

【在 T******r 的大作中提到】
: 多来这里逛逛, 为以后作准备少走弯路.
avatar
s*V
28 楼
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
avatar
j*s
29 楼
今天收到了重新预约的FP通知，看日期是他们收到的当天就做好了发出来（12月28日），
预约的时间是按照我要求的那样比原来的推迟了8天。
赞一下本地USCIS的工作效率，还是比较令人满意的。

【在 j******s 的大作中提到】
: 我老EB2，08年二月的PD，12月8号的RD，今天收到FP的通知，一看，NND，怕什么来什
: 么。我老一月要回国出差一周，FP的预约时间正好是那一周的周一。现在已经把FP通知
: 打了个叉寄回去了，还附了封信请人家帮忙重新约个时间。
: 请问过来的各位，重新约时间大概多长时间能收到通知？
: 多谢多谢！
avatar
r*t
30 楼
用 copyreg

【在 s*****V 的大作中提到】
: python这个multiprocess确实很难用，稍微复杂点的就pickle不了，不知道你们是怎么
: 折腾的。牢靠点的还是上google proto buffer自己写serialize和de-serialize
avatar
a*6
31 楼
好奇问一下，h5是如何比np.save高效率的？

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

【在 w***g 的大作中提到】
: 昨天借着python的讨论，终于把这个代码写出来了。
: 最近半年突然客户需求就从图像转到各种乱七八糟的东西了。
: 比较难搞的是三维医学图像和三维点云。数据量大，CPU负载
: 重，如果不能CPU/GPU并行，训练效率会明显降低。
: 这种数据python自身的局限非常明显。就是multiprocessing
: 默认是用pickle。所以网上包括tf在内的各种python包，
: 都是用pickle进行进程间通信。全都在内存里的东西，通过
: pickle走一边，简直比穿雨衣洗澡还难受。必须干掉。
: 关键：1. C++多线程预处理。每个线程占用一个CPU，完成
: 数据读入和augmentation等预处理，最后生成np::ndarray
相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章，不代表同意其说法或描述，仅为提供更多信息，也不构成任何建议。文章信息的合法性及真实性由其作者负责，与Redian.news及其运营公司无关。欢迎投稿，如发现稿件侵权，或作者不愿在本网发表文章，请版权拥有者通知本网处理。