@MSGID:
<e5616850-37a8-46fd-b2a8-e3ca252b8a5an@googlegroups.com> 9806969e
@REPLY:
<db903ba2-8ccd-418e-bd18-a9eb381cd222n@googlegroups.com> af6ff43a
@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>
@RFC-Message-ID:
<e5616850-37a8-46fd-b2a8-e3ca252b8a5an@googlegroups.com>
@TZUTC: -0700
@PID: G2/1.0
@TID: FIDOGATE-5.12-ge4e8b94
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