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. >> > > |
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 ;) > |
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. >> > > > |
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 |
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. |
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. |
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. |
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 > |
Free forum by Nabble | Edit this page |