On 31/10/16 5:44 AM, Rik Howard wrote:
thanks for the reply. Conceptually I like the idea of a single address space, it can then be a matter of configuration as to whether what you're addressing is another local process, processor or something more remote.
The world doesn't care what you or I happen to like. I completely agree in *liking* a single address space. But it's not true to what is *there*, and if you program for that model, you're going to get terrible performance. I've just been attending a 1-day introduction to our national HPC system. There are two clusters. One has about 3,300 cores and the other over 6,000. One is POWER+AIX, the other Intel+Linux. One has Xeon Phis (amongst other things), the other does not. Hint: neither of them has a single address space, and while we know about software distributed memory (indeed, one of the people here has published innovative research in that area), it is *not* like a single address space and is not notably easy to use. It's possible to "tame" single address space. When you start to learn Ada, you *think* you're dealing with a single address space language, until you learn about partitioning programs for distributed execution. For that matter, Occam has the same property (which is one of the reasons why Occam didn't have pointers, so that it would be *logically* a matter of indifference whether two concurrent processors were on the same chip or not). But even when communication is disguised as memory accessing, it's still communication, it still *costs* like communication, and if you want high performance, you had better *measure* it as communication. One of the presenters was working with a million lines of Fortran, almost all of it written by other people. How do we make that safe?