@MSGID:
<5cc272c3-80cf-4a20-9ae2-ac80aa91c65dn@googlegroups.com> d54c2908
@REPLY: 1@solani.org> 7ee760e1
@REPLYADDR Mild Shock <bursejan@gmail.com>
@REPLYTO 2:5075/128 Mild Shock
@CHRS: CP866 2
@RFC: 1 0
@RFC-References:
<db903ba2-8ccd-418e-bd18-a9eb381cd222n@googlegroups.com> <e5616850-37a8-46fd-b2a8-e3ca252b8a5an@googlegroups.com>
<8f3f24d1-7258-4572-9b81-596f2139546bn@googlegroups.com> 1@solani.org>
@RFC-Message-ID:
<5cc272c3-80cf-4a20-9ae2-ac80aa91c65dn@googlegroups.com>
@TZUTC: -0700
@PID: G2/1.0
@TID: FIDOGATE-5.12-ge4e8b94
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.
--- G2/1.0
 * Origin: usenet.network (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441