MCG-NJU / MOTIP

Multiple Object Tracking as ID Prediction
https://arxiv.org/abs/2403.16848
Apache License 2.0
111 stars 10 forks source link

训练时gpu利用率极低,而且巨慢 #12

Closed hanzifan closed 6 months ago

hanzifan commented 6 months ago

您好,非常感谢您的工作。我现在在跑训练代码时遇到了一个问题。就是训练速度特别的慢,前100个iter卡了30分钟都没有任何动静,同时gpu利用率常年在50以下,请问这是正常的吗。 1715760715623 1715760784441

hanzifan commented 6 months ago

我记得我之前跑MOTR的时候100个iter只需要几分钟,感觉有点奇怪

HELLORPG commented 6 months ago

请问一下你所用机器的 CPU 是什么?或者您直接告诉我总计有多少个物理核心。

hanzifan commented 6 months ago

请问一下你所用机器的 CPU 是什么?或者您直接告诉我总计有多少个物理核心。

2颗Intel(R) Xeon(R) Gold 6248R CPU @ 3.00GHz, 96虚拟个核心,24个物理核心,我刚刚1个iter print了一下看了看,sportsmot 1个epoch要4.5个小时感觉有点慢。

hanzifan commented 6 months ago

请问一下你所用机器的 CPU 是什么?或者您直接告诉我总计有多少个物理核心。

2颗Intel(R) Xeon(R) Gold 6248R CPU @ 3.00GHz, 94个核心,我刚刚1个iter print了一下看了看,sportsmot 1个epoch要4.5个小时感觉有点慢。

我又多跑了几个iter看了看好像不止4.5个小时 1715763477690

HELLORPG commented 6 months ago

这个 CPU 配置对于 24G 来说稍微有点低,对于视频长序列的数据处理可能会有点压力。 你可以尝试一下在运行脚本中加入:--num-workers 3 --num-cpu-per-gpu 5,整体依据是 --num-cpu-per-gpu * n_gpus 不要大于你机器中的总物理核心数,此外 --num-workers 要小于 --num-cpu-per-gpu。

hanzifan commented 6 months ago

ok,他现在快了好多,sportsmot train+val大约2.5个小时一个epoch。看来就是dataloader这的问题,而且我们的内存条也不太行,估计也有这个原因。谢谢。

HELLORPG commented 6 months ago

不用谢~ 长时序连续的处理确实比较耗费 CPU 资源,同时感觉 pytorch 中的数据处理方法并没有特别好的解决办法,我之前有尝试过很多加速的方法,但是并没有解决这个问题。尤其是主要的问题出现在不同的数据处理线程之间会对 CPU 资源进行抢占,这一问题在有虚拟 CPU 的机器上会更加明显。 如果你之后可以找到更好的加速方法或者数据处理方法的话,也欢迎交流~

zsz00 commented 6 months ago

序列数据 的预处理(增强) 都是在cpu上做的, 会慢. 可以尝试用dali做dataloader, 预处理会在gpu上做, 会快很多.

HELLORPG commented 5 months ago

@hanzifan 在近期的其他工作中找到了一种加速的方法,可以尝试将 Normalization 和 ToDtype 这两类张量操作放到 dataloader 外部做(放到 training loop 中,.to("cuda") 之后做),可以加速并且可以用更高的 num_workers。您可以尝试一下,有时间了之后可能会更新到这个库中,最近有点忙,就先不更新了。

hanzifan commented 5 months ago

@hanzifan 在近期的其他工作中找到了一种加速的方法,可以尝试将 Normalization 和 ToDtype 这两类张量操作放到 dataloader 外部做(放到 training loop 中,.to("cuda") 之后做),可以加速并且可以用更高的 num_workers。您可以尝试一下,有时间了之后可能会更新到这个库中,最近有点忙,就先不更新了。

ok, 感谢