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

> [sorry for cutting multiple Re's from the subject line]
>
> On Mon, 07 Jul 2008 13:11:05 +0200, Igor Stasenko wrote:
>
>> 2008/7/7 Klaus D. Witzel:
>>>
>>> On Mon, 07 Jul 2008 10:49:06 +0200, Igor Stasenko wrote:
>>>
>>>> 2008/7/7 Andreas Raab :
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>> 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.
>>>
>>> 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).
>>>
>>
>> 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.
>
> 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.
>

> [snip]
>
> 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...
>
> [snip]
>
> 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 ]
>

>>>>> 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.
>>>>
>>>> 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).
>>>>
>>>
>>> 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.
>>
>> 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.
>>
> of course, a difference lies only in a way how we sending message to
> object, wrapped by FarRef.

> since you free to change a message
> sending semantics for FarRef.
> In this way, FarRef will act as transparent proxy, and ALL messages to
> it will lead to sending message to wrapped object which is located in
> different island.
>
> A FarRef could reserve a special selector for itself, like
> #performLocal: selector withArguments: args
> to send message to a FarRef object, not to wrapped object.
>

> On Mon, 07 Jul 2008 14:38:21 +0200, Igor Stasenko wrote:
>
>> 2008/7/7 Klaus D. Witzel:
>>> [sorry for cutting multiple Re's from the subject line]
>>>
>>> On Mon, 07 Jul 2008 13:11:05 +0200, Igor Stasenko wrote:
> [...]
>>>>>> 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.
>>>>>
>>>>> 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).
>>>>>
>>>>
>>>> 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.
>>>
>>> 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.
>>>
>> of course, a difference lies only in a way how we sending message to
>> object, wrapped by FarRef.
>
> I think that the main difference we have here is induced by your "it  
> is impossible by design to get direct reference to any object which  
> not belongs to same island." which I take literally (without  
> objection, to be clear). As a consequence, when running "in island  
> #1" you cannot do
>
> proxy := anIsland2Object asFarRef.

>>>> 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 :)
>>>
>> Nah!
>> You don't need to use DNU pattern,
>
> See above, not having sort of DNU can easily contradict your "it is  
> impossible by design to get direct reference to any object which not  
> belongs to same island". Somehow every *failure* to *not* get a  
> direct reference must be detected and acted upon (note the negations).
>

> ---------------
>
> If you like we can go into more detail in email (also addressing  
> #new instances and their belonging to an owner).
>
>> since you free to change a message
>> sending semantics for FarRef.
>> In this way, FarRef will act as transparent proxy, and ALL messages  
>> to
>> it will lead to sending message to wrapped object which is located in
>> different island.
>>
>> A FarRef could reserve a special selector for itself, like
>> #performLocal: selector withArguments: args
>> to send message to a FarRef object, not to wrapped object.
>>
>
>

> On Jul 7, 2008, at 7:07 AM, Klaus D. Witzel wrote:
>
>> On Mon, 07 Jul 2008 14:38:21 +0200, Igor Stasenko wrote:
>>
>>> 2008/7/7 Klaus D. Witzel:
>>>> [sorry for cutting multiple Re's from the subject line]
>>>>
>>>> On Mon, 07 Jul 2008 13:11:05 +0200, Igor Stasenko wrote:
>> [...]
>>>>>>> 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.
>>>>>>
>>>>>> 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).
>>>>>>
>>>>>
>>>>> 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.
>>>>
>>>> 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.
>>>>
>>> of course, a difference lies only in a way how we sending message to
>>> object, wrapped by FarRef.
>>
>> I think that the main difference we have here is induced by your "it is  
>> impossible by design to get direct reference to any object which not  
>> belongs to same island." which I take literally (without objection, to  
>> be clear). As a consequence, when running "in island #1" you cannot do
>>
>> proxy := anIsland2Object asFarRef.
>
> Of course not... you can't have a direct-ref to anIsland2Object in the  
> first place.
>
>> instead you must do
>>
>> proxy := FarRef with: anIsland2Object.
>>
>
> Nope, can't do that either (for the same reason).
>
> To create an island in the first place, you evaluate
>
> anIsland := Island new.
>
> This doesn't give you a direct-ref to the island; it gives you a far-ref  
> to it.
>
> You can instantiate a new object on the island by sending #new: to the  
> island.
>
> aMorph := anIsland new: Morph.
>
> Of course, this gives you a far-ref to the newly created morph.  If you  
> send messages to this object, the answered object is also wrapped (for  
> most objects anyway; some types of objects are copied).
>
> subMorph := anIsland new: EllipseMorph.
> aMorph addMorph: subMorph.
> subMorph owner.              "a FarRef to aMorph"
> aMorph submorphs.         "an Array of FarRefs to Morphs"
> aMorph position.                "a Point (a copy of the on-island  
> Point)"
>
>
>> and moreover [on a sideline, not so important] one cannot ask to which  
>> island *any* far (but as-yet-not-wrapped) object belongs.
>>
>
> Every process is associated with an island, so any unwrapped object is  
> associated with the island of the currently running process.
>
>> Therefore I thought that sending something to a far (but as-yet-not-
>> wrapped) object is like a DNU which the VM detects and automatically  
>> wraps into a FarMessageSend.
>
> In terms of Tweak and Croquet, Tweak FarRefs do work by using DNU.  
> Croquet TFarRefs require an explicit #future message to be sent to a  
> far-ref.  For example, the above would look something like (neglecting  
> how to connect to a Croquet router):
>
> anIsland := TIsland new.
> aMorph := anIsland future new: Morph.
> subMorph := anIsland future new: EllipseMorph.
> aMorph future addMorph: subMorph.
> subMorph future owner.              "a FarRef to aMorph"
> aMorph future submorphs.         "an Array of FarRefs to Morphs"
> aMorph future position.                "a Point (a copy of the on-
> island Point)"
>
> The original implementation had #future return a proxy object.  In the  
> current implementation, #future is a keyword that is handled specially  
> by the Compiler.  It's a bit more verbose, but on the other hand, all  
> #future messages to a TFarRef result in network traffic, so being  
> explicit makes it easier to keep track of what is going over the wire.
>
>> I think this is quite a difference to systems which would be based on  
>> manually wrapping (developer-driven-wrapping DDW), in which the  
>> impossibly to obtain a direct reference would be left to the developer  
>> (and/or her/his bugs).
>
> Yes, definitely.  If it is easy to cheat, then developers will cheat.
>
>>>>> 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 :)
>>>>
>>> Nah!
>>> You don't need to use DNU pattern,
>>
>> See above, not having sort of DNU can easily contradict your "it is  
>> impossible by design to get direct reference to any object which not  
>> belongs to same island". Somehow every *failure* to *not* get a direct  
>> reference must be detected and acted upon (note the negations).
>>
>
> As described above, DNU is one way (but not the only way) to do this.
>
> Cheers,
> Josh
>
>
>> ---------------
>>
>> If you like we can go into more detail in email (also addressing #new  
>> instances and their belonging to an owner).
>>
>>> since you free to change a message
>>> sending semantics for FarRef.
>>> In this way, FarRef will act as transparent proxy, and ALL messages to
>>> it will lead to sending message to wrapped object which is located in
>>> different island.
>>>
>>> A FarRef could reserve a special selector for itself, like
>>> #performLocal: selector withArguments: args
>>> to send message to a FarRef object, not to wrapped object.
>>>
>>
>>
>
>
>

> It seems that there is a general assumption that threads will remain the
> unit of computational parallelism.  After attending Apple's WWDC and seeing
> some of the stuff in Snow Leopard, I don't believe this assumption is
> correct.
> Simply saying smalltalk threads must map to system threads is short sighted
> I think.  There are new models in the pipe that bear looking at.
> "Snow Leopard delivers unrivaled support for multi-core processors with a
> new technology code-named "Grand Central," making it easy for developers to
> create programs that take full advantage of the power of multi-core Macs.
> Snow Leopard further extends support for modern hardware with Open Computing
> Language (OpenCL), which lets any application tap into the vast gigaflops of
> GPU computing power previously available only to graphics applications.
> OpenCL is based on the C programming language and has been proposed as an
> open standard."
> Apple press release.  The unit of computation is not pthreads.  There is
> recognition that threads only get you so far and it is looking like it isn't
> far enough.

> I think there's a major game change afoot and it is too early to make bets.
> On Jul 6, 2008, at 8:45 PM, Peter William Lount wrote:
>
> 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?
>
>
>
>
>

>
>
> If I were working on a concurrent VM, I'd just barge ahead and parallelise
> the Squeak VM:
>
> * I'd refactor the VM so that multiple copies of the interpreter state could
> be held in the heap. I'd design it so that each pthread would run one
> instance of the standard Squeak interpreter, and so that each interpreter
> runs multiple green theads as it does now. This makes forking a very cheap
> operation and allows for having as many green threads as would fit in
> memory.
> * I'd then see what needs fixing in the VM / plug-ins / image to make it
> work. I'd probably start with the simple approach: an evil but simple global
> VM lock for memory writing operations, and no changes to GC. Later, we can
> revisit this to make it scale better.
> * I'd then spend the next decade finding and fixing concurrency bugs.
>

> What I'm actually going to do is:
>
> * Modify the Squeak schedular to simulate concurrency better and bring up
> lots of concurrency bugs in the image.
> * Spend a decade fixing concurrency bugs in the image.
> * Write enough concurrent code to make it worth having a concurrent VM.
> * Sell that code, make a lot of money.
> * Buy the rights to Gemstone or some other high-performance, concurrent VM.
> * Port my code to that instead.
> * Make a lot more money.
>

> 2008/7/8 David P Harris <[hidden email]>:
>> Klaus D. Witzel wrote:
>>>
>>> The main principle, which I based on Igor's "islands for CorruptVM"
>>> suggestion (island term can be confusing to people when used with  
>>> this new
>>> MT stuff, must find alternate word), is this:
>>
>> island --> continent --> planet --> solar system --> galaxy -->  
>> universe ?
>> (Spanish: isla --> continente --> planeta --> Sistema Solar -->  
>> galaxia -->
>> universo)
>> (French: île --> ; continent --> ; planète --> ; système solaire  
>> --> galaxie
>> --> ; univers)
>> (German: Insel --> Kontinent --> Planet --> Sonnensystem -->  
>> Galaxie -->
>> Universum)
>> (Greek: νησί --> ήπειρος --> πλανήτης -->  
>> ηλιακό σύστημα --> γαλαξίας-->
>> κόσμος,
>> (in roman alphabet: nesi --> epeiros --> plantes --> eliako systema  
>> -->
>> galasias --> kosmos (take this with a large grain of salt!)
>>
>> pints --> quarts --> gallons -> barrels ?
>>
>> David
>
> Its not confusing to those, who ever heard about Croquet. And island
> is very precise word in terms of parallel computing:
> Islands are isolated from each other. To travel from one island to
> another you need to cross the water.
>