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

[Ted Zlatanov <tzz@lifelogs.com>]

On 04 Dec 2003, monnier@iro.umontreal.ca wrote:

>> take too long.  I understand all this can be hacked into place, but
>> is it really necessary to avoid multithreading so desperately?
> 
> Nobody is avoiding it here.  We're just explaining to you why nobody
> bothered to do it yet and why none of us feels the urge to do it:
> lots of work, unclear payoff.

I was referring to hacking things into place in that particular
example, where multithreading seemed like a natural approach, not the
attitude of this group.  Sorry if it seemed otherwise.  The attitude
of this group of developers is wonderful.

>> Plus, I am pretty sure that when an application uses N processors
>> instead of one (as Emacs might with true preemptive multithreading)
>> there is at least some speed improvement.
> 
> Your being pretty sure does not magically eliminate all the known
> counter examples.

You're right.  I had specific applications in mind, not any general
application.  In the general case that is not necessarily true,
because not all applications can take advantage of multithreading of
course.  I think that Emacs in particular can use it right now, and
that applications will develop in time that will take full advantage
of multithreading.

>> (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
benchmarks, vendors' benchmarks.  I think you'll find that Solaris
specifically is known to scale very well with additional processors,
at the penalty of being pretty slow on a single-processor machine.

The Linux kernel (2.5 especially), to give another example, scales
well with additional processors too, even when hyper-threading instead
of a real additional processor is used.  See this article for an
overview and benchmarks:

http://www-106.ibm.com/developerworks/linux/library/l-htl/

Note I did not say that an *application's* performance increases by at
least 80%.  The machine's performance, given processes or threads
within them that can be effectively run on separate processors by the
OS scheduler, is what increases.  This is generally understood but
perhaps my language was not clear enough.

> Yes, things can be made to work well, but do you have an idea of the
> amount of work it takes to do that ?

Specifically in the context of Emacs, I do not know the internals well
enough to judge that.  I hope I can help with the work in any way I
can, no matter what the eventual "multithreading or not" decision is.

Ted