[llvm-dev] [Openmp-dev] [cfe-dev] RFC: Proposing an LLVM subproject for parallelism runtime and support libraries

[Chandler Carruth via llvm-dev]

On Tue, May 10, 2016 at 7:11 PM <cbergstrom at pathscale.com> wrote:

> The words to describe what you're referring to are onload vs offloading.
> It's a very frequent term in networking as well as computation.
>
> Accelerator lib... feels odd
>
> What about computation lib?
>

I don't find that any more clear.


>
> ‎Sorry on phone and can't quote your text, but about math libraries and
> c++ standard..
>
> Math libs *really* need their own home, source repo and project page. Unix
> philosophy, do one thing and do it well.. I'm not a big fan of bucket of
> soup project.
>

I agree with you about the overarching philosophy, but I don't think it
applies well to subprojects of LLVM.

We should have *libraries* that do one thing and do them well. These
libraries can have their own webpage and information, no problem. But
they're all part of LLVM, and I'd like to keep the infrastructure as simple
as possible. I really strongly feel like we should have a common home for
these things that provides an umbrella of infrastructure, and then
dedicated and specific information for the particular components.



> At the target layer depending on it may be nice but not required. This is
> a big and wholly complex problem on its own. Do you write it in CUDA, OCL,
> asm, C.. is it just to provide vector versions of functions or what about
> transcendentals... what about cuFFTW alternative. then we go into accuracy
> vs speed discussions..
>

A lot of this is implementation questions. I think the mechanism of
implementation should be largely based on what Clang and LLVM support well
as that's the specific audience. I don't have strong opinions past that.


> C++-standard... why would this live anywhere except libc++? Should
> filesystem be in compiler-rt instead?
>

I'm not talking about the actual implementation of the C++ standard
library, but the underlying *infrastructure* that is used. That
infrastructure should be shared for lots of parallel programming workflows,
one of which might be libc++'s APIs and others might be any of the other
programmer interfaces here.

As a concrete example, you might want to use stream executor under the hood
to implement some parts of the C++ standard library's parallel extensions.


> ----
> To add more complexity to the conversation.. what about debugging and
> profiling api.. from a tools perspective it should likely be exposed from
> the runtime.
>
> You can call this a 'lib' but will it ever be a runtime?
>

If there are runtime library components to support profiling and debugging,
they should go there if they are parallel specific. We certainly have
generic profiling libraries in compiler-rt.

I guess I'm not seeing the problem here. But I also suspect that we can
cross this bridge when we get there. I'm currently not specifically
interested in these pieces, I've mentioned the specific and concrete use
cases I have in mind.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160511/ab17d78c/attachment.html>