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

[Ted Zlatanov <tzz@lifelogs.com>]

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

>> I don't think process filters would help much if I wanted to look
>> up several entries in a hashtable in parallel to build an article
>> summary buffer.  Right now, doing this sequentially is the only
>> way, and consequently doing fancy things while building the summary
>> buffer is not a good idea.
> 
> So you want to reduce the time it takes to build a summary buffer?
> I agree that it would be good to build the summary buffer "in the
> background" so I can do something else during this time, but if you
> want to use parallelism to make things faster, then I think you're
> barking up the wrong tree: Emacs is not optimized for speed and
> there are probably much easier ways to make it faster.  Easier and
> safer as well (after all, parallelising doesn't always speed things
> up, far from it).

The point is not to make Emacs *faster* but to make the user
experience better :) When Emacs can *respond* faster due to preemptive
multithreading, the user can start reading a message thread while the
summary buffer is being built, or the user can cancel the summary
build and leave the group if something else came up.  C-g is the only
option to do the latter right now, and for instance nnrss servers in
Gnus can be very slow so I often find myself hitting C-g when they
take too long.  I understand all this can be hacked into place, but
is it really necessary to avoid multithreading so desperately?

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.  With the good ole Pentiums
this was not such an issue, but today's processors are definitely
better at simulating multiples (hyperthreading) or cooperating
(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.

Ted