朱莉婭的並行性。功能和侷限性

Question

在他們arXiv paper，朱莉婭的原始作者提到以下幾點：

2.14 Parallelism。 並行執行由標準庫中Julia實現的基於消息的多處理系統提供。 語言設計支持通過 提供對稱協程的這種庫的實現，它也可以被認爲是協作調度的線程 。此功能允許在庫中隱藏異步通信，而不要求 用戶設置回調。 Julia目前不支持本地 線程，這是一個限制，但其優點是避免了同步使用共享內存的複雜性。

他們是怎麼說朱莉婭不支持本地線程是什麼意思？什麼是本地線程？

其他解釋語言如Python或R是否支持這種類型的並行？朱莉婭獨自一人嗎？

Answer 1

「原生線程」是獨立的執行上下文，由操作系統內核管理，訪問共享內存空間並可能在不同的內核上並行執行。將其與單獨的進程進行比較，這些進程可以在多個核心上同時執行，但具有單獨的內存空間確保流程很好地交互很容易，因爲它們只能通過內核相互通信。確保線程不以不可預知的錯誤方式進行交互非常困難，因爲它們可以以不受限制的方式讀取和寫入同一內​​存。

R情況相當簡單：R is not multithreaded。 Python有點複雜：Python確實支持線程，但是由於global interpreter lock (GIL)，並沒有實際的Python代碼併發執行。其他流行的開源動態語言在本地線程方面處於各種混合狀態（Ruby：no/kinda/yes?; Node.js：no），但總的來說，答案是否定的，它們不支持完全併發的本地線程，所以Julia不是獨自在此。

當我們向Julia添加共享內存並行性時，as we plan to - 無論是使用本機線程還是使用共享內存的多進程 - 這將是真正的併發性，並且不會有GIL阻止同時執行Julia代碼。然而，這是一種難以置信的棘手特性，可以添加到語言中，正如其他非常流行的，成熟的動態語言中不存在或有限的支持所證明的那樣。添加共享內存併發模型在技術上很困難，但真正的問題在於設計一種編程模型，以便程序員能夠高效安全地使用硬件併發。這個問題一般都沒有解決，而且是一個非常活躍的研究和實驗領域 - 沒有「黃金標準」來複制。我們可以添加POSIX線程支持，但這種編程模型通常被認爲是危險的，難以置信地難以正確有效地使用。 Go具有出色的併發性故事，但其設計用於編寫高度併發的服務器，而不是用於同時處理大型數據，因此，簡單複製Go模型對Julia來說是個好主意，這一點並不十分清楚。