Multy-core CPUs

Sebastian Sastre ssastre at seaswork.com
Wed Oct 24 13:44:10 UTC 2007


> 
> This having a perspective, only if you have unlimited memory 
> resources and zero cost memory allocation.
> Lets look more precise on this. I will write only in ST(i 
> don't know Erlang), and assuming that i understood well your 
> concept , by having following ST code:
> 
> SomeClass>>setVars
> self setVar1: value1.
> self setVar2: value2.
> ...
> ^ self
> 
> here at each message send , instead of writing to receiver 
> memory, we do copy-on-write cloning.

But I don't understand why you want to do that if you can just make that the
process of the receiver update it's own memory when receives that message
that 1 was already assigned and 2 no copy is needed at all. 

Cheers,

Sebastian



> so, self setVar1: value1 will return us a modified copy - 
> self' , To keep things semantically correct, then we 
> substitute self in 'self
> setVar2: value2' by just received copy and so on..
> at the end by returning self we substitute it by self''''''' .
> So, each time we modifying object we got a modified copy 
> instead modifying original.
> Now think about costs: memory allocation and orders of 
> magnitude more garbage generated.
> Now, even if we assume that each process haves own private 
> memory region, its still should be located somewhere in 
> physical memory. And as you may know, a physical memory is 
> shared among all cores, so your 'topmost' memory manager have 
> no excuses, but to use so disliked by you locking to deal 
> with concurrent requests for resources.
> And as you may see from this example, this model really fast 
> going to, that memory manager will become great bottleneck of 
> your model, because of orders of magnitude higher memory consumption.
> 
> And now consider alternative: even by putting a dumb 
> lock-write-unlock we can have much less cycles wasted. 
> Because in your 'non-locking'
> model your main load is just producing tons of garbage by 
> cloning objects over and over.
> 
> --
> Best regards,
> Igor Stasenko AKA sig.
> 




More information about the Squeak-dev mailing list