Received: by 10.68.190.104 with SMTP id gp8mr15696287pbc.4.1340690325737;
        Mon, 25 Jun 2012 22:58:45 -0700 (PDT)
Path: l9ni20918pbj.0!nntp.google.com!news1.google.com!goblin2!goblin.stu.neva.ru!aioe.org!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail
From: Stephen Fuld <SF...@alumni.cmu.edu.invalid>
Newsgroups: comp.arch
Subject: Re: hardware support for Actors
Date: Mon, 25 Jun 2012 22:58:44 -0700
Organization: A noiseless patient Spider
Lines: 79
Message-ID: <jsbj2k$5s8$1@dont-email.me>
References: <jrqq8g$gg$1@dont-email.me> <0d92af59-d350-40ee-8480-daf4e6e46a6d@googlegroups.com> <4FE3F4DC.7030409@SPAM.comp-arch.net>
Reply-To: SF...@Alumni.cmu.edu.invalid
Mime-Version: 1.0
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
In-Reply-To: <4FE3F4DC.7030409@SPAM.comp-arch.net>
Cancel-Lock: sha1:Aga4BxP6+bfRtsFzyjJh/s2dqcc=
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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:

snip


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

snip

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

snip

> 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 
scalable applications.



-- 
  - Stephen Fuld
(e-mail address disguised to prevent spam)