Message from discussion hardware support for Actors
Received: by 10.68.190.104 with SMTP id gp8mr15696287pbc.4.1340690325737;
Mon, 25 Jun 2012 22:58:45 -0700 (PDT)
From: Stephen Fuld <SF...@alumni.cmu.edu.invalid>
Subject: Re: hardware support for Actors
Date: Mon, 25 Jun 2012 22:58:44 -0700
Organization: A noiseless patient Spider
References: <firstname.lastname@example.org> <email@example.com> <4FE3F4DC.7030409@SPAM.comp-arch.net>
Injection-Date: Tue, 26 Jun 2012 05:58:44 +0000 (UTC)
Injection-Info: mx04.eternal-september.org; posting-host="PhzQ7CVP/xQMUpCj8UJOiw";
logging-data="6024"; mail-complaints-to="ab...@eternal-september.org"; posting-account="U2FsdGVkX1+NN9207wm5TDHH7EdDqwFf"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 6/21/2012 9:30 PM, Andy (Super) Glew wrote:
> On 6/21/2012 4:34 PM, MitchAlsup wrote:
>> On Tuesday, June 19, 2012 4:17:06 PM UTC-5, Stephen Fuld wrote:
> This is morphing from the IMHO excessively specific "hardware support
> for Actors" to the more general "hardware support for message passing".
I have no problem with that, as long as it doesn't get so far away that
simple actor models are not easily accommodated.
> I'm okay with this. Indeed, I admit to having spent quite a lot of my
> last decade looking at [lwb,upb) protection, a la Milo Martin et al's
> However: non shared memopry message passing systems are *also* here to
> stay. They are more common than shared memory.
> My agenda, therefore, is
> a) to have message passing instruction set extensions - send/receive
> (and possibly also PGAS-like, MIP 3.x like, put, get, which are just
> shared memory in another form).
> I.e., yes, I propose instructions
> put(channel, regval ) / get( channel, regval )
> put( channel, buf, nbytes ) / get( channel, buf, nbytes )
> + possibly scatter/gather forms,
> and/or RDMA forms
> (and whatever is necessary to match MPI's matching semantics)
I agree that message passing instructions are exactly the kind of thing
I was looking for. But I think it must be more than the instructions.
If you want the solution to be all in hardware, don't you need some
hardware data structures to insure that someone doesn't flood an
unprepared process with a huge number of messages, or that the message
goes into the area the receiver prepared for it, etc.? These may not be
necessary in the simplest case of messages within the multiple threads
of a single program, but beyond that, I think you need something.
> The base+bounds stuff, aka "capabilities" stuff, is cool - but I think
> is only the last stage in optimizing such a system.
> Although it might be the first stage if you are thinking like a startup,
> and not Intel.
Well, I was thinking of Intel. With the future looking like more and
more cores per chip/system, it seem to be to Intel's advantage to do
things that make parallel programming easier/more efficient/more bug
free, etc. I proposed this in the, perhaps mistaken, belief that actor
based programs provided a better way forward and that Intel doing things
to encourage that route would be good for Intel.
The idea is that as a first step, it could provide better HW support for
the existing actor based languages. Since Intel also provides
compilers, A further step would be to provide an option for their C (and
perhaps Fortran) based compilers encourage actor based programs by
supporting send/receive directly and at the same time, make it harder
(at least with warnings, perhaps compile time errors) to do the things
in C that would hurt increased parallelism. This would allow people to
leverage their C skills, and parts of existing programs to develop more
- Stephen Fuld
(e-mail address disguised to prevent spam)