C++ Accelerated Massive Parallelism

Wed, June 15, 2011, 09:16 AM under GPGPU | ParallelComputing

At AMD's Fusion conference Herb Sutter announced in his keynote session a technology that our team has been working on that we call C++ Accelerated Massive Parallelism (C++ AMP) and during the keynote I showed a brief demo of an app built with our technology. After the keynote, I go deeper into the technology in my breakout session. If you read both those abstracts, you'll get some information about what C++ AMP is, without being too explicit since we published the abstracts before the technology was announced.

You can find the official online announcement at Soma's blog post.

Here, I just wanted to capture the key points about C++ AMP that can serve as an introduction and an FAQ. So, in no particular order…

C++ AMP

  1. lowers the barrier to entry for heterogeneous hardware programmability and brings performance to the mainstream, without sacrificing developer productivity or solution portability.
  2. is designed not only to help you address today's massively parallel hardware (i.e. GPUs and APUs), but it also future proofs your code investments with a forward looking design.
  3. is part of Visual C++. You don't need to use a different compiler or learn different syntax.
  4. is modern C++. Not C or some other derivative.
  5. is integrated and supported fully in Visual Studio 11. Editing, building, debugging, profiling and all the other goodness of Visual Studio work well with C++ AMP.
  6. provides an STL-like library as part of the existing concurrency namespace and delivered in the new amp.h header file.
  7. makes it extremely easy to work with large multi-dimensional data on heterogeneous hardware; in a manner that exposes parallelization.
  8. introduces only one core C++ language extension.
  9. builds on DirectX (and DirectCompute in particular) which offers a great hardware abstraction layer that is ubiquitous and reliable. The architecture is such, that this point can be thought of as an implementation detail that does not surface to the API layer.

Stay tuned on my blog for more over the coming months where I will switch from just talking about C++ AMP to showing you how to use the API with code examples…

Wednesday, 15 June 2011 10:55:18 (Pacific Daylight Time, UTC-07:00)
Bearing in mind your statements "is part of Visual C++" and "provides an STL-like library as part of the existing concurrency namespace and delivered in the new amp.h header file."; I take from this that it's a library provided with MS Visual Studio.

Is it (or will it be) possible to use C++-AMP on a Windows machine without going via Visual Studio, and are there any plans to make this cross-platform (or even just release it all and let others port it as they wish)?

Where I suppose I'm going with this is the question "If I want to use C++-AMP, am I tying myself to Visual Studio and/or to Windows"?
Moschops
Wednesday, 15 June 2011 21:10:04 (Pacific Daylight Time, UTC-07:00)
Hi Moscops, Microsoft offers a C++ AMP implementation that is available in the same way as every other C++ library that Microsoft ships. Microsoft intends to make the C++ AMP specification open so other compiler vendors will be allowed and encouraged to implement it. Thank you for your interest in C++ AMP.
Thursday, 16 June 2011 00:12:07 (Pacific Daylight Time, UTC-07:00)
these bullet points are nice but I still have no concrete idea of what these languages extensions look like.
chris g
Thursday, 16 June 2011 03:41:19 (Pacific Daylight Time, UTC-07:00)
Will C++ AMP applications be able to run in session 0?
Neil
Thursday, 16 June 2011 09:47:24 (Pacific Daylight Time, UTC-07:00)
Where's the beef? Please show us the AMP equivalent of "Hello, world". Thanks!
HPC enthusiast
Thursday, 16 June 2011 14:13:44 (Pacific Daylight Time, UTC-07:00)
Neil, yes you will be able to use C++ AMP in an app running in session 0. More details when we make bits available, stay tuned.
Thursday, 16 June 2011 14:17:29 (Pacific Daylight Time, UTC-07:00)
chris g and HPC enthusiast, thank you for your interest in C++ AMP. Like I said at the end of my post, over the coming months I will switch from just talking about C++ AMP to showing you how to use the API with code examples. I appreciate your patience.
Friday, 17 June 2011 13:33:30 (Pacific Daylight Time, UTC-07:00)
Why was my post deleted, it was a simple request of uploading the sample source code.
James
Friday, 17 June 2011 15:00:36 (Pacific Daylight Time, UTC-07:00)
James, I do not delete any comments unless they are rude. Sounds like a glitch with the blog engine or an over-aggressive spam filter... sorry. As for your request for code, please see this: http://www.danielmoth.com/Blog/C-AMP-Recording-And-Slides.aspx
Friday, 17 June 2011 16:06:39 (Pacific Daylight Time, UTC-07:00)
really liked your talk about c++ AMP! can't argue with leveraging the power of lambdas and integrating a c++ to hlsl compiler into the whole picture really just rocks. the versatility we gain with this goes a long way.
introducing a single language keyword to gain all these pros probably even goes down well with the most die hard c++ language purists. herb sutter's view that as much as possible should be done in a library is most wellcome. i'm a strong proponent of libraries instead of language extensions.
(on a sidenote... something like restrict(analyse) limiting your function to parts of C++ that would allow some proof generators to do their work similar to what the ADA ravenscar profile offers.... that would be something!)

this news just came at a time where i developed a few things using OpenCL and wondering if i should *really* go all the way with that technology. things like nvidia's thrust library (unfortunately using their nvcc wrapper compiler..) showed a way that is less error prone and more intuitive than plain OpenCL. this just made me wonder if it is really worth to fully invest in OpenCL, seeing that staying in 'high level' c++ does the trick aswell. for nowadays needs OpenCL is the way to go but future planning probably should be lambda heavy ;-)
btw, if im talking about OpenCL i just mean OpenCL's way of dealing with kernels. writing code in an "external" language, "external" compilers etc. the same probably applies for directcompute etc.

one rather profane question though.. why do some of the microsoft technologies regarding concurrency ignore another "parallel strategy" that was available in the openmp days? im thinking of parallel reduce. C# 's new parallel features seem to not offer that, i *think* the ppl doesnt have it. intel's TBB does have a nice parallel_reduce function that is really useful! is that left out because people can implement it on top of parallel_for?
but its probably a bit too early in the game for that question..
anyways..

polla *sync*haritiria! ;)
martin wirth
Friday, 17 June 2011 18:02:10 (Pacific Daylight Time, UTC-07:00)
Martin, thanks for sharing your thoughts. To answer your question, in PPL vNext you get parallel_reduce and a bunch of others - see: http://blogs.msdn.com/b/nativeconcurrency/archive/2011/06/16/announcing-the-ppl-agents-and-concrt-efforts-for-v-next.aspx. In C++ AMP, just like with PPL in v1, we start with the main one and who knows what the future holds ;)
Comments are closed.