Running many parallel v-rep instances

Typically: "How do I... ", "How can I... " questions
Post Reply
Posts: 1
Joined: 25 Oct 2019, 16:51

Running many parallel v-rep instances

Post by MikeAngus » 30 Oct 2019, 10:00

As part of evolutionary robotics research, we are hoping to run many parallel instances of V-Rep simultaneously for evaluating the members of each population; potentially up to 64 threads on a 2990WX Threadripper-based PC. This raises some interesting questions that we have no idea how to answer:

- Will this require a separate virtual machine for each instance? Early tests suggest that when two instances are run on the same machine, only one of them is able to successfully save out to file, which might suggest that there is some conflict like the use of common directories for run-time files. If so, obviously running a lot of virtual machines would be very inefficient, so it'd be much better to avoid this - any suggestions for alternative strategies?

- Assuming that we need hardware graphics processing to handle cameras/visual sensing on the robots, how might the graphics hardware be shared between the threads? Also, how much GPU power might that then require? This is a really important question as we haven't bought the computer hardware yet and graphics hardware is easily the most widely variable in terms of potential cost.

Any thoughts, insights, experience or suggestions would be hugely welcome! Thank you :)

Site Admin
Posts: 7396
Joined: 14 Dec 2012, 00:25

Re: Running many parallel v-rep instances

Post by coppelia » 01 Nov 2019, 12:08


as of now, we haven't put too much emphasis on the multiple instance aspect, since this is not the regular use case.

Within one V-REP instance things are not really parallelized, since we wouldn't otherwise be able to synchronize the various script executions. So in the end, a single thread is handling the whole simulation. Even with threaded child scripts, that behaves more like coroutines rather than real threads. This again for the same reason of wanting to have a strict synchronization (or synchronization possibility). The UI runs inside of another thread.

If you start V-REP several times from the same folder, then you'll possibly have conflicting access to files when V-REP writes them. But V-REP rarely writes to file, except for scene auto-save, user settings modification, and a few other things, which can be suppressed via the user setting file (system/usrset.txt).

GPU (basically only vision sensors) is also sequentially used within one V-REP instance.

Processing/thread and GPU distribution across several instances is handled by the system and you can't directly influence this.

Since we haven't tried this ourselves, you'll have to make tests and see which set-up/configuration works best


Post Reply