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