[cfe-dev] parallel C++

[Edward Givelberg via cfe-dev]

Yes, I agree. The new language is what C++ should be, a parallel language,
and in my opinion what it will inevitably become with hardware evolution.


On Wed, Nov 28, 2018 at 6:45 PM Oleg Smolsky <oleg at cohesity.com> wrote:

> Ed, it sounds like you have an idea for a new language with a new
> execution model and a special object representation. I was merely trying to
> point out that these ideas have little to do with what C++ compilers do
> today.
>
> Oleg.
> On 2018-11-28 15:28, Edward Givelberg wrote:
>
> Oleg,
>
> May be I am misunderstanding what you're saying...
> Since I am proposing a different framework for execution,
> the architecture which has an abstract machine
> and a memory model will have to change.
> Since I'd like to have remote objects,
> which are native to C++, unlike the existing objects, which are all local,
> I am proposing this IOR layer. Access to objects will have to change.
> An object access will not longer be a memory access, unless some
> compiler optimization determines that the object is local.
> So this probably means that it requires changes to the LLVM IR?
> As I said, I don't know enough about the current LLVM architecture
> to make a detailed plan, but I think it is an interesting problem.
>
> Ed
>
>
> On Wed, Nov 28, 2018 at 5:42 PM Oleg Smolsky <oleg at cohesity.com> wrote:
>
>> On 2018-11-28 13:14, Edward Givelberg via cfe-dev wrote:
>> >
>> > [...]
>> > Naively, it seems to me that LLVM is a sequential VM, so perhaps its
>> > architecture needs be extended.
>> > I am proposing an intermediate representation which encodes object
>> > operations,
>> > let's call it IOR. IOR is translated to interconnect hardware
>> > instructions, as well as LLVM's IR.
>> > I am proposing a dedicated back end to generate code for the
>> > interconnect fabric.
>>
>> Edward, it sounds to me like you are trying to reinvent Smalltalk. Its
>> core is really about message passing and perhaps people have made
>> attempts to make it parallel already.
>>
>> On a more serious and specific note, I think you are ignoring the
>> "abstract C machine" on which both C and C++ languages are built.
>> Fundamentally, objects are laid out in memory (let's ignore the stack
>> for now) and are built off primitive and user-defined types. These types
>> are known (and stable) throughout the compilation process of a single
>> program and so are the offsets of various fields that comprise the
>> objects. All these objects (and often their sub-objects) can be read and
>> written anywhere in a single-threaded program. Multi-threaded programs
>> must be data-race-free, but essentially follow the same model.
>>
>> The point I am trying to make is that the whole model is built on memory
>> accesses that are eventually lowered to the ISA. There is no rigid
>> protocol for invoking a member function or reading a member variable -
>> things just happen in the program's address space. And then there is
>> code optimizer. The memory accesses (expressed via LLVM IR, for example)
>> go through various techniques that reduce and eliminate pointless
>> work... at which point you have the target's ISA and absolutely no
>> notion of a "method" or "object" (as a well-formed program cannot tell
>> that the code has been re-arranged, reduced, reordered etc).
>>
>> I suggest that you take a look at https://godbolt.org and see what the
>> compiler emits with -O3 for a few short class/function templates as well
>> as normal procedural code.
>>
>> Oleg.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181128/3bc492df/attachment.html>