dual processor

[Scott David Daniels]

Nick Craig-Wood wrote:
> Splitting the GIL introduces performance and memory penalties....
> However its crystal clear now the future is SMP.  Modern chips seem to
> have hit the GHz barrier, and now the easy meat for the processor
> designers is to multiply silicon and make multiple thread / core
> processors all in a single chip.
> So, I believe Python has got to address the GIL, and soon.
However, there is no reason to assume that those multiple cores must
work in the same process.  One of the biggest issues in running python
in multiple simultaneously active threads is that the Python opcodes
themselves are no longer indivisible.  Making a higher level language
that allows updates work with multiple threads involves lots of
coordination between threads simply to know when data structures are
correct and when they are in transition.

Even processes sharing some memory (in a "raw binary memory" style) are
easier to write and test.  You'd lose too much processor to coordination
effort which was likely unnecessary.  The simplest example I can think
of is decrementing a reference count.  Only one thread can be allowed to
DECREF at any given time for fear of leaking memory, even though it will
most often turn out the objects being DECREF'ed by distinct threads are
themselves distinct.

In short, two Python threads running simultaneously cannot trust that
any basic Python data structures they access are in a consistent state
without some form of coordination.

--Scott David Daniels
Scott.Daniels at Acm.Org