在GNU Make進程中分配可用內核是否是一個好主意？

Question

有人看到的情況，其中運行n GNU使每個過程與

$ make -j <number of cores/n> 

快於運行他們所有

$ make -j < number of cores> 

，讓GNU讓照顧它。我在練習中從來沒有見過這樣的效果，在我看來，做前者毫無意義。也就是說，也許有可能製作出具有這種效果的具體非實際例子，但在現實世界中，沒有。

我的問題是，有沒有人在他們的實踐中看到這樣的效果。

ADDED：當然假設不同的進程是相互獨立的，並且可以邏輯運行。

ADDED：問題是：手動分區通常會更快。我知道答案是，它是：沒有。問題是，它可以在實踐中發生嗎？有人看過嗎？

尤其是我感興趣的MadScientist的答案:)

這個問題是在計算器上的話題，因爲，上面的紋路都是方案，即，對於GNU包裝腳本製作。 （是的，我知道這可能是不會飛，但至少我嘗試了:)）

如你所描述

Answer 1

手動分區很可能有很強的負面影響：

• 與獨立之間沒有同步製作流程時，他們可能會嘗試同時重建相同的文件，這不僅導致浪費的工作，而且還會由於垃圾無效輸入而導致構建失敗。
• 即使您設法對整個依賴關係鏈進行分區而沒有任何重疊，在第一個分區完成後，您將有空閒的CPU。

我已經看到，可以提高生成文件速度的唯一方法是：

• 地方「更貴」的目標（即最鏈接二進制）此前在相關性列表，以防止空閒CPU結束。
• 包含生成的具有緩存依賴項的生成文件，而不是在每次運行時重新計算它們，即使它們沒有更改。
• 使用系統避免在源文件更改時間戳而不更改內容時重建文件。我只是開始研究這裏有什麼可能。