3167
原文標題：Why SYCL: Elephants in the SYCL Room
By James Reinders and Michael Wong
摘錄自：https://www.hpcwire.com/2022/02/03/why-sycl-elephants-in-the-sycl-room/
評論——在第二個關于異構計算的一系列客座帖子中，James Reinders在短暫的“退休”后于去年回到了英特爾，他繼續(xù)了講述SYCL將如何為C++的異構未來做出貢獻的文章。Codeplay Software Ltd.的Michael Wong也加入了他的行列，他也是現(xiàn)任SYCL委員會主席。他們一起對所謂的“SYCL房間里的大象”做出了回應。
熟悉 SYCL 規(guī)范的人已經(jīng)很好地闡明了 SYCL 帶來了全面異構支持的 C++ 編程案例，包括最近的一篇文章“考慮 C++ 的異構未來”以及 sycl.tech 上列舉的許多其他資源。 SYCL 是一種 Khronos 標準，引入了對 C++ 的完全異構數(shù)據(jù)并行性的支持。 雖然 SYCL 并不是包治百病的靈丹妙藥，但它是一個方面的解決方案：鑒于硬件多樣性的爆炸式增長，我們如何充分啟用完全異構編程？
在本文中，我們基于我們在該領域工作了數(shù)十年的觀點，提出了對 SYCL 關鍵問題的看法。 這些重要問題是由希望了解 SYCL 對他們是否重要的軟件開發(fā)人員提出的。 讓我們面對現(xiàn)實吧：在某些時候，每個重大項目都會有“房間里的大象”。[1] 成功的項目公開地解決了他們的問題。
大象一：GPU 還不夠嗎？ 其他加速器真的重要嗎？
關于哪些加速器將繼續(xù)存在、哪些將成為曇花一現(xiàn)，存在一些合理的問題。 幾十年來，不同的加速器來了又去，而 CPU 卻一直存在。 如今，GPU 出現(xiàn)在絕大多數(shù)計算機系統(tǒng)中。 鑒于 GPU 幾乎無處不在，編寫應用程序來利用 GPU 非常有意義。
因此，首要問題之一是我們是否真的需要泛化，即我們是否需要多架構和多供應商？
以近藤正明教授為首的研究人員等專家在《下一代高級計算基礎設施白皮書》中預計，未來將需要“專用或半專用硬件加速器”作為這十年計算的必備功能。 ”以及 Hennessy 和 Patterson 在他們的論文“計算機架構的新黃金時代”中。
既然我們談論的是專用加速器，為什么只停留在 GPU 上呢？ 針對不同類型的加速器進行優(yōu)化是一個偉大的目標，但我們不想為不同類型的加速器編寫不同的代碼。 我們相信，該行業(yè)將受益于標準化語言，每個人都可以做出貢獻、進行協(xié)作，不會被鎖定到特定的供應商，并且可以根據(jù)其成員和公眾要求有機發(fā)展。
SYCL 采用了一種有趣的方法，允許我們在需要時使用通用代碼，并在需要時進行專業(yè)化。 通過這種方式，SYCL 總體上擁抱加速器，讓我們開發(fā)人員來決定何時編寫通用的跨架構代碼，以及何時我們認為專門化代碼有足夠的優(yōu)勢。
其底層編程模型 SPMD 已被證明可在多種體系結構中使用。 SPMD 是大多數(shù)使用 Nvidia CUDA/OpenCL/SYCL 的程序員的想法：從操作一個工作項的角度編寫代碼，并期望它在大多數(shù)硬件上同時運行，以便多個工作項填充矢量硬件通道。
SYCL 提供了跨供應商（例如，許多不同的 GPU 來源）以及架構（例如，GPU、FPGA、ASIC）的高度可移植性。
大象2：為什么不直接使用Nvidia CUDA？
由于多個 GPU 供應商的競爭，一個充滿活力的 GPU 生態(tài)系統(tǒng)正在興起。 這是加速器競爭越來越激烈的趨勢的一部分。 使用 Nvidia GPU 的 CUDA 應用程序的安裝基礎將能夠隨著時間的推移適應開放的、多供應商、多架構的軟件方法，該方法旨在為所有供應商（而不僅僅是 Nvidia）提供服務。
雖然 CUDA 因其價值主張和 Nvidia GPU 在生態(tài)系統(tǒng)中的實力而贏得了眾多追隨者，但人們越來越擔心 CUDA 的使用造成的鎖定。 這些擔憂源于以下因素所強調的專有關注：
? ? 1. CUDA 的定義、其實現(xiàn)和發(fā)展由 Nvidia 管理，并專門為服務 Nvidia GPU 產品設計而發(fā)展。 CUDA 中新功能的詳細信息通常不會公開，直到 NVIDIA 擁有支持它們的硬件和軟件為止。 正如下面更全面討論的，這種控制抑制了其他供應商的創(chuàng)新。
????2. Nvidia 的 CUDA 工具和庫的許可特別指出，它們必須用于“開發(fā)僅在具有 Nvidia GPU 的系統(tǒng)中使用的應用程序”。 即使是 Nvidia 的“開源”也包含以同樣方式限制關鍵部分的許可語言。
Nvidia CUDA 因使用 Nvidia GPU 為大眾帶來加速計算而享有盛譽。隨著加速器市場競爭的爆發(fā)，CUDA 似乎已經(jīng)成為一個日益開放和透明的世界中的圍墻花園。對 CUDA 的開放、多供應商、多架構替代方案的渴望不會消失。
大象 3：為什么不直接使用 AMD HIP？
AMD 異構計算可移植接口 (HIP) 是一種 C++ 方言。 AMD 工具包括“HIPify 工具”，可幫助將 CUDA 代碼轉換為 HIP。 AMD 表示，“HIP 代碼可以在 AMD 硬件（通過 HCC 編譯器）或 Nvidia 硬件（通過 NVCC 編譯器）上運行，與原始 CUDA 代碼相比，不會有任何性能損失?！?/em>
HIP 是一種“跟隨 CUDA”策略，即在 Nvidia 發(fā)布其 CUDA 平臺更新后，AMD 盡快開發(fā) HIP 更新。 支持 HIP 的論點是基于 AMD GPU 重用大型 CUDA 代碼庫的優(yōu)點。 不幸的是，鑒于 CUDA 的不透明性，沒有人能夠太密切、及時或準確地跟蹤 CUDA。 如果不迫使 CUDA 開發(fā)人員使用 AMD GPU 的 #ifdefs 更改代碼，AMD 就沒有機會展示獨特的 AMD 硬件創(chuàng)新。
雖然 AMD 通過 HIP 為那些尋求 AMD GPU 作為 Nvidia GPU 替代品的人創(chuàng)造了價值，但想要更多并不難。 想象一下，擁有一個能夠與 CUDA 的功能創(chuàng)新和性能保持同步的解決方案！我們相信，創(chuàng)新將在開放的領域而不是在圍墻花園的陰影中蓬勃發(fā)展。
[編者注：有一個名為 hipSYCL 的 SYCL 實現(xiàn)，它位于 HIP 之上，并針對運行 ROCm 和 Nvidia GPU 的 AMD GPU。]
大象4：為什么不直接使用OpenCL？
OpenCL 提供了一種開放的多供應商替代方案，但其軟件堆棧層低于 SYCL 或 CUDA 提供的軟件堆棧層。 SYCL 的誕生是為了通過為異構并行架構提供標準 C++ 接口來發(fā)揮 OpenCL 開放、多供應商、多架構方法的優(yōu)勢。 SYCL 實現(xiàn)通常使用 OpenCL 進行實現(xiàn)，但從 SYCL2020 開始，也可以靈活地在后臺使用其他后端。 SYCL 通過其 C++ 抽象以更高的生產力形式兌現(xiàn)了 OpenCL 的承諾。
大象5：我們不能只使用C++嗎？
讓我們首先假設我們想要對異構機器進行編程，我們重視可移植性，并且我們不想為可移植性付出性能上的代價。
我們可能會回答“是”——當您也有 SYCL 支持時，C++ 就足夠了。 畢竟，C++ 的構建是為了通過 SYCL 等模板庫進行擴展。 SYCL 沒有添加新的關鍵字，但它確實受益于 SYCL 感知的 C++ 編譯器來幫助交叉編譯、胖二進制文件和遠程內存。 這些都是 C++ 編譯器歷史上并不容易做到的事情。
如今，SYCL 還在標準 C++ 中提供了一種解決方案，用于解決構建在 ISO C++ 之上的完全異構計算的編程問題。 這包括設備枚舉（信息）、定義工作（內核）、跨設備提交和協(xié)調工作（隊列）以及管理遠程內存。
這讓我們得出“不”的結論——C++ 標準沒有定義對具有不相交（非連貫）內存的異構系統(tǒng)的支持。 有些人認為有一天會添加這一點，并且正在朝著這個方向努力，但即使是那些參與其中的人也認為當前的方向至少需要 10 年，并且它受到 C++ 需要保持與數(shù)百萬行向后兼容性的限制。 現(xiàn)有代碼。 事實上，我們中的一位 (MW) 已經(jīng)撰寫了論文，敦促 C++ 朝這個方向發(fā)展。 出于向后兼容性的考慮，WG21 (ISO C++) 的反應是從并行算法和執(zhí)行器開始，并添加向前的進度保證，而不是對內存和尋址模型進行根本性的外科手術改變。 因此，如果您正在對異構機器進行編程，那么聲稱“C++ 就足夠了”可能還不夠。 有些人試圖朝這個方向前進，這就是競爭行業(yè)的美妙之處，我們可以看到什么將最符合市場和消費者的利益。 然而，今天立即起作用的是“C++ 加 SYCL”或“C++ 加 CUDA”或“C++ 加 OpenCL”。
將 SYCL 支持添加到我們的 C++ 編譯器和運行時中的目的是添加功能，以便 C++ 支持完整的異構支持，而如果沒有 SYCL，C++ 目前無法提供這種支持。 這也是展示 C++ 如何支持未來異構性的一種方式，因為 ISO 標準傾向于標準化現(xiàn)有知識的最佳實踐。 下面我們將展示一個這樣的例子。
大象6：SYCL隊列可以進入ISO C++嗎？
隊列是 SYCL 將工作分配給異構設備的方式，包括在復雜的內存系統(tǒng)（不一定是統(tǒng)一和一致的）內傳遞數(shù)據(jù)。
從長遠來看，很容易推測一個隊列類是否屬于C++，但這種推測還為時過早。
C++23 的提案包括各種直接執(zhí)行到特定設備的結構，包括 p2300 中的“std::execution”。 我們知道C++23將繼續(xù)依賴統(tǒng)一的全局內存地址空間，并且不會支持不相交的遠程內存（復雜的內存系統(tǒng)）。
很容易陷入語法困境。 最終，如果 C++ 擴展到包括完整的異構支持，則將需要 SYCL 隊列中體現(xiàn)的概念。 在此之前，SYCL 填補了這一空白。 一些重要的功能，例如并行指令和消息傳遞，仍然是獨立的標準（OpenMP 和 MPI）。 雖然 C++ 可能不會發(fā)展到包含完整的異構支持，但我們相信 C++ 最終將逐步添加此類支持。
C++ 的目標是標準化既定的最佳實踐，而不是發(fā)明新的和未經(jīng)驗證的功能，因此 SYCL 是一個重要的踏腳石，作為“既定的最佳實踐”進入故意緩慢發(fā)展的 C++ 標準化過程的眾多饋送者之一。
隨著 C++23 的穩(wěn)定和 C++26 的考慮，C++ 異構計算的未來將開始成形，包括語法，但完整的解決方案可能在未來 5-10 年內不會出現(xiàn)。
SYCL 如今在標準 C++ 中提供了一種解決方案，用于解決完全異構計算的編程問題。 這包括設備枚舉（信息）、定義工作（內核）、向設備提交工作（隊列）以及管理遠程內存。
大象7：誰是SYCL的幕后推手？ 它真的是真正意義上的開放嗎？
我們相信開放的國際標準和開源軟件 (OSS) 項目對每個人都有好處。 當英特爾和 Codeplay 的個人參與其中時，我們發(fā)現(xiàn)他們努力幫助開發(fā)和推廣此類標準和 OSS——從 WiFi、USB、PCIe 到 OpenMP、MPI、Fortran、C、C++、OpenCL 和 SYCL。
Apple 是 OpenCL 背后的原始力量，它最初是一組相當?shù)图墑e的 C 接口。 SYCL 最初源于 OpenCL 內部考慮更高級別接口（特別是使用 C++）的努力。 經(jīng)過多年的公開辯論，SYCL 誕生了。 Codeplay 從一開始就在 SYCL 中發(fā)揮了重要作用。 在進入 FPGA 市場并宣布英特爾 Xe 架構包含用于計算的 GPU 后，英特爾對 SYCL 的興趣與日俱增。 英特爾很自豪能夠成為 SYCL 委員會的積極成員，并為支持 SYCL 的實施做出積極貢獻。 SYCL 是一項社區(qū)努力，本文的兩位作者（Intel 和 Codeplay）以及許多其他人都是熱情的參與者。
大象8：我看到一群大象——我為什么要相信SYCL？
如果您還不需要為多個異構機器編寫應用程序，那么您可能還沒有真正理解為什么我們對 SYCL 的前景如此興奮。 質疑這種需求是非常合乎邏輯的。
異構編程有很多用例。 在我們的 CPPCON 2021 教程中，我們向來自大公司、小公司和國家實驗室的程序員教授如何將高吞吐量工作負載卸載到專用加速器。
基于許多類似的經(jīng)驗，我們有充分的理由相信，由于異構平臺對 C++ 編程的需求，對 SYCL 的興趣將繼續(xù)快速增長。
如果您相信硬件多樣性的力量并希望利用即將到來的架構多樣性爆炸，那么 SYCL 值得一看。 它不僅是開放的、多供應商、多架構的游戲，而且是 C++ 程序員的關鍵（詳見“考慮 C++ 的異構未來”）。
開放的行業(yè)標準對于實現(xiàn)大容量市場至關重要
新技術通常始于專有開發(fā)，這可能足以實現(xiàn)利基應用和市場。 但是，隨著這些利基應用程序成長為技術生態(tài)系統(tǒng)，競爭和行業(yè)標準化的需求也隨之增加，以實現(xiàn)廣泛采用。 多年來，加速計算一直只是一種小眾功能，但無疑已經(jīng)以“長期存在”的狀態(tài)出現(xiàn)。 造成這種情況的因素有很多，而且它們并不會全部消失（電源墻、IPC 墻、內存墻）。
SYCL 和相關工作（例如 oneAPI）的推出是為了將開放的行業(yè)標準帶入歷史上專有的加速計算領域。
最大的問題是：有多少影響者渴望推動標準的發(fā)展，而有多少人被專有利益所束縛？
隨著新型計算機架構的大爆炸的展開，開放、多供應商、多架構標準的需求只會變得更加強烈。
SYCL 是一個開放標準，邀請每個人對該標準以及實施該標準的開源項目提供反饋和貢獻。 所有參與者的共同目標是明確確保所有加速器在這個令人興奮的計算機架構新黃金時代實現(xiàn)高性能。
你都看到這里了，不如我們嘮叨幾句吧！
從（國內）芯片公司的角度，不想&也不愿去考慮用戶可能需要面對多個異構機器編寫應用程序。但這是市場需要的，這種革命性的想法，只會來自于第三方。????????
我知道Codeplay 今年被intel全資收購了。但國內有這樣的公司生存的土壤嗎？如果像澎峰科技、一流科技這樣的從事基礎軟件研發(fā)的公司，是近年中國少有的火苗，如果他們都不能生存，中國的計算產業(yè)有能有什么希望？也希望投資者別去扭曲這種小而美的軟件企業(yè)，去幫助他們，大家一起獲得成功。
關于作者
James Reinders?believes the full benefits of the evolution to full heterogeneous computing will be best realized with an open, multivendor, multiarchitecture approach. Reinders rejoined Intel a year ago, specifically because he believes Intel can meaningfully help realize this open future. Reinders is an author (or co-author and/or editor) of ten technical books related to parallel programming; his latest book is about SYCL (it can be freely downloaded?here).
Michael Wong?is the Distinguished Engineer at Codeplay Software. He is a current Director and VP of ISOCPP Foundation, and a senior member of the C++ Standards Committee with more than 25 years of experience. He is a member of the C++ Directions Group. He chairs the WG21 SG19 Machine Learning? and SG14 Games Development/Low Latency/Financials C++ groups and is the co-author of a number C++/OpenMP/Transactional memory features including generalized attributes, user-defined literals, inheriting constructors, weakly ordered memory models, and explicit conversion operators. He has published numerous research papers and is the author of a book on C++11. He has been an invited speaker and keynote at numerous conferences. He is currently the editor of SG1 Concurrency TS and SG5 Transactional Memory TS. He is also the Chair of the SYCL standard and all Programming Languages for Standards Council of Canada. Previously, he was CEO of OpenMP involved with taking OpenMP toward Accelerator support and the Technical Strategy Architect responsible for moving IBM’s compilers to Clang/LLVM after leading IBM’s XL C++ compiler team.
[1] Elephants in the Room can be defined as important questions that are obvious, but no one mentions them because they make at least some persons uncomfortable.
下載ECAD模型
