[cfe-dev] parallel C++

Tue Nov 27 09:55:53 PST 2018

Ø  Could you please provide me with a reference to causal asynchronous execution?

https://en.wikipedia.org/wiki/Futures_and_promises

-Troy

From: Edward Givelberg <ed.givelberg at gmail.com>
Sent: Tuesday, November 27, 2018 11:41 AM
To: Troy Johnson <troyj at cray.com>
Cc: jeff.science at gmail.com; cfe-dev at lists.llvm.org
Subject: Re: [cfe-dev] parallel C++

Troy,

"Multi-core CPUs are a dead end" is not a sensationalist statement. Multi-core CUs are limited to about a dozen cores. Nobody knows how to program CPUs with 1000 cores.
Some "religious" people may actually like to program with threads, but there are at least 20 million programmers who use OO programming. How many of them enjoy threads or MPI?
Not to mention PGAS....

About remote pointers: my question is specifically why can't we write
Object * some_object = new Object(a, b, c, d);
in C++ where some_object is not an ordinary pointer, but a remote pointer?
It is possible to implement this without breaking existing code.

Could you please provide me with a reference to causal asynchronous execution?
I think you may very well be right about it, but I searched and I did not find anything like this.
It seems to me logical that someone thought about it before me, but I'd like to see and read the work.

On Tue, Nov 27, 2018 at 12:17 PM Troy Johnson <troyj at cray.com<mailto:troyj at cray.com>> wrote:

>  Multi-core CPUs and all the associated software technologies (shared memory, threads, etc) are a technological dead end.

Wow.

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

They have and this is why Jeff pointed you to a variety of related work that is not cited in the paper.  Just as one example, UPC has the concept of a pointer to shared data that may exist with another thread on another node.  Two recent attempts at a PGAS model for C++ (UPC++ and Coarray C++) have similar concepts.

>  I am also proposing a new way of executing code, which I call causal asynchronous execution.

Again, that’s also not new.  There are a lot of existing concepts in your paper, which isn’t by itself bad – perhaps you are combining them all together in some nice new way – but please don’t represent the component ideas as brand new.

>  The object-oriented computing framework provides the foundation for a new computer architecture, which we call a multiprocessor computer. [From the linked paper]

That really *really* needs a new name.  ☺

-Troy

From: cfe-dev <cfe-dev-bounces at lists.llvm.org<mailto:cfe-dev-bounces at lists.llvm.org>> On Behalf Of Edward Givelberg via cfe-dev
Sent: Tuesday, November 27, 2018 10:14 AM
To: jeff.science at gmail.com<mailto:jeff.science at gmail.com>
Cc: cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>
Subject: Re: [cfe-dev] parallel C++

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<mailto: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<mailto: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<mailto:cfe-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
--
Jeff Hammond
jeff.science at gmail.com<mailto:jeff.science at gmail.com>
http://jeffhammond.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181127/13774aa0/attachment.html>