扯誰比誰厲害都沒意義，第一是因為山外有山，第二是因為術業有專攻。水貨和正品的區別不是水平而是態度。我認可的態度第一是打破沙鍋問到底，第二是有自己的想法，第三是有常識。

云風那個樂觀悲觀鎖是個好的反面栗子，可以看看他的態度有多毛糙。

碰到性能問題，第一步是簡化場景，第二步是量化分析。簡化場景可以幫你更容易發現熱點，也更容易搭起測試環境，而不是靠線上程序的反應來查找熱點。量化分析是性能問題的唯一解決方法，除此之外其它方法都是瞎蒙。

云風兩件事都沒干。他猜了下問題是lock的方式引起的，然后沒有任何測試數據依據就把cas改成了spinlock，最后根據線上程序的反應，說問題得到了解決。我不知道他怎么能說服自己安心睡覺。

這個問題正確的解決方法如下。首先是把程序執行邏輯拆開成可以單獨profile的單元，根據profiling的結果找到熱點。然后把有問題的部分單獨提出到測試環境，用模擬的壓力測試重現問題。這是一個遞歸的過程，直到熱點的范圍能精確到源代碼某一兩行，甚至到某一兩條指令上。------這就叫常識。要在只有很少symptom的情況下，知道該做什么以及怎么做。

然后開始考慮這一兩條指令為什么會引起性能問題。通常profiler的數據都會給出明確提示，這個性能問題其實是branchmiss或者d$miss或者i$miss。但也有時候看不出明顯的原因，那你就得多想一點，是不是deadlock/livelock，是不是甚至可能不是performance而是correctness的一個表現方式，如果是的話，有什么測試可以證明這個想法。通常這時候你不需要跟任何人討論，因為跟其他人思想同步的過程純屬浪費時間。-----這就叫有自己的想法。任何能用搜索引擎找到正確答案的問題都不是問題，但有些問題是在哪也找不到答案的，只有靠自己想。

有了自己的想法，接下來就是要獲得驗證。這里必須搬出量化分析。換個姿勢再來一次，看看各種miss是否有穩定的減少，時間是否有穩定的降低，具體降低了百分之幾。更優的解法必須通過這個過程來獲得。但有些問題注定是無解的，因為性能問題最終都要回歸到trade-off上，而且需要tradeout的部分甚至可能是correctness。

你回過頭再看看云風是怎么“解決”問題的。不知道根據什么，匆匆得出個結論說“多核心無助于提高隊列的性能”，然后依據此結論推出spinlock比cas更高效。這種既沒有上下文，又沒有數據支持，又籠統的結論，連說服自己都難。

還有個沒提到的態度，是打破沙鍋問到底。你們可以翻翻我之前幾篇日記，其中之一提到了一個想法，就是有沒有可能在軟件里借鑒bus的設計來做分布式系統。到目前為止沒有結果。歸其原因是我對bus了解的還太少了。busprotocol只是暴露出來的冰山一角，bus的atomicy也是一個虛擬的概念。實際當中，cachecontroller的state-machine有幾個transient的狀態，每條transaction的原子性也不是僅僅靠arbiter來解決的。不搞清楚這些內在的設計就不知道實現bus的黑魔法到底是怎么回事。很有可能最后還是個deadend，但我必須把bus的設計搞清楚，另外directory-based的系統也同樣要搞清楚。

干碼農這行就是得有這樣的動力，要分析性能嗎？那必須知道從register到LLC到memorybus的全部細節，要知道pipeline上所有hazard的全部細節，要知道store/loadbuffer是怎么干擾programorder的，要知道out-of-order哪些情況下是不可避免的、哪些情況下是邪惡的。

要知道TCP狀態是怎么跳轉的嗎？那么不僅要讀幾乎所有的TCPrfc，還要把Linux/BSD的stack翻一遍--因為implementation和rfc是相互參照相互傾軋的。這不是你網上搜一個TCPFSM圖就能明白的。

口口聲聲talkischeap,showmethecode的人，Linus的話搬過來也壓不死人。代碼只是記錄思想的工具，而且絕大部分代碼都是廢話。看書比寫代碼重要的多的多。

最后說一下我認同的正品程序員。銀神我很佩服，冰河我很欽佩，知乎/微博上的溫兆倫也不錯。