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


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

Reply via email to