Slow RL-Viz rendering

[W Bradley Knox]

Brian et al.,

We're having some strange issues with the environmental rendering
speed in RL-Viz on some computers that Matt Taylor's trying to run
TAMER on. It's updating the Environment Visualizer every 10 time steps
or less often. I believe this is happening with both Mountain Car and
Cart Pole. I've checked that render() in Cart Pole is called each time
step, so the issue isn't there. And I can't find where in the RL-Viz
code it updates the graphics, so I wasn't able to check that.

Can you tell me where in the RL-Viz code I would dig into to figure
out what's slowing it down. And/or do you have any general ideas why
this might be an issue on multiple computers of his department's but
not any others (including Cygwin, Mac, and Linux machines at UT)?

Thanks,
Brad

>>>>>
>>>>>
>>>>> On Mon, Apr 4, 2011 at 3:32 PM, Matthew E. Taylor <tay...@lafayette.edu> wrote:
>>>>>> Yes - it's run on the box I'm sitting in front of. I've never seen
>>>>>> that either....
>>>>>> Do you know how to print out the frame rate or # of updates in RL-viz?
>>>>>> I'm not sure I know enough to go digging around in your code, but if
>>>>>> you can't replicate the problem from texas, I'm not sure what the best
>>>>>> strategy is.
>>>>>>
>>>>>> -Matt
>>>>>>
>>>>>>
>>>>>> -----------------------------------------------------------
>>>>>> Matthew E. Taylor   |  Lafayette College
>>>>>> Assistant Professor |  Computer Science
>>>>>> http://cs.lafayette.edu/~taylorm
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 4, 2011 at 3:28 PM, W Bradley Knox <brad...@cs.utexas.edu> wrote:
>>>>>>> Weird. That's never been an issue before. And you're running it locally?
>>>>>>>
>>>>>>> On Mon, Apr 4, 2011 at 2:22 PM, Matthew E. Taylor <tay...@lafayette.edu> wrote:
>>>>>>>> The visualizer is only re-drawing the picture
>>>>>>>> once or twice every episode. I had thought it was just me using VNC,
>>>>>>>> but I went and sat at the machine, and the updates to the visualizer
>>>>>>>> were really slow. It was slow enough that there's really no way to see
>>>>>>>> what the agent's policy is in cart pole.
>>>>>>>>
>>>>>>>> -Matt
>>>>>>>>

[Brian Tanner]

Hmph.  That is weird.  RL-Viz does a bunch of things to be fancy at many different layers.  There is the whole layered drawing subsystem where things only get re-drawn when they change, so you can layer some vizcomponents that get drawn often (Car) over some that don't (Mountain) and each separate component will only be drawn when it needs to be.  I won't pretend it's necessarily elegant or well written, but  it was an attempt at being efficient when I started the project, so that I could support fancy visualizations.

Then there is also the whole vizcomponent render system that I overhauled at NIPS 2008 I think... when I added the polling vizcomponents and the self updating viz components. It's all a bit murky in my memory unfortunately.  If it works on some computers and not others.. well, that's just gross.

Is this happening on ALL environments or SOME environments?  That should tell us a lot.

I would suggest troubleshooting by running an environment that uses the GenericVisualizer, because it has a GenericScoreComponent that should be updated at every step:

http://code.google.com/p/rl-viz/source/browse/trunk/projects/rlVizLibJava/src/rlVizLib/visualization/GenericScoreComponent.java

The GenericVisualizer should load up automatically if you have the environment visualizer on and there is no environment-specific one, I think.  Actually even mountain car and acrobat probably use that score component in the top corner... does the step counter really not get updated every step? Is this only with TAMER or with a regular old random agent?

Can you isolate two machines, one with the problem and one without and see if Java is different? What OS/Platform are the problematic machines running?  Is RL-Viz being run over sockets or in auto-load happy Java land?  So yeah it turns out I have lots of questions but I'd start troubleshooting from the machines first, not from the code first.  But that's because maybe I haven't looked at all the stuff you guys have already.

--

Brian Tanner

br...@fireplan.ca

Cell: 204.228.1683

Fire Plan Strategies:  We provide fire safety training, planning, signs, and supplies across Canada!

Our business grows by referrals. If you have any associates who may be interested in our services, we would appreciate your referral.

WHEN THE FIRE TRUCKS ROLL, IT'S TOO LATE TO PLAN!

--
You received this message because you are subscribed to the Google Groups "rl-library" group.
To post to this group, send email to rl-li...@googlegroups.com.
To unsubscribe from this group, send email to rl-library+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rl-library?hl=en.

[W Bradley Knox]

Hi, Brian. Weird indeed. In fact, the problem disappeared once we
started printing to the terminal every time render() was called in
Cart Pole. We were in a hurry to do experiments, so we just left that
in and didn't test whether that was just coincidental. After your
graciously thorough response, this is a lame epilogue. Thank you
though. I'll let you know if we do test it again and find that the
printing has no effect, and whatever was causing the problem just
disappeared without our notice.

Brad