Home Original page

[Python-ideas] solving multi-core Python

Gregory P. Smith greg at krypto.org
Tue Jun 23 21:26:23 CEST 2015 
On Tue, Jun 23, 2015 at 9:01 AM Barry Warsaw <barry at python.org> wrote:

> On Jun 23, 2015, at 01:52 PM, Nick Coghlan wrote:
>
> >The current reference-counts-embedded-in-the-object-structs memory
> >layout also plays havoc with the all-or-nothing page level
> >copy-on-write semantics used by the fork() syscall at the operating
> >system layer, so some of the ideas we've been considering
> >(specifically, those related to moving the reference counter
> >bookkeeping out of the object structs themselves) would potentially
> >help with that as well (but would also have other hard to predict
> >performance consequences).
>
> A crazy offshoot idea would be something like Emacs' unexec, where during
> the
> build process you could preload a bunch of always-used immutable modules,
> then
> freeze the state in such a way that starting up again later would be much
> faster, because the imports (and probably more importantly, the searching)
> could be avoided.
>

I actually would like something like this for Python, but I want it to work
with hash randomization rather than freezing a single fixed hash seed. That
means you'd need to record the location of all hash tables and cached
hashes and fix them up after loading such a binary image at process start
time, much like processing relocations when loading a binary executable.
Non trivial.

-gps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20150623/1d6b3021/attachment-0001.html>
More information about the Python-ideas mailing list