Multy-core CPUs

Igor Stasenko siguctua at gmail.com
Wed Oct 24 17:07:33 UTC 2007


On 24/10/2007, Sebastian Sastre <ssastre at seaswork.com> wrote:
> >
> > 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.
>
Because a receiver is an object which passed as parameter to method.
We can't modify it, thats why - we can't suppose where it passed from
and can't suppose it it used in another parallel process, so best we
can do is cloning. And since the above, you forced to do same for
_any_ method, so you'll go cloning and cloning even by sending self
setVar: ..


> 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.
> >
>
>
>


-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list