<div dir="ltr"><div>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. Some assumptions about what can be expected from local resources need to be dropped but I believe that it works in other situations. Your point about not wanting to have to rewrite when the underlying platform evolves seems relevant. Perhaps that suggests that a language, while needing to be aware of its environment, oughtn't to shape itself entirely for that environment. While we're on the subject of rewrites, that is the fate of the WIP. I was wrong.<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 28 October 2016 at 01:38, 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 28/10/16 8:41 AM, Rik Howard wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Any novelty in the note would only ever be in the way that the mix is<br>
provided. You raise salient points about the sort of challenges that<br>
languages will need to confront although a search has left me still<br>
unsure about PGPUs. Can I ask you to say a bit more about programming<br>
styles: what Java can't do, what others can do, how that scales?<br>
</blockquote>
<br></span>
The fundamental issue is that Java is very much an imperative language<br>
(although books on concurrent programming in Java tend to strongly<br>
recommending immutable data structures whenever practical, because they<br>
are safer to share).<br>
<br>
The basic computational model of (even concurrent) imperative languages<br>
is the RAM: there is a set of threads living in a single address space<br>
where all memory is equally and as easily accessible to all threads.<br>
<br>
Already that's not true. One of the machines sitting on my desk is a<br>
Parallela: 2 ARM cores, 16 RISC cores, there's a single address space<br>
shared by the RISC cores but each of them "owns" a chunk of it and<br>
access is not uniform. Getting information between the ARM cores and<br>
the RISC cores is not trivial. Indeed, one programming model for the<br>
Parallela is OpenCL 1.1, although as they note,<br>
"Creating an API for architectures not even considered during the creation of a standard is challenging. This can be seen in the case of Epiphany, which possesses an architecture very different from a GPU, and which supports functionality not yet supported by a GPU. OpenCL as an API for Epiphany is good, but not perfect." The thing is that the<br>
Epiphany chip is more *like* a GPU than it is like anything say Java<br>
might want to run on.<br>
<br>
For that matter, there is the IBM "Cell" processor, basically a Power<br>
core and a bunch of RISCish cores, not entirely unlike the Epiphany.<br>
As the Wikipedia page on the Cell notes, "Cell is widely regarded as a challenging environment for software development".<br>
<br>
Again, Java wants a (1) large (2) flat (3) shared address space, and<br>
that's *not* what Cell delivers. The memory space available to each<br>
"SPE" in a Cell is effectively what would have been L1 cache on a more<br>
conventional machine, and transfers between that and main memory are<br>
non-trivial. So Cell memory is (1) small (2) heterogeneous and (3)<br>
partitioned.<br>
<br>
The Science Data Processor for the Square Kilometre Array is still<br>
being designed. As far as I know, they haven't committed to a CPU<br>
architecture yet, and they probably want to leave that pretty late.<br>
Cell might be a candidate, but I suspect they'll not want to spend<br>
much of their software development budget on a "challenging"<br>
architecture.<br>
<br>
Hmm. Scaling.<br>
<br>
Here's the issue. It looks as though the future of scaling is<br>
*lots* of processors, running *slower* than typical desktops,<br>
with things turned down or off as much as possible, so you won't<br>
be able to pull the Parallela/Epiphany trick of always being able<br>
to access another chip's local memory. Any programming model<br>
that relies on large flat shared address spaces is out; message<br>
passing that copies stuff is going to be much easier to manage<br>
than passing a pointer to memory that might be powered off when<br>
you need it; anything that creates tight coupling between the<br>
execution orders of separate processors is going to be a nightmare.<br>
<br>
We're also looking at more things moving into special-purpose<br>
hardware, in order to reduce power costs. It would be nice to be<br>
able to do this without a complete rewrite...<br>
<br>
Coarray Fortran (in the current standard) is an attempt to deal with<br>
the kinds of machines I'm talking about. Whether it's a good attempt<br>
I couldn't say, I'm still trying to get my head around it. (More<br>
precisely, I think I understand what it's about, but I haven't a<br>
clue about how to *use* the feature effectively.) There are people<br>
at Rice who think it could be better.<br>
<br>
Reverting to the subject of declarative/procedural, I recently came<br>
across Lee Naish's "Pawns" language. Still very much a prototype,<br>
and he is interested in the semantics, not the syntax.<br>
<a href="https://github.com/lee-naish/Pawns" rel="noreferrer" target="_blank">https://github.com/lee-naish/P<wbr>awns</a><br>
<a href="http://people.eng.unimelb.edu.au/lee/papers/pawns/" rel="noreferrer" target="_blank">http://people.eng.unimelb.edu.<wbr>au/lee/papers/pawns/</a><br>
<br>
<br>
<br>
<br>
<br>
</blockquote></div><br></div>