<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">AFAICT, it seems like what you’re suggesting to build isn’t a good fit for C++. I maybe be wrong.<div class=""><br class=""></div><div class="">If you think it should in fact be how C++ evolves, you should take your proposal to the C++ standards committee. To do so, you really need to dig into the references folks have sent and integrate them into your thinking, which you seem on track to do. I also suggest having some believable implementation, because that type of idea basically doesn’t see the light of day without someone committing to implementing it.<br class=""><div><br class=""></div><div>If you think it’s a new language you’re creating, do you think LLVM has the right model for what you’re trying to do? Again, it seems like implementation experience would help figure that out.</div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 27, 2018, at 5:12 PM, Edward Givelberg via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="">Bruce, Jeff, Bryce,</div><div class=""><br class=""></div><div class="">I am just a user of C++ and am not familiar with all the work that goes into language development and standardization, so this is certainly interesting to me.</div><div class="">Perhaps due to my being an outsider, and unaware of all the difficulties,</div><div class="">my proposal is radical.</div><div class="">It is not about extending C++, but redefining it at its core.</div><div class="">The only definition of an object that I found in the standard is "a region of storage".</div><div class="">Perhaps there is a better definition somewhere. I'd be interested to read it.</div><div class="">I am proposing that an object is a virtual machine.</div><div class="">When I talk about a remote pointer, it is not just another pointer into some memory.</div><div class="">It is a way to access a virtual machine. I don't know what the architecture will look like,</div><div class="">and I don't know what is memory and where is it.<br class=""></div><div class="">If I may be so rude, I propose to get rid of the C++ memory model and the C++ abstract machine enitirely. I did not know about the existence of SG1, the C++ subcommittee for concurrency and parallelism. An object-oriented language (like C++) is conceptually inherently parallel, and it is bizarre that for several decades it has been a sequential language. SG1 should not even exist, or it should be the committee for the whole of C++ language.<br class=""></div><div class=""><br class=""></div><div class="">I have sketched a trivial abstract model of object-oriented computation in my paper. It does not mention memory and it does not mention network. It doesn't even mention a processor. I propose it as a starting point for a more detailed and workable model.</div><div class="">I wrote in my paper that</div><div class="">"We perceive the world primarily as a world of objects,<br class="">a world where a multitude of objects interact simultaneously.<br class="">From the programmer's point of view <br class="">interactions between objects are meaningful and memorable,<br class="">unlike interactions of processes exchanging messages."</div><div class="">The fact that C++ is a sequential language is kinda perverse!<br class=""></div><div class=""><br class=""></div><div class="">To summarize, I am not proposing a mechanism, a language extension, a library, a tool, a framework or a paradigm. I am proposing to redefine the existing language.</div><div class="">I know it sounds completely crazy and impractical, but I believe that continuing to build on the current base is not going to work. The hardware can only go in the direction of parallelism. There is a need to build desktops with thousands, or millions, of processors, and the obstacle is programmability. The sequential framework of C++ won't work, and adding threads, language extensions, libraries, tools is futile.</div><div class=""><br class=""></div><div class="">The reason that I so presumptuously named my paper as a solution to the problem of parallel programming is that while my proposal is radical, I also think that a fairly smooth and gradual transition is possible from sequential C++ to parallel C++. Parallel interepretation will break a lot of code, but a lot of code can be translated to a parallel interpretation automatically, or with a relatively small programming effort. Moreover, I have shown in my paper that you can run your sequential code on parallel hardware without breaking it, and since the hardware will be more energy efficient, you will be able to run your code at a lower cost.<br class=""></div><div class=""><br class=""></div><div class="">Bryce, thanks for the pointers. I am looking over them.</div><div class="">Again, thanks to everybody for their remarks. The topic is too complex for one man, and this input has helped me tremendously already.<br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Tue, Nov 27, 2018 at 6:36 PM Bryce Adelstein Lelbach aka wash <<a href="mailto:brycelelbach@gmail.com" target="_blank" class="">brycelelbach@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> I propose to introduce remote pointers into C++. I am very surprised nobody thought of this before.<br class="">
<br class="">
0.) People have thought of this before. The earliest work I know of<br class="">
was published in 1993.<br class="">
1.) People have proposed this before.*<br class="">
<br class="">
I read your paper this afternoon. I think your paper needs to explain<br class="">
how it differentiates itself from the plethora of related work in this<br class="">
problem space.<br class="">
<br class="">
SG1, the C++ subcommittee for concurrency and parallelism, has decided<br class="">
to not pursue "inaccessible memory" (e.g. remote memory) at this time;<br class="">
we'd like to tackle affinity, memory access, and heterogeneous memory<br class="">
first. This decision was made via a straw poll at the 2017 Toronto<br class="">
committee meeting:<br class="">
<br class="">
Straw poll: In the near term, ignore inaccessible memory except for<br class="">
cross-process sharing on the same device.<br class="">
SF F N A SA<br class="">
7 7 5 2 1<br class="">
<br class="">
Before any work can be done on extending C++ to support diverse memory<br class="">
kinds, we must first explore how the C++ memory model and abstract<br class="">
machine will be impacted - what breaks, what needs to be extended,<br class="">
etc. We still don't have a proposal for that. I would welcome an<br class="">
SG1-targeted paper on that subject matter.<br class="">
<br class="">
*: I don't have a full list of prior proposals in this space, but<br class="">
here's some material to get you started:<br class="">
<br class="">
<a href="https://wg21.link/P0009" rel="noreferrer" target="_blank" class="">https://wg21.link/P0009</a><br class="">
<a href="https://wg21.link/P0234" rel="noreferrer" target="_blank" class="">https://wg21.link/P0234</a><br class="">
<a href="https://wg21.link/P0367" rel="noreferrer" target="_blank" class="">https://wg21.link/P0367</a><br class="">
<a href="https://wg21.link/P0567" rel="noreferrer" target="_blank" class="">https://wg21.link/P0567</a><br class="">
<a href="https://wg21.link/P0687" rel="noreferrer" target="_blank" class="">https://wg21.link/P0687</a><br class="">
<a href="https://wg21.link/P0796" rel="noreferrer" target="_blank" class="">https://wg21.link/P0796</a><br class="">
<a href="https://wg21.link/P1026" rel="noreferrer" target="_blank" class="">https://wg21.link/P1026</a><br class="">
<a href="http://www.nersc.gov/assets/Uploads/IJHPCA-paper.pdf" rel="noreferrer" target="_blank" class="">http://www.nersc.gov/assets/Uploads/IJHPCA-paper.pdf</a><br class="">
<a href="http://stellar.cct.lsu.edu/pubs/pgas14.pdf" rel="noreferrer" target="_blank" class="">http://stellar.cct.lsu.edu/pubs/pgas14.pdf</a><br class="">
<a href="http://charm.cs.illinois.edu/newPapers/93-02/paper.pdf" rel="noreferrer" target="_blank" class="">http://charm.cs.illinois.edu/newPapers/93-02/paper.pdf</a><br class="">
On Tue, Nov 27, 2018 at 8:14 AM Edward Givelberg via cfe-dev<br class="">
<<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class="">
><br class="">
> Jeff,<br class="">
> Multi-core CPUs and all the associated software technologies (shared memory, threads, etc) are a technological dead end.<br class="">
> I argue more than that: all software technologies that use processes<br class="">
> are dead on arrival. This includes the technologies you mention in<br class="">
> your presentation<br class="">
> <a href="https://www.ixpug.org/images/docs/KAUST_Workshop_2018/IXPUG_Invited2_Hammond.pdf" rel="noreferrer" target="_blank" class="">https://www.ixpug.org/images/docs/KAUST_Workshop_2018/IXPUG_Invited2_Hammond.pdf</a><br class="">
> People got used to processes over decades, so when they talk about parallelism they immediately talk about processes, but this is the root of the problem. I propose object-level parallelism. An object is more than a process. It is a virtual machine.<br class="">
><br class="">
> I propose to introduce remote pointers into C++. I am very surprised nobody thought of this before. I'd be curious to know how much work<br class="">
> people think this would be to do it in LLVM. I know it may be possible to introduce something like remote_ptr, but I don't think it is a good idea.<br class="">
><br class="">
> I am also proposing a new way of executing code, which I call causal asynchronous execution. I'd like to know if people find it natural to write code like this.<br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
><br class="">
> On Mon, Nov 26, 2018 at 10:26 PM Jeff Hammond <<a href="mailto:jeff.science@gmail.com" target="_blank" class="">jeff.science@gmail.com</a>> wrote:<br class="">
>><br class="">
>> I’ll probably have more detailed comments later but the related work you may wish to consider includes:<br class="">
>> - UPC and Berkeley UPC++<br class="">
>> - Charm++<br class="">
>> - HPX from LSU<br class="">
>> - DASH (<a href="http://www.dash-project.org/" rel="noreferrer" target="_blank" class="">http://www.dash-project.org/</a>)<br class="">
>> - MADNESS (<a href="https://arxiv.org/abs/1507.01888" rel="noreferrer" target="_blank" class="">https://arxiv.org/abs/1507.01888</a>)<br class="">
>><br class="">
>> There are quite a few dead parallel C++ dialects from the last millennium but it’s probably not worth your time to find and read about them.<br class="">
>><br class="">
>> I’m very glad that you used MPI as your communication runtime. This will save you lots of pain.<br class="">
>><br class="">
>> Jeff<br class="">
>><br class="">
>> On Mon, Nov 26, 2018 at 2:57 PM Edward Givelberg via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>> wrote:<br class="">
>>><br class="">
>>><br class="">
>>> Chris Lattner suggested that I post to this mailing list.<br class="">
>>><br class="">
>>> I used Clang/LLVM to build a prototype for parallel<br class="">
>>> interpretation of C++. It's based on the idea that C++<br class="">
>>> objects can be constructed remotely, and accessed via<br class="">
>>> remote pointers, without changing the C++ syntax.<br class="">
>>> I am a mathematician, not an expert on compilers.<br class="">
>>> I am proposing changes to the C++ standard and to the<br class="">
>>> compiler architecture, so I'm very interested to hear from<br class="">
>>> experts.<br class="">
>>> My paper is<br class="">
>>> <a href="https://arxiv.org/abs/1811.09303" rel="noreferrer" target="_blank" class="">https://arxiv.org/abs/1811.09303</a><br class="">
>>> Best regards,<br class="">
>>> Ed<br class="">
>>><br class="">
>>> -----------------------------------------------------------------<br class="">
>>> A solution to the problem of parallel programming<br class="">
>>> E. Givelberg<br class="">
>>><br class="">
>>> The problem of parallel programming is the most important<br class="">
>>> open problem of computer engineering.<br class="">
>>> We show that object-oriented languages, such as C++,<br class="">
>>> can be interpreted as parallel programming languages,<br class="">
>>> and standard sequential programs can be parallelized automatically.<br class="">
>>> Parallel C++ code is typically more than ten times shorter than<br class="">
>>> the equivalent C++ code with MPI.<br class="">
>>> The large reduction in the number of lines of code in parallel C++<br class="">
>>> is primarily due to the fact that communications instructions,<br class="">
>>> including packing and unpacking of messages, are automatically<br class="">
>>> generated in the implementation of object operations.<br class="">
>>> We believe that implementation and standardization of parallel<br class="">
>>> object-oriented languages will drastically reduce the cost of<br class="">
>>> parallel programming.<br class="">
>>> his work provides the foundation for building a new computer<br class="">
>>> architecture, the multiprocessor computer, including<br class="">
>>> an object-oriented operating system and more energy-efficient,<br class="">
>>> and easily programmable, parallel hardware architecture.<br class="">
>>> The key software component of this architecture is a compiler<br class="">
>>> for object-oriented languages. We describe a novel compiler<br class="">
>>> architecture with a dedicated back end for the interconnect fabric,<br class="">
>>> making the network a part of a multiprocessor computer,<br class="">
>>> rather than a collection of pipes between processor nodes.<br class="">
>>> Such a compiler exposes the network hardware features<br class="">
>>> to the application, analyzes its network utilization, optimizes the<br class="">
>>> application as a whole, and generates the code for the<br class="">
>>> interconnect fabric and for the processors.<br class="">
>>> Since the information technology sector's electric power consumption<br class="">
>>> is very high, and rising rapidly, implementation and widespread<br class="">
>>> adoption of multiprocessor computer architecture<br class="">
>>> will significantly reduce the world's energy consumption.<br class="">
>>> _______________________________________________<br class="">
>>> cfe-dev mailing list<br class="">
>>> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class="">
>>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">
>><br class="">
>> --<br class="">
>> Jeff Hammond<br class="">
>> <a href="mailto:jeff.science@gmail.com" target="_blank" class="">jeff.science@gmail.com</a><br class="">
>> <a href="http://jeffhammond.github.io/" rel="noreferrer" target="_blank" class="">http://jeffhammond.github.io/</a><br class="">
><br class="">
> _______________________________________________<br class="">
> cfe-dev mailing list<br class="">
> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a><br class="">
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="">
<br class="">
<br class="">
<br class="">
-- <br class="">
Bryce Adelstein Lelbach aka wash<br class="">
ISO C++ Committee Member<br class="">
HPX and Thrust Developer<br class="">
CUDA Convert and Reformed AVX Junkie<br class="">
--<br class="">
</blockquote></div>
_______________________________________________<br class="">cfe-dev mailing list<br class=""><a href="mailto:cfe-dev@lists.llvm.org" class="">cfe-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev<br class=""></div></blockquote></div><br class=""></div></body></html>