-----Mensaje original----- De: squeak-dev-bounces@lists.squeakfoundation.org [mailto:squeak-dev-bounces@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@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