llvm dev - Apr 2010 - [LLVMdev] Proposal for a new LLVM concurrency memory model

On 27 April 2010 19:16, David Greene <dag at cray.com>
wrote:
> IMHO, LLVM is the wrong
> place to deal with these.  It should be done at a higher level.
> It _can_ be done at the LLVM IR level, but much less conveniently.
Now I agree with you, completely. ;)

It is important, it is the future, but it is in the library/language
definition space that the solution will be more elegant.

Like functional languages, HPF, openMPI, Scala having intrinsic
message passing or openMP constructs, the compiler has much more
freedom to guess and do the right thing (tm).


cheers,
--renato

http://systemcall.org/

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

On Tuesday 27 April 2010 13:56:05 Renato Golin wrote:
> On 27 April 2010 19:16, David Greene <dag at cray.com> wrote:
> > IMHO, LLVM is the wrong
> > place to deal with these.  It should be done at a higher level.
> > It _can_ be done at the LLVM IR level, but much less conveniently.
>
> Now I agree with you, completely. ;)
I suspect not.  :)  I still mean within the compiler, just at a higher
level program abstraction; a higher-level IR.

Concurrent languages can help, but history shows that it's tough to
get them accepted.  HPF is a four-letter word here.  ;)  Now CAF,
on the other hand...

Maybe this trend will change with the new silicon constraints, but I'm 
skeptical.  We'll be programming in C, C++ and Fortran for a long time.

The compiler is going to have to find parallelism and the user is
going to have to help with directives.

                            -Dave

On 27 April 2010 20:00, David Greene <dag at cray.com>
wrote:
> Maybe this trend will change with the new silicon constraints, but I'm
> skeptical.  We'll be programming in C, C++ and Fortran for a long time.
That I don't deny...

> The compiler is going to have to find parallelism and the user is
> going to have to help with directives.
But that is taking a bit too long... I reckon we're going to see
Haskell in production before that... ;)


cheers,
--renato

http://systemcall.org/

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

On Tue, Apr 27, 2010 at 12:00 PM, David Greene <dag at cray.com>
wrote:
> On Tuesday 27 April 2010 13:56:05 Renato Golin wrote:
>> On 27 April 2010 19:16, David Greene <dag at cray.com> wrote:
>> > IMHO, LLVM is the wrong
>> > place to deal with these.  It should be done at a higher level.
>> > It _can_ be done at the LLVM IR level, but much less conveniently.
>>
>> Now I agree with you, completely. ;)
>
> I suspect not.  :)  I still mean within the compiler, just at a higher
> level program abstraction; a higher-level IR.
>
> Concurrent languages can help, but history shows that it's tough to
> get them accepted.  HPF is a four-letter word here.  ;)  Now CAF,
> on the other hand...
>
> Maybe this trend will change with the new silicon constraints, but I'm
> skeptical.  We'll be programming in C, C++ and Fortran for a long time.
>
> The compiler is going to have to find parallelism and the user is
> going to have to help with directives.
I think we're diverging from the memory model now... David, I think
you're happy with the current proposal to define atomics as
non-tearing even for vector operands (acknowledging that the backend
may fail to codegen operands that are too big)? Did I miss any other
suggestions you made?

Thanks,
Jeffrey