[cfe-dev] parallel C++

Tue Nov 27 15:35:32 PST 2018

> I propose to introduce remote pointers into C++. I am very surprised nobody thought of this before.

0.) People have thought of this before. The earliest work I know of
was published in 1993.
1.) People have proposed this before.*

I read your paper this afternoon. I think your paper needs to explain
how it differentiates itself from the plethora of related work in this
problem space.

SG1, the C++ subcommittee for concurrency and parallelism, has decided
to not pursue "inaccessible memory" (e.g. remote memory) at this time;
we'd like to tackle affinity, memory access, and heterogeneous memory
first. This decision was made via a straw poll at the 2017 Toronto
committee meeting:

Straw poll: In the near term, ignore inaccessible memory except for
cross-process sharing on the same device.
SF F N A SA
7 7 5 2 1

Before any work can be done on extending C++ to support diverse memory
kinds, we must first explore how the C++ memory model and abstract
machine will be impacted - what breaks, what needs to be extended,
etc. We still don't have a proposal for that. I would welcome an
SG1-targeted paper on that subject matter.

*: I don't have a full list of prior proposals in this space, but
here's some material to get you started:

https://wg21.link/P0009
https://wg21.link/P0234
https://wg21.link/P0367
https://wg21.link/P0567
https://wg21.link/P0687
https://wg21.link/P0796
https://wg21.link/P1026
http://www.nersc.gov/assets/Uploads/IJHPCA-paper.pdf
http://stellar.cct.lsu.edu/pubs/pgas14.pdf
http://charm.cs.illinois.edu/newPapers/93-02/paper.pdf
On Tue, Nov 27, 2018 at 8:14 AM Edward Givelberg via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
>
> Jeff,
> Multi-core CPUs and all the associated software technologies (shared memory, threads, etc) are a technological dead end.
> I argue more than that: all software technologies that use processes
> are dead on arrival. This includes the technologies you mention in
> your presentation
> https://www.ixpug.org/images/docs/KAUST_Workshop_2018/IXPUG_Invited2_Hammond.pdf
> 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.
>
> 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
> 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.
>
> 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.
>
>
>
>
>
>
>
>
> On Mon, Nov 26, 2018 at 10:26 PM Jeff Hammond <jeff.science at gmail.com> wrote:
>>
>> I’ll probably have more detailed comments later but the related work you may wish to consider includes:
>> - UPC and Berkeley UPC++
>> - Charm++
>> - HPX from LSU
>> - DASH (http://www.dash-project.org/)
>> - MADNESS (https://arxiv.org/abs/1507.01888)
>>
>> 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.
>>
>> I’m very glad that you used MPI as your communication runtime. This will save you lots of pain.
>>
>> Jeff
>>
>> On Mon, Nov 26, 2018 at 2:57 PM Edward Givelberg via cfe-dev <cfe-dev at lists.llvm.org> wrote:
>>>
>>>
>>> Chris Lattner suggested that I post to this mailing list.
>>>
>>> I used Clang/LLVM to build a prototype for parallel
>>> interpretation of C++. It's based on the idea that C++
>>> objects can be constructed remotely, and accessed via
>>> remote pointers, without changing the C++ syntax.
>>> I am a mathematician, not an expert on compilers.
>>> I am proposing changes to the C++ standard and to the
>>> compiler architecture, so I'm very interested to hear from
>>> experts.
>>> My paper is
>>> https://arxiv.org/abs/1811.09303
>>> Best regards,
>>> Ed
>>>
>>> -----------------------------------------------------------------
>>> A solution to the problem of parallel programming
>>> E. Givelberg
>>>
>>> The problem of parallel programming is the most important
>>> open problem of computer engineering.
>>> We show that object-oriented languages, such as C++,
>>> can be interpreted as parallel programming languages,
>>> and standard sequential programs can be parallelized automatically.
>>> Parallel C++ code is typically more than ten times shorter than
>>> the equivalent C++ code with MPI.
>>> The large reduction in the number of lines of code in parallel C++
>>> is primarily due to the fact that communications instructions,
>>> including packing and unpacking of messages, are automatically
>>> generated in the implementation of object operations.
>>> We believe that implementation and standardization of parallel
>>> object-oriented languages will drastically reduce the cost of
>>> parallel programming.
>>> his work provides the foundation for building a new computer
>>> architecture, the multiprocessor computer, including
>>> an object-oriented operating system and more energy-efficient,
>>> and easily programmable, parallel hardware architecture.
>>> The key software component of this architecture is a compiler
>>> for object-oriented languages.  We describe a novel compiler
>>> architecture with a dedicated back end for the interconnect fabric,
>>> making the network a part of a multiprocessor computer,
>>> rather than a collection of pipes between processor nodes.
>>> Such a compiler exposes the network hardware features
>>> to the application, analyzes its network utilization, optimizes the
>>> application as a whole, and generates the code for the
>>> interconnect fabric and for the processors.
>>> Since the information technology sector's electric power consumption
>>> is very high, and rising rapidly, implementation and widespread
>>> adoption of multiprocessor computer architecture
>>> will significantly reduce the world's energy consumption.
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>> --
>> Jeff Hammond
>> jeff.science at gmail.com
>> http://jeffhammond.github.io/
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

-- 
Bryce Adelstein Lelbach aka wash
ISO C++ Committee Member
HPX and Thrust Developer
CUDA Convert and Reformed AVX Junkie
--