ps看清了上面问题的本质,我尝试来调整批次大小以及多进程数(也就是torch的DataLoader函数的参数)来看看怎么样可以加快运行速度.(同时会看下cup负载和gpu占用率).先根据自己的回忆大致计算周末约60个小时的192个批次的运行速度(192*512)/(60*60*60)fps,得到0.455fps.(这个进程数忘了是16还是32或者是64了)
part1 :batch_size=64, num_workers=8(进程)
先来看看cpu的负载 load average: 8.92, 8.73, 8.93 (电脑是八个核超过去了)(1分钟,5分钟,15分钟)
再来看看gpu占用率:GTX1080:1883MiB / 8112MiB (没有跑程序的基准:888MiB / 8112MiB)
GTX1080Ti:1062MiB / 11172MiB (没有跑程序的基准:2MiB / 11172MiB)
开始start time : Tue Apr 23 16:06:54 2019 结束end time : Tue Apr 23 16:43:23 2019,共36分24秒总合2184秒
一共88个批次共88*64=5632张.运行训练速度5632/2184(fps)为2.58fps.
首先是负载超过8了根基https://www.cnblogs.com/TaleG/p/6030992.html里讲不要超过负载,就相当于一座桥单位时间的同行量是10辆车,但是单位时间内要通过桥车的数量是11辆(负载),那么每个单位时间都会多出1辆车.那么排队的车辆会越来越多.也就是等待I/O的CPU时间百分比会越来越高.所以可以适当降低num_workers,同时gpu占用率太低感觉浪费,可以适当增大批次大小.
ps:从part2回过头补充参数
某一刻%Cpu(s): 71.8 us, 28.2 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
另一时刻%%Cpu(s): 66.1 us, 33.8 sy, 0.0 ni, 0.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
其中id在0.0到0.2之间抖动,而0.0 wa一直保持,并没有发生I/O时发生堵塞的情况.目前是24个批次(64).速度为2.62fps比之前88批次快了一丢丢,应该也是比较正常.
part2 :batch_size=128, num_workers=4(进程)
先来看看cpu的负载 load average: 4.52, 4.60, 4.96
(我还发现一个关键参数%Cpu(s): 35.0 us, 18.3 sy, 0.0 ni, 46.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st)
us：用户态进程占用CPU时间百分比
sy：内核占用CPU时间百分比
ni：renice值为负的任务的用户态进程的CPU时间百分比。nice是优先级的意思
id：空闲CPU时间百分比
wa：等待I/O的CPU时间百分比
hi：CPU硬中断时间百分比
si：CPU软中断时间百分比
居然还有46.7id空闲CPU时间百分比,刚刚在part1上没有注意到这个数字,还有提升空间.而负载4.5左右同样可以稍微提升下
再来看看gpu占用率:GTX1080:2318MiB / 8112MiB (没有跑程序的基准:888MiB / 8112MiB)
GTX1080Ti:1618MiB / 11172MiB (没有跑程序的基准:2MiB / 11172MiB)
gpu还是有很大的提升空间的.
下面我们来看下我没最关心过的运行速度
开始start time : Tue Apr 23 16:52:04 2019 结束end time : Tue Apr 23 17:40:06 2019 共48分02秒总合2882秒
一共68个批次68*128=8704张,运行训练速度为3.02fps.提升蛮大的.
part3 :batch_size=64, num_workers=7(为了对比part1)记录下临近个批次和临近88个批次运行速度.
先来看看cpu的负载 load average: 7.51, 7.50, 7.24.已经小于8了
%Cpu(s): 62.7 us, 27.2 sy, 0.0 ni, 10.1 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
10.1 id在10左右徘徊.
再来看看gpu占用率:GTX1080:1775MiB / 8112MiB (没有跑程序的基准:888MiB / 8112MiB)
GTX1080Ti:1030MiB / 11172MiB (没有跑程序的基准:2MiB / 11172MiB)
对比part1小于一丢丢.
(需要是线程的倍数)看看速度21批次:start time : 18:15:00 end time:18:23:06 ,换算速度为2.77fps
28批次: end time18:25:55,换算速度为2.74fps
84批次: end time 18:47:11,换算速度为2.78fps
91批次: end time 18:49:46,换算速度为2.79fps
添加,刚刚又发现了一件事,一开始运行是会根据线程数,比如7.那么批次1到7计算完成的时间几乎同时.但是到了之后已经没有明显7个批次一批完成计算的规律了.
(不规律)128批次: end time 19:04:06,换算速度为2.78fps
163批次: end time 19:18:13,换算速度为2.75fps
总体比part1要好一些.所以不沾满cpu的负载还是对的.推荐的0.7的比例还是值得肯定的.
part4 :batch_size=128, num_workers=7(不放心主要为了对比part2和part3),验证是不是在不超负载的时候是不是越满越好.(这里就少运行一些只是看看思路对不对)
先来看看cpu的负载 load average: 7.51, 7.50, 7.24.已经小于8了
%Cpu(s): 64.8 us, 27.4 sy, 0.0 ni, 7.7 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 st
再来看看gpu占用率: GTX1080 2280MiB / 8112MiB (没有跑程序的基准:888MiB / 8112MiB)
GTX1080Ti:1502MiB / 11172MiB (没有跑程序的基准:2MiB / 11172MiB)
对比part2 小了一些.
21批次:start time : 19:22:44 end time: 19:39:08 ,换算速度为2.73fps(怎么感觉增大批次没用对比part3)
28批次:end time: 19:44:20 ,换算速度为2.77fps
35批次:end time: 19:49:56 ,换算速度为2.75fps(跟我想的不太一样啊).
42批次: end time: 19:55:42,换算速度为2.72fps.
从22批次开始算到42批次,换算速度为2.70fps. (越来越慢啊)
49批次: end time: 20:00:49,换算速度为2.74fps.(难道进程需要2的n次幂)
part5 :batch_size=128, num_workers=6
load average: 6.48, 6.43, 6.55
%Cpu(s): 57.7 us, 23.7 sy, 0.0 ni, 18.6 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
GPU跟part2和part4差不多就不贴了.
6批次:start time:20:06:13 end time: 20:10:59,换算速度为2.69fps
12批次:end time: 20:15:22,换算速度 2.80fps 单独7到12批次2.91fps
18批次:end time:20:19:40,换算速度 2.86fps 单独13到18批次2.99fps.
24批次:end time:20:24:03,换算速度 2.87fps 单独19到24批次2.92fps
30批次:end time:20:28:28,换算速度 2.88fps 单独25到30批次
对比part5,part4和part2可以看出, num_workers为2的n幂次的运行速度大于为2的倍数,而2的倍数大于不是2的倍数.(4,6,7)
part6 :batch_size=512, num_workers=4(对比part2)
load average: 4.12, 4.25, 4.33(感觉就是比num_workers要大一点点)
%Cpu(s): 40.8 us, 12.8 sy, 0.0 ni, 46.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
再来看看gpu占用率: GTX1080: 5374MiB / 8112MiB (没有跑程序的基准:888MiB / 8112MiB)
GTX1080Ti:4796MiB / 11172MiB (没有跑程序的基准:2MiB / 11172MiB)
epoch 0 中1到16批次:start time : 23 20:30:01 end time: 23 21:12:20,换算速度为3.23fps
epoch 0到epoch 14的16批次start time : 23 20:30:01 end time: 24 10:22:56,其中一个epoch共23个批次,换算速度为3.46fps
epoch 14 开始的1-16批次 start time : 09:42:06 end time:10:22:56 ,换算速度为3.34fps
速度都是是快于part2的.说明增大显存也能加快运行速度.
总结:
1.num_workers选择最大不大于等于电脑核数的2的n次幂(如8核选4,主要如果选8满负荷,还有其它运行的基本程序会占一定负荷这样负载一般就超过8了,而5到7由于不是2的整数次幂反而会降低运行速度).可以达到最快速度.
2.加大批次大小可以加大GPU占有率也可以加快运行速度.
ps 添加 天寿啊!!不放心再次重试了part2 :batch_size=128, num_workers=4(进程)
32批次:10:44:48-11:05:34, 速度3.29fps
40批次:11:10:42, 速度3.29fps
48批次:11:15:33, 速度3.33fps
72批次:11:31:12, 速度3.31fps
啊啊啊啊,好像加大批次大小没啥大用啊(512的前16个批次,相当于128的前64可批次还不如呢),之前那个part2 是怎么测出来的????.
我的猜测:是不是这个程序主要是单个数据的GPU的运算速度快于CPU的读入数据的速度,所以你增大批次是无效的.GPU其实总是要等CPU一段时间.那有没有办法加快CPU读取的速度呢,来提高整体速度呢,下一步我将测试这个.
ps 添加
- 显存占用不是和 batch_size 简单成正比，模型自身的参数及其延伸出来的数据也要占据显存
- batch_size 越大，速度未必越快。在你充分利用计算资源的时候，加大 batch size 在速度上的提升很有限（主要是并行计算的优化，多张GPU的计算能力）。
- 速度对与GPU来说最主要跟显卡的tflops有关。与占用的显存大小无关。有时增大批次速度变快主要是可能之前没把GPU的计算处理能力全部调用起来。