paavo512 <paavo@osa.pri.ee> wrote or quoted:
|Anyway, multithreading performance is a non-issue for Python so far as
|the Python interpreter runs in a single-threaded regime anyway, under a
|global GIL lock. They are planning to get rid of GIL, but this work is
|still in development AFAIK. I'm sure it will take years to stabilize the
|whole Python zoo without GIL.

The GIL only prevents multiple Python statements from being
interpreted simultaneously, but if you're waiting on inputs (like
sockets), it's not active, so that could be distributed across
multiple cores.

With asyncio, however, you can easily handle the application
for threads to "wait in parallel" for thousands of sockets in a
single thread, and there are fewer opportunities for errors than
with multithreading.

Additionally, there are libraries like numpy that use true
multithreading internally to distribute computational tasks
across multiple cores. By using such libraries, you can take
advantage of that. (Not to mention the AI libraries that have their
work done in highly parallel fashion by graphics cards.)

If you want real threads, you could probably work with Cython
sometimes.

Other languages like JavaScript seem to have an advantage there
because they don't know a GIL, but with JavaScript, for example,
it's because it always runs in a single thread overall. And in
the languages where there are threads without a GIL, you quickly
realize that programming correct non-trivial programs with
parallel processing is error-prone.

Often in Python you can use "ThreadPoolExecutor" to start
multiple threads. If the GIL then becomes a problem (which is
not the case if you're waiting on I/O), you can easily swap it
out for "ProcessPoolExecutor": Then processes are used instead
of threads, and there is no GIL for those.

If four cores are available, by dividing up compute-intensive tasks
using "ProcessPoolExecutor", you can expect a speedup factor of two
to eight.

With the Celery library, tasks can be distributed across multiple
processes that can also run on different computers. See, for
example, "Parallel Programming with Python" by Jan Palach.

On 29.04.2024 18:19, Stefan Ram wrote:
> paavo512 <paavo@osa.pri.ee> wrote or quoted:
> |Anyway, multithreading performance is a non-issue for Python so far as
> |the Python interpreter runs in a single-threaded regime anyway, under a
> |global GIL lock. They are planning to get rid of GIL, but this work is
> |still in development AFAIK. I'm sure it will take years to stabilize the
> |whole Python zoo without GIL.
>
> The GIL only prevents multiple Python statements from being
> interpreted simultaneously, but if you're waiting on inputs (like
> sockets), it's not active, so that could be distributed across
> multiple cores.
>
> With asyncio, however, you can easily handle the application
> for threads to "wait in parallel" for thousands of sockets in a
> single thread, and there are fewer opportunities for errors than
> with multithreading.

In C++, async io is provided e.g. by the asio library.

Just for waiting on thousands on sockets I believe a single select()
call would be sufficient, no threads or asio is needed. But you probably
meant something more.

>
> Additionally, there are libraries like numpy that use true
> multithreading internally to distribute computational tasks
> across multiple cores. By using such libraries, you can take
> advantage of that. (Not to mention the AI libraries that have their
> work done in highly parallel fashion by graphics cards.)
>
> If you want real threads, you could probably work with Cython
> sometimes.

Huh, my goal is to avoid Python, not to work with it. Unfortunately this
(avoiding Python) becomes harder all the time.

>
> Other languages like JavaScript seem to have an advantage there
> because they don't know a GIL, but with JavaScript, for example,
> it's because it always runs in a single thread overall. And in
> the languages where there are threads without a GIL, you quickly
> realize that programming correct non-trivial programs with
> parallel processing is error-prone.

Been there, done that, worked through it ... 15 years ago. Nowadays
non-trivial multi-threaded parallel processing in C++ seems pretty easy
for me, one just needs to follow some principles and take care to get
the details correct. I guess it's about the same as memory management in
C, one can get it correct with taking some care. In C++ I can forget
about memory management as it is largely automatic, but for
multithreading I still need to take care.

Am 29.04.2024 um 17:19 schrieb Stefan Ram:

> With asyncio, however, you can easily handle the application
> for threads to "wait in parallel" for thousands of sockets in a
> single thread, and there are fewer opportunities for errors than
> with multithreading.
>

But you need multithreading to have maximum throughput since you often
process the data while other data is available.

On 04/29/2024 08:19 AM, Stefan Ram wrote:
> paavo512 <paavo@osa.pri.ee> wrote or quoted:
> |Anyway, multithreading performance is a non-issue for Python so far as
> |the Python interpreter runs in a single-threaded regime anyway, under a
> |global GIL lock. They are planning to get rid of GIL, but this work is
> |still in development AFAIK. I'm sure it will take years to stabilize the
> |whole Python zoo without GIL.
>
> The GIL only prevents multiple Python statements from being
> interpreted simultaneously, but if you're waiting on inputs (like
> sockets), it's not active, so that could be distributed across
> multiple cores.
>
> With asyncio, however, you can easily handle the application
> for threads to "wait in parallel" for thousands of sockets in a
> single thread, and there are fewer opportunities for errors than
> with multithreading.
>
> Additionally, there are libraries like numpy that use true
> multithreading internally to distribute computational tasks
> across multiple cores. By using such libraries, you can take
> advantage of that. (Not to mention the AI libraries that have their
> work done in highly parallel fashion by graphics cards.)
>
> If you want real threads, you could probably work with Cython
> sometimes.
>
> Other languages like JavaScript seem to have an advantage there
> because they don't know a GIL, but with JavaScript, for example,
> it's because it always runs in a single thread overall. And in
> the languages where there are threads without a GIL, you quickly
> realize that programming correct non-trivial programs with
> parallel processing is error-prone.
>
> Often in Python you can use "ThreadPoolExecutor" to start
> multiple threads. If the GIL then becomes a problem (which is
> not the case if you're waiting on I/O), you can easily swap it
> out for "ProcessPoolExecutor": Then processes are used instead
> of threads, and there is no GIL for those.
>
> If four cores are available, by dividing up compute-intensive tasks
> using "ProcessPoolExecutor", you can expect a speedup factor of two
> to eight.
>
> With the Celery library, tasks can be distributed across multiple
> processes that can also run on different computers. See, for
> example, "Parallel Programming with Python" by Jan Palach.
>

It sort of seems there are two approaches to
the parallel, and the asynchronous.

There's, "divide-and-conquer", and "information-cooperation".

The linear-speedup of the embarrassingly parallel
in the divide-and-conquer, or single-instruction-multiple-data,
is a pretty great thing.

Notions like map-reduce when the count of values
per key is about same and thusly the computing
the aggregates (summaries, digests, aggregate
and analytic functions) can be accomplished by
horizontal scaling (more boxes with same resources),
is another usual divide-and-conquer approach
(horizontal scaling).

Once upon a time there was this great idea called
"Aglets" or "mobile agents" or "mobile code". This
is basically that a functional program is distributed
to nodes, to run on the facilities of the nodes with
some resources, then to return to the "aglet-hive"
what results can be composed. This is also usually
called anything the "agent" or "instrumentation"
on the box. (The box, a process model, its processes,
their threads, their "inter-thread calls", their "inter-process
calls", their network, a node, a box. Aglets are the
little caps or tape at the end of shoe-laces, here
with regards to notions like "aggregate functions"
and "analytic functions".)

The cooperation is basically any notion of a callback.
The callback is one of the fundamental notions of
flow-of-control, and about the most elementary
notion of the functional paradigm in otherwise
the procedural or the imperative paradigm.

Otherwise for threads to fork, to divide, then
whether they join, is a callback.

So, first learning the idea of a callback is like,
"you mean I need to provide a different entry
point for this code to return and then where
I'm at is exiting forever as if in a shell process
model exec'ing another process and resulting
that this process becomes that one", and it's
like "yeah, you just give it a callback address
and what results is that's where it goes".
It's functional.

(Functional/event-driven, procedural/imperative.)

Some people learn functional first, and others
procedural first. It's hard to say how people
think, in their mental models of the things,
which is pretty much always flow-machines.
The chip, or the old planar integrated-circuit
the usually standard logic the chip, is systolic,
the systolic flow driven by the systolic clock,
that most people have a flow-model of code.

So, there's callbacks, and then there's funnels
and distributors, say, then as with regards to
something like a "Clos network", any kind of
usual model of data-flow, it's a flow-machine.

Funnels/sprinklers: Venturi effect.

In flow machines, there's basically something
like "Ford-Fulkerson flow algorithm", which is
a hypothetical sort of algorithm that formalizes
and optimizes flow.

Threads fork, and they also join.

The only hardware threads are independent cores,
and, their semantics of memory barriers,
according to their clocks. The rest is organization
of context and routine and state and stack,
and for the general purpose usually pre-emptive,
or, "time-sharing".

Or, you know, "nodes".

It's a time-sharing system.

So, there's processes and a process model,
there's the inter-process, then there's threading
models, and the re-entrant and shared and
the mutex, according to ordering and serial
guarantees or "delivery", it's message-passing
of course, vis-a-vis "the core" or memory,
a monad or a purely functional state,
it's a distributed system of nodes.

Once there was an initiative called "Parallel C",
language and compiler extensions to support
language constructs embodying the notions of
the parallel.

Somebody came up with pi calculus, process
calculus, communicating sequential processes
and the like. I've heard of Djikstra's law yet I
forget it, and any entry point is a "goto".

In clusters, there's a usual notion of message-passing,
often organized about the process model among nodes
of the cluster. There's MPI and old Silicon Grid Engine.
Once there was Wolfpack cluster. The clusters are
often mounted in a rack together and about things
like Infiniband networking and NUMA memory.

"HPC" they call it, though that includes both
clusters the horizontally scale-able, and also
computers of the super-scalar word variety.

The process model, is the usual way of the old
control-plane way to organize processes with
shared resources and separate quotas, and
to support independent process spaces,
making for fork as spawn and otherwise
though pipes and message-slots what make
for join. Then there are thread, OS threads,
and in some cases fibers, OS threads, as
about processes, OS threads.

Some usual virtual machines or runtimes like
ye olde Java, have threads and synchronization
for barriers and monitors and mutexes and what,
about system calls and barriers and monitors and
mutexes, in the process model.

The interpreted runtimes are usually "single-threaded",
about though the notions of event loops and responsiveness.
That follows from "a Win32 app the message pump", then
mostly these days since "a JavaScript binding for the script
element binding of an HTML with HTTP user-agent, for
UI-Events according to old W3C now whatwg, and maybe
it's ECMAScript and with modules or something, and then
also there's new-fangled web workers which are threads for
ECMAScript or JavaScript which are about the same".

Writing algorithms in event loops is a sort of
exercise in frustration, in a sense. Yet, when
recursion is figured out as having to build a state
instead of just filling the stack, it's a thing.
(A single-threaded thing.)

These days most distributed algorithms are sort
of advised for "horizontal scaling" and "eventual
consistency" with often "opportunistic locks" in
a world of "Murphy guarantees the un-ordered".

Then transactions of the more critical sort are
often "boxes with huge RAM rollback segments"
or as with regards to "matching and reconciliation",
after the fact.

Then of course obligatory about C++, or, C/C++,
it's about OS threads and, "guarantees".

Here my approach is "re-routines". "Re-routines:
it's a co-routine, though instead of suspending
it just quits, and instead of switching it just
builds its own monad for the recusion, and
instead of having callbacks, it's always callbacks,
and instead of having futures everywhere,
it's futures everywhere. Try, try again."

On 04/29/2024 09:44 AM, Ross Finlayson wrote:
> On 04/29/2024 08:19 AM, Stefan Ram wrote:
>> paavo512 <paavo@osa.pri.ee> wrote or quoted:
>> |Anyway, multithreading performance is a non-issue for Python so far as
>> |the Python interpreter runs in a single-threaded regime anyway, under a
>> |global GIL lock. They are planning to get rid of GIL, but this work is
>> |still in development AFAIK. I'm sure it will take years to stabilize the
>> |whole Python zoo without GIL.
>>
>> The GIL only prevents multiple Python statements from being
>> interpreted simultaneously, but if you're waiting on inputs (like
>> sockets), it's not active, so that could be distributed across
>> multiple cores.
>>
>> With asyncio, however, you can easily handle the application
>> for threads to "wait in parallel" for thousands of sockets in a
>> single thread, and there are fewer opportunities for errors than
>> with multithreading.
>>
>> Additionally, there are libraries like numpy that use true
>> multithreading internally to distribute computational tasks
>> across multiple cores. By using such libraries, you can take
>> advantage of that. (Not to mention the AI libraries that have their
>> work done in highly parallel fashion by graphics cards.)
>>
>> If you want real threads, you could probably work with Cython
>> sometimes.
>>
>> Other languages like JavaScript seem to have an advantage there
>> because they don't know a GIL, but with JavaScript, for example,
>> it's because it always runs in a single thread overall. And in
>> the languages where there are threads without a GIL, you quickly
>> realize that programming correct non-trivial programs with
>> parallel processing is error-prone.
>>
>> Often in Python you can use "ThreadPoolExecutor" to start
>> multiple threads. If the GIL then becomes a problem (which is
>> not the case if you're waiting on I/O), you can easily swap it
>> out for "ProcessPoolExecutor": Then processes are used instead
>> of threads, and there is no GIL for those.
>>
>> If four cores are available, by dividing up compute-intensive tasks
>> using "ProcessPoolExecutor", you can expect a speedup factor of two
>> to eight.
>>
>> With the Celery library, tasks can be distributed across multiple
>> processes that can also run on different computers. See, for
>> example, "Parallel Programming with Python" by Jan Palach.
>>
>
>
>
> It sort of seems there are two approaches to
> the parallel, and the asynchronous.
>
> There's, "divide-and-conquer", and "information-cooperation".
>
> The linear-speedup of the embarrassingly parallel
> in the divide-and-conquer, or single-instruction-multiple-data,
> is a pretty great thing.
>
> Notions like map-reduce when the count of values
> per key is about same and thusly the computing
> the aggregates (summaries, digests, aggregate
> and analytic functions) can be accomplished by
> horizontal scaling (more boxes with same resources),
> is another usual divide-and-conquer approach
> (horizontal scaling).
>
> Once upon a time there was this great idea called
> "Aglets" or "mobile agents" or "mobile code". This
> is basically that a functional program is distributed
> to nodes, to run on the facilities of the nodes with
> some resources, then to return to the "aglet-hive"
> what results can be composed. This is also usually
> called anything the "agent" or "instrumentation"
> on the box. (The box, a process model, its processes,
> their threads, their "inter-thread calls", their "inter-process
> calls", their network, a node, a box. Aglets are the
> little caps or tape at the end of shoe-laces, here
> with regards to notions like "aggregate functions"
> and "analytic functions".)
>
>
> The cooperation is basically any notion of a callback.
> The callback is one of the fundamental notions of
> flow-of-control, and about the most elementary
> notion of the functional paradigm in otherwise
> the procedural or the imperative paradigm.
>
> Otherwise for threads to fork, to divide, then
> whether they join, is a callback.
>
> So, first learning the idea of a callback is like,
> "you mean I need to provide a different entry
> point for this code to return and then where
> I'm at is exiting forever as if in a shell process
> model exec'ing another process and resulting
> that this process becomes that one", and it's
> like "yeah, you just give it a callback address
> and what results is that's where it goes".
> It's functional.
>
> (Functional/event-driven, procedural/imperative.)
>
>
> Some people learn functional first, and others
> procedural first. It's hard to say how people
> think, in their mental models of the things,
> which is pretty much always flow-machines.
> The chip, or the old planar integrated-circuit
> the usually standard logic the chip, is systolic,
> the systolic flow driven by the systolic clock,
> that most people have a flow-model of code.
>
>
> So, there's callbacks, and then there's funnels
> and distributors, say, then as with regards to
> something like a "Clos network", any kind of
> usual model of data-flow, it's a flow-machine.
>
> Funnels/sprinklers: Venturi effect.
>
> In flow machines, there's basically something
> like "Ford-Fulkerson flow algorithm", which is
> a hypothetical sort of algorithm that formalizes
> and optimizes flow.
>
>
> Threads fork, and they also join.
>
> The only hardware threads are independent cores,
> and, their semantics of memory barriers,
> according to their clocks. The rest is organization
> of context and routine and state and stack,
> and for the general purpose usually pre-emptive,
> or, "time-sharing".
>
> Or, you know, "nodes".
>
>
> It's a time-sharing system.
>
>
> So, there's processes and a process model,
> there's the inter-process, then there's threading
> models, and the re-entrant and shared and
> the mutex, according to ordering and serial
> guarantees or "delivery", it's message-passing
> of course, vis-a-vis "the core" or memory,
> a monad or a purely functional state,
> it's a distributed system of nodes.
>
>
> Once there was an initiative called "Parallel C",
> language and compiler extensions to support
> language constructs embodying the notions of
> the parallel.
>
> Somebody came up with pi calculus, process
> calculus, communicating sequential processes
> and the like. I've heard of Djikstra's law yet I
> forget it, and any entry point is a "goto".
>
> In clusters, there's a usual notion of message-passing,
> often organized about the process model among nodes
> of the cluster. There's MPI and old Silicon Grid Engine.
> Once there was Wolfpack cluster. The clusters are
> often mounted in a rack together and about things
> like Infiniband networking and NUMA memory.
>
> "HPC" they call it, though that includes both
> clusters the horizontally scale-able, and also
> computers of the super-scalar word variety.
>
> The process model, is the usual way of the old
> control-plane way to organize processes with
> shared resources and separate quotas, and
> to support independent process spaces,
> making for fork as spawn and otherwise
> though pipes and message-slots what make
> for join. Then there are thread, OS threads,
> and in some cases fibers, OS threads, as
> about processes, OS threads.
>
> Some usual virtual machines or runtimes like
> ye olde Java, have threads and synchronization
> for barriers and monitors and mutexes and what,
> about system calls and barriers and monitors and
> mutexes, in the process model.
>
> The interpreted runtimes are usually "single-threaded",
> about though the notions of event loops and responsiveness.
> That follows from "a Win32 app the message pump", then
> mostly these days since "a JavaScript binding for the script
> element binding of an HTML with HTTP user-agent, for
> UI-Events according to old W3C now whatwg, and maybe
> it's ECMAScript and with modules or something, and then
> also there's new-fangled web workers which are threads for
> ECMAScript or JavaScript which are about the same".
>
> Writing algorithms in event loops is a sort of
> exercise in frustration, in a sense. Yet, when
> recursion is figured out as having to build a state
> instead of just filling the stack, it's a thing.
> (A single-threaded thing.)
>
> These days most distributed algorithms are sort
> of advised for "horizontal scaling" and "eventual
> consistency" with often "opportunistic locks" in
> a world of "Murphy guarantees the un-ordered".
>
> Then transactions of the more critical sort are
> often "boxes with huge RAM rollback segments"
> or as with regards to "matching and reconciliation",
> after the fact.
>
>
> Then of course obligatory about C++, or, C/C++,
> it's about OS threads and, "guarantees".
>
>
> Here my approach is "re-routines". "Re-routines:
> it's a co-routine, though instead of suspending
> it just quits, and instead of switching it just
> builds its own monad for the recusion, and
> instead of having callbacks, it's always callbacks,
> and instead of having futures everywhere,
> it's futures everywhere. Try, try again."
>
> In the process model in the runtime though,
> it's mostly about what services the bus DMA.
> "Systems", programming.
>
> Boxes is nodes, ....
>
>

On 4/29/2024 8:19 AM, Stefan Ram wrote:
> paavo512 <paavo@osa.pri.ee> wrote or quoted:
> |Anyway, multithreading performance is a non-issue for Python so far as
> |the Python interpreter runs in a single-threaded regime anyway, under a
> |global GIL lock. They are planning to get rid of GIL, but this work is
> |still in development AFAIK. I'm sure it will take years to stabilize the
> |whole Python zoo without GIL.
>
> The GIL only prevents multiple Python statements from being
> interpreted simultaneously, but if you're waiting on inputs (like
> sockets), it's not active, so that could be distributed across
> multiple cores.
>
> With asyncio, however, you can easily handle the application
> for threads to "wait in parallel" for thousands of sockets in a
> single thread, and there are fewer opportunities for errors than
> with multithreading.
>
> Additionally, there are libraries like numpy that use true
> multithreading internally to distribute computational tasks
> across multiple cores. By using such libraries, you can take
> advantage of that. (Not to mention the AI libraries that have their
> work done in highly parallel fashion by graphics cards.)
>
> If you want real threads, you could probably work with Cython
> sometimes.
>
> Other languages like JavaScript seem to have an advantage there
> because they don't know a GIL, but with JavaScript, for example,
> it's because it always runs in a single thread overall. And in
> the languages where there are threads without a GIL, you quickly
> realize that programming correct non-trivial programs with
> parallel processing is error-prone.
[...]

Have you ever used webworkers?

On Mon, 29 Apr 2024 19:13:09 +0300, Paavo Helde wrote:

> Just for waiting on thousands on sockets I believe a single select()
> call would be sufficient ...

We use poll(2) or epoll(2) nowadays. select(2) is antiquated.

On Mon, 29 Apr 2024 18:18:57 +0200, Bonita Montero wrote:

> But you need multithreading to have maximum throughput since you often
> process the data while other data is available.

In a lot of applications, the bottleneck is the network I/O, or a GUI
waiting for the next user event, that kind of thing. In this situation,
multithreading is more trouble than it’s worth. This is why coroutines (in
the form of async/await) have made a comeback over the last decade or so.

On 4/29/2024 1:29 PM, Lawrence D'Oliveiro wrote:
> On Mon, 29 Apr 2024 19:13:09 +0300, Paavo Helde wrote:
>
>> Just for waiting on thousands on sockets I believe a single select()
>> call would be sufficient ...
>
> We use poll(2) or epoll(2) nowadays. select(2) is antiquated.

AIO on Linux, IOCP on windows.

On 29 Apr 2024 15:19:19 GMT, Stefan Ram wrote:

> With asyncio, however, you can easily handle the application for
> threads to "wait in parallel" for thousands of sockets in a single
> thread, and there are fewer opportunities for errors than with
> multithreading.

It makes event-loop programming much more convenient. I posted a
simple example here from some years ago
<https://github.com/HamPUG/meetings/tree/master/2017/2017-05-08/ldo-generators-coroutines-asyncio>:
compare the version based on callbacks, with the one using asyncio:
the former is about 30% bigger.

On Mon, 29 Apr 2024 13:33:22 -0700, Chris M. Thomasson wrote:

> On 4/29/2024 1:29 PM, Lawrence D'Oliveiro wrote:
>
>> On Mon, 29 Apr 2024 19:13:09 +0300, Paavo Helde wrote:
>>
>>> Just for waiting on thousands on sockets I believe a single select()
>>> call would be sufficient ...
>>
>> We use poll(2) or epoll(2) nowadays. select(2) is antiquated.
>
> AIO on Linux, IOCP on windows.

AIO is for block I/O. Try io_uring instead.

On 4/29/2024 3:41 PM, Lawrence D'Oliveiro wrote:
> On Mon, 29 Apr 2024 13:33:22 -0700, Chris M. Thomasson wrote:
>
>> On 4/29/2024 1:29 PM, Lawrence D'Oliveiro wrote:
>>
>>> On Mon, 29 Apr 2024 19:13:09 +0300, Paavo Helde wrote:
>>>
>>>> Just for waiting on thousands on sockets I believe a single select()
>>>> call would be sufficient ...
>>>
>>> We use poll(2) or epoll(2) nowadays. select(2) is antiquated.
>>
>> AIO on Linux, IOCP on windows.
>
> AIO is for block I/O. Try io_uring instead.

Afaict, AIO is analogous to IOCP.

On Mon, 29 Apr 2024 16:46:17 -0700, Chris M. Thomasson wrote:

> On 4/29/2024 3:41 PM, Lawrence D'Oliveiro wrote:
>>
>> On Mon, 29 Apr 2024 13:33:22 -0700, Chris M. Thomasson wrote:
>>
>>> On 4/29/2024 1:29 PM, Lawrence D'Oliveiro wrote:
>>>
>>>> On Mon, 29 Apr 2024 19:13:09 +0300, Paavo Helde wrote:
>>>>
>>>>> Just for waiting on thousands on sockets I believe a single select()
>>>>> call would be sufficient ...
>>>>
>>>> We use poll(2) or epoll(2) nowadays. select(2) is antiquated.
>>>
>>> AIO on Linux, IOCP on windows.
>>
>> AIO is for block I/O. Try io_uring instead.
>
> Afaict, AIO is analogous to IOCP.

So not really analogous to io_uring, then?

Am 29.04.2024 um 22:31 schrieb Lawrence D'Oliveiro:
> On Mon, 29 Apr 2024 18:18:57 +0200, Bonita Montero wrote:
>
>> But you need multithreading to have maximum throughput since you often
>> process the data while other data is available.
>
> In a lot of applications, the bottleneck is the network I/O, or a GUI
> waiting for the next user event, that kind of thing. In this situation,
> multithreading is more trouble than it’s worth. This is why coroutines (in
> the form of async/await) have made a comeback over the last decade or so.

Having a single thread and using state machines is more effortz.

On Tue, 30 Apr 2024 05:58:31 +0200, Bonita Montero wrote:

> Am 29.04.2024 um 22:31 schrieb Lawrence D'Oliveiro:
>
>> On Mon, 29 Apr 2024 18:18:57 +0200, Bonita Montero wrote:
>>
>>> But you need multithreading to have maximum throughput since you often
>>> process the data while other data is available.
>>
>> In a lot of applications, the bottleneck is the network I/O, or a GUI
>> waiting for the next user event, that kind of thing. In this situation,
>> multithreading is more trouble than it’s worth. This is why coroutines
>> (in the form of async/await) have made a comeback over the last decade
>> or so.
>
> Having a single thread and using state machines is more effortz.

It would indeed. That’s why coroutines (async/await) are so handy.

Am 30.04.2024 um 06:09 schrieb Lawrence D'Oliveiro:
> On Tue, 30 Apr 2024 05:58:31 +0200, Bonita Montero wrote:
>
>> Am 29.04.2024 um 22:31 schrieb Lawrence D'Oliveiro:
>>
>>> On Mon, 29 Apr 2024 18:18:57 +0200, Bonita Montero wrote:
>>>
>>>> But you need multithreading to have maximum throughput since you often
>>>> process the data while other data is available.
>>>
>>> In a lot of applications, the bottleneck is the network I/O, or a GUI
>>> waiting for the next user event, that kind of thing. In this situation,
>>> multithreading is more trouble than it’s worth. This is why coroutines
>>> (in the form of async/await) have made a comeback over the last decade
>>> or so.
>>
>> Having a single thread and using state machines is more effortz.
>
> It would indeed. That’s why coroutines (async/await) are so handy.

Using a thread is even more handy.

On Tue, 30 Apr 2024 07:59:06 +0200, Bonita Montero wrote:

> Am 30.04.2024 um 06:09 schrieb Lawrence D'Oliveiro:
>>
>> On Tue, 30 Apr 2024 05:58:31 +0200, Bonita Montero wrote:
>>
>>> Having a single thread and using state machines is more effortz.
>>
>> It would indeed. That’s why coroutines (async/await) are so handy.
>
> Using a thread is even more handy.

Do you know what a “heisenbug” is?

Am 30.04.2024 um 08:42 schrieb Lawrence D'Oliveiro:
> On Tue, 30 Apr 2024 07:59:06 +0200, Bonita Montero wrote:
>
>> Am 30.04.2024 um 06:09 schrieb Lawrence D'Oliveiro:
>>>
>>> On Tue, 30 Apr 2024 05:58:31 +0200, Bonita Montero wrote:
>>>
>>>> Having a single thread and using state machines is more effortz.
>>>
>>> It would indeed. That’s why coroutines (async/await) are so handy.
>>
>> Using a thread is even more handy.
>
> Do you know what a “heisenbug” is?

This has nothing to do with a heisenbug. Threads are slightly less
performance than managing state with a coroutine, but they're more
convenient to develop. In Python the difference wouldn't count.

ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:
>The GIL only prevents multiple Python statements from being
>interpreted simultaneously, but if you're waiting on inputs (like
>sockets), it's not active, so that could be distributed across
>multiple cores.

Disclaimer: This is not on-topic here as it discusses Python,
not C or C++.

FWIW, here's some multithreaded Python code modeled after what
I use in an application.

I am using Python to prepare a press review for me, getting article
headers from several newssites, removing all headers matching a list
of regexps, and integrating everything into a single HTML resource.
(I do not like to read about Lindsay Lohan, for example, so articles
with the text "Lindsay Lohan" will not show up on my HTML review.)

I'm usually downloading all pages at once using Python threads,
which will make sure that a thread uses the CPU while another
thread is waiting for TCP/IP data. This is the code, taken from
my Python program and a bit simplified:

from multiprocessing.dummy import Pool

....

with Pool( 9 if fast_internet else 1 )as pool:
for i in range( 9 ):
content[ i ] = pool.apply_async( fetch,[ uris[ i ] ])
pool.close()
pool.join()

. I'm using my "fetch" function to fetch a single URI, and the
loop starts nine threads within a thread pool to fetch the
content of those nine URIs "in parallel". This is observably
faster than corresponding sequential code.

(However, sometimes I have a slow connection and have to download
sequentially in order not to overload the slow connection, which
would result in stalled downloads. To accomplish this, I just
change the "9" to "1" in the first line above.)

In case you wonder about the "dummy":

|The multiprocessing.dummy module module provides a wrapper
|for the multiprocessing module, except implemented using
|thread-based concurrency.
| |It provides a drop-in replacement for multiprocessing,
|allowing a program that uses the multiprocessing API to
|switch to threads with a single change to import statements.

. So, this is an area where multithreading the Python way is easy
to use and enhances performance even in the presence of the GIL!

On Tue, 30 Apr 2024 09:37:18 +0200, Bonita Montero wrote:

> Am 30.04.2024 um 08:42 schrieb Lawrence D'Oliveiro:
>> On Tue, 30 Apr 2024 07:59:06 +0200, Bonita Montero wrote:
>>
>>> Am 30.04.2024 um 06:09 schrieb Lawrence D'Oliveiro:
>>>>
>>>> On Tue, 30 Apr 2024 05:58:31 +0200, Bonita Montero wrote:
>>>>
>>>>> Having a single thread and using state machines is more effortz.
>>>>
>>>> It would indeed. That’s why coroutines (async/await) are so handy.
>>>
>>> Using a thread is even more handy.
>>
>> Do you know what a “heisenbug” is?
>
> [No]

Do you know what a “race condition” is?

Am 30.04.2024 um 11:09 schrieb Lawrence D'Oliveiro:
> On Tue, 30 Apr 2024 09:37:18 +0200, Bonita Montero wrote:
>
>> Am 30.04.2024 um 08:42 schrieb Lawrence D'Oliveiro:
>>> On Tue, 30 Apr 2024 07:59:06 +0200, Bonita Montero wrote:
>>>
>>>> Am 30.04.2024 um 06:09 schrieb Lawrence D'Oliveiro:
>>>>>
>>>>> On Tue, 30 Apr 2024 05:58:31 +0200, Bonita Montero wrote:
>>>>>
>>>>>> Having a single thread and using state machines is more effortz.
>>>>>
>>>>> It would indeed. That’s why coroutines (async/await) are so handy.
>>>>
>>>> Using a thread is even more handy.
>>>
>>> Do you know what a “heisenbug” is?
>>
>> [No]
>
> Do you know what a “race condition” is?
>

Race conditions are mostly easy to handle. If you do I/O and the
send / receive options are atomic you'd even not need a mutex and
the race condition isn't a problem although it is not handled.

Paavo Helde <eesnimi@osa.pri.ee> writes:
>On 29.04.2024 18:19, Stefan Ram wrote:
>> paavo512 <paavo@osa.pri.ee> wrote or quoted:
>> |Anyway, multithreading performance is a non-issue for Python so far as
>> |the Python interpreter runs in a single-threaded regime anyway, under a
>> |global GIL lock. They are planning to get rid of GIL, but this work is
>> |still in development AFAIK. I'm sure it will take years to stabilize the
>> |whole Python zoo without GIL.
>>
>> The GIL only prevents multiple Python statements from being
>> interpreted simultaneously, but if you're waiting on inputs (like
>> sockets), it's not active, so that could be distributed across
>> multiple cores.
>>
>> With asyncio, however, you can easily handle the application
>> for threads to "wait in parallel" for thousands of sockets in a
>> single thread, and there are fewer opportunities for errors than
>> with multithreading.
>
>In C++, async io is provided e.g. by the asio library.

And the POSIX aio interfaces, on systems that support them.

I used lio_listio heavily in Oracle's RDMS.

On 4/30/2024 12:37 AM, Bonita Montero wrote:
> Am 30.04.2024 um 08:42 schrieb Lawrence D'Oliveiro:
>> On Tue, 30 Apr 2024 07:59:06 +0200, Bonita Montero wrote:
>>
>>> Am 30.04.2024 um 06:09 schrieb Lawrence D'Oliveiro:
>>>>
>>>> On Tue, 30 Apr 2024 05:58:31 +0200, Bonita Montero wrote:
>>>>
>>>>> Having a single thread and using state machines is more effortz.
>>>>
>>>> It would indeed. That’s why coroutines (async/await) are so handy.
>>>
>>> Using a thread is even more handy.
>>
>> Do you know what a “heisenbug” is?
>
> This has nothing to do with a heisenbug. Threads are slightly less
> performance than managing state with a coroutine,

Huh? Threads allow one to take advantage of the processing power of a
multi-core/socket system. We can multiplex coroutines on a single
thread, okay fine, ugg... This is not going to use the full spectrum of
a system wrt multiple processing units. We can decide to use at least as
many threads as there are cores. This can get the full power of said
system. Sometimes using number_of_cores * 2 threads might be in order.

> but they're more
> convenient to develop. In Python the difference wouldn't count.

On 4/30/2024 2:25 AM, Bonita Montero wrote:
> Am 30.04.2024 um 11:09 schrieb Lawrence D'Oliveiro:
>> On Tue, 30 Apr 2024 09:37:18 +0200, Bonita Montero wrote:
>>
>>> Am 30.04.2024 um 08:42 schrieb Lawrence D'Oliveiro:
>>>> On Tue, 30 Apr 2024 07:59:06 +0200, Bonita Montero wrote:
>>>>
>>>>> Am 30.04.2024 um 06:09 schrieb Lawrence D'Oliveiro:
>>>>>>
>>>>>> On Tue, 30 Apr 2024 05:58:31 +0200, Bonita Montero wrote:
>>>>>>
>>>>>>> Having a single thread and using state machines is more effortz.
>>>>>>
>>>>>> It would indeed. That’s why coroutines (async/await) are so handy.
>>>>>
>>>>> Using a thread is even more handy.
>>>>
>>>> Do you know what a “heisenbug” is?
>>>
>>> [No]
>>
>> Do you know what a “race condition” is?
>>
>
> Race conditions are mostly easy to handle.

Have you fixed your massive bug in your DCL futex thing?

> If you do I/O and the
> send / receive options are atomic you'd even not need a mutex and
> the race condition isn't a problem although it is not handled.
>

On Tue, 30 Apr 2024 11:25:13 +0200, Bonita Montero wrote:

> Am 30.04.2024 um 11:09 schrieb Lawrence D'Oliveiro:
>> On Tue, 30 Apr 2024 09:37:18 +0200, Bonita Montero wrote:
>>
>>> Am 30.04.2024 um 08:42 schrieb Lawrence D'Oliveiro:
>>>> On Tue, 30 Apr 2024 07:59:06 +0200, Bonita Montero wrote:
>>>>
>>>>> Am 30.04.2024 um 06:09 schrieb Lawrence D'Oliveiro:
>>>>>>
>>>>>> On Tue, 30 Apr 2024 05:58:31 +0200, Bonita Montero wrote:
>>>>>>
>>>>>>> Having a single thread and using state machines is more effortz.
>>>>>>
>>>>>> It would indeed. That’s why coroutines (async/await) are so handy.
>>>>>
>>>>> Using a thread is even more handy.
>>>>
>>>> Do you know what a “heisenbug” is?
>>>
>>> [No]
>>
>> Do you know what a “race condition” is?
>>
> [No]

You haven’t actually done much thread programming, have you?