基本的 POSIX 實用程序是否並行化？
在一個常見的 Linux 發行版中，像
rm,mv,ls,grep,wc等實用程序是否在它們的參數上並行執行？換句話說，如果我
grep在 32 執行緒 CPU 上處理一個巨大的文件，它會比在雙核 CPU 上執行得更快嗎？
您可以通過檢查實用程序是否與
pthread庫連結來獲得第一印象。任何使用作業系統執行緒的動態連結程序都應該使用 pthread 庫。ldd /bin/grep | grep -F libpthread.so例如在 Ubuntu 上：
for x in $(dpkg -L coreutils grep findutils util-linux | grep /bin/); do if ldd $x | grep -q -F libpthread.so; then echo $x; fi; done但是，由於程序與本身與 pthread 連結的庫連結，這會產生很多誤報。例如，
/bin/mkdir在我的系統上與 PCRE 相關聯（我不知道為什麼……），它本身與 pthread 相關聯。但mkdir不以任何方式並行化。在實踐中，檢查執行檔是否包含
libpthread會給出更可靠的結果。它可能會錯過並行行為完全包含在庫中的執行檔，但基本實用程序通常不是這樣設計的。dpkg -L coreutils grep findutils util-linux | grep /bin/ | xargs grep pthread Binary file /usr/bin/timeout matches Binary file /usr/bin/sort matches所以唯一真正有機會被並行化的工具是
sort. （timeout僅連結到 libpthread，因為它連結到 librt。） GNUsort確實可以並行工作：執行緒的數量可以使用--parallel選項進行配置，預設情況下，每個處理器使用一個執行緒，最多 8 個。（使用更多的處理器會越來越少隨著處理器數量的增加而受益，逐漸減少的速度取決於任務的可並行化程度。）
grep根本沒有並行化。PCRE 庫實際上鍊接到 pthread 庫只是因為它提供了使用鎖的執行緒安全函式，並且鎖操作函式在 pthread 庫中。在處理大量數據時從並行化中受益的典型簡單方法是將這些數據拆分為多個片段，然後並行處理這些片段。在 grep 的情況下，保持文件大小可管理（例如，如果它們是日誌文件，請經常輪換它們）並在每個文件上呼叫單獨的 grep 實例（例如使用GNU Parallel）。請注意，grepping 通常是受 IO 限制的（如果您有一個非常複雜的正則表達式，或者如果您遇到 GNU grep 的一些 Unicode 極端情況，它的性能很差，它只會受 CPU 限制），因此您不太可能從中獲得太多好處有很多執行緒。