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
|