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

Multiprocessing very slow #34

Open
TrentBrick opened this issue Jun 3, 2020 · 2 comments
Open

Multiprocessing very slow #34

TrentBrick opened this issue Jun 3, 2020 · 2 comments

Comments

@TrentBrick
Copy link

TrentBrick commented Jun 3, 2020

I am running controllertrain.pyon a google cloud VM headlessly with python 3.7 and xvfb. Everything works but I have noticed what seems to be a linear relationship between the number of workers I allow and the time for each worker to execute its rollout.

If only one worker is allowed it can run 200 steps of the environment in 5 seconds. For 10 workers each worker is only able to get 10 steps, this means that the 10 workers are actually 50% slower at getting through the iterations (each worker is outputting the iteration it is on in its rollout (added a print statement inside misc.utils.py for this))!

Has anyone else observed a similar effect? What could be wrong with my server? I am not using any GPUs, just CPU to run the VAE and MDRNN.

Thank you.

@TrentBrick
Copy link
Author

I have started using the Ray multiprocessing library which so far seems to be working very well.

@longfeizhang617
Copy link

Hi,have you ever met a issue like this, when I try to run the controllertrain.py on my local computer,I found that the 32g RAM was quickly out of memory,even though I have set the work_number as 1.I don't know why,have you ever met this issue?

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

2 participants