Clamp Q&A

[Ruben Van Boxem]

As whchung said, there's no direct communication channel, so abusing the bug tracking system as he suggested is what we'll do.

I liked the whole AMP idea from the start because it forms the abstraction layer I'd have to write would I want to get started with OpenCL/GPGPU. Your project gives it the opportunity to become a lot more than just a Microsoft gimmick, and I really hope it will catch on, so to speak.

I have a couple of questions that may come from my limited knowledge about it all, so bear with me:

1. What are the plans with respect to upstreaming the AMP language extensions to the LLVM project? With all due respect, I think that may be the only way to keep the project usable for the masses and the best way to propagate C++ AMP into the open source world.
2. Why did you opt for a new language standard (-std=c++amp) instead of a language extension (e.g. -famp or -fcxxamp, like OpenMP)? It seems that the language standard puts unnecessary constraints on the whole thing (e.g. how does one select C++11 vs C++1z?). A seperate compile/link option like OpenMP has would make much more sense from a usability point of view.
3. Is libc++ usage absolutely necessary? Is it patched somehow for use with AMP, or would a system-installed version work just as well? It'd be better if the whole AMP stack woudl not depend on a certain C++ standard library, and instead use the toolchain's default. This would also be a showstopper to test Clamp on Windows, because libc++ is not yet fully functional there (I did some work there some time ago). It may not make much sense to port it to Windows, but it actually does: it allows direct comparison with a "reference" implementation, and gives a straight performance benchmarking method. Or am I rambling and does Clamp already run on Windows?
4. Are there plans/possibilities for a pure CPU implementation, that is, when OpenCL is missing, or maybe if the OpenCL CPU driver, well, underperforms with respect to what normal C++/OpenMP could do?

Thanks!

[Jack Chung]

Hi rebenvb, these are very good observations. Let me try answer them.

1. Pushing back this work is within the roadmap of the project. We hope to get it done within the next quarter or two. Doing that may require some additional changes to existing implementation and we are in the phase of figuring out the requirements.

2. For that I have no idea, it was the decision made back in 2012 when the project first started, before I joined the project in 2014. However I see no reason we can't adopt -f approach. Just a few changes in Clang Frontend / Driver should suffice.

3. Clamp doesn't run on Windows yet, and no efforts were made to make it so yet. It would be very beneficial if you could help contribute to a Windows port. The decision to adopt libc++ was also made back in 2012 when the project first started. I think the rationale back then was to make the whole deliverable self-contained. Right now there is no libc++-specific patches so it's surely possible to experiment using Clamp with other C++ library implementations.

4. A pure CPU implementation is available already. You can try that with:

clang++ ` clamp-config --build --cxxflags --ldflags ` -cpu -o foo foo.cpp

Essentially it would trigger another separate invocation to cc1 and produce CPU-only codes. You can set environment variable CLAMP_RUNTIME=CPU to force use CPU-only codes at runtime.