hardware support for Actors - comp.arch

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion hardware support for Actors
Path: l9ni5618pbj.0!nntp.google.com!news1.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 21 Jun 2012 23:30:25 -0500
Message-ID: <4FE3F4DC.7030409@SPAM.comp-arch.net>
Date: Thu, 21 Jun 2012 21:30:20 -0700
From: "Andy (Super) Glew" <a...@SPAM.comp-arch.net>
Reply-To: a...@SPAM.comp-arch.net
Organization: comp-arch.net
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120604 Thunderbird/13.0
MIME-Version: 1.0
Newsgroups: comp.arch
Subject: Re: hardware support for Actors
References: <jrqq8g$gg$1@dont-email.me> <0d92af59-d350-40ee-8480-daf4e6e46a6d@googlegroups.com>
In-Reply-To: <0d92af59-d350-40ee-8480-daf4e6e46a6d@googlegroups.com>
Lines: 111
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 6/21/2012 4:34 PM, MitchAlsup wrote:
> On Tuesday, June 19, 2012 4:17:06 PM UTC-5, Stephen Fuld wrote:
>> I recently read the book Seven Languages in Seven Weeks.  In the, they
>> make the point several times that the actor model is superior to the
>> shared memory model for multi-threaded applications.
>>
>> In recent threads in this group, we have discussed hardware support for
>> the primitives required for shared memory multi=threading.  So the
>> question arises, is there something that could reasonably be done to
>> improve support for actor model programs.
>>
>> I know that in the mid 1980s, Elixsi had a system with hardware
>> (actually microcode) instructions for message passing.  Would something
>> like that make sense now?  Could it, with appropriate software support,
>> make actor model programs more prevalent and reduce the issues related
>> to shared memory programs.
>>
>> I expect that Actor models are not a panacea, but they do seem an
>> improvement.  Is the improvement enough that with some HW support, they
>> could help things considerably?
>
> I have been giving some though to bringing back some support for base-and-bounds on-top-of paging (or first-byte/last-byte on-top-of paging) to enable
> smaller than page-sixed messages, or just messages on odd boundaries in the paging tables.
>
> {You would have a limit of (say) 128 of these things at a time (and Your Own Memory Space would have to consue a few.)}
>
> What this means is that the virtual address would have to pass a base-and-bounds check before the address is translated through the page tables. Thus on could in theory, pass a 2 byte message starting on the last byte of one page and ending on the first byte of a second page. The receriver of said message would have access to both bytes of both pages, but no other bytes of either page. The OS/HyperVisor would be involved with setting up the paging parst of the message passing.
>
> With 64-bit virtual addressses, and conventional 4KB pages, and 4KB page tables, you get 7 high order address bits that could be used to address a 4 DoubleWord container. In this container would be a root pointer, a base bit pattern, a limit bit pattern, and a DW of other stuff to make the message efficient. So, in essence, you get 128 messages of (essentially) unbounded size, and a 57-bit virtual address space for each message. {Tricks are used to make the paging table overheads "reasonable".}
>
> Mitch


This is morphing from the IMHO excessively specific "hardware support 
for Actors" to the more general "hardware support for message passing".

I think Mitch is in the world of designing efficient message passing 
support in a shared memory system - where processors that are on 
separate address spaces in a shared memory system can pass messages 
efficiently, by arranging

a) for pages to be remapped from one process into the other

or possibly

b) having such processes be SAS, Single Address Space, sharing addresses
but not necessarily having access to each others pages.  I.e. pages 
mapped, but not p;ermitted.

Using the fine grain base+bounds protection to allow access to specific 
parts of pages not otherwise allowed, parts passed by messages between 
processes.

---

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)

b) On non-shared memory but tightly bound systems, to interface these to
"channels" that match to the network switches' message passing

c) On loosely bound systems, to interface these to channels that talk 
TCP/IP networking - ideally without OS intervantion, apart from the 
initial setting up of the channel, assuming you have TOE (TCP/IP Offload 
Engines).
     Or at least to have an efficient way of putting stuff into OS 
networking queues without system calls, only invoking the OS if it needs 
to be woken up.

d) On shared memory systems, to use

d.1) efficient shared virtual memory if suitable

d.1a) passing pointers if the addresses are already shared

d.1b) remapping pages - in hardware/microcode, without or with minimal 
OS intervention, if not already shared.

d.2) copying, in hardware or microcode, if virtual memory tricks are not 
usable - e.g. if not page sized and aligned, and that is required.

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.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
