C++；放大器 我正在研究C++中的高性能代码，并且一直使用CUDA和OpenCL，最近使用的是C++ AMP，这是我非常喜欢的。然而，我有点担心它没有被开发和扩展，并将消亡

让我想到这一点的是，即使是微软的C++AMP博客也已经沉默了大约一年。看看C++ AMP算法库，似乎一年多没有发生过。

我所看到的唯一的发展是，现在LLVM支持C++AMP，所以它不仅仅是windows，但仅此而已，而不是被广泛告知的东西

你知道正在进行什么样的工作，如果有的话

让我想到这一点的是，即使是微软的C++AMP博客也已经沉默了大约一年。看看C++ AMP算法库，似乎一年多没有发生过。

我曾经在C++AMP算法库工作。在最初的版本发布后，微软将其整合在一起，我构建了许多附加功能，并将其移植到了VS的新版本中。看起来C++AMP的势头有所减弱。我没有计划在这个项目上做进一步的工作

---

你想怎么做就怎么做。也许微软的人可以澄清一些事情？

我发现AMD仍在使用C++AMP。。 在一些论坛参考资料中，英特尔也提到了这一点

我看到的主要事情是，我们程序员终于开始玩弄这样一个想法：我们也可以将GPU用于普通任务。尤其是现在，HBMs正在进入APU，你可以在一个相对便宜的系统上做很多事情。 因此，不需要将数据复制到图形卡或主内存，而是将其保存在一个大的HBM“缓存”中，在那里可以“实时”访问数据，即不需要GPU延迟

因此，微软开发了一项非常好的技术，只有在未来几年，也就是说，当硬件最终“用户友好”时，这项技术才有意义。

---

但如果他们不像其他人那样进步，这件事可能会过时。并不是在C++中有些东西是行不通的，而是因为最近的变化速度太大，程序员们不会冒险使用它，如果他们看不到一些进步…每年至少有一两个博客，他们用它测试了一些东西，让你看到微软仍然相信它。

我仍然在使用amp。现在，我正在制作一个gpu路径跟踪器（希望）用于游戏

---

令人遗憾的是，amp目前没有太多文档，也没有太多新的更新。这肯定是我希望看到更新和使用更多的东西，但它已经死了。

FWIW我们在金融界也在使用C++AMP。非常成功，相对容易编码。CUDA可能是一个更安全的选择，但如果有人正在考虑学习AMP，我建议先复习基本STL，然后再阅读阵列视图。

您可能需要寻找支持导出到设备的OpenMP 4.0。我在ClangML上看到他们正在进行GPU代码生成，但我不知道当前的状态。由于OpenMP 3.0是在Clang3.6中推出的，我想另一个会在稍后推出。谢谢你的提示。我不知道openmp现在支持gpu。虽然这不是一个我个人有过的“框架”，但它看起来确实很有趣。在看了更多之后，我真的想知道为什么你会想在OpenMP上使用CUDA、OpenCL或AMP？似乎在一般情况下提供了很多相同的功能，但也许我还不太了解这些问题。OpenMP将为您“生成”代码。这很好，但可能没有预期的那么有效。在这种情况下，您可能需要编写CUDA代码以提高效率。正如您可能会编写sse/avx代码，因为编译器无法成功地对循环进行矢量化。但我同意，从长远来看，如果我们能够依靠这些功能，那将会更好！！现在一个有趣的细节是，我有一些很重的并行代码（n-body），我使用了Microsofts PPL（比如Intels TBB），并且运行得很好。我将循环切换到动态计划OpenMP，它直接“开箱即用”将计算速度提高了25%。我仍然不知道该如何使用它，但我很喜欢：-）我仍然没有尝试OpenMP 4.0+，因为我需要另一个编译器，而不是Visual Studio中的编译器。还注意到，这显然只是Nvidia暂时。我只是看C++ AMP，我同意它是好的。但我更喜欢AMD的HCC实现。下面是Waldemar提到的。AMD的HCC几乎是AMP，但它现在是标准C++。AMD还支持原始C++ AMP的版本。感谢您给出了一个稍微清晰的回答。你是《C++AMP》一书的作者之一，但现在不在写这本书，这使我们可以很清楚地假设C++AMP或多或少已经死了。真的太糟糕了。在我看来，这是一个非常有希望的举措，但我想CUDA和OpenCL不愿意退位。我想知道你现在认为什么是实现大规模并行的最佳工具？遗憾的是ms对此保持沉默，因为我认为这是一个非常好的库（除了困难的平铺选项）。听到这个消息非常难过。现在只看C++的AMP书，对于像我这样的C++程序员来说，这似乎是一个更容易的GPU路径。我现在在想，我应该放弃它，转而使用OpenCL吗。顺便说一句，这本书很好，MS在这方面做得更多，真是太丢脸了。