www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Intel Single-chip Cluster

reply 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
May 13 2010
next sibling parent reply 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
May 13 2010
parent reply 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
May 13 2010
parent reply 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.
May 13 2010
parent reply 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! :)
May 13 2010
parent reply 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
May 13 2010
parent reply 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
May 15 2010
parent reply 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.
May 16 2010
parent 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.

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 ?
May 17 2010
prev sibling parent reply 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-

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.
May 13 2010
parent reply 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
May 13 2010
parent 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
May 13 2010