Has Intel implemented erlang IPC in a chip?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Has Intel implemented erlang IPC in a chip?

Richard Andrews-5
http://www.pcper.com/article.php?aid=825

I found the parallels between this chip's message passing system and
the erlang inter-process messaging interesting. In some ways it's a
validation of the core ideas in erlang about how to scale for truly
concurrent operations - eg. share nothing, pass messages.

How well do you think erlang would run on this architecture?

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

Reply | Threaded
Open this post in threaded view
|

http://en.wikipedia.org/wiki/Intel_iAPX_432#Multitasking_and_interprocess_communication

Michael Turner-7

Intel architecture per core, with (unstated but necessarily) limited
memory per core, and no cache coherence . . . well, this just leaves me
asking: Why bother with Intel architecture per core?  All it gets you is
binary compatibility with apps written for Intel CPUs, and just about
everything already written for Intel CPUs requires a large virtual
address space these days.

Just about any RISC architecture would probably consume less area and
power per core.  ARM cores, for example, would make a lot more sense.
Not likely to see that from Intel, though.

Intel's Justin Rattner (the CTO quoted in the article) and message
passing architectures actually have some shared history.  Under his
direction, Intel R&D probably implemented something like Erlang
messaging in silicon as far back as 1981:

http://en.wikipedia.org/wiki/Intel_iAPX_432#Multitasking_and_interprocess_communication

But not just message passing and h/w support for concurrency and
parallelism, but on-chip object-orientation and garbage collection as
well.

These people know how to do everything, and they have known how for a
long time.  But once you get them started, they just don't know where
to stop.

-michael turner

On 12/2/2009, "Richard Andrews" <[hidden email]> wrote:

>http://www.pcper.com/article.php?aid=825
>
>I found the parallels between this chip's message passing system and
>the erlang inter-process messaging interesting. In some ways it's a
>validation of the core ideas in erlang about how to scale for truly
>concurrent operations - eg. share nothing, pass messages.
>
>How well do you think erlang would run on this architecture?
>
>________________________________________________________________
>erlang-questions mailing list. See http://www.erlang.org/faq.html
>erlang-questions (at) erlang.org
>
>

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

Reply | Threaded
Open this post in threaded view
|

Re: http://en.wikipedia.org/wiki/Intel_iAPX_432#Multitasking_and_interprocess_communication

Martin Scholl-4
Michael Turner wrote:
> Intel architecture per core, with (unstated but necessarily) limited
> memory per core, and no cache coherence . . . well, this just leaves me
> asking: Why bother with Intel architecture per core?  All it gets you is
> binary compatibility with apps written for Intel CPUs, and just about
> everything already written for Intel CPUs requires a large virtual
> address space these days.
Actually, there is a an operating system written to handle this:
Barrelfish[0].
Why does this arch have no cache coherent shared memory? In [1] you will
find arguments why a low-level rpc / message passing system actually
outperforms shared-memory based communication given a sufficient large
number of cores / dies / cpus.

>
> Just about any RISC architecture would probably consume less area and
> power per core.  ARM cores, for example, would make a lot more sense.
> Not likely to see that from Intel, though.
True. But ARM is getting traction in large-scale deployment. E.g. Dell
has an offering based on low-cost low-power ARM-based "microslice" servers.


Martin

[0] http://barrelfish.org/
[1] http://barrelfish.org/barrelfish_sosp09.pdf

________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org

Reply | Threaded
Open this post in threaded view
|

Re: http://en.wikipedia.org/wiki/Intel_iAPX_432#Multitasking_and_interprocess_communication

Michael Richter
In reply to this post by Michael Turner-7
2009/12/3 Michael Turner <[hidden email]>

> Just about any RISC architecture would probably consume less area and
> power per core.  ARM cores, for example, would make a lot more sense.
> Not likely to see that from Intel, though.
>

Intel wasn't always x86-only... <http://en.wikipedia.org/wiki/XScale>
Reply | Threaded
Open this post in threaded view
|

Re: http://en.wikipedia.org/wiki/Intel_iAPX_432#Multitasking_and_interprocess_communication

Michael Turner-7


On 12/4/2009, "Michael Richter" <[hidden email]> wrote:

>2009/12/3 Michael Turner <[hidden email]>
>
>> Just about any RISC architecture would probably consume less area and
>> power per core.  ARM cores, for example, would make a lot more sense.
>> Not likely to see that from Intel, though.
>>
>
>Intel wasn't always x86-only... <http://en.wikipedia.org/wiki/XScale>

Which kind of proves my point: they got a line of ARM-based IP from a
lawsuit settlement with DEC, only to dump that line later, on Marvell.
Admittedly, before that, they had their i860/960 RISC processors, even
their own workstations that used them.  But I never got the impression
they were very serious about RISC on the product side.  They didn't
have to be, really.  Intel has deep pockets, they learn a lot about
competitive threats (and new markets within them) simply by emulating
industry trends in-house.  Even if they lost money on the i860 and the
workstation they cobbled together around it, they probably learned
something very valuable: how to make money in the market for support
chips for engineering workstations.  In any market-based view of the
matter, however, anything RISCy is risky -- mainly, cannibalistic -- for
Intel.

I think Erlang is more likely to have an impact sometime soon in
massive-multicore apps IF it can become popular as some sort of
higher-level control language for specialized processor arrays, such as
the kind suggested here (in another response to the Intel announcement):

  Researchers rethink approaches to computer vision
  http://tinyurl.com/yaybfj9

Not just in the lab, either.  For apps with a (relatively) fixed process
structure, Erlang programs might, with modifications, be mapped onto
systems like the picoArray

  http://www.picochip.com/page/42/multi-core-dsp-architecture%20

Note that typical applications for picoArrays (cellular basestations) are
also conveniently adjacent to the telecom equipment where Erlang earned
its spurs industrially.

-michael turner


________________________________________________________________
erlang-questions mailing list. See http://www.erlang.org/faq.html
erlang-questions (at) erlang.org