[cfe-dev] parallel C++

Tue Nov 27 10:22:42 PST 2018

Thank you. I do know about the futures mechanism though I didn't know that
futures can be implicit. Causal asynchronous execution sounds indeed like
implicit future mechanism.
I will check it out a bit more and I'll reference it accordingly.

There are similar mechanisms in actor-based languages, but I am proposing
to execute
a compound C++ statement in a non-sequential way, with causal asynchronous
execution.
This would certainly break a lot of code, but I am proposing this as a
compiler flag.
There is a lot of code that can be automatically translated from sequential
to causal asynchronous code. There is also a lot of code that can be
translated with not too much human programming effort. And then people
could write new causal asynchronous code,
which will be naturally parallel. I show some extensive examples of such
code. Would be nice to see if people like such code.

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

> Ø  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> 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.  J
>
>
>
> -Troy
>
>
>
> *From:* cfe-dev <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
> *Cc:* 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>
> 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/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181127/59a6594f/attachment.html>