<div dir="ltr"><div>As usual, you give me much to ponder.  For some reason it pleases that the world is not too concerned with what we happen to like.</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">But it's not true to what is *there*, and if you program for that model, you're going to get terrible performance.</blockquote></div><div><br></div><div>I heard recently of a type system that captures the complexity of functions in their signatures.  With that information available to the machine, perhaps the machine could be equipped with a way to plan an execution such that performance is optimised.</div><div><br></div><div>Your day with the HPC system sounds fascinating.  Do you think that an Ada/Occam-like approach to partitioned distribution could tame the sort address space that you encountered on the day?</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Any programming model that relies on large flat shared address spaces is out; message passing that copies stuff is going to be much easier to manage than passing a pointer to memory that might be powered off when you need it</blockquote><div><br></div><div>But there'll still be some call for shared memory?  Or maybe only for persistence stores?</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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?</blockquote></div><div><br></div>Ultimately only proof can verify safety.  (I'm trying to address something like that in my rewrite, which given the high quality of feedback from this list, I hope to post soon.)<div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 31 October 2016 at 04:07, Richard A. O'Keefe <span dir="ltr"><<a href="mailto:ok@cs.otago.ac.nz" target="_blank">ok@cs.otago.ac.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 31/10/16 5:44 AM, Rik Howard wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
thanks for the reply.  Conceptually I like the idea of a single address<br>
space, it can then be a matter of configuration as to whether what<br>
you're addressing is another local process, processor or something more<br>
remote.<br>
</blockquote>
<br></span>
The world doesn't care what you or I happen to like.<br>
I completely agree in *liking* a single address space.<br>
But it's not true to what is *there*, and if you program for that<br>
model, you're going to get terrible performance.<br>
<br>
I've just been attending a 1-day introduction to our national HPC<br>
system.  There are two clusters.  One has about 3,300 cores and<br>
the other over 6,000.  One is POWER+AIX, the other Intel+Linux.<br>
One has Xeon Phis (amongst other things), the other does not.<br>
Hint: neither of them has a single address space, and while we<br>
know about software distributed memory (indeed, one of the people<br>
here has published innovative research in that area), it is *not*<br>
like a single address space and is not notably easy to use.<br>
<br>
It's possible to "tame" single address space.  When you start to<br>
learn Ada, you *think* you're dealing with a single address space<br>
language, until you learn about partitioning programs for<br>
distributed execution.  For that matter, Occam has the same<br>
property (which is one of the reasons why Occam didn't have<br>
pointers, so that it would be *logically* a matter of indifference<br>
whether two concurrent processors were on the same chip or not).<br>
<br>
But even when communication is disguised as memory accessing,<br>
it's still communication, it still *costs* like communication,<br>
and if you want high performance, you had better *measure* it<br>
as communication.<br>
<br>
One of the presenters was working with a million lines of Fortran,<br>
almost all of it written by other people.  How do we make that safe?<br>
<br>
</blockquote></div><br></div>