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
> 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
> 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:
> >>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.
B. Estrade <estr...@gmail.com>