Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Training is too slow #28

Open
wangq95 opened this issue Mar 19, 2020 · 2 comments
Open

Training is too slow #28

wangq95 opened this issue Mar 19, 2020 · 2 comments

Comments

@wangq95
Copy link

wangq95 commented Mar 19, 2020

Hi, @Tramac , I use your code with default setting, and find the speed of training is too slow. The usage of GPU is less than 10%, resulting in about 130 seconds to train a mini-batch. How to solve this problem?

@Bidski
Copy link

Bidski commented Aug 6, 2021

I am also encountering this issue

@SarBH
Copy link

SarBH commented Sep 14, 2021

Same issue. To debug, I ran timing on each portion of training, I was able to identify the source of the largest delay:
The computation of the SoftmaxCrossEntropyOHEMLoss occurs on CPU:

input_label = target.data.cpu().numpy().ravel().astype(np.int32)

On my workstation and my training data, the training is taking ~1.1 seconds/image. The execution of the forward method in class SoftmaxCrossEntropyOHEMLoss(nn.Module) alone accounts for ~60% of that duration.

Has anyone come up with a more efficient implementation of this OHEM loss? Possibly translating the ops from numpy to torch to be able to run on GPU?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants