線程級並行度VS進程級並行度

Question

我對線程和進程有基本的了解，我想知道為什么每本教科書都談到線程級並行性，進程級並行性是否存在？ 線程級並行性比進程級並行性有什么優勢？

Answer 1

簡短答案：性能和編程輕松

長答案：

首先，必須考慮兩種不同的並行性：基於任務的並行性（或“宏並行性”）（例如，任務A修改一些數據並將結果傳遞給任務B）和數據級並行性（或“微並行性”）（例如，處理大型矩陣或向量的負載分布在多個並行代理之間）。

其次，當考慮並行性時，不同的代理需要交換信息。 對於線程級並行性，所有線程都可以訪問相同的地址空間，而通信僅是內存訪問。 相反，進程級並行性要求進行過程間通信（IPC）的特定方法，以允許進程交換數據。 存在幾種IPC方法（管道，共享內存，套接字等）（例如， 請參閱https://en.wikipedia.org/wiki/Inter-process_communication ）。

問題在於這些方法通常具有重要的開銷，並且通信可能需要幾個耗時的數據副本。 這就是為什么它們現在很少在單個proc上使用的主要原因。 但是，當考慮在不同且可能距離較遠的處理器上運行的進程時，將大量使用進程級並行性。 例如，客戶端-服務器應用程序是進程級並行性。

在單個處理器上，進程級並行性目前還用於Shell腳本，作為重用現有程序的簡單方法。 例如，在Unix上，類似“ sort <a_large_file | uniq”的腳本是進程級並行性。 可能不是執行此操作的最有效方法（就性能而言），但是如果考慮編程時間，則是完全無與倫比的。

除此之外，線程級並行的主要優點是：

1）通過共享內存的簡單快速的通信機制

2）非常適合任務級並行或數據級並行

3）易於編程

要點2）和3）可能是最重要的。 盡管線程級並行性可以基於獨立的任務，但是速度通常受到限制，並且大多數當前的應用程序都依賴於數據級並行性，線程可以很好地適應於此。 公用內存空間使通信開銷非常有限（考慮鎖定時除外），並且存在非常高效且易於使用的並行化工具（例如open-MP）

在獨立進程上實現這種並行性也是可能的。 當考慮使用大型計算器進行高性能計算時，它甚至經常發生。 存在一些（粗略的）工具（例如“消息傳遞接口”），但是實現比線程級並行性要復雜得多 ，容易出錯並且效率較低。

Answer 2

存在過程級並行性。

但是，Linux內核不了解線程或進程。 它只知道任務。

有Task_parallelism由進程或線程執行。

線程是與父任務共享大多數資源（地址空間，mmap，管道，打開的文件處理程序，套接字等）的任務。 並行性不可避免的問題是共享資源。

還有一些Linux API可控制線程之間共享或不共享多少資源，從而提供了更大的靈活性。

這就是為什么線程級並行性更受歡迎的原因，特別是在為商業服務器（如數據庫）編寫的應用程序中。