Re: Are there plans for a multi-threaded Emacs?

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>> (Xeons).  I don't have benchmarks, sorry, but at least on Solaris
>>> the performance of a machine increases by at least 80% with each
>>> additional SPARC processor.
>> 
>> Such naive sweeping claims would tend to ruin your credibility, I'm
>> afraid.

> OK, here's some Novell benchmarks that show significant increases in
> performance with additional processors in Solaris in a particular
> application (LDAP server):

> http://www.novell.com/info/collateral/docs/4621167.01/4621167.html

> I work with Solaris for a living, so I feel justified in making that
> claim based on what I know - years of experience, Sun's published

Solaris is indeed fairly well designed w.r.t scalability (at the cost of
single-proc performance, of course).  But that only means that Solaris is
not an obstacle: it will not magically make your application scalable
unless your application was designed for it.

Making Emacs scalable is probably best done by starting all over
from scratch.  The current structure of the C code together with the
semantics of elisp means that it's about as far from scalable as you'll
ever get.

Now, that doesn't mean you can't do it, but just that it's going to be a lot
of work and it might introduce subtle incompatibilities, so you need a lot
of motivation to start the effort and you'll need really good arguments to
convince RMS that breaking compatibility is worth the pay off.  Now what is
the payoff ?  Speed.  Given the fact that elisp is known to be slow, and
that pretty much no work has been done to speed up Emacs in the last
N years, I get the impression that nobody really cares about speed here.

What people do care about a little is the "non-blocking thingy" which might
require some form of multithreading but does not require any kind of
scalability and does not require nearly as much work (and as much breakage
of backward compatibility).
So I'd recommend people start with this if they want to work on something
like that.  Once this is done, we might be able to start thinking about
scalability.


        Stefan