openai / mujoco-py

MuJoCo is a physics engine for detailed, efficient rigid body simulations with contacts. mujoco-py allows using MuJoCo from Python 3.
Other
2.87k stars 813 forks source link

Big drop in performance in new version #58

Open Feryal opened 7 years ago

Feryal commented 7 years ago

Thanks a lot for the new release, I'm really excited about being able to use the newer version of MuJoCo and its features! :tada:

Unfortunately, since upgrading to the new bindings, I've seen a big drop in performance, specifically linked to RGB rendering.

I'm training an agent using RGB inputs, that I used to capture from a MjViewer instance (I actually capture 2 different views, but the problem is the same for a single view). I now use the MjSim render() method (which is nicer, thanks) .

Unfortunately, I'm seeing a 3-4x drop in performance per thread, which compounds with multiprocessing, making training nearly impossibly slow right now...

Here are some profiling traces. Obviously there is some variability, but these numbers seem pretty consistent.

This is with the codebase v0.5:

*** PROFILER RESULTS ***
_step function called 1 times

         329 function calls in 0.018 seconds

   Ordered by: cumulative time, internal time, call count
   List reduced from 87 to 40 due to restriction <40>

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000    0.018    0.018 myenv.py:68(_step)
        1    0.000    0.000    0.016    0.016 myenv.py:42(_get_obs)
        2    0.000    0.000    0.016    0.008 mujoco_env.py:120(_render)
        1    0.000    0.000    0.014    0.014 myenv.py:52(_get_obs_rgb_view1)
        2    0.000    0.000    0.011    0.006 mjviewer.py:118(get_image)
        4    0.000    0.000    0.011    0.003 mjviewer.py:110(get_dimensions)
        4    0.011    0.003    0.011    0.003 glfw.py:916(get_framebuffer_size)
        2    0.004    0.002    0.004    0.002 mjviewer.py:91(render)
        1    0.000    0.000    0.001    0.001 myenv.py:60(_get_obs_rgb_view2)
        1    0.000    0.000    0.001    0.001 mujoco_env.py:105(do_simulation)
        4    0.001    0.000    0.001    0.000 mjcore.py:79(step)
        2    0.001    0.000    0.001    0.000 images.py:338(glReadPixels)

This is with the new codebase:

*** PROFILER RESULTS ***
step function called 1 times

         65 function calls in 0.058 seconds

   Ordered by: cumulative time, internal time, call count

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.000    0.000    0.058    0.058 myenv.py:131(step)
        1    0.000    0.000    0.056    0.056 myenv.py:114(get_obs)
        2    0.000    0.000    0.056    0.028 myenv.py:97(render)
        2    0.056    0.028    0.056    0.028 {method 'render' of 'mujoco_py.cymj.MjSim' objects}
        1    0.000    0.000    0.029    0.029 myenv.py:109(_get_obs_rgb_view2)
        1    0.000    0.000    0.028    0.028 myenv.py:104(_get_obs_rgb_view1)
        1    0.000    0.000    0.001    0.001 myenv.py:117(do_simulation)
        4    0.001    0.000    0.001    0.000 {method 'step' of 'mujoco_py.cymj.MjSim' objects}

My assumptions for why that may be are currently: 1) There is no go_fast option in the new codebase anymore. Would that mean that we are stuck at 60Hz even in offscreen rendering? 2) The render() function in the MjSim class and the MjRenderContext became slower due to added ifs and memory allocations?

Trying to force a GLFW context instead of the new OpenGL one didn't help.

I'm using CPU offscreen rendering, Linux Ubuntu 16.04, Python 3.5.2.

It would be great if you could tell me what I may be doing wrong or if you are seeing this on your side as well?

welinder commented 7 years ago

@Feryal this is a known issue where GLFW rendering isn't supported on Linux. It's currently using OSMesa, which is unfortunately much slower (but makes headless rendering easier since you don't need xserver running etc). That said, it should be pretty straight forward to add GLFW support by just changing builder.py to link against GLFW on Linux as well, and then add some flag to MjSim.render to make it use the GLFW backend instead. We don't have immediate plans add it at the moment, but I'd be happy to review a PR for it.