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