Info: No GIL Multithreading strat for Python

Info: No GIL Multithreading strat for Python

[Arthur Miller]

I just stumbled over an intersting presentation of a multithreading experiment
for a "no-gil" Python, with relatively well-explained strategy they use,
problems they face and what it offers:

https://www.youtube.com/watch?v=rImAmkS2ySE&t=2s

The presentation is about ~ ½ year old, I have no idea what is the status and
how well it works. But some of what they discuss is perhaps of the interest for
emacs devs.

Sorry for the "non-free" platform; use the yt-download or something if it
bothers. I don't think the presentation is available elsewhere.

Re: Info: No GIL Multithreading strat for Python

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Date: Sun, 03 Mar 2024 12:50:18 +0100
> 
> 
> I just stumbled over an intersting presentation of a multithreading experiment
> for a "no-gil" Python, with relatively well-explained strategy they use,
> problems they face and what it offers:
> 
> https://www.youtube.com/watch?v=rImAmkS2ySE&t=2s
> 
> The presentation is about ~ ½ year old, I have no idea what is the status and
> how well it works. But some of what they discuss is perhaps of the interest for
> emacs devs.

Python is a programming language, where the programmers are
responsible for what the parallel programs they write do and how do
they cope with the various dangers of concurrency.  If the program
crashes, the programmer has only him/herself to blame.

By contrast, Emacs is a program that lets users process text in
various scenarios, where users expect Emacs to react gracefully to
errors.  Emacs the program has a very large global state that doesn't
work well with any concurrency, and which any programmer will keep as
far from as possible.  If Emacs crashes, users blame Emacs, not the
Lisp they wrote.

So there's a large difference, and therefore not every technique used
by a programming language can be used by Emacs to achieve similar
goals.

Re: Info: No GIL Multithreading strat for Python

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Date: Sun, 03 Mar 2024 12:50:18 +0100
>> 
>> 
>> I just stumbled over an intersting presentation of a multithreading experiment
>> for a "no-gil" Python, with relatively well-explained strategy they use,
>> problems they face and what it offers:
>> 
>> https://www.youtube.com/watch?v=rImAmkS2ySE&t=2s
>> 
>> The presentation is about ~ ½ year old, I have no idea what is the status and
>> how well it works. But some of what they discuss is perhaps of the interest for
>> emacs devs.
>
> Python is a programming language, where the programmers are
> responsible for what the parallel programs they write do and how do
> they cope with the various dangers of concurrency.  If the program
> crashes, the programmer has only him/herself to blame.

I am not sure what you are trying to say? Python is not Elisp; Elisp is not
Python, and Python interpretter is not Emacs, and Emacs is not Python
interpretter. I think it is self-evident. Sure, nobody said they are the same?

Anyway; Python Intepretter and Emacs are not the same, but there are some
important similarities and similar problems. What they are talking there might
be an interesting multithreading strategy for Emacs as well. They have similar
problem with the shared state.

> By contrast, Emacs is a program that lets users process text in
> various scenarios, where users expect Emacs to react gracefully to
> errors.  Emacs the program has a very large global state that doesn't
> work well with any concurrency, and which any programmer will keep as

Yes, we all know that, and that is what that presentation was about; that is why
I have hinted abou it.

> far from as possible.  If Emacs crashes, users blame Emacs, not the
> Lisp they wrote.

Mnjah; I think you are little bit unjust to your users here :). I think that
people do understand when they write bad code and crash Emacs.

> So there's a large difference, and therefore not every technique used

Naturally, there is a difference between a text editor and an interpretter; but
Emacs happens to be both at the same time; and the interpretter part is rather
similar to Python.

> by a programming language can be used by Emacs to achieve similar
> goals.

Of course; and nobody said that you pick any random strat for some programming
language implementation and apply to Emacs.

However, what they are trying to solve there, is potentially very similar to
what we have in Emacs too.

Anyway, just information sharing.

Re: Info: No GIL Multithreading strat for Python

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 03 Mar 2024 20:01:06 +0100
> 
> > Python is a programming language, where the programmers are
> > responsible for what the parallel programs they write do and how do
> > they cope with the various dangers of concurrency.  If the program
> > crashes, the programmer has only him/herself to blame.
> 
> I am not sure what you are trying to say?

Just what I said: that problems with implementing concurrency in Emacs
are not problems of the Emacs Lisp programming language.  So they
cannot be solved solely by changing the language.

> Anyway; Python Intepretter and Emacs are not the same, but there are some
> important similarities and similar problems. What they are talking there might
> be an interesting multithreading strategy for Emacs as well. They have similar
> problem with the shared state.

No, the problems in Emacs are much harder, because the shared state
exists independently of the programs written in Emacs Lisp, and
because the way we write Emacs Lisp programs basically _requires_ the
shared state to exist.

> > By contrast, Emacs is a program that lets users process text in
> > various scenarios, where users expect Emacs to react gracefully to
> > errors.  Emacs the program has a very large global state that doesn't
> > work well with any concurrency, and which any programmer will keep as
> 
> Yes, we all know that, and that is what that presentation was about; that is why
> I have hinted abou it.

Yes, we all know what you wanted to say.  And that is why I wrote the
response: to point out an important caveat.  So that people would keep
that in mind when they watch.

Re: Info: No GIL Multithreading strat for Python

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: emacs-devel@gnu.org
>> Date: Sun, 03 Mar 2024 20:01:06 +0100
>> 
>> > Python is a programming language, where the programmers are
>> > responsible for what the parallel programs they write do and how do
>> > they cope with the various dangers of concurrency.  If the program
>> > crashes, the programmer has only him/herself to blame.
>> 
>> I am not sure what you are trying to say?
>
> Just what I said: that problems with implementing concurrency in Emacs
> are not problems of the Emacs Lisp programming language.  So they
> cannot be solved solely by changing the language.

I am not sure if that would be a change the Emacs Lisp language per se; rather
to the implementation of the language (the lisp machine that the C core is).

>> Anyway; Python Intepretter and Emacs are not the same, but there are some
>> important similarities and similar problems. What they are talking there might
>> be an interesting multithreading strategy for Emacs as well. They have similar
>> problem with the shared state.
>
> No, the problems in Emacs are much harder, because the shared state
> exists independently of the programs written in Emacs Lisp, and

How is shared state in Emacs independent of Emacs Lisp programs? Lisp programs
can modify, introduce and remove shared state, and that is what they do all the
time; and so can Python programs. I am not sure I following; honestly, I am
probably thinking of something different than you there.

Anyway, it is not impossible that Emacs case is harder. I don't say either yes
or no. I don't know honestly. But the mentioned "biased reference counting"
seems like something interesting that could/might be usable in Emacs as
well.

Again; I don't know, they are doing an experiment, it may very well end-up that
the experiment fails. I am just sharing the information, perhaps someone more
familiar with the internals can look at it.

> because the way we write Emacs Lisp programs basically _requires_ the
> shared state to exist.

I thought you are talking about the cultural difference between the typical Lisp
and Python programs. By the nature of elisp extensions, as of typical use-case,
they are an addon to the environment, while Python programs are written more as
general-purpose programs. But that is just a typical use-case, not an explicit
limitation in either language. There are Elisp programs that are just that:
programs that use Elisp as a scripting engine, and are not meant as an extension
for the text editor itself.

As we see also in social media, which you read as well, there is a tendency
among users to use Elisp for more general computing purposes than just extending
the text editor, which I personally think is a good thing, but that is a regression.

>> > By contrast, Emacs is a program that lets users process text in
>> > various scenarios, where users expect Emacs to react gracefully to
>> > errors.  Emacs the program has a very large global state that doesn't
>> > work well with any concurrency, and which any programmer will keep as
>> 
>> Yes, we all know that, and that is what that presentation was about; that is why
>> I have hinted abou it.
>
> Yes, we all know what you wanted to say.  And that is why I wrote the
> response: to point out an important caveat.  So that people would keep
> that in mind when they watch.

Definitely, I agree with you, and I don't thing it is 1:1 either, but the
strategy is perhaps worth looking at.

Re: Info: No GIL Multithreading strat for Python

[Eli Zaretskii]

> From: Arthur Miller <arthur.miller@live.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 04 Mar 2024 13:19:15 +0100
> 
> >> Anyway; Python Intepretter and Emacs are not the same, but there are some
> >> important similarities and similar problems. What they are talking there might
> >> be an interesting multithreading strategy for Emacs as well. They have similar
> >> problem with the shared state.
> >
> > No, the problems in Emacs are much harder, because the shared state
> > exists independently of the programs written in Emacs Lisp, and
> 
> How is shared state in Emacs independent of Emacs Lisp programs?

Because Emacs Lisp programs run inside Emacs, and Emacs itself has a
very large global shared state.  The tiniest ELisp program inherits
that state whether it wants it or not.  By contrast, a Python program
has only the state that the programmer programmed.

> Lisp programs
> can modify, introduce and remove shared state, and that is what they do all the
> time; and so can Python programs. I am not sure I following; honestly, I am
> probably thinking of something different than you there.

In Emacs, we have the current buffer and the selected window, and all
of the global variables and symbols that exist in Emacs from the
get-go.  A Lisp program cannot remove that state.

Re: Info: No GIL Multithreading strat for Python

[Arthur Miller]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Arthur Miller <arthur.miller@live.com>
>> Cc: emacs-devel@gnu.org
>> Date: Mon, 04 Mar 2024 13:19:15 +0100
>> 
>> >> Anyway; Python Intepretter and Emacs are not the same, but there are some
>> >> important similarities and similar problems. What they are talking there might
>> >> be an interesting multithreading strategy for Emacs as well. They have similar
>> >> problem with the shared state.
>> >
>> > No, the problems in Emacs are much harder, because the shared state
>> > exists independently of the programs written in Emacs Lisp, and
>> 
>> How is shared state in Emacs independent of Emacs Lisp programs?
>
> Because Emacs Lisp programs run inside Emacs, and Emacs itself has a
> very large global shared state.  The tiniest ELisp program inherits
> that state whether it wants it or not.

Yes, but every interpretter and runtime has some state exposed to applicaiton
programs and shared with them. Otherwise we are speaking about assembly or C at
best. I agree that Python is much smaller and cleaner, then Emacs. But I think
the priniple with the shared state is still similar.

>> Lisp programs
>> can modify, introduce and remove shared state, and that is what they do all the
>> time; and so can Python programs. I am not sure I following; honestly, I am
>> probably thinking of something different than you there.
>
> In Emacs, we have the current buffer and the selected window, and all
> of the global variables and symbols that exist in Emacs from the
> get-go.  A Lisp program cannot remove that state.

Of course. But buffers and other objects are built-in parts of the
implementation. Every runtime has some parts that are not exposed to applicaiton
programs, and can't be altered.

Emacs adds many special-purpose objects to its Lisp machine, I agree. But that
is rather volume. The solution they are trying seems to address exactly that
problem: shared objects, so principally it might be something for the Emacs too;
but practically I don't know.

Re: Info: No GIL Multithreading strat for Python

[Konstantin Kharlamov]

On Mon, 2024-03-04 at 14:44 +0200, Eli Zaretskii wrote:
> > From: Arthur Miller <arthur.miller@live.com>
> > Lisp programs
> > can modify, introduce and remove shared state, and that is what
> > they do all the
> > time; and so can Python programs. I am not sure I following;
> > honestly, I am
> > probably thinking of something different than you there.
> 
> In Emacs, we have the current buffer and the selected window, and all
> of the global variables and symbols that exist in Emacs from the
> get-go.  A Lisp program cannot remove that state.

I'd like to just point out that a state that a program does not use is
not interesting in context of the comparison to Python. Python too has
an unsolicited global state a program may modify. In a module with no
imports you have __name__, __doc__, __builtins__… And you can modify
all of that.

What matters though is whether the code accesses that. An ELisp program
`(print "hello")` does not access anything, so buffers and stuff being
available doesn't matter.

P.S.: I sometimes wish Emacs had more functions avoiding mutating the
state. E.g. there's a frequent pattern of checking a regexp and
indentation at previous line, and every time it has to be wrapped to a
`(save-excursion …`, because you have to `(forward-line -1)`.

Re: Info: No GIL Multithreading strat for Python

[Eli Zaretskii]

> From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
> Cc: emacs-devel@gnu.org
> Date: Mon, 04 Mar 2024 19:30:32 +0300
> 
> What matters though is whether the code accesses that. An ELisp program
> `(print "hello")` does not access anything, so buffers and stuff being
> available doesn't matter.

I think if this is your idea of how programs run in Emacs and which
parts of the global state they use, it is a very inaccurate idea.

But I will bow out of this discussion, since all I had to say on this
subject I did say already.

Re: Info: No GIL Multithreading strat for Python

[chad]

[-- Attachment #1.1: Type: text/plain, Size: 362 bytes --]

People who are interested in this topic might want to take a look at this
examination of the subject from a couple years back:

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

I suggest follow-ups to emacs-tangents, and have attempted to encourage
that. Please forgive me if my somewhat clumsy attempt to do so goes awry.

Thanks!
~Chad

[-- Attachment #1.2: Type: text/html, Size: 519 bytes --]

[-- Attachment #2: Type: text/plain, Size: 92 bytes --]

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

Re: Info: No GIL Multithreading strat for Python

[chad]

[-- Attachment #1: Type: text/plain, Size: 362 bytes --]

People who are interested in this topic might want to take a look at this
examination of the subject from a couple years back:

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

I suggest follow-ups to emacs-tangents, and have attempted to encourage
that. Please forgive me if my somewhat clumsy attempt to do so goes awry.

Thanks!
~Chad

[-- Attachment #2: Type: text/html, Size: 519 bytes --]