36

I am working on high performance code in C++ and have been using both CUDA and OpenCL and more recently C++AMP, which I like very much. I am however a little worried that it is not being developed and extended and will die out.

What leads me to this thought is that even the MS C++AMP blogs have been silent for about a year. Looking at the C++ AMP algorithms library http://ampalgorithms.codeplex.com/wikipage/history it seems nothing at all has happened for over a year.

The only development I have seen is that now LLVM sort of supports C++AMP, so it is not windows only, but that is all, and not something which has been told far and wide.

What kind of work is going on, if any, that you know of?

JoeTaicoon
  • 1,383
  • 1
  • 12
  • 28
  • 2
    You may want to look for OpenMP 4.0 which support export to device. I saw on the clang ML that they are working on GPU code generation but I don't know the current state. As OpenMP 3.0 came in clang 3.6, I guess the other will come later. – P. Brunet Jan 23 '16 at 22:28
  • 1
    Thanks for the hint. I was not aware that openmp now supported gpu's. This is not a "framework" that I have any personal experience with, though, but it does look interesting. After looking at it some more, I am actually wondering why you would want to use CUDA, OpenCL or AMP over OpenMP? Seems to offer much of the same in a general way, but perhaps I just do not know enough to see the issues yet. – JoeTaicoon Jan 24 '16 at 15:51
  • OpenMP will "generate" code for you. It is great but It may not be as efficient as expected. In these case, you may want to write CUDA code to make it more efficient. Just as you may write sse/avx code because the compiler doesn't succeed to vectorize a loop. But I agree that on the long term, it will be really better if we can rely on these features !! – P. Brunet Jan 25 '16 at 21:23
  • An interesting detail now is that I have some heavy parallel code (n-body) for which I was using Microsofts PPL (like Intels TBB) and it was running nicely. I switched my loops to dynamic scheduled OpenMP and it straight "out of the box" increased the computation speed by 25%. I still don't quite know what to make of it, but I am liking it :-) I still have not tried OpenMP 4.0+ since I need another compiler than the one in Visual Studio. Also noted that it is apparently only for NVidia for the time being. – JoeTaicoon Jan 25 '16 at 21:42
  • 1
    I was just looking at C++ AMP and I agree that it's good. But I liked AMD's HCC implementation even better. It's been mentioned by Waldemar below. AMD's HCC is almost AMP, but it's standard C++ now. AMD also supports a version of the original C++ AMP. https://github.com/RadeonOpenCompute/hcc/wiki – Aditya Kashi Jul 27 '17 at 04:13

4 Answers4

20

What leads me to this thought is that even the MS C++AMP blogs have been silent for about a year. Looking at the C++ AMP algorithms library http://ampalgorithms.codeplex.com/wikipage/history it seems nothing at all has happened for over a year.

I used to work on the C++AMP algorithms library. After the initial release, which Microsoft put together I built a number of additional features and ported it to newer versions of VS. It seemed like there was a loss of momentum around C++AMP. I have no plans to do further work on the project.

Make of this what you will. Perhaps someone from Microsoft can clarify things?

Ade Miller
  • 13,575
  • 1
  • 42
  • 75
  • 7
    Thanks for responding with a somewhat clear answer. You being one of the authors of "The C++AMP" book, and now not working on it, makes this a rather clear case for assuming c++amp is more or less dead. Too bad really. In my mind it was a very promissing initiative, but I guess CUDA and OpenCL were not willing to step aside. I wonder what you see as the best tool for massive parallelism now then? – JoeTaicoon Jul 27 '16 at 10:23
  • 1
    Pity that ms is silent about it, since I think it is a really good library (except for the difficult tiling option). – gast128 Mar 15 '17 at 12:26
  • 1
    Very sad to hear this. Just reading the C++ AMP book at present and it seems a much easier path to the GPU for may C++ programmers like myself. I'm now left wondering should I ditch it and go for OpenCL instead. Great book by the way and shame on MS for doing more with this. – SmacL Aug 16 '18 at 08:23
2

I've found that AMD is still using the C++AMP.. http://developer.amd.com/community/blog/2015/09/15/programming-models-for-heterogeneous-systems/ http://developer.amd.com/community/blog/2015/01/19/bolt-1-3-whats-new/ and there are some forum references where Intel is mentioning it too.

The main thing I see is that we the programmers are finally starting to play with the idea that we can use the GPU for ordinary tasks also. Especially now that the HBMs are coming to the APUs you could do a lot on a relatively cheap system. So no copying of data to graphic card or main memory, but keep it in a BIG HBM "cache" where it can be accessed "real-time" i.e. without GPU latency.

So Microsoft build a really really nice technology which will become relevant only in next few years i.e. when the hardware is finally "user friendly". But the thing can become obsolete if they wont advance as others do. Not that something wouldn't work in C++ AMP, but because the speed of change is so big lately that programmers wont risk to start using it, if they don't see some advancements... at least a blog or two per year, where they tested something with it so that you see Microsoft still believes in it.

mirh
  • 514
  • 8
  • 14
Waldemar
  • 171
  • 9
1

FWIW we are also using C++AMP in the financial world. very successful relatively easy to code. CUDA is probably a safer choice but if anyone is considering learning AMP i suggest brush up on your basic STL first then read up on array views.

Yaron Bental
  • 31
  • 3
0

I'm still using amp. Right now I'm making a gpu path tracer (hopefully) for games use.

It seams that amp doesn't have much documentation at the moment or many new updates sadly. Its definitely something I would like to see updated and used more, but it seams dead.

John
  • 1