On Fri, May 14, 2010 at 03:48:10PM +0400, Richard Hainsworth wrote: > After reading this thread and S17, I have lots of questions and some > remarks. > > Parallelism and Concurrency could be considered to be two different things. > > The hyperoperators and junctions imply, but do not require, parallelism. > It is left for the implementors to resolve whether a single or multiple > processor(s) is/are used. Hence, parallelism could be considered to be > something under the hood of perl6 and not directly specified. > > Given that: > - concurrency is a topic of ongoing research > - several models of concurrency have been tried, including two in perl5 > - there are a variety of contexts (internet, clouds, multiple cores, etc) > - different operating systems provide different resources > > then: > How much needs to be specified and implemented in perl6 so that > different concurrency models can be implemented in modules to take into > account the above diversity? > > The less, or rather the more abstract, the specification in perl6, the > less likely perl6 will 'age'.
I might be over simplifying this, but you're going to be building on essentially 2 different underlying approaches - one is message passing. The second is threading - I mean *real* threading. If these basic facilities are provided in the base, or even via a couple of robust and tightly integrated modules, then I believe any other scheme one wishes to implement (even a hybrid scheme), could be done so - thus solidifying Perl 6's ability to implement the parallel scheme de jour. Brett > On 05/12/2010 09:12 PM, Dave Whipp wrote: > >Daniel Ruoso wrote: > >>Hi, > >> > >>The threading model topic still needs lots of thinking, so I decided to > >>try out some ideas. > >> > >>Every concurrency model has its advantages and drawbacks, I've been > >>wondering about this ideas for a while now and I think I finally have a > >>sketch. My primary concerns were: > >> > >> 1 - It can't require locking: Locking is just not scalable; > >> 2 - It should perform better with lots of cores even if it suffers > >> when you have only a few; > >> 3 - It shouldn't require complicated memory management techniques > >>that will make it difficult to bind native libraries (yes, STM > >>is damn hard); > >> 4 - It should suport implicit threading and implicit event-based > >> programming (i.e. the feed operator); > >> 5 - It must be easier to use then Perl 5 shared variables; > >> 6 - It can't use a Global Interpreter Lock (that already said in 1, > >> but, as this is a widely accepted idea in some other environments, > >> I thought it would be better to make it explicit). > >> > >>The idea I started was that every object has an "owner" thread, and only > >>that "thread" should talk to it, and I ended up with the following, > >>comments are appreciated: > >> > > > >>comments? ideas? > >> > > > > > >Before discussing the implementation, I think it's worth while stating > >what it is that you are attempting to abstract. For example, is the > >abstraction intended for a mapping down to a GPU (e.g. OpenCL) with a > >hierarchical address space, or is it intended for a multicore CPU with > >linear address space, or is it intended to abstract a LAN, with > >communication via sockets (reliable TCP? unreliable UDP?), or is it > >intended to abstract the internet/cloud? Are you thinking in terms of > >streaming computation where throughput is dominant, or interacting > >agents where latency is the critical metric? > > > >I'm not sure that it makes sense to talk of a single abstraction that > >supports all of those environments. However, there may be bunch of > >abstractions that can be combined in different ways. > > > >"object belongs to thread" can have two interpretations: one is that > >the object-thread binding lasts for the life of the object; the other > >is that a client that wishes to use an object must request ownership, > >and wait to be granted (in some scenarios, the granting of ownership > >would require the thread to migrate to the physical processor that > >owns the state). In many cases, we might find that specific > >object-state must live in specific "places", but not all of the state > >that is encapsulated by an object lives in the same place. > > > >Often, an object will encapsulate state that is, itself, accessed via > >objects. If a model requires delegated access to owned state to be > >passed through an intermediate object then this may imply significant > >overhead. A better way to think about such scenarios may be that a > >client would request access to a subset of methods -- and thus we have > >"role belongs to thread", not "object belongs to thread". One could > >imagine that a FIFO object might have a "put" role and a "get" role > >that producer/consumer clients would (temporarily) own while using > >(note that granting of ownership may imply arbitration, and later > >forced-revocation if the resource-ownership is not released/extended > >before some timeout expires). It may be wrong to conflate "role" as a > >unit of reuse with "role" as an owned window onto a subset of an > >object's methods. > > > >Perl6 has a set of language primitives to support various aspects of > >concurrency. It is indeed interesting to consider how these map ot > >vastly difference computation platforms: OpenCl Vs OpenMP Vs Cloud. It > >deeps a little premature to be defining roles (e.g. RemoteInvocation) > >without defining the mapping of the core operators to these various > >models of computation. > > > > > >Dave. -- B. Estrade <estr...@gmail.com>
