what's the point of rpython?

[MRAB]

Brendan Miller wrote:
> On Wed, Jan 21, 2009 at 8:19 AM, Scott David Daniels
> <Scott.Daniels at acm.org> wrote:
>> Brendan Miller wrote:
>>> On Tue, Jan 20, 2009 at 10:03 PM, Paul Rubin
>>> <"http://phr.cx"@nospam.invalid> wrote:
>>>> ....  Of course I'm aware of the LOCK prefix but it slows
>>>> down the instruction enormously compared with a non-locked instruction.
>>> I'm curious about that. I've been looking around for timing
>>> information on the lock signal, but am having some trouble finding
>>> them. Intuitively, given that the processor is much faster than the
>>> bus, and you are just waiting for processor to complete an addition or
>>> comparison before put the new memory value on the bus, it seems like
>>> there should be very little additional bus contention vs a normal add
>>> instruction.
>> The opcode cannot simply talk to its cache, it must either go directly
>> to off-chip memory or communicate to other processors that it (and it
>> alone) owns the increment target.
> 
> Oh, right. *light bulb goes on* I wasn't thinking about cache at all.
> 
I'm not sure whether multicore processors share a cache or, if not, have 
some other on-chip mechanism. Multiprocessor machines, however, are a 
different matter...