Re: Lush2 performance

Yann LeCun <[email protected]> Sun, 15 Mar 2009 17:56:56 -0400
Newsgroups gmane.lisp.lush.devel
Organization Courant Institute, NYU
Message-ID <[email protected]>
Unfortunately (as you probably suspected), shutting off gc doesn't
solve the problem.  

If a robot runs a sensor-reading/actuator-controlling loop, it will
eventually run out of memory and probably crash unless the gc is
called periodically. While gc runs, the robot runs blinds (or the
game, video, or music stops in a multimedia app).

One possibility is to systematically call the gc at the end of the loop,
but the question is: how long does the gc takes to complete, even if
little a small amount of memory was allocated since the last call?

On the current SVN version of lush2, a simple call to (gc) on a
"blank" interpreter (right after startup) takes about 15ms on my
Core2Duo laptop. That makes the option of calling (gc) all the time
totally impractical.

If lush2 is to be used for applications where a predictable response
time is required, which includes real-time vision and signal
processing, robotics, games, video and multimedia, it seems to me that
a separate gc thread is the only viable solution.

That's precisely why Java has a separate thread for gc.

These applications are very important to many Lush users.

  -- Yann


On Sunday 15 March 2009, Ralf Juengling wrote:
> Not sure if it solves the problem, but I added a new
> form 'with-nogc' which temporarily blocks garbage
> collections. Should work when the number of allocations
> in the loop is within reasonable limits.
>
> You can do a similar thing in C (see the implementation
> of with-nogc in toplevel.c).
>
> Ralf
>
> On Wed, 11 Mar 2009, Yann LeCun wrote:
> > One problem with a single thread implementation of
> > course is that it pretty much precludes the use
> > of Lush 2.0 for any semi-real-time application
> > like robotics or games. For these applications
> > you want a repeatable run time for a loop, and
> > can't afford to have the system sit around and do
> > garbage collection once in a while.
> >
> > So, maintaining the option to spawn a separate
> > thread for GC might be a good idea.
> >
> >  -- Yann
>
> ---------------------------------------------------------------------------
>--- Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> Lush-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/lush-devel



------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com