Re: Lush2 performance
Yann LeCun <[email protected]> Wed, 11 Mar 2009 18:12:46 -0400
| Newsgroups | gmane.lisp.lush.devel |
|---|---|
| Organization | Courant Institute, NYU |
| Message-ID | <[email protected]> |
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 On Wednesday 11 March 2009, Ralf Juengling wrote: > Hey Lushies, > > If you have played around with Lush 2 a bit you will > have noticed that it runs quite a bit slower than > Lush 1.x. The reason is that much has changed under > the hood, Lush 2 is powered by a mark-and-sweep garbage > collector, whereas Lush 1.x uses reference counting > internally. So a *lot* has changed in the interpreter > and getting the interpreter to work again after taking > it apart and putting it back together was the main > concern. > > The reason we changed to a mark-and-sweep collector is > that it is now much easier to re-write the compiler so > that compiled code behaves the same as interpreted code > in terms of memory management (no more memory pools for > dynamically allocated objects and no more "hidden > arguments" problems...). Alas, we are not there yet and > won't be for the 2.0 release. > > The collector currently spawns a child process to do the > mark-and-sweep, so it is working "concurrently" in a > modest sense. I was doing a lot of experiments and found > that this does not really speed things up significantly > on a multicore box. Apparently the cost of spawning a > child process is large enough (on a linux box at least) > to offset the concurrency gains. > > I finally decided to simplify the collector and to rip out > all the code that has to do with creating the child process > and with communication. After this, the interpreter was a > fast as before, but it opened the possibilities for some > other optimizations in the interpreter. After all this Lush2 > is within a factor of two to Lush 1.x in terms of execution > speed on my machine (if you want to check it out, the code > is currently in the branch lush2-mmrev, I will merge it > back into trunk within a few days). > > This simplification should also eliminate some potential > portability problems (to be looked at this summer)! > > Cheers, > Ralf > > > --------------------------------------------------------------------------- >--- 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