Multy-core CPUs

Sebastian Sastre ssastre at seaswork.com
Wed Oct 24 20:52:50 UTC 2007


> > > 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: ..
> 
Well I see your point. But let me clarify that I talk about something that
does not suffer of that problem at all. 

If we can forget that problem for a minute I can try to show you what I see.
So here I go:

I don't know if you saw the reference I cited about the Alan Kay's OOPSLA 97
presentation. Is about an hour and a half or less in duration. It's
reacheable with youtube.

There at some point Alan talks about someone said once that every host must
be able to have a valid IP in internet and he states that every object
should be able to have a valid IP. At first that statement is shocking
because is too radical. And we don't have resources for that yet. The
problem is that no matter how radical it is, it's still being a great idea.

As I saw it as just scaling the message passing between objects paradigm
from image level to interenet level (which is of course massive). 

We have no technology to make use of something like that, and maybe is not
important to try to make that today nor in next five years. But that unhappy
fact, forced by todays lack of resources reality, does not make that idea to
be less good. 

So we can decide to have the attitude to prepare ourselves to the moment in
which hardware and industry makes that reality more closer. Could be in next
10? 20? 30 years? Nobody knows but we all do know that this industry is very
accellerated and we are inventing future.

Now I'm trying to think <metaphore>with same software Alan used to sate that
prhase</metaphore> but in another domain. The domain of processes. And with
something that todays is closer to us: multicore technology. 

So I'm stating here that in a smalltalk image of the future *every object
should have a process*. Every instance. All of them.

We also could decide to interpret the phenomenon of seing the Erlang VM
managing 100k processes messaging themselves sucessfully like a mere proof
of concept to encourage us about hardware starting to turn *less worst*
creatures than in the past. That way we can start to think that hardware
it's becoming less worst to the point in wich we can take more seriusly
making this hardware to manage a quantity of processes of the same order of
magnitude of the quantity of instances in a smalltalk image. This makes
feasible to map 1:1 process with instances.

Said that I return to the problem you stated about the need of copy copy
copy, saying that this premise changes things and you don't need to copy
anymore because a VM like that, no matter who or when, an instVar of an
object is to be modified it will provide you of guarantee that the write
will be made by the process that corresponds to that instance.

This idea is redefining what we understood today as anObject by *coupling*
it to aProcess. In this hypothetical smalltalk anObject can't live without a
process. It's indissociable.

So.. in this hypothetical smalltalk:

	- we can supose that every object lives in a process
	- we can supose that nobody but the very owner of an instVar can
write that instVar
	- we can supose that no other process but the one of that instance
will write that piece of RAM
	- we can supose that everythig is an object
	- we can supose that all the instances-processes can be freely
balanced trhough cores

Besides:
	- we have no need to pollute syntax nor smalltalk rules
	- we are not introducing singularities in the paradigm
	- we do are consuming more resources but in compensation of gaining
unprecedent scalability
	- we are keeping the heuristic, completism and simplicity that
defines smalltalk
	- we are making a step forward in anthropomorphism that will
maintain smalltalk concepts familiar to persons	- last but not least: we
take advantage of multicore cpus transparently

Take a minute to think in it's consequences. This suposition, same concept
in more explicit words, this assumption of anObject being an indissociable
thing with aProcess, objects being 1:1 with processes, makes all the
difference and dramatically simplifies all. An we do know that
simplification improves scalability.

I'm, of course, being extremely speculative in the exploration of this idea
in group with you all. But think is cheap :). In fact I don't even buy it
myself yet. The problem is that I'm honestrly unable to refute myself about
the convenience of this path :) so it becomes stronger. 

I hope you and others understand why I'm starting to think that this is a
powerful idea.

	all the best,

Sebastian Sastre
PS: Sorry for the size. I've tried to express this in my previous post. I'm
trying to be didactic and illustrative.

> 
> > Cheers,
> >
> > Sebastian
> >
...
> 
> 
> --
> Best regards,
> Igor Stasenko AKA sig.
> 




More information about the Squeak-dev mailing list