Multy-core CPUs

On 10/25/07, Peter William Lount <[hidden email]> wrote:
>
>  The "process-based model of concurrency" - as used in Erlang - is but one
> approach in a wide range of techniques that provide solutions for
> concurrency.

A wide range?  I'm aware of variations of only 3 ideas.  Could you
expand on "wide range"?

>It doesn't solve every problem in concurrency - I don't even
> think that they claim that for it. If they do please show us where.

Would you please stop making a statement that I obviously didn't say
(you even quoted me!) and then attacking that statement you made as
though it were mine?  I find that quite disingenuous.

>  Further the example of the one million object graph being processed by
> 10,000 compute nodes processing the problem is that you don't know in
> advance how to slice up the data. If you can know in advance how to slice up
> the data then you've simplified and possibly optimized the problem solving.
> However, that's the problem, slicing up real world data object sets that are
> highly interconnected with each other and processing them in parallel.
> That's an example of a more general case. There are other examples that
> won't compute with the slice em and dice em approach using the process-based
> model of concurrency.

Do you have any real-world cases where it's a problem?  I'm not
interested in solving theoretical problems that never come up in
actual practice.

On 10/25/07, Matej Kosik <[hidden email]> wrote:
> I am sorry. This wasn't the proper word.
>
> Certainly, I believe that there are things that cannot be modelled in the pure functional language
> (whose constructs can be without exceptions mapped to the lambda-calculus). This is not only the
> case of input/output. This is also the case of modelling stateful systems that interact with their
> environment over time (not only at the beginning and at the end). So pretending that functional
> programming can cover all the important aspects of systems we need to model is unfaithful. Those
> impurities are useful.

Um, you are aware that lambda-calculus is Turing equivalent right?

http://en.wikipedia.org/wiki/Turing-complete

"The untyped lambda calculus is Turing-complete, but many typed lambda
calculi, including System F, are not."

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Peter William Lount wrote:
Some initial examples:
After some initial introduction:
http://www.erights.org/elang/intro/index.html

These things might be understandable
(concerning distributed programming, and event-loop concurrency)
http://www.erights.org/elib/index.html

Many things (together with reasons why they are done as they are done) is sequentially described here:
http://www.erights.org/talks/thesis/index.html

Some powerbox examples (in the E programming language as well as in other programming language) is here:
http://altair.sk:60001/mediawiki/upload/f/f9/Powerbox-rants.article.pdf
It is basic technique; not available in Erlang. Available in some (I do not say in every respects
perfect) other languages.

I am sure, at e-lang
http://www.eros-os.org/mailman/listinfo/e-lang
you might get detailed answers for questions.

Best regards
- --
Matej Kosik
ICQ: 300133844
skype: matej_kosik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHINvCL+CaXfJI/hgRArWxAKCY7w9w3ZJLPhy+GVugz+Xlmv5TZACgm2+Z
XrAU8A9DdeXBN9DJ8XiLad8=
=Pbdy
-----END PGP SIGNATURE-----

On 10/25/07, Matej Kosik <[hidden email]> wrote:
>
> I agree. Neither Erlang nor Smalltalk were designed with security in mind. Funny thing about
> security is, that if you do not get it right in the beginning, you cannot "add it later".

The funny thing about security is that it is on the opposite end of a
sliding scale, with "user friendly-ness" on the other side.

As far as "you cannot add it later", given that nearly all the secure
systems I can think off of the top of my head were indeed "added
later" (e.g. HTTPS), I think this claim is false.

Thanks for the summaries.  The language does sound interesting, I admit.

On 10/25/07, Matej Kosik <[hidden email]> wrote:

Hi,


Jason Johnson wrote:

On 10/25/07, Peter William Lount [hidden email] wrote:
  

Hi,

Slicing up the data objects and shipping them in one deep copied parcel
from one Smalltalk image to another isn't a general solution. It may be
a solution for some problems that can be simplified but it will NOT work
for the majority of problems. In fact I'd find a "deep copy and split up
the data objects only solution" quite useless for most of the parallel
problems that I'm working on solving.
    

Ok, you just made a jump there from "majority of problems" to "most of
the problems that *I'm* working on".  It works just fine for the
problems I'm interested in at the moment, and obviously for most of
the problems businesses, etc. are using Erlang for.

So what are these "majority of problems" you're talking about and who
is solving them now?
  

You're splitting hairs with my use of English. The vast majority of concurrency problems won't fit well with the process-based model of concurrency (of Erlang and other systems).

Process-based model of concurrency won't solve ALL the problems. Consider that there are an infinite number of concurrency problems. You're telling me that the solution you are proposing solves them all?

Sure if you have a set of problems that you are solving that fit perfectly with the process-based model of concurrency - as used in Erlang - then excellent use that approach to solve your problems. Go for it.

However, please don't force your "process-based ONLY model of concurrency" onto Smalltalk since there are those of us out here with other real world problems that the process-based model of concurrency won't solve easily or at all. This also applies for the deep coping of objects as an only solution - it just works for a tiny subset of problems. Please don't force ill conceived deep copying solutions upon us as the ONLY solution.

One solution won't fit all. That's the point of a programming language - to be general purpose enough to enable programmers or users to solve as wide a range of problems as possible.

It sounds like you need to put your code into a library of objects that are optional rather than forcing them into the virtual machine.

In the general large scale case that I gave as an example (in an earlier
email) the one million data objects could be retrieved or accessed by
any of the 10,000 processes used in the example. While shipping them all
in a deep copied parcel in one message is possible it's not always the
wisest move.
    

And why would you do that?  No paradigm can remove the responsibility
to think from the programmer.  As I've said I don't know how many
times, the point of this is simply to move this to design where it
belongs instead of implementation where it is now.

Sharing memory is breaking encapsulation.
  

No, sharing memory does not necessarily break encapsulation. Many things break encapsulation for sure. Blocks for one (see Alan Kay's comments on this).

It's how you look at it. If many processes are accessing an object via the objects methods then encapsulation is not broken since the object is in control of who can see what and when. It doesn't matter how many processes see the object if the object is in control of what is happening to it. That is a current capability of Smalltalk.

A key characteristic of the general problems
is that the data objects can and must be accessible from ANY of the
forked off processes with ANY of them being able to alter the objects at
any point in time with those changes being propagated back to the
central node (assuming there is just one central node) when a commit
occurs and then updating the other forked off processes that have an
interest in seeing updates to objects in mid transaction. Some of these
changes will of course nullify the work of some of these processes
requiring them to abort and possibly start over with the newest changes.
Too many interacting changes between the processes will of course cause
too many aborts and retry (assuming that's the chosen mechanism for
dealing with overlapping changes that are mutually exclusive resulting
in inconsistency to the data objects).
    

You lost me again.  You seem to come up with a problem *and the way
you want it solved* and then complain that a message passing paradigm
can't solve it.  What does that prove?
  

I apologize if my writing wasn't clear.

I provide an example and one way (of many ways) to solve it. Yes. That's being responsible from my perspective since I know the a solution that will work I'm not going to hide it as some sort of covert test.

Obviously the message passing paradigm of Smalltalk can solve the problem since that's what I've presented. What's not clear is how the "process-based model of concurrency" - of Erlang - can solve every concurrency problem out there. What's not clear is how Erlang would solve the example I put forward without changing it into a slice and dice of the original one million objects.

The point or "what does it prove" is that no one concurrency solution will solve all the problems. I provided an example to show that and to show the kind of nasty problem that other concurrency problems can solve.

See the "Little Book of Semaphores" that I linked to for many other solutions to concurrency problems.

Solving for 90%
of the cases will thus require much more than what is being proposed by
the simplify concurrency at the loss of capability proponents.
    

Your 90% is different then mine then.  In fact, I can't think of any
concurrency problems I wish to resolve that this *wont* handle.
  

As I said in another recent email today your set of problems is of a nature that can be solved that way. That's great. However, please don't force your approach unto us all since it won't work for all of us.

Please put your solution into a library so that those who wish to use it can do so if they so choose. Thanks.

What are needed are solutions that cover various chunks of the solution
space and a way of selecting the correct solution mechanisms either
manually or automatically (preferred if viable). Then the "deep copy and
split up the data objects only solution" may do it's part as a piece in
a wider matrix of solutions. To dispense with the tools we need to solve
the general problems is folly IMHV (In My Humble View).
    

We already have.  

How so?

Or is Squeak/most Smalltalks folly?  There are
certain classes of memory management that don't work well with a GC,
but would with manual memory management.  Is it a mistake to deny it's
use at the language level?
  

Sure Smalltalk has limits to what it can do. That is very important to recognize it's limits.

However, within the current limits of what Smalltalk can do is working powerfully with concurrency (albeit in a single native thread for most but not all implementations of Smalltalk). To reduce this current capability to solve just a subset of concurrency problems is what I'm calling folly.

If you can provide a proof that your proposed process-based model of concurrency methodology can solve all the concurrency problems that can currently be solved by Smalltalk then you'll have convinced me (and likely others). So far I'm still not even clear what you are proposing.

I work quite hard to implement more power and capability for Smalltalk not take it away. Altering the Smalltalk language - or even one version of it, Squeak - in such a way as to make it less powerful by removing concurrency control capabilities isn't going to fly with me and a large number of users of Squeak.

If you wish to do that then you'll likely need to be very creative and put your concurrency solution into an optional class library somehow. That will fly. Or fork a new version off of Squeak. That would also fly with many or almost all I suspect.

In fact there are many small versions of Smalltalk such as Little Smalltalk or Susie Smalltalk or ... that are quite limited (actually almost all Smalltalks are quite limited when compared with VisualAge with Envy but that's another discussion ;--). They are separate versions of Smalltalk for that reason and it's a good thing too. (I use Susie Smalltalk and Squeak Smalltalk in the Smalltalk.org web site for various jobs - the right tool for the right job).

Some of the innovations that I've encountered or created will enable Smalltalk to be a more powerful language while retaining all aspects of Smalltalk - if they are adopted. (See my other postings in this group and on Smalltalk.org for some of the details of those).

Other innovations that I've encountered or created however, alter the Smalltalk language so much so that it's no longer really Smalltalk - more powerful and highly influenced by Smalltalk but clearly not Smalltalk anymore (at least to me). For this reason and others I'm implementing ZokuScript which is highly influenced by Smalltalk but goes beyond it enough that it isn't Smalltalk anymore. At the same time I'm implementing ZokuTalk which is meant to be a version of Smalltalk. Actually for leverage ZokuTalk will be converted to ZokuScript on the fly and the ZokuScript equivalent will be compiled for execution.

In the meantime I regularly use the following Smalltalks for various projects (paying and otherwise): Squeak, Susie, Dolphin, Visual Age, Visual Works, Coke-Pepsi-idst, and less often others. Naturally as is the way of a mobius system that evolves to it's next level I'm writing ZokuScript/ZokuTalk in Smalltalk. Once the Zoku Execution Engine (not a virtual machine) has reached a stage that it can run by itself development will proceed self hosted by itself.

An excellent book for learning the ins and outs of concurrency control -
and most importantly the common mistakes - is the free PDF book, "The
Little Book of Semaphores",  by Allen B. Downey and his students:
http://www.greenteapress.com/semaphores/downey05semaphores.pdf. Enjoy
the full power of parallel programming.
    

For me that's just old-think.  Solutions to incredibly complex
problems we never would have had if we simply avoided violating
encapsulation

Well even the Greeks and Babylonians got some things right even if some of their ideas have been refined. As a general principle I concur and support your efforts - as there is some overlap with some of the solutions that I've been working on with Transactions and parallel processing. However, I'm also grounded in the harsh realities of concurrency control in a wide range of contexts - not all problems can be solved by the solution you are presenting. To ignore that is to ignore reality.

If you can however provide a proof I'd have to be adapt since the science aspect of computing implies an evidence based approach.

All the best,

Peter

Jason Johnson wrote:
> Of course the one thing I have to disagree with in your message is the
> comment about an object responding to multiple messages.  I wouldn't
> want that.  If you want an object to respond to more messages
> concurrently make more of them.

Hi,

If you make more of them then they aren't the same object! That could
have wide implications for an object graph. Identity is an important
concept especially in large object graphs.

Also, if you do make more than one of the object you have to
concurrently synchronize any changes between it's copies unless of
course it's the simple case where the objects are read only.

Simplification can get one in trouble when it comes to concurrency,
distribution and other areas of computing. Part of that trouble is
thinking that ones solution is general when it just covers a subset of
the desired solution space. This is why discussion is a good thing as it
tends to reveal the blind spots that one has. This goes for me too!

Thanks by the way for the correction about Erlang being able to
"message" more than simple data types across it's wire. I'd forgotten
that part.

All the best,

Peter

hi,

What? That just won't work. Think of the memory overhead. 
 

I don't give credit to unfounded apriorisms. I think it deserves to be proved that does not work. Anyway let's just assume that may be too much for state of the art hardware in common computers in year 2007. What about in 2009? what about in 2012? Remember the attitude you had saying this now the first day of 2012.

 
Tying an object instance to a particular process makes no sense. If you did that you'd likely end up with just as many dead locks and other concurrency problems since you'd now have message sends to the object being queued up on the processes input queue. Since processes could only process on message at a time deadlocks can occur - plus all kinds of nasty problems resulting from the order of messages in the queue. (There is a similar nasty problem with the GUI event processing in VisualAge Smalltalk that leads to very difficult to diagnose and comprehend concurrency problems). It's a rats maze that's best to avoid.
 
Besides, in some cases an object with multiple threads could respond to many messages - literally - at the same time given multiple cores. Why slow down the system by putting all the messages into a single queue when you don't have to!?

You didn't understand the model I'm talking about. There isn't such a thing as an object with multiple trheads. That does not exists in this model. It does exists one process per instance no more no less. I think you're thinking about processes and threads the same way you know them today. Lets see if this helps you to get the idea: Desambiguation: for this model I'm talking about process not as an OS process but as a VM light process which we also use to call them threads. So I'm saying that in this model you have only one process per instance but that process is not a process that can have threads belonging to it. That generates a hell of complexity. The process I'm saying it's tied to an instance it's more close to the process word you know from dictionary plus what you know what an instance is and with the process implemented by a VM that can balance it across cores.

 

I'm not falling in the pitfall of start trying to parallelize code automagically. This far from it. In fact I think this is better than that illusion. Every message is guaranteed by VM to reach it's destination in guaranteed order. Otherwise will be chaos. And we want an ordered chaos like the one we have now in a Squeak reified image.

 

Clarified that I ask why do you think could be deadlocks? and what other kind of concurrency problems do you think that will this model suffer?

 
Tying an object's life time to the lifetime of a process doesn't make sense since there could be references to the object all over the place. If the process quits the object should still be alive IF there are still references to it.

You'd need to pass around more than references to processes. For if a process has more than one object you'd not get the resolution you'd need. No, passing object references around is way better.
 

Yes of course there will be. In this system a process termination is one of two things: A) that instance is being reclaimed in a garbage collection or B) that instance has been written to disk in a kind of hibernation that can be reified again on demand.  Please refer to my previous post with subject "One Process Per Instance.." where I talk more about exacly this. 

 
Even if you considered an object as having it's own "logical" process you'd get into the queuing problems hinted at above.
 

Which I dont see and I ask your help to understand if you still find them after the clarifications made about the model.

 
Besides objects in Smalltalk are really fine grained. The notion that each object would have it's own thread would require so much thread switching that no current processor could handle that. It would also be a huge waste of resources.

And what do you think was going out of the mouths of criticizers of the initiatives like the park place team had in 1970's making a Smalltalk with the price of the CPU's and RAM at that time? that VM's are a smart efficient use of resources?

 

So I copy paste myself: "I don't give credit to unfounded apriorisms. It deserves to be proven that does not work. Anyway let's just assume that may be too much for state of the art hardware in common computers in year 2007. What about in 2009? what about in 2012?"

 
Again, one solution does not fit all problems - if it did programming would be easier.
 

But programming should have to be easier. Smalltalk made it easier in a lot of aspects. Listen.. I'm not a naif silver bullet purchaser nor a faithful person. I'm a critic Smalltalker that thinks he gets the point about OOP and tries to find solutions to surpass the multicore crisis by getting an empowered system not consoling itself with a weaker one. Peter please try to forget about how systems are made and think in how you want to make them.

 

    cheers,

 

Sebastian

 
All the best,

Peter

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jason Johnson wrote:
Absolutely correct.

But there are strictly more interesting things that we want to describe whose behavior cannot be
described in the lambda-calculus.

The thing that comes to my mind is
- - ClockMorph
- - the web-server
- - the programmable interrupt timer
- - Erlang concurrent, mutually interacting, processes.
  ...

There are other (equivalent) formalisms that cover also these systems formally. However, it is true
that dealing with them is more difficult. But they exist and it does not make sense that they do not
exist only because we (me not excluding) do not fully understand them.

>
> "The untyped lambda calculus is Turing-complete, but many typed lambda
> calculi, including System F, are not."
>


- --
Matej Kosik
ICQ: 300133844
skype: matej_kosik
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHIOQAL+CaXfJI/hgRAs6nAKCsiz4abhVOPEgH4CIRSKOxpzaLAgCgitw4
6F6DWvWGjpA/2+eGI3eWZyQ=
=q9RE
-----END PGP SIGNATURE-----

Hi,

Jason Johnson wrote:

On 10/25/07, Peter William Lount [hidden email] wrote:
  

 The "process-based model of concurrency" - as used in Erlang - is but one
approach in a wide range of techniques that provide solutions for
concurrency.
    

A wide range?  I'm aware of variations of only 3 ideas.

What are they?

  Could you expand on "wide range"?
  

Sure, one only has to search the internet for "concurrency" and one sees a wide range of problems and potential solutions. Look at the Little Book of Semaphores for a breathtaking look at a few of the many possible solutions to various problems. Open your eyes to the wider horizon.

It doesn't solve every problem in concurrency - I don't even
think that they claim that for it. If they do please show us where.
    

Would you please stop making a statement that I obviously didn't say
(you even quoted me!) and then attacking that statement you made as
though it were mine?  I find that quite disingenuous.
  

I never said you stated that explicitly - I'd have to check all your postings to find that out. It's implied by what you are saying in many of your postings. At least that is the impression that I'm getting from your writing. You've certainly not acknowledged the opposite.

 Further the example of the one million object graph being processed by
10,000 compute nodes processing the problem is that you don't know in
advance how to slice up the data. If you can know in advance how to slice up
the data then you've simplified and possibly optimized the problem solving.
However, that's the problem, slicing up real world data object sets that are
highly interconnected with each other and processing them in parallel.
That's an example of a more general case. There are other examples that
won't compute with the slice em and dice em approach using the process-based
model of concurrency.
    

Do you have any real-world cases where it's a problem?  I'm not
interested in solving theoretical problems that never come up in
actual practice.

Yes, the example I gave is a good summary of real world problems that actually occur (and that I'm working to solve for one project). It's not just theory, it's a harsh reality.



Cheers,

Peter

Jason Johnson wrote:

On 10/25/07, Matej Kosik [hidden email] wrote:
  

I am sorry. This wasn't the proper word.

Certainly, I believe that there are things that cannot be modelled in the pure functional language
(whose constructs can be without exceptions mapped to the lambda-calculus). This is not only the
case of input/output. This is also the case of modelling stateful systems that interact with their
environment over time (not only at the beginning and at the end). So pretending that functional
programming can cover all the important aspects of systems we need to model is unfaithful. Those
impurities are useful.
    

Um, you are aware that lambda-calculus is Turing equivalent right?

http://en.wikipedia.org/wiki/Turing-complete

"The untyped lambda calculus is Turing-complete, but many typed lambda
calculi, including System F, are not."


  

Hi,

As an aside, the simplest possible Universal Turning Machine was just discovered by a mathematical proof. See http://www.wolframscience.com/prizes/tm23/solution_news.html.

Yes, almost any computing machine can compute any solution. But ick, not in practice. Shivers.

All the best,

Peter

Jason Johnson wrote:

On 10/25/07, Matej Kosik [hidden email] wrote:
  

I agree. Neither Erlang nor Smalltalk were designed with security in mind. Funny thing about
security is, that if you do not get it right in the beginning, you cannot "add it later".
    

The funny thing about security is that it is on the opposite end of a
sliding scale, with "user friendly-ness" on the other side.

As far as "you cannot add it later", given that nearly all the secure
systems I can think off of the top of my head were indeed "added
later" (e.g. HTTPS), I think this claim is false.


  

Hi,

I agree with the point of view that it's better to add it before hand when it comes to certain topics like security.

Cheers,

peter

On 10/25/07, Peter William Lount <[hidden email]> wrote:
>
>  You're splitting hairs with my use of English.

I was under the impression you were a native English speaker.  Am I incorrect?

> The vast majority of
> concurrency problems won't fit well with the process-based model of
> concurrency (of Erlang and other systems).
>
>  Process-based model of concurrency won't solve ALL the problems.

And here another jump.  It wont solve *the vast majority* or it wont
solve *all*?  Which is it?

> Consider
> that there are an infinite number of concurrency problems. You're telling me
> that the solution you are proposing solves them all?

No!  Again, will you please stop asking me to defend statements *you made*???

> Please don't force ill
> conceived deep copying solutions upon us as the ONLY solution.

Who is forcing anything on anyone?  I'm pointing out what I thought
(prior to this thread) was already obvious:  shared state locking
can't scale.  The fact is, Squeak already *has* futures in several
incarnations, shared state locking in various incarnations and so on.

I'm simply pointing out that adding true threading like Java has to
Squeak is a pour use of resources we don't have.

>  One solution won't fit all.

And too many unnecessary choices produce indecision and worse.

Options are good.  Too many options are less good.  Bad options are
bad.  Look at C++.

>  No, sharing memory does not necessarily break encapsulation. Many things
> break encapsulation for sure. Blocks for one (see Alan Kay's comments on
> this).

Of course it does.  Two separate entities that "own" the same resource
at the same time.

>  I provide an example and one way (of many ways) to solve it. Yes. That's
> being responsible from my perspective since I know the a solution that will
> work I'm not going to hide it as some sort of covert test.

That's fine to do, but you seem to assume there is no other solution
and therefor Actor-style message passing can't handle it.

>  The point or "what does it prove" is that no one concurrency solution will
> solve all the problems. I provided an example to show that and to show the
> kind of nasty problem that other concurrency problems can solve.

And what exactly is going to solve this problem?  Shared state
fine-grained locking?  Across 10k nodes!  You can't be serious.

>  I work quite hard to implement more power and capability for Smalltalk not
> take it away. Altering the Smalltalk language - or even one version of it,
> Squeak - in such a way as to make it less powerful by removing concurrency
> control capabilities isn't going to fly with me and a large number of users
> of Squeak.

And this is the funniest part.  The current model we have
(shared-state) is the weakest of the models.

On 10/25/07, Peter William Lount <[hidden email]> wrote:
>
>  What are they?

Here.  Again.  http://sixtyk.blogspot.com/2007/05/threading.html

>  Sure, one only has to search the internet for "concurrency" and one sees a
> wide range of problems and potential solutions. Look at the Little Book of
> Semaphores for a breathtaking look at a few of the many possible solutions
> to various problems. Open your eyes to the wider horizon.

Open my eyes to the wider horizon of yesterday?  I've seen it.  It's
complicated.  I prefer to look at tomorrow.

>  I never said you stated that explicitly - I'd have to check all your
> postings to find that out. It's implied by what you are saying in many of
> your postings. At least that is the impression that I'm getting from your
> writing. You've certainly not acknowledged the opposite.

I really believe that over-all your intentions are good, but this
seems downright dishonest.  Either that are you simply don't read what
I write.  I have told you *every single time* you brought up this
charge that I don't think it will solve all cases.



Ok, we're getting no where with this.  I apologized to the list for
what this thread has turned into, and I'll try to do a better job
staying out of this sort of pointless "nu uh", "uh hu!", "nu uh!"
discussions in the future.  (if I start it again just warn me!  It's a
bit of a weakness of mine).

And I prefer to see it at interface points.  Not deep down in a
language where it's making everything inconvenient.

On 10/25/07, Peter William Lount <[hidden email]> wrote:

On 10/25/07, Matej Kosik <[hidden email]> wrote:
>
> But there are strictly more interesting things that we want to describe whose behavior cannot be
> described in the lambda-calculus.
>
> The thing that comes to my mind is
> - - ClockMorph
> - - the web-server
> - - the programmable interrupt timer
> - - Erlang concurrent, mutually interacting, processes.

Why not?  You don't need to update variables to have updates.  And,
you know that Erlang can not modify variables after creation right,
although I don't know if this is the property of L-C you had in mind?

> Ok, we're getting no where with this.  I apologized to the
> list for what this thread has turned into, and I'll try to do
> a better job staying out of this sort of pointless "nu uh",
> "uh hu!", "nu uh!"
> discussions in the future.  (if I start it again just warn
> me!  It's a bit of a weakness of mine).
>
You have nothing to apoligize about. Controversy is good when you need to
agitate the mind a little. IMHO "fencing of arguments" (plz not persons) is
healthy. Without that we will be frozen in comfort.

Please continue defending your thesis as long as they can survive. This is a
discussion list. So it is by definition.

        cheers,

Sebastian

I don't apologize for my statements, just that I don't think we've
gained any ground in at least a day and I'm part of that.

On 10/25/07, Sebastian Sastre <[hidden email]> wrote:

Hi,

Sebastian Sastre wrote:

hi,

What? That just won't work. Think of the memory overhead. 
 

I don't give credit to unfounded apriorisms. I think it deserves to be proved that does not work. Anyway let's just assume that may be too much for state of the art hardware in common computers in year 2007. What about in 2009? what about in 2012? Remember the attitude you had saying this now the first day of 2012.

It's not an unfounded apriorism as you put it.

Current hardware and technology expected in the next ten years isn't optimized for N hundred thousand or N million threads of execution. Maybe in the future that will be the case.

The Tile-64 processor is expected to grow to about 4096 processors by pushing the limits of technology beyond what they are today. To reach the levels you are talking about for a current Smalltalk image with millions of objects each having their own thread (or process) isn't going to happen anytime soon.

I work with real hardware.

I am open and willing to be pleasantly surprised however.

Tying an object instance to a particular process makes no sense. If you did that you'd likely end up with just as many dead locks and other concurrency problems since you'd now have message sends to the object being queued up on the processes input queue. Since processes could only process on message at a time deadlocks can occur - plus all kinds of nasty problems resulting from the order of messages in the queue. (There is a similar nasty problem with the GUI event processing in VisualAge Smalltalk that leads to very difficult to diagnose and comprehend concurrency problems). It's a rats maze that's best to avoid.
 
Besides, in some cases an object with multiple threads could respond to many messages - literally - at the same time given multiple cores. Why slow down the system by putting all the messages into a single queue when you don't have to!?

You didn't understand the model I'm talking about.

That is likely the case.

There isn't such a thing as an object with multiple trheads. That does not exists in this model.

Ok. I got that.

It does exists one process per instance no more no less.

I did get that. Even if you only do that logically you've got serious problems.

I think you're thinking about processes and threads the same way you know them today.

I can easily see such a scenario working and also breaking all over the place.

Lets see if this helps you to get the idea: Desambiguation: for this model I'm talking about process not as an OS process but as a VM light process which we also use to call them threads.

Ok.

So I'm saying that in this model you have only one process per instance but that process is not a process that can have threads belonging to it.

ok.

That generates a hell of complexity.

You lost me there. What complexity?

The process I'm saying it's tied to an instance it's more close to the process word you know from dictionary plus what you know what an instance is and with the process implemented by a VM that can balance it across cores.

I didn't understand. Please restate.

 

I'm not falling in the pitfall of start trying to parallelize code automagically. This far from it. In fact I think this is better than that illusion. Every message is guaranteed by VM to reach it's destination in guaranteed order. Otherwise will be chaos. And we want an ordered chaos like the one we have now in a Squeak reified image.

Yes, squeak is ordered chaos. ;--).

 

Clarified that I ask why do you think could be deadlocks? and what other kind of concurrency problems do you think that will this model suffer?

If a number of messages are waiting in the input queue of a process that can only process one message at a time since it's not multi-threaded then those messages are BLOCKED while in the thread. Now imagine another process with messages in it's queue that are also BLOCKED since they are waiting in the queue and only one message can be processed at a time. Now imagine that process A and process B each have messages that the other needs before it can proceed but those messages are BLOCKED waiting for processing in the queues.

This is a real example of what can happen with message queues. The order isn't guaranteed. Simple concurrency solutions often have deadlock scenarios. This can occur when objects must synchronize events or information. As soon as you have multiple threads of execution you've got problems that need solving regardless of the concurrency model in place.

 
Tying an object's life time to the lifetime of a process doesn't make sense since there could be references to the object all over the place. If the process quits the object should still be alive IF there are still references to it.

You'd need to pass around more than references to processes. For if a process has more than one object you'd not get the resolution you'd need. No, passing object references around is way better.
 

Yes of course there will be. In this system a process termination is one of two things: A) that instance is being reclaimed in a garbage collection or B) that instance has been written to disk in a kind of hibernation that can be reified again on demand.  Please refer to my previous post with subject "One Process Per Instance.." where I talk more about exacly this.

If all there is is a one object per process and one process per object - a 1 to 1 mapping then yes gc would work that way but the 1 to 1 mapping isn't likely to ever happen given current and future hardware prospects.

 
Even if you considered an object as having it's own "logical" process you'd get into the queuing problems hinted at above.
 

Which I dont see and I ask your help to understand if you still find them after the clarifications made about the model.

See the example above.

 
Besides objects in Smalltalk are really fine grained. The notion that each object would have it's own thread would require so much thread switching that no current processor could handle that. It would also be a huge waste of resources.

And what do you think was going out of the mouths of criticizers of the initiatives like the park place team had in 1970's making a Smalltalk with the price of the CPU's and RAM at that time? that VM's are a smart efficient use of resources?

That's not really relevant. If you want to build that please go ahead - please don't let me stop you, that's the last thing I'd want. I wish you luck. I get to play with current hardware and hardware that's coming down the pipe such as the Tile-64 or the newest GPUs when they are available to the wider market.

 

So I copy paste myself: "I don't give credit to unfounded apriorisms. It deserves to be proven that does not work. Anyway let's just assume that may be too much for state of the art hardware in common computers in year 2007. What about in 2009? what about in 2012?"

Well just get out your calculator. There is an overhead to a thread or process in bytes. Say 512 bytes per thread plus it's stack. There is the number of objects. Say 1 million for a medium to small image. Now multiply those and you get 1/2 gigabyte. Oh, we forgot the stack space and the memory for the objects themselves. Add a multiplier for that, say 8 and you get 4 gigabytes. Oh, wait we forgot that the stack is kind weird since as each message send that isn't to self must be an interprocess or interthread message send you've got some weirdness going on let along all the thread context switching for each message send that occurs. Then you've got to add more for who knows what... the list could go on for quite a bit. It's just mind boggling.

Simply put current cpu architectures are simply not designed for that approach. Heck they are even highly incompatible with dynamic message passing since they favor static code in terms of optimizations.

 
Again, one solution does not fit all problems - if it did programming would be easier.
 

But programming should have to be easier.

Yes, I concur, whenever it's possible to do so. But it also shouldn't ignore the hard problems either.

Smalltalk made it easier in a lot of aspects.

Sure I concur. That's why I am working here in this group spending time (is money) on these emails.

Listen.. I'm not a naif silver bullet purchaser nor a faithful person. I'm a critic Smalltalker that thinks he gets the point about OOP and tries to find solutions to surpass the multicore crisis by getting an empowered system not consoling itself with a weaker one.

I do get that about you.

Peter please try to forget about how systems are made and think in how you want to make them.

I do think about how I want to make them. However to make them I have no choice but to consider how to actually build them using existing technologies and the coming future technologies.

Currently we have 2-core and 4-core processors as the mainstream with 3-core and 8-core coming to a computer store near you. We have the current crop of GPUs from NVidia that have 128 processing units that can be programmed in a variant of C for some general purpose program tasks using a SIMD (single instruction multiple data) format - very useful for those number crunching applications like graphics, cryptology and numeric analysis to name just a few. We also have the general purpose networked Tile-64 coming - lots of general purpose compute power with an equal amount of scalable networked IO power - very impressive. Intel even has a prototype with 80-cores that is similar. Intel also has it's awesomely impressive Itanium processor with instruction level parallelism as well as multiple cores - just wait till that's a 128 core beastie. Please there is hardware that we likely don't know about or that hasn't been invented yet. Please bring it on!!!

The bigger problem is that in order to build real systems I need to think about how they are constructed.

So yes, I want easy parallel computing but it's just a harsh reality that concurrency, synchronization, distributed processing, and other advanced topics are not always easy or possible to simplify as much as we try to want them to be. That is the nature of computers.

Sorry for being a visionary-realist. Sorry if I've sounded like the critic. I don't mean to be the critic that kills your dreams - if I've done that I apologize. I've simply meant to be the realist who informs the visionary that certain adjustments are needed.

All the best,

Peter

Sebastian Sastre wrote:

Ok, we're getting no where with this.  I apologized to the 
list for what this thread has turned into, and I'll try to do 
a better job staying out of this sort of pointless "nu uh", 
"uh hu!", "nu uh!"
discussions in the future.  (if I start it again just warn 
me!  It's a bit of a weakness of mine).

    

You have nothing to apoligize about. Controversy is good when you need to
agitate the mind a little. IMHO "fencing of arguments" (plz not persons) is
healthy. Without that we will be frozen in comfort.

Please continue defending your thesis as long as they can survive. This is a
discussion list. So it is by definition.

	cheers,

Sebastian



  

Hi,

I concur with Sebastian.

All the best,

Peter