A vision of a multi-threaded Emacs (2022)

https://coredumped.dev/2022/05/19/a-vision-of-a-multi-threaded-emacs/

by tosh • 2 years ago

93 15 2 years ago

sapiogram• 2 years ago

Level 2 - memory safe and data races allowed
Languages where parallelism is memory safe, but can still lead to data races.
This includes Java and Go.

Despite this common misconception, parallel Go is absolutely not memory safe: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...

tra3• 2 years ago

As a user, after using emacs for the past couple of years this is where emacs shows its age vs the “newcomers”. Every once in a while the whole UI is blocked when a long running task is invoked. Still, I love using emacs.

rickstanley2• 2 years ago

I'm a newcomer, started using Emacs in 2022, well, not vanilla, but Doom Emacs. I was immediately hooked! The defaults are sane for my workflow, and to make it short: it boosted my productivity. But, I've been bitten many times by Emacs' UI nature, unfortunately, mainly in big repos. It's not bad enough to drive me away though.

I has gotten better over this past year, I've noticed many improvements with Nativa Compilation and Tree-Sitter, not sure if it can get even better; I sure hope so.

finaard4• 2 years ago

We're now at Emacs 29. I've been following the threads stuff back then out of curiosity - but never seen it as game changer, as most of the annoyances where stuff hangs could just be solved by using async methods.

I just went over all my packages - I'm not using a single one which does make use of the threads API. I used to use lsp-mode, which _does_ create a thread in one situation - which also could've been solved by doing async calls.

A lot of the stuff that should've used async, but didn't got fixed, plus there's an external library to move some other stuff along. I've moved gnus (which used to be notorious for blocking everything) into my main emacs process years ago - and last year even tried setting up a new notebook without the local imap, and made it directly go to upstream servers. Turns out, so much improvements landed in the imap code over the years that doing this works so well now that I've dropped the local cache from all my existing systems by now.

rickstanley2• 2 years ago

I used to use lsp-mode

Do you not use it any more? Have you switched to Eglot or something?

I use lsp-mode, was going to switch to eglot, but it doesn't have the features that lsp-mode has, like lsp-ui (as far as I can remember), and the last time a compared (last year), the performance impact was somewhat noticeable.

aulin• 2 years ago

Eglot philosophy is to hook into existing emacs features instead of reinventing the wheel, so you may find some of the lsp-mode/lsp-ui features in other packages. imenu-list for sideline navigation, breadcrumb, flymake has a way to display inline diagnostics (can never remember how as I don't use it and google does not help).

I work on a huge codebase with eglot+clangd and the few times where it gets slow is where there are tons of flymake warnings. Like when you enable all the clang-tidy checks.

finaard4• 2 years ago

I've found lsp-mode to troublesome to configure for what it provided, and occasionally getting in the way, so with emacs 29 I just moved to the integrated eglot. Not that I'm using it much, though - I've found it marginally useful for getting used to new languages, but generally prefer to just have full documentation open - once I'm familiar with the code base completion tends to just get in the way, so I often have any form of completion switched off anyway.

taeric• 2 years ago

I've been curious why threads will be so much better than async. My gut was that they are both hard to do and the default will be to just run the compute. But once you have to offload compute from main thread, seemed we already had facilities and examples. What is new with threads?

samsquire• 2 years ago

Thank you, this was really interesting.

Multithreading and parallelism is my hobby, so I'm curious how emacs implements this. I imagine it would be really difficult to migrate the entire ecosystem from code that is not designed to be accelerated by multicore.

I feel that if you just add a mutex, the code will fall very short of expectations of Amdahls law because:

* you cannot accelerate any single memory address mutability rates/performance by adding threads * to accelerate write/read performance (to get up to theoretical memory bandwidth) you need no-locks and multiple threads with DIFFERENT memory addresses

You need a different model to programming that is efficient.

One thing I can think of is that each thread owns a few buffers and you load balance that way.

A vision of a multi-threaded Emacs (2022)

Related Stories