Can SWI-Prolog lean back concerning multi-threading? The
Python store looks like a nice piece of darwinism. So there is some
evolutionary pressure through some selection mechanism:

> Allen Goodman, author of CellProfiler and staff engineer at
Prescient Design and Genentech, describes how the GIL makes
biological methods research more difficult in Python.

So basically Python starts lacking behind as the datascience language.
Oh the irony. But I would not blame it so much on the GIL. Deep down many
programming languages have still a GIL,

for example in malloc(). I don’t know whether SWI-Prologs tcmalloc() integration
even squeezes the lemon. From >JDK 9 Java had a slower GC single-threaded
because they started optimizing their virtual machine for multi-threaded.

Such optiminzations do not only consists of removing the GIL, you
need optimize malloc(). Some approaches uses thread affine memory
areas, but this is also tricky, since not all objects have a clear thread affinity.

In as far, concerning thread affinity, one has to also watch what happens
concerning JavaScript Worker concept adoptions in Python. Multi-threading
can be optimized even more If you have such isolation concepts.

In this respect there is also PEP 683 – Immortal Objects, which on the
surface might not be related, but it also relates to the effort to better handle
strings and make a GIL per-interpreter, the later could underly Workers.

Mild Shock schrieb am Samstag, 29. Juli 2023 um 13:57:15 UTC+2:
> Can SWI-Prolog lean back concerning multi-threading? The
> Python store looks like a nice piece of darwinism. So there is some
> evolutionary pressure through some selection mechanism:
>
> > Allen Goodman, author of CellProfiler and staff engineer at
> Prescient Design and Genentech, describes how the GIL makes
> biological methods research more difficult in Python.
>
> So basically Python starts lacking behind as the datascience language.
> Oh the irony. But I would not blame it so much on the GIL. Deep down many
> programming languages have still a GIL,
>
> for example in malloc(). I don’t know whether SWI-Prologs tcmalloc() integration
> even squeezes the lemon. From >JDK 9 Java had a slower GC single-threaded
> because they started optimizing their virtual machine for multi-threaded.
>
> Such optiminzations do not only consists of removing the GIL, you
> need optimize malloc(). Some approaches uses thread affine memory
> areas, but this is also tricky, since not all objects have a clear thread affinity.

There are a couple of non-GIL Pythons already
around. For example Jython 2.7.3. But they are
currently busy with migrating from Python 2 to Python 3.

For example I cannot use it, it didn’t understand
the “async” keyword. Async/await was introduced in
Python version 3.5. There are more such no-GIL Pythons,

like IronPython (for CLR) and GraalVM Python (for JVM).
GraalVM Python is farther ahead, it supports Python 3.8,
but is slower than PyPy. But with IronPython, one would

also have less luck, its only Python 3.4 now.

Mild Shock schrieb:
> In as far, concerning thread affinity, one has to also watch what happens
> concerning JavaScript Worker concept adoptions in Python. Multi-threading
> can be optimized even more If you have such isolation concepts.
>
> In this respect there is also PEP 683 – Immortal Objects, which on the
> surface might not be related, but it also relates to the effort to better handle
> strings and make a GIL per-interpreter, the later could underly Workers.
>
> Mild Shock schrieb am Samstag, 29. Juli 2023 um 13:57:15 UTC+2:
>> Can SWI-Prolog lean back concerning multi-threading? The
>> Python store looks like a nice piece of darwinism. So there is some
>> evolutionary pressure through some selection mechanism:
>>
>>> Allen Goodman, author of CellProfiler and staff engineer at
>> Prescient Design and Genentech, describes how the GIL makes
>> biological methods research more difficult in Python.
>>
>> So basically Python starts lacking behind as the datascience language.
>> Oh the irony. But I would not blame it so much on the GIL. Deep down many
>> programming languages have still a GIL,
>>
>> for example in malloc(). I don’t know whether SWI-Prologs tcmalloc() integration
>> even squeezes the lemon. From >JDK 9 Java had a slower GC single-threaded
>> because they started optimizing their virtual machine for multi-threaded.
>>
>> Such optiminzations do not only consists of removing the GIL, you
>> need optimize malloc(). Some approaches uses thread affine memory
>> areas, but this is also tricky, since not all objects have a clear thread affinity.

Whats quite interesting, is that PyPy, one of the fastest Pythons,
isn’t based on ARC LLVM. i.e. Automatic Reference Counting (ARC).
One effect is that dead objects, might be detected a little later

than via reference counting, so it is recommended to explicitly
close resources such as files, and not rely on reference counting.
Having no reference counting, does also help multi-threading.

So in PyPy there is no PL_register_atom or PL_unregister_atom.
Memory systems without reference counting are usually associated
with tracing garbage collectors, based on two color mark sweep.

But I guess they get more bang out of it, if incremental garbage
collection is deployed and if some escape analysis of the code
is performed as well. Have to find a paper.

Mild Shock schrieb am Samstag, 29. Juli 2023 um 23:16:41 UTC+2:
> There are a couple of non-GIL Pythons already
> around. For example Jython 2.7.3. But they are
> currently busy with migrating from Python 2 to Python 3.
>
> For example I cannot use it, it didn’t understand
> the “async” keyword. Async/await was introduced in
> Python version 3.5. There are more such no-GIL Pythons,
>
> like IronPython (for CLR) and GraalVM Python (for JVM).
> GraalVM Python is farther ahead, it supports Python 3.8,
> but is slower than PyPy. But with IronPython, one would
>
> also have less luck, its only Python 3.4 now.
>
> Mild Shock schrieb:
> > In as far, concerning thread affinity, one has to also watch what happens
> > concerning JavaScript Worker concept adoptions in Python. Multi-threading
> > can be optimized even more If you have such isolation concepts.
> >
> > In this respect there is also PEP 683 – Immortal Objects, which on the
> > surface might not be related, but it also relates to the effort to better handle
> > strings and make a GIL per-interpreter, the later could underly Workers..
> >
> > Mild Shock schrieb am Samstag, 29. Juli 2023 um 13:57:15 UTC+2:
> >> Can SWI-Prolog lean back concerning multi-threading? The
> >> Python store looks like a nice piece of darwinism. So there is some
> >> evolutionary pressure through some selection mechanism:
> >>
> >>> Allen Goodman, author of CellProfiler and staff engineer at
> >> Prescient Design and Genentech, describes how the GIL makes
> >> biological methods research more difficult in Python.
> >>
> >> So basically Python starts lacking behind as the datascience language.
> >> Oh the irony. But I would not blame it so much on the GIL. Deep down many
> >> programming languages have still a GIL,
> >>
> >> for example in malloc(). I don’t know whether SWI-Prologs tcmalloc() integration
> >> even squeezes the lemon. From >JDK 9 Java had a slower GC single-threaded
> >> because they started optimizing their virtual machine for multi-threaded.
> >>
> >> Such optiminzations do not only consists of removing the GIL, you
> >> need optimize malloc(). Some approaches uses thread affine memory
> >> areas, but this is also tricky, since not all objects have a clear thread affinity.

Why will this never fly?

https://www.swi-prolog.org/howto/http/

Because its too static. For example the
recent SVG example:

reply_html_page(title('SVG circle'),
Etc...

Looks a little pointless to me. Since its static,
You could store an `.svg` file on the server.
How do you draw 12 circles into SVG?

Computed into a grid of 3 x 4 via Prolog?
Make the number of columns and rows
a parameter to a Prolog predicate.