[squeak-dev] Prepare for Thousands of Cores --- oh my Chip - it's full of cores!

On Jul 6, 2008, at 11:41 AM, Peter William Lount wrote:

> Hi,
>
> Oh, clearly I misunderstood about Hydra. I thought it could handle  
> more than one native thread per image in memory.

Nope, only one.

That's true.  However, it provides a simple way to conceptualize which  
threads are accessing which memory; you can then design your  
application accordingly.  This simple model doesn't exist with  
multiple-threads-per-image (not that *something* couldn't be designed  
to play the same role, but it's not immediately clear to me how that  
would work).

Best,
Josh

Jason Johnson wrote:
> If you mean what I think you mean (fine grained shared state
> multi-threading) then I find this a pretty ironic message: "the
> multi-cores on upon us, we need to hurry up and adapt the method of
> concurrent program that absolutely wont work on 1k+ cores".

This is by far the best summary of the issues that I've ever seen.

Cheers,
   - Andreas

Smalltalk has the best concurrent programming potential I've seen in a programming language. The concurrent features are all there - blocks are easy to fork, semaphores are easy to use, and very nice concurrent abstractions can be built up using this powerful language. I can't see any reason that a Smalltalk VM won't run well on 1k+ cores with good concurrent algorithms.

I agree completely with Peter.

I'm not going to contribute to this flame war though as I'm not going to start work on a shared-state concurrent VM any time soon.

Gulik.

--
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/

Benoit St-Jean wrote:

Peter, betting "All-in" is easy.  Winning is something else.  Criticizing is easy.  Let's see the cards now!  I've seen plently of Igor's code/papers/discussions/ideas, i.e  REAL stuff...  Now, it's your turn to go "all-in" !  What about Zoku Peter???  Will it support multi-core, native, "non-green" threads/processes ???  Any roadmap?  Any ideas, plans, whatever?  Any demo?  Beyond theorical ideas, anything to refute Igor's ideas?

I don't mind "ideas bashing." when the opponents have something to prove/show/discuss...  I wouldn't mind arguing with Vassili Bykov, Elliott Miranda, Dan Ingalls, Matthew Fullmer, Stéhane Ducasse and a lot of others (sorry guys if you're not in the enumeration) but sometimes, being silent is the best solution when you've got nothing to add/prove to the discussion.

I don't mind aurguing about ideas...  But please guys, back your arguments with *something* !

 -----------------
Benoit St-Jean
Yahoo! Messenger: bstjean
Blog: lamneth.wordpress.com
A standpoint is an intellectual horizon of radius zero.
(Albert Einstein)&

Hi Benoit,

How's it going Benoit? It's been a long while. How's the family? It would be good to talk with you again. You know my person email and phone numbers.

I think you misread my intentions; I was not intending to criticize the hard work of others. I am a big supporter of all versions of Smalltalk and encourage all developers of these systems to push their state of the art forward. As for your "all in" comments I don't know what to say, other than to say they are not conducive to a sense of community. I agree that theory and practical results are both very important.

I think Igor is doing amazing work! I'm glad that he produced the HydraVM. I was mistaken about it being able to run multiple native threads since I've not had a chance to really study it yet. I like his ideas for writing low level virtual machine code in a limited form of Smalltalk (aka Igor slang), it is similar to an approach that I'm using for ZokuScript in which the contents of blocks can be viewed, parsed, interpreted or compiled in different ways. I'm looking forward to looking at his work closer.

I simply desire Smalltalk to move to the general solution of one or more native threads per image in memory. Smalltalk MT is one REAL example that leads shining the way showing that M native threads per image in a Smalltalk is not only doable but quite nice indeed. Smalltalk MT has been out there for a long time now, fourteen years, proving that it can be done. As you said the REAL stuff of proof it is in the pudding known as Smalltalk MT.

"Smalltalk MT is fully multithreaded and all primitives are reentrant. Threads are very lightweight and share a common address space, which is consistent with the way threads are used on Win32. The system is scalable and can benefit from multiprocessor architectures. ... Smalltalk MT is multithreaded from the ground up, with garbage collection running in a separate thread. A process can have any number of threads. This enables the development of scalable applications on Windows NT, and simplifies considerably the design and implementation of applications that use blocking I/O. There are no restrictions on sharing data between threads (other than application-specific synchronization issues). In addition, all Win32 synchronization mechanisms can be used, which enables a non-Smalltalk thread or process to synchronize with a Smalltalk thread. Starting with version 2.5, fibers and asynchronous procedure calls (APC) are also supported."
http://www.objectconnect.com/stmt_overview.htm

"Smalltalk MT provides extensive multithreading capabilities based on the Win32 API. For example, multithreading can be used to spawn several unrelated applications that respond independently to user interaction. An application can create any number of threads, and use Win32 synchronization objects to control their execution. The internal system architecture is reentrant and multiprocessing safe. The automatic memory management runs in a separate thread and preempts garbage collected threads to scan their memory. ... Unlike traditional implementations [of Smalltalk], Smalltalk MT does not have it's own processing model. Instead, a Smalltalk process (we call it a thread) runs always as a native thread. Also there is no restrictions on what can be done in a thread." - Page 172 of the Smalltalk MT manual cira 1995.

I do really like the N (small, medium, large) images in memory at the same time model as it's excellent for things like web application serving and many other applications.

However, fixing the number of native threads to one per image simply limits solutions by forcing a developer/user to split their program across multiple images just so they can run multiple native threads to take advantage of their hardware. I think it not a good thing to impose that upon developers or users, in part because it will often impose a solution refactoring and in part because it only works for a subset of problems that can be easily partitioned across images. A refactoring might be worthwhile but may be cost prohibitive. Also moving all the objects around between images (in one memory space or across memory spaces) involves other problems just as complex as any multi-threading issues solved. So all you've done it punt the ball aways down the field but it's still there... lurking... ready to strike...

Sure it's easier for developing virtual machines, but it has been done (Smalltalk MT) before so why can't it be done again? The only limit seems to be the thinking of those who would need to do the work.

I am a big supporter of using separate images collaborating with each other on the same processor box and across networks with many processing nodes each with one to many images running. However, sometimes it is easier, not to mention cheaper development time wise, to simply fork off M native threads and get the work done in one image maximizing the processors cores on one box.

I and my clients have Smalltalk applications that require M threads per memory image. It's disappointing to me - and my clients - that the main developers behind the squeak smalltalk (and the other commercial smalltalk vendors) seemingly are not interested in moving in the general purpose multi threading direction - which is fine as that's their choice. I think it's a crucial mistake in direction for Smalltalk. I've had clients tell me so and tell me to choose another environment that does support full native multi-threading to take advantage of the huge numbers of cores that are coming.

As for Zoku it is in development. There is no public road map at this time. I have written a number of postings and articles about Zoku, ZokuScript, and ZokuTalk. You can look them up if you wish. Zoku supports M native threads per image (object space) and it can have N images (object spaces) in memory at one time. It also supports multiple independent or connected images (object spaces) on one or more processor boxes. Zoku is not yet ready for commercial work. Thus, my need for Smalltalk.

It seems that there are a number of different approaches to solving concurrency issues and that the current developers working on squeak and commercial smalltalks have chosen the easier path with minimal work to utilize multi-core cpus. That is fine. It's not what I want or many of my clients need but it is fine. It simply puts constraints upon the sets of solutions that can be built with Smalltalk implementations or that will be built.

If the Smalltalk/Squeak/Commercial community doesn't want to move forward to take maximal general purpose advantage of the multi-core cpus that would be a big disappointment indeed. The other languages will leave Smalltalk in their dust. That is what clients are telling me and I happen to agree with them.

I ask the Squeak Smalltalk (and Commerical Smalltalk) virtual machine developers and communities to please reconsider the general purpose many native threads per image solution for the next versions of your virtual machines.

I think it's best to let each developer-user choose how many native threads per image and how many images are loaded and which images are loaded. After all it's their program. Isn't our job as language and systems designers to provide them with the tools that they need to build the systems that they want to build? I think so. What do you think?

All the best,

Peter William Lount
[ | peter at smalltalk dot org ]

Peter William Lount wrote:
> I think it's best to let each developer-user choose how many native
> threads per image and how many images are loaded and which images are
> loaded. After all it's their program. Isn't our job as language and
> systems designers to provide them with the tools that they need to build
> the systems that they want to build? I think so. What do you think?

Everything you say, to the letter, can and has been said about manual
memory management. The point you're apparently not getting is that the
"one native thread per image" is not only a workaround to avoid some
very nasty issues down in the VM, it also provides a clean *model* for
concurrency. No such model exists for shared state concurrency which is
the real problem - since all synchronization is manual, it is pretty
much impossible to write large scalable systems correctly with manual
locks and mutexes. Just as it is impossible to write large scalable
systems correctly with manual memory management.

Cheers,
   - Andreas

--
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/

Hi,

Everything you say, to the letter, can and has been said about manual memory management.

Not in my view.

The point you're apparently not getting is that the "one native thread per image" is not only a workaround to avoid some very nasty issues down in the VM, it also provides a clean *model* for concurrency.

I do get that you guys think that.

No such model exists for shared state concurrency which is the real problem - since all synchronization is manual, it is pretty much impossible to write large scalable systems correctly with manual locks and mutexes. Just as it is impossible to write large scalable systems correctly with manual memory management.

No, it's not impossible as evidenced by many large systems written in C++ and other languages without automatic garbage collection.

Automatic synchronization is a hot field of research.

It's not *that* hard to write a large, scalable, concurrent systems using Processes and Semaphores. Sure, at times it can be difficult with horrible bugs that take a decade to manifest, but if you use consistent patterns and encapsulate complex behaviour well, it is quite tractable.

I concur.

One of my points is that it's one thing to say we simply doing it this one particular way and quite another to assert it can't be done when there is a Smalltalk that has done it (Smalltalk MT).

All the best,

Peter

On Mon, Jul 7, 2008 at 7:09 AM, Michael van der Gulik <[hidden email]> wrote:
>
> It's not *that* hard to write a large, scalable, concurrent systems using
> Processes and Semaphores. Sure, at times it can be difficult with horrible
> bugs that take a decade to manifest, but if you use consistent patterns and
> encapsulate complex behaviour well, it is quite tractable.

This is the second time I've seen you express this opinion.  It is
irrelevant whether *you* think it's easy/tractable/etc. or not.  The
empirical data is in: it's really really hard to do.  And languages
like Erlang show it is entirely too complex for no real gain.

People were (and still are I'm sure) expressing this same thing with
manual memory management.  "Oh, it's not that hard, these guys just
don't use the right technique/are lazy/etc" and it that's just not the
case.  The fact is, with both MM and concurrency, both of these models
ruin composability.  That's the point.

Hi,

Andreas Raab: "The point you're apparently not getting is that the "one
native thread per image" is not only a workaround to avoid some very
nasty issues down in the VM, it also provides a clean *model* for
concurrency."

I get that you think that it's a clean model for concurrency. I don't
buy it though.

Please describe it fully and in detail. Thank you.

You'll allow multiple non-native smalltalk green threads right? If yes,
then it's not solving anything as we know from working on very large
single native threaded deployed Smalltalk systems that have even a
modest number (10 through 25) of threads running at one time.

Your "simplified" model doesn't seem to be simple at all. You'd have to
prevent any green threads within the native thread.

You then push the concurrency processing problems off on to multiple
images and now the problems become data base like concurrency issues and
serialization issues and object identity/version issues.

You've not gained much and you've limited others needs in the process.

You can certainly accomplish your goals with a general purpose N native
threads per image by simply setting an image level configuration
property that would limit the native threads to 1 for that image.

All the best,

Peter William Lount
[ | peter at smalltalk dot org ]

Jason Johnson wrote:

On Mon, Jul 7, 2008 at 7:09 AM, Michael van der Gulik [hidden email] wrote:
  

It's not *that* hard to write a large, scalable, concurrent systems using
Processes and Semaphores. Sure, at times it can be difficult with horrible
bugs that take a decade to manifest, but if you use consistent patterns and
encapsulate complex behaviour well, it is quite tractable.
    

This is the second time I've seen you express this opinion.  It is
irrelevant whether *you* think it's easy/tractable/etc. or not.  The
empirical data is in: it's really really hard to do.  And languages
like Erlang show it is entirely too complex for no real gain.

People were (and still are I'm sure) expressing this same thing with
manual memory management.  "Oh, it's not that hard, these guys just
don't use the right technique/are lazy/etc" and it that's just not the
case.  The fact is, with both MM and concurrency, both of these models
ruin composability.  That's the point.


  

Hi,

Let's drop the flawed analogy with manual memory management shall we. It doesn't map very well at all as an example.

Unless you're claiming some advancement in process concurrency that is similar to garbage collection.

So you're going after an Erlang model? Is that it?

I've seen no cleaner solution presented by any of you. How is it cleaner? Be specific please.

All the best,

Peter William Lount
[ | peter at smalltalk dot org ] value.

On Mon, Jul 7, 2008 at 8:00 AM, Peter William Lount <[hidden email]> wrote:
> Hi,
>
> I get that you think that it's a clean model for concurrency. I don't buy it
> though.
>
> Please describe it fully and in detail. Thank you.

Why does he need to describe this again?  You could look at past
threads or you could look at some of the *actual research on this
subject*.  Here is a paper from 2006:

"The problem with threads"
http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.html

> You'll allow multiple non-native smalltalk green threads right?

I wouldn't.  This is a big source of bugs and confusion.  I would
personally change the ST process model to have "processes" instead of
"threads" (i.e. nothing is shared between them).

> Your "simplified" model doesn't seem to be simple at all. You'd have to
> prevent any green threads within the native thread.
>
> You then push the concurrency processing problems off on to multiple images
> and now the problems become data base like concurrency issues and
> serialization issues and object identity/version issues.
>
> You've not gained much and you've limited others needs in the process.

Here you just seem to be going off on a tangent without even knowing
what solution he had in mind.  Wonderfully productive way to argue.

Hi,

Peter: You'll allow multiple non-native smalltalk green threads right?

Jason Johnson: I wouldn't.  This is a big source of bugs and confusion.  I would
personally change the ST process model to have "processes" instead of
"threads" (i.e. nothing is shared between them).

Ah, ok. Then you are aiming for the elimination of much of the existing Smalltalk process/thread semantics. That's what I am afraid of.

What other changes do you plan?



Peter: Your "simplified" model doesn't seem to be simple at all. You'd have to
prevent any green threads within the native thread.

Peter: You then push the concurrency processing problems off on to multiple images
and now the problems become data base like concurrency issues and
serialization issues and object identity/version issues.

Peter: You've not gained much and you've limited others needs in the process.


Jason Johnson: Here you just seem to be going off on a tangent without even knowing
what solution he had in mind.  Wonderfully productive way to argue.

No need to get snarky Jason. It is a fine way to get across my points. You obviously read something into it that wasn't intended. If you don't like my writing style don't answer the posts, but there isn't any need to criticize me for it Sir Jason.

Jason Johnson: Why does he need to describe this again?

Heck if you have a simple process concurrency model that you'll be sending our way then it should be easy to describe it fully and in detail, don't you think?

You're planning on fundamental changes to smalltalk/squeak and I think it's very reasonable for a squeak user to ask what those changes are going to be and how they will work and how they will impact existing Smalltalk programs that make use of concurrency. Isn't that fair?

To make it simpler maybe someone has a web page on it?

All the best,

Peter William Lount
[ | peter at smalltalk dot org ] value.

I'm a lot more interested in architectures that scale well on both multi-core machines and across blade servers, data centers and clouds than in multi-threaded architectures that may (or may not) scale on a single address space.   A multi-threaded image comes up short here when compared to Erlang-like approaches.

-david

David Pennell wrote:
> I'm a lot more interested in architectures that scale well on both
> multi-core machines and across blade servers, data centers and clouds
> than in multi-threaded architectures that may (or may not) scale on a
> single address space.   A multi-threaded image comes up short here
> when compared to Erlang-like approaches.
>
> -david

Hi,

I'm also interested in such scaling.

There is nothing that says that a native multi-threaded image couldn't
scale just like erlang. Just set native threads to 1 and smalltalk
threads to 1.

Why prevent others from having their needed multiple native threads?

All the best,

Peter William Lount
[ | peter at smalltalk dot org ] value.

Peter William Lount wrote:
>
> Why prevent others from having their needed multiple native threads?
>

It's not about preventing anything. If you have a proposal for how to do
multiple threads per image I will most definitely listen, and if it is a
reasonable proposal (i.e., one that can be implemented with bounded
resources) I will even try to find funding for it. However, until such a
time that there is a proposal I will drop this pointless discussion
since, simply put, there is nothing to discuss here. The only available
path at this point is by using one native thread per image and
consequently that's what's going to happen.

Cheers,
   - Andreas

2008/7/7 Andreas Raab <[hidden email]>:
I have some ideas of using Island/Vat model in future CorruptVM project.

I'm not going into deep detail right now, but the essence of model is following:

- an Island is the group of objects sharing same memory region.
Objects in island can communicate without need in synchronization.
- a Process is the state of computation running in some island.
Islands can have many processes, but only one of them can be active at
single point of time.
- a native thread treated by system as system resource, and scheduler
doing its job to distribute the available resources among islands.

> Cheers,
>  - Andreas
>
>



--
Best regards,
Igor Stasenko AKA sig.

On Mon, 07 Jul 2008 10:49:06 +0200, Igor Stasenko wrote:

s/memory region/owner/ where owner can be sort of "deputy" of memory/VM  
monitor. A very interesting concept indeed, thanks for posting :)

I think that can be addressed with a small trick in Squeak's VM and *no*  
extra object header (using one of the Metaclass ideas that Alex+my  
discussed in Bern for Goya => coloring of metaclass instances).

2008/7/7 Klaus D. Witzel <[hidden email]>:
Yes, there is no need in having extra state which indicates to which
island belongs object.
It is impossible by design to get direct reference to any object which
not belongs to same island.
For referencing objects from different island there will be a FarRef,
which will be responsible for handling message sends to object in
different island.


--
Best regards,
Igor Stasenko AKA sig.

[sorry for cutting multiple Re's from the subject line]

On Mon, 07 Jul 2008 13:11:05 +0200, Igor Stasenko wrote:

I think that, "ref to any object" can be restricted to "any receiver",  
just so when sending something. When not sending something (=> when just  
peeking and poking oops) then belonging to some island is of not so much  
importance (this "receiver detail" is why I suggested s/memory  
region/owner/).

You agree? Of course the "any receiver" detail is relative to SqueakVM;  
CorruptVM's mileage may vary.

> For referencing objects from different island there will be a FarRef,
> which will be responsible for handling message sends to object in
> different island.

Hah :) a natural extension of the #doesNotUnderstand: concept (with  
FarMessageSend a subclass of MessageSend :)

>