Eyot 是一種我正在開發的新語言，旨在讓將工作卸載到 GPU 的過程，如同啟動背景執行緒一樣無縫。
Eyot 的原始程式碼會被透明地編譯給 CPU 和 GPU，而兩者之間的通訊則由執行階段處理。傳統的 GPU 程式設計需要您處理許多任務，例如記憶體配置、核心編譯、工作排程等。當為 CPU 編寫程式碼時，這些任務早已由語言執行階段處理，而 Eyot 將這種便利性延伸到了預計在 GPU 上執行的程式碼。
目標使用者是那些 GPU 或其他加速器被大量使用的領域，例如遊戲開發、數值分析和人工智慧。
Eyot 仍處於早期階段。它尚未準備好用於實際工作，但您可以進行實驗，如果您這樣做了，我很樂意聽聽您的想法。以一個簡單的範例（可在 playground 中找到）
首先，這會宣告一個名為 square 的函式，該函式接受並返回一個 64 位元整數。main 然後以 3 種不同的方式呼叫此函式，這些方式說明了 Eyot 的獨特功能。
square 函式被呼叫，正如您所預期的，直接在 CPU 上執行。
從 square 函式建立一個 CPU 工作執行緒（ let cpu_worker = cpu square ）。此工作執行緒會處理透過 send 函式傳送給它的值，在背景 CPU 執行緒上執行。在對數字進行平方運算後，工作執行緒會透過呼叫 receive 返回結果。
這次建立的是 GPU 工作執行緒，而不是 CPU 工作執行緒（ let gpu_worker = gpu square ）。這會導致 square 函式被編譯為一個核心，並在 GPU 上執行，否則其行為完全相同。正如您所見，Eyot 的 print_ln 在 GPU 端也能正常運作。
我曾參與過許多專案，其中將計算轉移到 GPU 提供了明顯的效能提升途徑，但由於難以實現而被忽略了。這些專案不僅限於電腦視覺或遊戲開發等明顯領域，還包括桌面應用程式開發等不太適合 GPU 程式設計的領域。
例如，在我先前開發 macOS LaTeX 編輯器 Texifier 時，我調整了古老的 TeX 排版系統，使其直接將多邊形輸出到 GPU 記憶體，而不是寫入 PDF。這大大降低了延遲，使我們能夠即時更新輸出。該功能很受歡迎，但使其正常工作的難度讓我質疑這個專案是否值得。
透過 Eyot，我想建立一種語言，讓在 GPU 上工作深深植根於語言設計中，使其變得微不足道。長期以來，我們一直將 CPU/OS 組合視為執行我們程式碼的環境，而不是一個可操作的裝置。Eyot 只是將此概念延伸到了 GPU。像 CUDA 這樣的選項已經存在，但 Eyot 的目標是圍繞這種 GPU 並行模型建立整個語言。
由於我利用業餘時間進行開發（歡迎贊助！），進展緩慢，而且最近由於新生命的誕生，我暫停了一段時間，但我的主要開發路線圖項目包括：
渲染：現階段 Eyot 僅支援出於計算目的存取 GPU。遊戲開發是此專案的一個重要目標，因此渲染支援是我最希望實現的功能。我希望使用 Vulkan 來實現這一點，同時用 Vulkan 計算取代 OpenCL。
語法：我推遲了 Eyot 語法的開發，以便在不添加在兩種情況下都不可行的語言功能的情況下，實驗 CPU/GPU 互動。我目前缺少的主要語法功能是代數資料型別、Lambda 函式以及某種形式的介面/特徵風格的多型。
GPU 記憶體管理：這方面還有很多工作要做。向量和字串目前只能在 CPU 端分配，這應該能在 GPU 上運作。我也希望記憶體管理器能夠在適當的時候，自動將分配轉移到共用緩衝區。
效能：遵循「先讓它工作，再讓它正確，再讓它快速」的原則，我可能會將此留待不久的將來進行，但很快就能用真實的工作負載來測試 Eyot 並提高其速度，這將是很好的。
標準函式庫：這不需要改進，我只有少數函式，它需要開始建立……
說明一些我不會著手進行的工作也很有用。
自動平行化：Eyot 不會，也不會自動在 CPU/GPU 核心之間平行化工作。其目的是提供一種方便的處理器間工作分發選項，而不是減少控制。
理論上最佳效能：Eyot 並非旨在完全取代目前的 GPGPU 函式庫，正如 C 和 C++ 並非旨在完全取代組合語言一樣。我會將 Eyot 程式碼與等效的 C/Vulkan 程式碼之間顯著的效能差異視為錯誤，但對我來說，易用性是為了一些效能損失可以接受的代價。
成為下一個偉大的通用程式語言：GPU 和 CPU 之間的語法差異將盡可能少，因此語言設計將受限於 GPU 的功能，這可能會限制我可以在 Eyot 的語法中添加的內容。
感謝您的閱讀。您可以從其文件和原始程式碼中進一步了解 Eyot。如果您想嘗試，有 playground，或者您可以將 Eyot 安裝在您的機器上。
在通用和遊戲開發領域。