Erste Nicht-Microsoft-C++-AMP-Implementierung verlässt Dock und zeigt Ausblicke in die Zukunft

Erste Nicht-Microsoft-C++-AMP-Implementierung verlässt Dock und zeigt Ausblicke in die Zukunft

Eine der Behauptungen bei der ursprünglichen Ankündigung von C++ AMP war, dass es sich um einen portablen, erweiterbaren Standard handeln würde. Das Analysieren der offenen Spezifikation macht deutlich, dass das Design diesem Ziel entspricht, aber uns fehlte ein tatsächlicher Beweis. Auf einen Schlag haben die guten Leute bei AMD, die mit MulticoreWare zusammenarbeiten, diese letzte Sorge beseitigt, indem sie eine Open-Source-Implementierung von C++ AMP eingeführt haben. Dadurch wird es möglich, C++ AMP in Windows, Linux oder in OS X zu verwenden und dabei eine Fülle von Hardwareplattformen auszunutzen. Da wir dieses Projekt in der Vergangenheit besprochen haben, können Sie es besser verstehen, indem Sie unseren älteren Blogbeitrag lesen.

Die andere (möglicherweise wichtigere) Neuigkeit ist, dass dies auch der erste Fall ist, in dem ein Partner daran arbeitet, den Standard zu erweitern, bevor die Kernsprachenspezifikation aktualisiert wird. Dies ist eine glückliche Entwicklung, da die Zwänge, unter denen die Kernsprache gewachsen ist – die Maximierung der Abdeckung durch die Nähe zum kleinsten gemeinsamen Nenner – die Anpassung an den Stand der Technik manchmal verzögern können. Es ist auch ein Modell, das nachweislich Vorteile für Kern-C++ bringt, wo Boost ein hervorragendes Beispiel für Erweiterungen ist, die einen Einblick in die zukünftige Entwicklung des Standards geben. Lassen Sie uns schnell einen Blick auf die Ergänzungen werfen:

  1. Gemeinsam genutzter virtueller Speicher (SVM) – ermöglicht es, Datenstrukturen zwischen Host und Beschleuniger unkompliziert zu teilen, z. direktes Erfassen in einem „restrict(amp)“-Lambda, anstatt sie durch „concurrency::array“ oder „concurrency::array_view“ zu leiten;
  2. C++11 Atomic and Memory Ordering – wenn es mit SVM gekoppelt ist, öffnet es die Tür für die Konstruktion effizienter Synchronisierungsprimitive, die über Host und Beschleuniger hinweg funktionieren (oder für Mutige, lockfreien Code zu schreiben);
  3. Dynamische Speicherzuweisung und -freigabe (AKA operator new &operator delete) in restriktiven (amp) Funktionen.

Sie werden feststellen, dass all dies großartige Produktivitätssteigerer sind, die dabei helfen, bestimmte Falten zu glätten und uns näher daran bringen, „nur C++“ ohne Einschränkungen zu sein. Wenn sie ausgereift sind, werden sie es Neueinsteigern in die heterogene Datenverarbeitung erleichtern, direkt einzutauchen, ohne herausfinden zu müssen, wie sie ihre bereits vorhandenen Datenstrukturen in Array-freundliche Formen abbilden können.

Die folgende vernünftige Frage wird sich wahrscheinlich stellen:Wann werden wir sehen, dass die Kernsprachspezifikation aktualisiert wird, um diese Erweiterungen aufzunehmen? So gerne wir immer am Puls der Zeit sein mögen, in dieser Hinsicht sind uns die Hände gebunden, bis herstellerunabhängige Enthüllungsmethoden, z. SVM werden eingeführt. Die Erweiterungen von AMD sind auf eine Teilmenge ihrer Hardware beschränkt, nämlich Prozessoren aus der Kaveri-Familie, ein Luxus, den wir uns nicht leisten können. In der Zwischenzeit setzen wir uns weiterhin voll und ganz dafür ein, dass Visual Studio die beste C++ AMP-Entwicklungserfahrung auf dem Markt bietet, und ermutigen Sie, mit den von AMD angebotenen Erweiterungen zu spielen, um eine frühe Vorschau darauf zu erhalten, wohin der Standard schließlich führen soll. Ihr Feedback wird sich als unschätzbar für die Gestaltung unserer zukünftigen Entscheidungen erweisen. Beachten Sie abschließend, dass alles, was gegen die C++-AMP-Kernspezifikation geschrieben wurde, nahtlos sowohl in Visual Studio als auch in der erweiterten Implementierung von AMD funktioniert – die Ausrichtung auf diese Baseline gewährleistet maximale Portabilität. Die spezifischen, nicht portierbaren Bits haben mit den Erweiterungen von AMD zu tun, die wir derzeit nicht implementieren, bzw. mit den von uns bereitgestellten DirectX-spezifischen Elementen. Wenn Sie eines der beiden verwenden, verlieren Sie das andere und müssen die unterstützende Toolkette verwenden.

Abschließend möchten wir unseren Kollegen bei AMD und MulticoreWare unseren Dank für ihre hervorragende Arbeit aussprechen.