• bearophile (14/14) May 13 2010 Found this through Reddit, it's a short article, but it's to the point:
• Andrei Alexandrescu (3/27) May 13 2010 Mmmm... message passing.
• Nick B (4/4) May 13 2010 Can any one give a short update as to what has been happening/decided
• Jason House (3/8) May 13 2010 Buy Andrei's book ;)
• Nick B (3/14) May 13 2010 Perhaps Andrei can us an update? Its cheaper than buying his book!
• Andrei Alexandrescu (9/31) May 13 2010 I think the concurrency model is in good shape. We went with message
• Nick B (4/10) May 15 2010 Andrei - thanks for this update.
• Sean Kelly (2/10) May 16 2010 The implementation is complete but for compile-time restrictions on what...
• Nick B (4/15) May 17 2010 Sean - Thanks for th info.
• retard (7/12) May 13 2010 paper.pdf
• bearophile (4/6) May 13 2010 No it doesn't, it means that each core is a true computer with its own O...
• Andrei Alexandrescu (4/13) May 13 2010 Isolation FTW. Man it looks we've placed the right bet for D's

bearophile <bearophileHUGS lycos.com> writes:

Found this through Reddit, it's a short article, but it's to the point:
http://www.linux-mag.com/id/7762

Inside that article there is a link to a little paper:
http://techresearch.intel.com/UserFiles/en-us/File/terascale/ISSCC-paper.pdf

Probably future true commercial Intel CPUs will be different from this one, and
they can be less extreme (for example they can be hybrid, with few fast cores
for single threaded code too), but this CPU shows a trend that can't be ignored.

It contains 24 dual cores, each core has 256 KB of L2 cache (10 clocks latency)
that is rather small, plus the usual 16+16 L1. This CPU prototype is at 1 GHz.

Each core is in-order, as the Atom CPU, instead of being out-of-order like a
Core Duo. This saves a very large number of transistors and energy power, but
forces the usage of refined compilers that are able to perform a good
instruction scheduling. Otherwise performance are awful (as on Atom). I think
currently compilers like LLVM for static languages are better at instruction
scheduling that the Java HotSpot. But a fitter HotSpot can be designed (or they
have already designed it, I don't know how well Java runs on Atom CPUs today).

Each pair of cores also has 16 KB of memory used for message passing among
pairs of cores. Plus there are connections to external memory. I don't exactly
know how L2 cache is managed, but each of 48 cores run a single Linux, because
there is no global cache coherence. I don't know about its RAM coherence or how
it manages the RAM. I don't know if the RAM is shared.

The memory used for message passing is managed with a lent/unique strategy,
there is only an owner of a datum.

This CPU looks perfect for the Chapel language, that natively supports the idea
of CPU local data plus very refined ways to share it. D design is nowhere this
good on such things. But as I have said this is mostly a prototype, so future
commercial Intel CPUs can be less extreme.

I think higher level languages that use a lot message passing as Erlang too can
be adapted to run quite well on this CPU.

The future will be interesting.

Bye,
bearophile

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

bearophile wrote:
 Found this through Reddit, it's a short article, but it's to the point:
 http://www.linux-mag.com/id/7762
 
 Inside that article there is a link to a little paper:
 http://techresearch.intel.com/UserFiles/en-us/File/terascale/ISSCC-paper.pdf
 
 Probably future true commercial Intel CPUs will be different from this one,
and they can be less extreme (for example they can be hybrid, with few fast
cores for single threaded code too), but this CPU shows a trend that can't be
ignored.
 
 It contains 24 dual cores, each core has 256 KB of L2 cache (10 clocks
latency) that is rather small, plus the usual 16+16 L1. This CPU prototype is
at 1 GHz.
 
 Each core is in-order, as the Atom CPU, instead of being out-of-order like a
Core Duo. This saves a very large number of transistors and energy power, but
forces the usage of refined compilers that are able to perform a good
instruction scheduling. Otherwise performance are awful (as on Atom). I think
currently compilers like LLVM for static languages are better at instruction
scheduling that the Java HotSpot. But a fitter HotSpot can be designed (or they
have already designed it, I don't know how well Java runs on Atom CPUs today).
 
 Each pair of cores also has 16 KB of memory used for message passing among
pairs of cores. Plus there are connections to external memory. I don't exactly
know how L2 cache is managed, but each of 48 cores run a single Linux, because
there is no global cache coherence. I don't know about its RAM coherence or how
it manages the RAM. I don't know if the RAM is shared.
 
 The memory used for message passing is managed with a lent/unique strategy,
there is only an owner of a datum.
 
 This CPU looks perfect for the Chapel language, that natively supports the
idea of CPU local data plus very refined ways to share it. D design is nowhere
this good on such things. But as I have said this is mostly a prototype, so
future commercial Intel CPUs can be less extreme.
 
 I think higher level languages that use a lot message passing as Erlang too
can be adapted to run quite well on this CPU.
 
 The future will be interesting.
 
 Bye,
 bearophile

Mmmm... message passing.

Andrei

Nick B <"nick_NOSPAM_.barbalich" gmail.com> writes:

Can any one give a short update as to what has been happening/decided 
on the concurrency front lately, especially in regards to D  2.0

regards
Nick B

Jason House <jason.james.house gmail.com> writes:

Nick B <nick_NOSPAM_.barbalich gmail.com> Wrote:

 Can any one give a short update as to what has been happening/decided 
 on the concurrency front lately, especially in regards to D  2.0
 
 regards
 Nick B

Buy Andrei's book ;)

I have the impression that the language spec escaped more or less unscathed.
That's based mostly on early dmd-concurrency discussion and the lack of
compiler updates in that area. I had expected Andrei's book would use a new
message passing API, but I haven't seen anything completed in that area. It may
be in druntime and I simply didn't notice. At a minimum, there were no breaking
changes (do far) that effect my multi-threaded D2 code.

Nick B <"nick_NOSPAM_.barbalich" gmail.com> writes:

Jason House wrote:
 Nick B <nick_NOSPAM_.barbalich gmail.com> Wrote:
 
 Can any one give a short update as to what has been happening/decided 
 on the concurrency front lately, especially in regards to D  2.0

 regards
 Nick B

 
 Buy Andrei's book ;)
 
 I have the impression that the language spec escaped more or less unscathed.
That's based mostly on early dmd-concurrency discussion and the lack of
compiler updates in that area. I had expected Andrei's book would use a new
message passing API, but I haven't seen anything completed in that area. It may
be in druntime and I simply didn't notice. At a minimum, there were no breaking
changes (do far) that effect my multi-threaded D2 code.

Perhaps Andrei can us an update? Its cheaper than buying his book!

:)

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

Nick B wrote:
 Jason House wrote:
 Nick B <nick_NOSPAM_.barbalich gmail.com> Wrote:

 Can any one give a short update as to what has been happening/decided 
 on the concurrency front lately, especially in regards to D  2.0

 regards
 Nick B

 Buy Andrei's book ;)

 I have the impression that the language spec escaped more or less 
 unscathed. That's based mostly on early dmd-concurrency discussion and 
 the lack of compiler updates in that area. I had expected Andrei's 
 book would use a new message passing API, but I haven't seen anything 
 completed in that area. It may be in druntime and I simply didn't 
 notice. At a minimum, there were no breaking changes (do far) that 
 effect my multi-threaded D2 code.

 
 Perhaps Andrei can us an update? Its cheaper than buying his book!
 
 :)

I think the concurrency model is in good shape. We went with message 
passing as the flagship and very limited sharing by use of the shared 
keyword. The prototype implementation is here:

http://www.dsource.org/projects/phobos/browser/trunk/phobos/std/concurrency.d

Sean is the author of it, so he can provide the details. My 
understanding is that it is a complete or near-complete implementation 
of the artifacts described in the book.


Andrei

Nick B <"nick_NOSPAM_.barbalich" gmail.com> writes:

Andrei Alexandrescu wrote:

 Sean is the author of it, so he can provide the details. My 
 understanding is that it is a complete or near-complete implementation 
 of the artifacts described in the book.
 
 
 Andrei

Andrei - thanks for this update.
Sean - are you able to add any details ?

Nick B

Sean Kelly <sean invisibleduck.org> writes:

Nick B <nick_NOSPAM_.barbalich gmail.com> Wrote:

 Andrei Alexandrescu wrote:
 
 Sean is the author of it, so he can provide the details. My 
 understanding is that it is a complete or near-complete implementation 
 of the artifacts described in the book.

 
 Andrei - thanks for this update.
 Sean - are you able to add any details ?

The implementation is complete but for compile-time restrictions on what can be
passed and the message list size constraints.  Looks like I missed adding it to
the doc generation.

Nick B <"nick_NOSPAM_.barbalich" gmail.com> writes:

Sean Kelly wrote:
 Nick B <nick_NOSPAM_.barbalich gmail.com> Wrote:
 
 Andrei Alexandrescu wrote:

 Sean is the author of it, so he can provide the details. My 
 understanding is that it is a complete or near-complete implementation 
 of the artifacts described in the book.

 Andrei - thanks for this update.
 Sean - are you able to add any details ?

 
 The implementation is complete but for compile-time restrictions on what can
be passed and the message list size constraints.  Looks like I missed adding it
to the doc generation.

Sean - Thanks for th info.

One quick question. I assume that this concurrency can be used by Tango, 
or is it Phobos only ?

retard <re tard.com.invalid> writes:

Thu, 13 May 2010 16:31:06 -0400, bearophile wrote:

 Found this through Reddit, it's a short article, but it's to the point:
 http://www.linux-mag.com/id/7762
 
 Inside that article there is a link to a little paper:
 http://techresearch.intel.com/UserFiles/en-us/File/terascale/ISSCC-

paper.pdf

The paper says "All 48 IA-cores boot Linux simultaneously."

Does this mean that all cores represent a virtual computer and have their 
own operating system? I understand this in the message passing context, 
but it seems rather radical compared to GPUs, multicore x86 and other 
contemporary systems.

bearophile <bearophileHUGS lycos.com> writes:

retard:

 Does this mean that all cores represent a virtual computer and have their 
 own operating system?

No it doesn't, it means that each core is a true computer with its own OS :-)

Bye,
bearophile

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

bearophile wrote:
 retard:
 
 Does this mean that all cores represent a virtual computer and have their 
 own operating system?

 
 No it doesn't, it means that each core is a true computer with its own OS :-)
 
 Bye,
 bearophile

Isolation FTW. Man it looks we've placed the right bet for D's 
concurrency. I'm so happy I can't stand myself.

Andrei