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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
68 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Proposal for CroquetMT [was: Prepare for Thousands of Cores --- oh my Chip - it's full of cores!]

Joshua Gargus-2

On Jul 8, 2008, at 11:14 PM, Joshua Gargus wrote:

> On Jul 8, 2008, at 5:56 PM, Igor Stasenko wrote:
>
>> 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.
>>
>
> I think that Klaus is saying (forgive me if I'm wrong) that "Island"  
> is confusing because it already has meaning in Tweak and Croquet.  
> However, I think that the meaning is the same (leaving aside  
> Croquet's notion of replicaion), so there's no need for a new term.  
> I also like the term for the same reason that you do (much better  
> than E's "vat").

Sorry to reply to myself, but an analogy came to me...

Both Java and Squeak have the concept of "Object" and we don't need a  
different word for each (in fact, that would be more confusing).  They  
both mean basically the same thing, even if Squeak objects are  
better ;-)  Similarly, we should use "Island" to refer to variations  
of the same concept.  If it becomes necessary to disambiguate, it's  
easy to refer to a particular instantiation ("CorruptVM Islands") or  
refinement ("replicated Islands") of the concept.

Cheers,
Josh


>
>
> Cheers,
> Josh
>
>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
>


Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: Proposal for CroquetMT [was: Prepare for Thousands of Cores --- oh my Chip - it's full of cores!]

Klaus D. Witzel
In reply to this post by Igor Stasenko
On Wed, 09 Jul 2008 02:56:26 +0200, Igor Stasenko wrote:

> 2008/7/8 David P Harris :
>> 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!)
>>

Hey David, nice list, thanks for the initiative :)

>> 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.

Like peninsulae are :)

> To travel from one island to
> another you need to cross the water.

Then I make this choice (integrating David's first two columns)

- the main .image is mainland (like continent)
- the other .images are peninsula (like island)

because oops in peninsula can point to mainland but not so cross-peninsula.

And the island concept is still part of peninsula, at the message send  
level (the travelling "teleporting" part ;)

>


Reply | Threaded
Open this post in threaded view
|

[squeak-dev] Re: Proposal for CroquetMT [was: Prepare for Thousands of Cores --- oh my Chip - it's full of cores!]

Klaus D. Witzel
In reply to this post by Joshua Gargus-2
On Wed, 09 Jul 2008 08:14:48 +0200, wrote:

> On Jul 8, 2008, at 5:56 PM, Igor Stasenko wrote:
>
>> 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 ?
...

>>>
>>> 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.
>>
>
> I think that Klaus is saying (forgive me if I'm wrong) that "Island" is  
> confusing because it already has meaning in Tweak and Croquet.

Yes, and I hope that suggested mainland and peninsula stress the  
similitarity as well as the difference.

> However, I think that the meaning is the same (leaving aside Croquet's  
> notion of replicaion), so there's no need for a new term.  I also like  
> the term for the same reason that you do (much better than E's "vat").

Hehe, I know many people who don't like to pay their vat ;)

> Cheers,
> Josh
>
>
>> --Best regards,
>> Igor Stasenko AKA sig.
>>
>
>
>



Reply | Threaded
Open this post in threaded view
|

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

Jason Johnson-5
In reply to this post by tblanchard
On Mon, Jul 7, 2008 at 10:15 PM, Todd Blanchard <[hidden email]> wrote:

> 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.

+1

Reply | Threaded
Open this post in threaded view
|

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

Jason Johnson-5
In reply to this post by Igor Stasenko
On Mon, Jul 7, 2008 at 10:43 PM, Igor Stasenko <[hidden email]> wrote:
>
> We may call it thread or fiber or string, no matter what, but at base
> we having a sequence of operations which should be performed in an
> order, defined by programmer (which also known as algorithm).
> Its about human's nature and perception: we separate the concept of
> time onto three categories: past, present and future.
> So, i think the concept of 'threads' will likely to stay until last
> human lives on planet :)

Different actions occurring in parallel?  Of course.  Shared state
threading with it's "ground changing under your feet" characteristics?
 No, I don't think there is anything that can relate to this in our
daily lives, which is one reason people have such a hard time
conceptualizing it and programming with it.

We deal with parallel every day and contention as well; it can be that
I bring a box of widgets to a work area to use, go to get the box of
tools I need and when I come back my widgets are gone because someone
else picked them up.  But what can't happen is I'm drawing a circular
widget but I actually end up drawing a square with one round side
because when I began to draw my brain was put in stasis and another
consciousness took over and began drawing a square without my
knowledge.

Reply | Threaded
Open this post in threaded view
|

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

Jason Johnson-5
In reply to this post by Michael van der Gulik-2
On Tue, Jul 8, 2008 at 12:57 AM, Michael van der Gulik
<[hidden email]> wrote:
>
> 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.

Yes, this is exactly the design I would propose for today (I think the
pthreads will have to go away entirely when we get more cores), and
it's the one Erlang uses as well.  In fact I believe Andreas and Igor
said this is what Hydra does too.

Reply | Threaded
Open this post in threaded view
|

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

Jason Johnson-5
In reply to this post by K. K. Subramaniam
On Tue, Jul 8, 2008 at 7:24 AM, K. K. Subramaniam <[hidden email]> wrote:

> On Tuesday 08 Jul 2008 3:26:14 am Igor Stasenko wrote:
>> It is good to see that they finally trying to use GPUs as generic
>> purpose processing units. But it has own limitations, like inability
>> to run different code in its 2^n working units. So it is more press
>> release than real breakthrough :)
> The discussions on this thread are on the lines of theatre artists discussing
> how to get a movie camera to record stage plays. It ignores a whole new class
> of story-telling possibilities opened up by a such a technology.
>
> A 1000-core commodity computing board is not going to be like a quad-core
> board with 1000 cores instead of 4. It will probably be a hypercube network
> of communicating cores. Nodes are not only "local" or "remote" but can also
> be 'neighbors'. Imagine how you could implement Kedama natively on such
> boards. Instead of having a single-thread VM simulating a world of particles,
> you could create a particle world super VM which would simulate a single-core
> VM as one of its "objects". Keeping a single time references across nodes is
> now easy. This could simplify support for temporal operators.
>
> Imagine!
> Subbu

This is a good point.  I can't imagine the Intel way with the snoopy
bus, write-through cache and so on scaling even to the hundreds, much
less the thousands.  AMD's NUMA is closer, but even that may be a
problem when cores number in the thousands.

Reply | Threaded
Open this post in threaded view
|

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

Klaus D. Witzel
In reply to this post by pwl
Hi Peter & all,

on Sat, 05 Jul 2008 14:27:16 +0200, Peter William Lount wrote:

...
> To take advantage of multi-core what is needed is real native  
> multi-threading per virtual machine + image not simply one native thread  
> per image. Both are good for various application scenarios. Remember  
> that a real multi-native threaded image can always just run one native  
> thread if you want it too while a single native thread virtual machine +  
> image will not run multiple native threads in the same image space. Sure  
> multiple images in one program memory space is nice for some scenarios.  
> I like that too and desire the option to deploy that way with multiple  
> native threads per image space in one program memory space.

What has perhaps been overlooked in this looong thread is, that you can  
give real multiple "native/OS" (posix) threads in the same image a try  
today, with a system that is based on Squeak and its Exupery,

- http://www.google.com/search?q=Huemul+Smalltalk+pthread+Squeak
- http://www.guillermomolina.com.ar/huemul/

Don't forget to read article "Huemul, a Smalltalk implementation" which  
has details about how Huemul was created.

Enjoy!

/Klaus

> All the best,
>
> Peter
>



1234