Exploiting Dual Core's with Py_NewInterpreter's separated GIL ?

Paul Rubin http
Sun Nov 5 03:30:18 EST 2006


"Martin v. Löwis" <martin at v.loewis.de> writes:
> > I think that has to be on a single processor, or at most a dual core
> > processor with shared cache on die.  With multiple cpu chips I don't
> > think can get the signals around that fast.
> 
> Can you explain what you mean? The lock# signal takes *immediate*
> effect, within the CPU cycle in which it is asserted. There is no
> delay whatsoever (except for speed-of-light issues, of course).

I dunno about x86 hardware signals but these instructions do
read-modify-write operaitons.  That means there has to be enough
interlocking to prevent two cpu's from updating the same memory
location simultaneously, which means the CPU's have to communicate.
See <http://en.wikipedia.org/wiki/MESI_protocol> (I think this is
how the current x86's do it):

    A cache that holds a line in the Modified state must snoop
    (intercept) all attempted reads (from all of the other CPUs in the
    system) of the corresponding main memory location and insert the
    data that it holds. This is typically done by forcing the read to
    back off (i.e. to abort the memory bus transaction), then writing
    the data to main memory and changing the cache line to the Shared
    state.
    
    A cache that holds a line in the Shared state must also snoop all
    invalidate broadcasts from other CPUs, and discard the line (by
    moving it into Invalid state) on a match.

It is quite difficult to get signals off of a chip at GHz speeds, and
so this signalling is much slower than the CPU cycle.



More information about the Python-list mailing list