what's the point of rpython?

[MRAB]

Paul Rubin wrote:
> Ross Ridge <rridge at csclub.uwaterloo.ca> writes:
>> Scott David Daniels  <Scott.Daniels at Acm.Org> wrote:
>>> 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.
> 
>> The cache coherency mechanism automatically prevents two or more 
>> processors that have cached the same area of memory from 
>> simultaneously modifying data in that area.
>> 
>> The same cache coherency mechanism that prevents ordinary 
>> "unlocked" instructions from simulanteously modifying the same 
>> cache line on two different processors also provides the guarantee 
>> with "locked" instructions.  There's no additional hardware locks 
>> involved, and no additional communication required.
> 
> The cache coherency mechanism is what Scott described as 
> "communicat[ing] to other processors that it (and it alone) owns the
> increment target".  The cache coherency mechanism is not a trivial 
> thing at all.  It introduces its own hazards and delays, and it is 
> getting more complicated all the time as processors and caches get 
> faster and larger.  Some time ago, cpu's hit their megahertz limits 
> and that's why we're using multicores now.  Some PL researchers think
> cache coherency is going to be the next limit, and are advocating 
> languages like Erlang, which avoid use of shared memory and have 
> separate heaps per thread; or alternatively, approaches like the MS 
> Singularity research OS which relies on something like a linear type
> system to statically ensure that a given object is accessible to
> only one thread at a time.  (That approach allows transferring
> objects between threads with no locks or copying required).
> 
How much difference would it make if the reference counts weren't in
cached memory? I'm thinking that an object could have a pointer to its
reference count, which would be stored elsewhere in some uncached memory.