Freigeben über

Targeting Heterogeneity with C++ AMP and PPL

  • Artikel

Previously, I blogged about key trends in software development starting with concurrency/parallelism, and indeed today multi-core systems are everywhere. You can target multi-core systems from many mainstream programming languages, and with Visual Studio 2010 we delivered market leading tooling for parallel development and debugging. You can see my post on our concurrency enhancements to C++ for VS2010 and here for a walkthrough of our parallel debugging tools.

In the last few years, we have been seeing an additional trend of heterogeneous hardware where, for example, developers take advantage of the GPU for computational purposes for their data parallel algorithms. This has been successful in narrow verticals using niche programing models. Microsoft wants to bring to the mainstream the ability to write code that takes advantage of heterogeneous hardware like GPUs. So like we’ve done with multi-core before, we are bringing this ability to the next version of Visual Studio.

I’m excited to announce that we are introducing a new technology that helps C++ developers use the GPU for parallel programming. Today at the AMD Fusion Developer Summit, we announced C++ Accelerated Massive Parallelism (C++ AMP). Additionally, I’m happy to say that we intend to make the C++ AMP specification an open specification.

By building on the Windows DirectX platform, our implementation of C++ AMP allows you to target hardware from all the major hardware vendors. We expect that it will be part of the next Visual C++ compiler and fully integrated in the next release of Visual Studio experience.

In addition, there is more work that we are doing on parallel computing. We also announced new enhancements to the next version of Parallel Patterns Library (PPL) and the C++ Concurrency Runtime. You can find easy-to-use C++ templates and runtime support to express algorithms for your domain expertise which scale on any provided hardware with PPL, Agent and the C++ Concurrency Runtime. With C++ AMP and PPL, we aim to make the next version of Visual Studio the most productive environment for targeting heterogeneous hardware available.

We will be making the session recording from Herb Sutter’s keynote session and Daniel Moth’s break-out session from the AMD Fusion conference available shortly. Please check the Visual C++ Team Blog or Channel 9 for those videos.

Namaste!

Comments

  • Anonymous
    June 15, 2011
    The comment has been removed

  • Anonymous
    June 15, 2011
    Hope it will be some easier than OpenCL, as easy as CUDA at least. COmmon computation platform is very cool indeed.

  • Anonymous
    June 15, 2011
    @ __m128i I believe the point is to promote c++ as a heterogeneous language for cpu, gpu, and eventually cloud computing. OpenCL is a nice multi-vendor language but DirectCompute supports multiple vendors more than OpenCL actually does (as of q1 2011) (note i said vendors, not platforms). I recommend watching the keynote from Herb Sutter at the AMD Fusion Summit. He is very thorough explaining why they made it.

  • Anonymous
    June 15, 2011
    Any way to use your efforts mentioned here in .Net?

  • Anonymous
    June 15, 2011
    Its sad, Microsoft is doing so much great stuff, but only using DirectX, it will never be an option for 50% of the world. Another niche again.

  • Anonymous
    June 16, 2011
    Dear Microsoft, Everyone, and I do mean everyone is supporting OpenCL. Why do you need to create something new that looks exactly like CUDA and OpenCL. Developers do not want this. We don't. Have you asked your customers what they want? How about building in OpenCL support from key vendors directly in the OS? If it is about Developers, Developers, Developers, then stop making it about you and having your own format please. Sincerely, A person with a clue

  • Anonymous
    June 16, 2011
    deerchao, Routines based on C++ Amp, like PPL, can be accessed through a native DLL which you P/Invoke or  you can provive a thin shim layer written in C++/CLR which calls the native DLL.  We discussed how to do this for ConcRT, PPL and Agents in this thread: social.msdn.microsoft.com/.../cf132b9c-3387-430e-a197-7222d3b6e389 You would use the same methods for C++ Amp code.

  • Anonymous
    June 17, 2011
    For __m128i, Ben L, Mad, Jim, and others wondering why we elected to take a non-OpenCL approach, I recommend you check out the video of Herb Sutter's AMD Fusion keynote, which you can find here: channel9.msdn.com/.../KEYNOTE You can fast forward to about 37 minutes into the video to hear Herb talk about why we chose the approach we did with C++AMP. Thanks! Steve Teixeira Director of Program Management MS Parallel Computing

  • Anonymous
    June 17, 2011
    The whole developer story is posted at blogs.msdn.com/.../introducing-amp.aspx.

  • Anonymous
    June 19, 2011
    I'm unable to understand Microsoft's strategy on Parallel computing. Earlier Visual C++ compiler had support for OpenMP and seems was not really successful. Also the there are different parallel libraries available for .NET world. Why AMP is introduced as a new technology rather an enhancement for PPL? Also I'm a bit confused about the term portability!

  • Anonymous
    June 20, 2011
    Wow! This is awesome. Way to do it right. Simply extend the existing standards and keeping it lite. If you guys can standardize it, kudos. Using multiple standards/constructs and having to patch them together is for the birds.

  • Anonymous
    September 16, 2011
    Obviously Microsoft doesn't want to support OpenCl because they don't own it. They've been doing this for years so it's no secret.

  • Anonymous
    September 16, 2011
    Wow - I just have to have this. I don't want to be compatible. Industry standards are sooooo 1990's. Standardized APIs are for losers - the only thing that could possibly be better if Microsoft would bring out new APIs even before they release the current ones ;)

  • Anonymous
    September 17, 2011
    Hey folks

  • Regarding why we created C++ AMP (i.e. a non-OpenCL approach), Steve Teixeira has addressed that already in his comment, so please follow his link if you haven't already. Herb Sutter also iterated some of the reasons on his blog here: herbsutter.com/.../c-amp-keynote
  • PPL and C++ AMP were created by essentially the same team. They are not separate competing technologies, but two complementary libraries. The C++ AMP library is large enough to have its own header file (amp.h), but the two technologies are in the same namespace and C++ AMP's parallel_for_each is just an overload to the existing parallel_for_each. Apologies if it seems that we are adding different libraries when in reality we are extending existing ones with new capabilities. We do need different names to distinguish the different targets (multi-core versus accelerators like the GPU).
  • On the Windows-only front, PPL can already be used on non-Windows platforms via Intel's implementation in TBB. Also note that the C++ AMP spec will be implemented by other compiler vendors too, and we are actively working on that. The announcement of C++ AMP was accompanied by the announcement of our intent to publish it as an open spec. For further questions on C++ AMP and PPL, please use our forum: social.msdn.microsoft.com/.../threads Cheers Daniel