[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
> build process you could preload a bunch of always-used immutable modules,
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas