question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Episodic length always divided by the number of environments for multiprocessing strangely

See original GitHub issue

Important Note: We do not do technical support, nor consulting and don’t answer personal questions per email. Please post your question on the RL Discord, Reddit or Stack Overflow in that case.

Question

Sorry to bother you. I’m using PPO for our task, but still have an issue regarding multiprocessing. To wrap a vector environment, I use make_vec_env with n_envs=1. And I set the episode length always to be 45 steps. And when n_envs=2, the average episode length is also 45 steps which is under expectation. However, when I set the episode length to be 50 steps with n_envs=2, the average episode length during training became 25 strangely.

So I test a few more cases and find that the average episode length is always equal to episode length/n_envs while the trained performance is as well worse when n_envs is larger than 1. From my perspective, episode length should be a value independent of n_envs. And I didn’t find any bugs after checking. However, the episodic length is divided by the number of processes during rollout. May I have your suggestions? Did I ignore anything in the settings?

Checklist

  • [yes] I have read the documentation (required)
  • [yes] I have checked that there is no similar issue in the repo (required)

Issue Analytics

  • State:closed
  • Created a year ago
  • Comments:11 (2 by maintainers)

github_iconTop GitHub Comments

1reaction
Miffylicommented, Jul 3, 2022

Hmm hmm I do not see how that would “fix” the problem: your environments might be reading/writing from/to a shared variable, which is causing the problems with DummyVecEnv (all environments live in the same process). In SubProcVecEnv, each environment lives in a separate process and you probably do not have multiple envs using same variables.

But to answer your question: No, no need to change a thing! Different implementations of VecEnv should act identically when it comes to training, apart from what they do underneath.

0reactions
pengzhi1998commented, Jul 27, 2022

Got it. Really appreciate the great help!

Read more comments on GitHub >

github_iconTop Results From Across the Web

multiprocessing: Understanding logic behind `chunksize`
The algorithm arbitrarily divides the iterable in approximately four times more chunks than the naive approach. More chunks mean more overhead, ...
Read more >
Stable Baselines Documentation - Read the Docs
Utility function for multiprocessed env. :param env_id: (str) the environment ID. :param num_env: (int) the number of environments you wish ...
Read more >
master PDF - Stable Baselines3 Documentation
Note: Trying to create Atari environments may result to vague errors related to missing DLL files and modules. This is an issue with...
Read more >
Prospective memory assessment: Scientific advances ... - NCBI
According to the Multiprocess Framework (McDaniel and Einstein, 2000), PM performance is determined by the allocation of cognitive resources based on the ...
Read more >
shared memory parallelism: Topics by Science.gov
The determined block size comprises, e.g., a total amount of the data to be stored divided by the number of parallel processes.
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found