Multy-core CPUs

Sebastian Sastre ssastre at seaswork.com
Thu Oct 25 13:48:04 UTC 2007


> -----Mensaje original-----
> De: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] En 
> nombre de dpharris at telus.net
> Enviado el: Miércoles, 24 de Octubre de 2007 17:53
> Para: The general-purpose Squeak developers list
> Asunto: RE: Multy-core CPUs
> 
> Quoting Sebastian Sastre <ssastre at seaswork.com>:
> 
> 
> > ... 
> > 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.
> 
> I was always impressed  in Self by an idea of the 
> implementers.  They chose a structure that is implicitly 
> inefficient in terms of implementation, namely that every 
> object has its own named slots.  
> 
> However, the smart idea was that, behind the scenes they used 
> implementation 'tricks' to mitigate the efficiency hit, while 
> maintaining the model at the top level.  For example, they 
> defined "maps to transparently group objects cloned from the 
> same prototype, providing data type information and 
> eliminating the apparent space overhead for prototype-based systems." 
> 
> Similarly, we could accept the object-process model, and then 
> explore ways to make this efficient behind the scenes.  It 
> seems to me that on a uniprocessor, the 'behind the scenes' 
> would look much like Smalltalk today. But as multi-core and 
> distributed computing becomes more prevalent we would gain 
> the benefit. 
> Certainly we could explore the realities and consequences of 
> this model.  
> 
> David
> 
Because they prioritized the conceptual model "workarrounding machines" to
provide an acceptable overall user experience. Machines are to be used by
persons. They are only important to materialize consequences of it's use.
They should be meant to improve quality of life of persons and/or the
environment. With a personal value like that, very deeply affecting all your
thought, it's obvious that systems has to be made priorizing intellectual
ergonomy and heuristic principles. 

The case you David are citing about Self, a system in which designers
managed to prioritize the conceptual model over the boolean, it's a rare and
precious coherent sample of what I'm saying.

If we program computers for some time *we know* there allways be ways to
optimize how things are done. So, if making a system, like this Smalltalk of
"One Process Per Instance", results that it has to consume some more
computer resources than others, I say "I don't care" because it's machines
work. Hardware it's becoming less worst and RAM and cores cheaper and
cheaper very fast. I don't feel empathy for machines, I use them to extract
value for me and other persons. So if that is the case lets do clever things
to mitigate the conceptual-boolean impedance mismatch instead of endlessly
discusing about machinery madness that pollute our ideas. As David say, Self
people has showed us mitigation in hard cases is possible by it's example.
Smalltalk it's a splendid example also. 

But this idea is about making the conceptual model to refine rising one
step. To step forward in a direction that will bring us unprecedent
scalability without compromising the simplicity we have today in Smalltalk.
I'm not saying it's the only path but I think it deserves more exploration
because seems to me that it's a path of success in a world of increasing
need of persons modeling it's complexity using machines. And in this path, I
think Smalltalk has a chance to be vanguardist. Again.

All the best,

Sebastian
PS1: Some people claimed I'm being too philosophic, maybe I am because it's
necessary to gestate a solid fundation to build things over it. But it's ok
nothing wrong with that claim, lets embrace pragmatism also. Use the list,
express yourself about this. Your experience or opinions may be important
for others or to continue cogitation.
PS2: I also read Peter posts and I think he's is very good arguing and he
seems to have a very valuable experience. Peter what do you think about this
One Process Per Instance Smalltalk?




More information about the Squeak-dev mailing list