What about "Erlanging" the smalltalk interstitial space?
(wasRE: Multy-core CPUs)
Sebastian Sastre
ssastre at seaswork.com
Tue Oct 23 18:43:43 UTC 2007
> -----Mensaje original-----
> De: squeak-dev-bounces at lists.squeakfoundation.org
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] En
> nombre de Jason Johnson
> Enviado el: Martes, 23 de Octubre de 2007 13:58
> Para: The general-purpose Squeak developers list
> Asunto: Re: What about "Erlanging" the smalltalk interstitial
> space? (wasRE: Multy-core CPUs)
>
> On 10/22/07, Sebastian Sastre <ssastre at seaswork.com> wrote:
> >
> > 1.4 I'm interpreting the normal thousands of
> processes Erlang
> > manages as analogue (so similar in function) to one of this
> tides and
> > point why we cannot make tides of Smalltalk message sends
> in an image?
>
> We can. In fact, I think we could do it right now with the
> existing VM and some packages that have been written already.
>
> > 3. If I understood well, Erlang's main strenght is
> not that it
> > has functions to do things but that it has a message
> passing technique
> > really great that was designed to take advantage of
> parallelism in a
> > simple way efficiently and making processes very cheap
> (ceaper than the OS ones).
>
> Erlang processes are much cheaper then OS processes *and* OS threads.
> But then, so are Smalltalk's. The only difference is that
> Erlang processes are encapsulated entities that have no
> shared memory [1], while Smalltalk's do.
>
> > The intersticial space of virtual objects, AKA
> messages sends,
> > can be "Erlanged" by making each message send to be in a "process"
> > (the cheap
> > ones) of it's own like Erlang messages between "process"?
>
> Well, keep in mind, Erlang is a functional language and code
> written in uses functions. Message sends are for
> communicating between processes.
>
> > Same in other words:
> >
> > What consequences will affect us if we make a
> Squeak to use a
> > VM that to pass messages use processes ala Erlang (that are simple,
> > cheap, efficient and scalable in a world of "cores")?
>
> If you mean every Smalltalk message send is what an Erlang
> message send is, then the results would be devastating. As I
> mentioned above, Erlang does it's work with functions. In
> Smalltalk, the equivalent method of doing work is what
> Smalltalk calls "messages". In Erlang there is a concept of
> sending messages between processes, and I would do the same
> for Smalltalk.
>
Erlang does not have objects so I don't think that one paradigm can map 1:1
the other in both sides. Trying to compare literally will be noisy as
minimum. That's why I'm using, as borgs do :), the word "assimilate" meant
to be parsed as "to take from it's conceptual essence it's virtues and
discarding it's vices".
> > Can this allow us to assimilate in the Smalltalk's objects
> > paradigm the Erlagn's process paradigm? This is: will this
> allow us to
> > gain that parallelizing benefits preventing us to change
> the programing paradigm?
>
> We can, and it would [2]. But I think we should, at least at
> first, make inter-process message sends very obviously
> different from inter-object message sends. It would be
> possible, for example, that objects of type "Process" have a
> different way of handling messages so
But that will introduce a singularity in the paradigm. I'm afraid that
accept that is too much. Can you find a way of archieve the goal of your
proposal without devastating the "all is an object" premise?
> that:
>
> (Processes at: 'bank account') addUSD: 5000
>
> Is actually an inter-process send, but I would still want to use the !
> syntax, or something equivalent so it's completely obvious
> that we are doing something different.
>
And accepting singularities like that is how a language gets it's syntax
polluted and developers has to compensate that uncompletism by having to
remember (and model) in it's brains N more rules. The worst of course is not
the syntax but damaging the paradigm. That's is accepting the policy of
unloading of work the machines to load humans. As I see things humans are
not here for that and machines are not here for that. Dear Jason, I'm in the
"opposite corner of the ring" for that policy.
> Inter-process message sends have their own lookup complexity
> that I think should be separate from the inter-object message
> sends we have now. For example, in Erlang if you send a
> message to a process that happens to be in the same image, a
> simple reference copy happens (no danger since variables are
> immutable). The other two cases would be:
> a different OS/native thread in the same image, and a totally
> different image (same computer or on the network).
>
> Now if what you're talking about is basically promoting every
> object to it's own process (using the terms I have described
> so far), then I haven't really given this much though. This
> would be a totally different paradigm and area of research
> (maybe like CORBA?). Though I'm sure someone somewhere has
> done research on it (or is currently).
> :)
>
Mmmm no. I mean that every message send should have a process ala Erlang. Of
course this will only optimize in the other cores the messages sends that
are parallelizable (discern on which is a question that deserves
cogitation). Maybe is just a modest improvement to take advantage of
multicore but it never has any intention to disrupt the paradigm.
> > Sebastian Sastre
> > PD: I've tried to imagine if this saves us from having to make code
> > trhead safe or not. I was unable to refutate this by myself
> so I also
> > ask kindly that the most experienced and critic minds
> collaborate on this regard.
>
> Us as people who use Smalltalk? Yes I believe it does. It
> doesn't make it impossible to make a design that has
> deadlocks, but imo the big win is that these concerns move to
> design time instead of implementation time.
>
> [1] This is enforced by the language. As far as I know, the
> processes actually share the same heap, etc.. They just
> don't know it and can't take advantage of it :)
>
> [2] Well, I believe so anyway, and aim to find out. The
> issue is that Erlang has it easy: you *can't* share data at a
> language level in Erlang. In Smalltalk this gets a little
> tricky, mainly due to one of Smalltalk's greatest strengths:
> Classes are live objects (with state and so on). I believe
> this can be overcome, while preserving the Smalltalk
> semantics, but I can't prove it yet. :)
>
Well.. To be honest I interpret belief as being the user of a system of
thought and of course diferent from a fact or a model that has enough proofs
of concept to deserve investment (time, efforts, $$, energy, etc).
But I think I see your point. I also think that there is no solution without
tradeoffs and I'm not willing to disrupt the paradigm. To gain my willing
(probably others) show a more complete model that works first ;)
All the best,
Sebastian Sastre
More information about the Squeak-dev
mailing list
|