如何評價Linux之父Linus認為並行計算基本上就是浪費大家的時間？
Linux之父Linus說：並行計算基本上就是浪費大家的時間
英文：RWT Forums並行只有對圖形計算和伺服器有意義，而在這些領域我們已經大量應用並行了。把並行推廣到其他的領域沒有意義。
（注意：原文中指的是「Parallel stupid small cores without caches are horrible unless you have a very specific load that is hugely regular (i.e. graphics)」 翻譯的童鞋水平有限，也算是斷章取義了吧。）
作為一個研究並行計算的人，我只能說Linus說的太對了……他說的這些在我們看來本就該是共識，然而普通的IT行業初學者卻經不住某些公司的大量宣傳，承認一些本就不對的，文中已經反駁的觀點。但是如果以我的名氣說了這話，知乎並不會專門開一貼來討論罷了。
不過沒關係，5年前的學術圈也是這個風氣，一下好像有了成千上萬的core，什麼東西都要GPU加速，現在早就回歸正常了，因為對於大多數application本來就是horribly useless。只要假以時日，對的終究是對的，錯的終究是錯的。
===========兩年後的ps=============
注意！（敲黑板！）不是並行計算沒用！是general但是沒有cache的並行計算單元沒用！人類很厲害的好吧！現在（是2017年）可以放上百個CPU core在一塊主板上且共享cache的！演算法導論上大多數問題分分鐘可以快幾十倍！當然不能再用那些演算法了，但是對應的並行演算法從理解到編程基本上都和串列版本相仿，你需要的只是知道他們！性能的提升以後還能更多（因為核也會多）！這比提主頻有效多了（因為memory access的latency很難提高几十倍）！對於更多的成百上千個核同步緩存當然是很困難的，但是相信人類的智慧吧！能做到的！同時專用的計算你可以專門設計電路或者晶元去做的！
總之你看Linus這篇文章的內容現在正在被逐步證實對吧！但是需要指出的是有一些答案裡面說並行計算沒什麼的前途的，可能對於並行的理解有些偏差吧，或者沒學過本科並行演算法的課程（不怪他們，這課好像國內就沒哪個學校開的），或者對於近二十年的新研究結果不熟的什麼的吧……另外想知道這些的，多看看MIT和CMU的課程課件吧。我這裡粘一個CMU本科一年級必修的並行演算法課的課本，有興趣的同學可以讀一讀，真的一點也不難的。15-210 textbook
阿姆達爾定律：用於研究一個程序在使用多個處理器時與使用單個處理器時可能出現的加速比。考慮一個運行在單處理器上的程序，執行時間中的（1-f）部分表示其代碼是固有的、只能被串列執行的部分，f部分表示其代碼可以無限制地並行、無調度負載。則使用具有m個處理器的並行系統後，探索該程序整個並行部分的加速比如下：
Amdahl』s law是一個fixed-size model，就是要解決的問題的大小是固定的，可並行化的比例是固定的。
斯塔夫森定律（Gustafson"s law）從另一個角度研究了加速比。它考慮了數據大小與核心數量成比例的增加並計算應用的加速比（上限），假設大數據集能夠以並行方式執行。擴展的加速比公式如 下：
vczh提到"在我們寫的並行程序還需要我們自己操作線程和鎖之前，談浪費時間還太早"這就必須提到另一個問題，我們目前容易實現並行程序嗎，現在的並行機制夠好嗎？
實現並行程序的主要方法有多線程鎖等。其中多線程鎖效率高，但是TM的不好寫啊！！！我們直觀的講講為什麼難寫。我們一般寫程序時，我們只需要關注我正在寫的函數就行，也就是說我只需要關心局部信息。並且在調用函數時，我不需要知道被調用函數的實現細節，這是抽象。我們處理複雜任務時希望處理方法能夠滿足這兩個條件：局部抽象。但是鎖機制破壞了這兩個條件：」出於多種原因，可變狀態和鎖容易出問題。鎖意味著要整理代碼中的依賴性，使開發人員對於執行路徑和預期結果有理可循。但是，由於鎖的多個方面未加以實施，因此看到低質量代碼是很常見的，這些代碼包含可見性、安全發布、競爭條件、死鎖和其他常見並發弊病方面的問題。
一個更嚴重的問題是，即使您一開始使用兩個在並發性方面得到正確編寫的組件，也有可能在結合它們時生成新的意外錯誤。因此編寫構建於可變狀態和鎖之上、且該狀態和鎖隨系統增長仍然可靠的並發系統很難。「 （參考自使用 GPars 解決常見並發問題）
為了解決編寫並發程序困難的問題，我們引入了一些方法：（使用 GPars 解決常見並發問題）
Fork/join（java）
Actors（Erlang ，Scala ）Agents（Clojure）軟體事務內存-STM
通信順序進程-CSP（go）
當然，上面的方法解決的不僅是現有方法編寫困難的問題，也對現有性能做了一定提升，
比如：
go語言聲稱：協程是輕量級的線程。協程十分輕量，Go語言可以在一個進程中執行有數以十萬計的協程，依舊保持高性能。而對於普通的平台，一個進程有數千個線程，其CPU會忙於上下文切換，性能急劇下降。隨意創建線程可不是一個好主意，但是我們可以大量使用的協程。
又比如：
已知你現在有4個核心，你要使用多線程做wordcount的問題，問在1G的數據量下，開幾個map線程，幾個reduce線程能夠使得處理時間最快？等這類最優調度問題。
但是，無論如何改進性能，他們仍然還是受到阿姆達爾定律和斯塔夫森定律的限制。
總結：linus說得有道理，在多核下一些問題（很大一部分問題）無法獲得好的加速比。對於那些有好的加速比的問題（比如多線程處理大數據，圖像處理，伺服器），並行程序並且已經大量地運用了。但是我們在阿姆達爾定律和斯塔夫森定律的限制下，仍有對現有並行機制的改進餘地，無論從編寫難度和性能上。
因為能力有限，本文權當拋磚引玉，就像坎寧安法則所講：」在互聯網上得到正確答案的最好方法不是提問，而是po一個錯誤的答案「，歡迎指正。O(∩_∩)O哈！
這裡沒有提到：
1、linus文中講到的微體系架構對並行的影響，譬如：亂序執行，cache等
2、並行研究領域最新的研究，談到並行必須看看他們在做什麼啊~~~
希望能夠看到這方面的答案。
------------------------------------------------------------補充---------------------------------------------------------
今天與大神討論，大神補充了我忽略的角度，Kenneth聚聚提到了
功耗角度，Linus提到：」在移動領域裡，不大幅增加能耗的情況下，你沒辦法再塞進更多的核。任何一個理智的人都不會為了要塞入更多的內核而閹割內核以降低其大小和性能，閹割內核的唯一理由是你想進一步降低功耗，因此你還是不會得到大量的核「
」假如你要做低功耗通用計算機視覺，我基本可以保證你不會使用通用圖形處理器（GP CPU）。你甚至不會用圖形處理器，因為其功耗也太高了。你大概會用特殊的硬體，很可能是基於某些神經網路的硬體「
功耗是一個相當重要的角度，這是我之前完全沒有意識到的一個問題，Linus一語中的啊~~
另外，Linus提到的微體系架構的問題，估計也是重要的一點，只不過能力有限，不了解。。
-----------------------------------------------------------瞎扯扯-------------------------------------------------------------
未來眾核可能是趨勢（？）但是是什麼樣子的？
是眾多general核心？
是幾個general核心拖著眾多小核心？（intel MIC，CPU+GPU）（參考自Intel MIC 沒有免費的午餐_gpu並行計算）
無論如何，能耗是關鍵（寫到這裡時，我旁邊的夥計來了一句：」核多沒關係，能關就行，頻率可以調，電壓可以調就行「，哈哈~~）
這篇翻譯可以作為一則（特別是 @bin li 的回答中關於我們目前容易實現並行程序嗎，現在的並行機制夠好嗎？）補充資料：http://coolshell.cn/articles/16910.html，從編程實例的角度進行延續Linus對並行複雜性的說明，主要摘錄如下。
Trust me, concurrency is hard. There』s a reason all the examples of
「look how easy it is to parallelize things」 tend to use simple arrays
and don』t ever have allocations or freeing of the objects.相信我，並發設計是困難的。所有關於「並行化如此容易」的理由都傾向於使用簡單數組操作做例子，甚至不包含對象的分配和釋放。
People who think that the future is highly parallel are invariably
completely unaware of just how hard concurrency really is. They』ve seen
Linpack, they』ve seen all those wonderful examples of sorting an array
in parallel, they』ve seen all these things that have absolutely no
actual real complexity – and often very limited real usefulness.那些認為未來是高度並行化的人一成不變地完全沒有意識到並發設計是多麼困難。他們只見過Linpack，他們只見過並行技術中關於數組排序的一切精妙例子，他們只見過一切絕不算真正複雜的事物——對真正的用處經常是非常有限的。
Oh, I agree. My example was the simple case. The really complex cases are much worse.
哦，我同意。我的例子還算簡單，真正複雜的用例更糟糕。
I seriously don』t believe that the future is parallel. People who
think you can solve it with compilers or programming languages (or
better programmers) are so far out to lunch that it』s not even funny.我嚴重不相信未來是並行的。有人認為你可以通過編譯器，編程語言或者更好的程序員來解決問題，他們目前都是神志不清，沒意識到這一點都不有趣。
Parallelism works well in simplified cases with fairly clear
interfaces and models. You find parallelism in servers with independent
queries, in HPC, in kernels, in databases. And even there, people work
really hard to make it work at all, and tend to expressly limit their
models to be more amenable to it (eg databases do some things much
better than others, so DB admins make sure that they lay out their data
in order to cater to the limitations).並行計算可以在簡化的用例以及具備清晰的介面和模型上正常工作。你發現並行在伺服器上獨立查詢里，在高性能計算(High-performance
computing)里，在內核里，在資料庫里。即使如此，人們還得花很大力氣才能使它工作，並且還要明確限制他們的模型來盡更多義務（例如資料庫要想做
得更好，資料庫管理員得確保數據得到合理安排來迎合局限性）。Of course, other programming models can work. Neural networks are
inherently very parallel indeed. And you don』t need smarter programmers
to program them either..當然，其它編程模型倒能派上用場，神經網路(neural networking)天生就是非常並行化的，你不需要更聰明的程序員為之寫代碼。
樓上的大V們壓根就沒有看原文吧。
linus已經提到「並行在圖形處理和伺服器上是有意義的」，他反對的是終端用戶和移動用戶過度的使用並行技術，因為功耗和性能並不會因為提升並行計算而得到改善。
不是linus老了，是你們壓根還沒長大。Linus並不是第一個出來抨擊多核化、並行化的大佬，Donald Knuth也曾開足火力猛轟多核
Interview with Donald Knuth除了搞OS和上層應用、演算法的人，在體系結構圈內部，Yale Patt（現代亂序執行微結構的重要貢獻者之一）也曾在公開場合多次抨擊多核，認為多核下的tuning很無聊、眾核更是根本不知怎麼用，等等。
這些吐槽是有道理的，雖然說能夠並行化的應用不少，但是也有極多的應用根本沒辦法並行或者並行的收益尚不如投入的成本，而且並行編程大大推高了程序員們的學習開銷，抱怨吐槽都是免不了的。
饒是如此，多核化在學術圈裡面仍然認為是大勢所趨，單核心性能早已經瓶頸，硬體亂序多發射的性能已經基本榨乾，再花多大力氣去嚼前人留下的那些乾巴巴的渣渣也嚼不出多少甜頭來了，多核心上倒是還有不少東西可以做，還沒有到山窮水盡的地步。Linus這篇文章里說移動平台上做低功耗機器視覺不應該考慮GPGPU,因為功耗大
但是做機器視覺和圖像處理完成相同工作量GPGPU需要的功耗應該比CPU小才對如果使用GPGPU功耗大也應該是CPU無法達到這個速度，只能用GPU我也認為現在手機上都搞8核CPU沒有太大意義，很大程度上就是營銷噱頭，還不如弄兩個可以睿頻300MHz--2.5GHz之間的Cortex-A17內核，即強勁又可以省電
很有道理。該並行的早已並行了，沒有並行的是因為沒有這個需求或沒有意義。
在有硬體反超線程的技術出來之前，我們其實沒有別的選擇，只能默默搞並行。其實並行在各種地方都會有其用武之地的。比如國內某著名IM軟體，就敢在UI線程里處理網路，發消息的時候網不好UI也卡成渣。不用並行才是浪費時間。
看了看原文說的是graphics，這個可並不只是圖形計算而包括圖形相關的所有東西，比如用戶界面也叫做graphics user interface。
他說除了graphics跟伺服器以外的領域用並行沒意義。但現實是，圖形和伺服器已經囊括了絕大多數領域。
你用手機，用微信，微信是圖形界面，需要並行，微信要連伺服器，伺服器需要並行，在這個環節中所有都需要並行。
Linux內核是伺服器上跑的，他屬於伺服器領域，它也需要並行。
神經網路也是他提到的，但鑒於神經網路的計算量，它也常常是在伺服器上運行，屬於伺服器領域，也需要並行。
非伺服器領域的軟體通常都有圖形界面，沒圖形界面的軟體一般都是伺服器領域，所以這兩者的定義已經包含了絕大多數軟體類別，個人感覺沒什麼錯。。
所以，這句話的意思有點象：除了男人跟女人以外的所有人都不需要並行。。。如果我沒理解錯的話。看看世界上最大規模的商用分散式技術現在用什麼吧，搜索關鍵詞：比特幣礦機
看了這個題目後發現有人連並行跟並發都搞混了...
沒有讀原文，個人看來，移動端以及輕客戶端確實沒有並行化的必要，也不推薦並行化，此處暫不提及GPGPU（通用圖形處理器）。 這裡的並行化只指優化大規模計算的運行時間。
這些輕客戶端本來就不是為大規模計算設計的，特別是今天單核CPU的處理能力以及足夠強大，從這個觀點上面看來，基本沒有並行的需要，當然，如果你要說多線程同時處理各種實時的事件，如同時處理UI和網路信息收發，那麼我們所說的並行不是同一範疇的。
另外一個點就是，基本上輕客戶端由於CPU的核數或者線程數有限，即使並行化，理論上而言，並行化所提供的加速比也不足一提，且不論並行化過程中所帶來的如Linus所言的耗能的增加，必要的數據同步和通訊時間還會把加速比再打個打折扣。特別是做並行優化的對問題不熟悉，甚至還可能出現比單核計算更慢的情況。因而，對於輕客戶端而言，並行所能提供的加速比和耗能的性價比太低。
有句話說得很對，在對的地方做對的事。勉強沒有幸福。他老了。
在我們寫的並行程序還需要我們自己操作線程和鎖之前，談浪費時間還太早。
呵呵，liunx10多年前就吸引大量開發者和公司的精力和財力;結果只比bsd家族好一點點(我是說佔有率和驅動).到底誰浪費了時間呢.
程序員不會使用超過640k的ram，是誰說的？
誰也料不到人類會怎麼折騰。對於串列任務使用多核，無意義，一般程序的並行度有限，無限制提高核心數沒必要，無法取得想要的速度，現在硅半導體硬體的主頻基本到極限了，現在基本上就是在工藝尺寸上不斷縮小，在同樣功能的情況下縮小大小，功率，電壓，於是沒其他辦法，只能增加核心，來提高同時能運行的程序數量，當核心提高到8-》16-》32-》64-》128.。。。對單個程序的速度就很少有影響了，而且很快硬體的工藝尺寸就會達到極限，我想我們應該等待另一種計算機了，例如頻率更高的光學計算機，工藝尺寸更小的量子計算機
如果硬要這麼說，沒有任何辦法。
並行如同BUG
用並行更容易寫出垃圾代碼，目的就是儘可能地吃掉硬體性能。這就叫軟體push硬體提升，更快地淘汰最終用戶手裡的硬體，不然硬體廠商怎吃什麼。。。
推薦閱讀：
※為什麼 ARM 和 MIPS 那麼多寄存器，x86 那麼少？
※如何評價驍龍808？
※CPU 違反能量守恆定律嗎？
※地平線/深鑒科技/寒武紀有什麼異同？
※至強E3 1231 v3和i5 6500誰的性價比高？