扯誰比誰厲害都沒意義，第一是因為山外有山，第二是因為術業有專攻。水貨和正品的區別不是水平而是態度。我認可的態度第一是打破沙鍋問到底，第二是有自己的想法，第三是有常識。
雲風那個樂觀悲觀鎖是個好的反面栗子，可以看看他的態度有多毛糙。
碰到效能問題，第一步是簡化場景，第二步是量化分析。簡化場景可以幫你更容易發現熱點，也更容易搭起測試環境，而不是靠線上程式的反應來查詢熱點。量化分析是效能問題的唯一解決方法，除此之外其它方法都是瞎蒙。
雲風兩件事都沒幹。他猜了下問題是lock的方式引起的，然後沒有任何測試資料依據就把cas改成了spinlock，最後根據線上程式的反應，說問題得到了解決。我不知道他怎麼能說服自己安心睡覺。
這個問題正確的解決方法如下。首先是把程式執行邏輯拆開成可以單獨profile的單元，根據profiling的結果找到熱點。然後把有問題的部分單獨提出到測試環境，用模擬的壓力測試重現問題。這是一個遞迴的過程，直到熱點的範圍能精確到原始碼某一兩行，甚至到某一兩條指令上。------這就叫常識。要在只有很少symptom的情況下，知道該做什麼以及怎麼做。
然後開始考慮這一兩條指令為什麼會引起效能問題。通常profiler的資料都會給出明確提示，這個效能問題其實是branch miss或者d$ miss或者i$ miss。但也有時候看不出明顯的原因，那你就得多想一點，是不是deadlock/livelock，是不是甚至可能不是performance而是correctness的一個表現方式，如果是的話，有什麼測試可以證明這個想法。通常這時候你不需要跟任何人討論，因為跟其他人思想同步的過程純屬浪費時間。-----這就叫有自己的想法。任何能用搜索引擎找到正確答案的問題都不是問題，但有些問題是在哪也找不到答案的，只有靠自己想。
有了自己的想法，接下來就是要獲得驗證。這裡必須搬出量化分析。換個姿勢再來一次，看看各種miss是否有穩定的減少，時間是否有穩定的降低，具體降低了百分之幾。更優的解法必須透過這個過程來獲得。但有些問題註定是無解的，因為效能問題最終都要回歸到trade-off上，而且需要trade out的部分甚至可能是correctness。
你回過頭再看看雲風是怎麼“解決”問題的。不知道根據什麼，匆匆得出個結論說“多核心無助於提高佇列的效能”，然後依據此結論推出spinlock比cas更高效。這種既沒有上下文，又沒有資料支援，又籠統的結論，連說服自己都難。
還有個沒提到的態度，是打破沙鍋問到底。你們可以翻翻我之前幾篇日記，其中之一提到了一個想法，就是有沒有可能在軟體裡借鑑bus的設計來做分散式系統。到目前為止沒有結果。歸其原因是我對bus瞭解的還太少了。bus protocol只是暴露出來的冰山一角，bus的atomicy也是一個虛擬的概念。實際當中，cache controller的state-machine有幾個transient的狀態，每條transaction的原子性也不是僅僅靠arbiter來解決的。不搞清楚這些內在的設計就不知道實現bus的黑魔法到底是怎麼回事。很有可能最後還是個dead end，但我必須把bus的設計搞清楚，另外directory-based的系統也同樣要搞清楚。
幹碼農這行就是得有這樣的動力，要分析效能嗎？那必須知道從register到LLC到memory bus的全部細節，要知道pipeline上所有hazard的全部細節，要知道store/load buffer是怎麼幹擾program order的，要知道out-of-order哪些情況下是不可避免的、哪些情況下是邪惡的。
要知道TCP狀態是怎麼跳轉的嗎？那麼不僅要讀幾乎所有的TCP rfc，還要把Linux/BSD的stack翻一遍--因為implementation和rfc是相互參照相互傾軋的。這不是你網上搜一個TCP FSM圖就能明白的。
口口聲聲talk is cheap, show me the code的人，Linus的話搬過來也壓不死人。程式碼只是記錄思想的工具，而且絕大部分程式碼都是廢話。看書比寫程式碼重要的多的多。
最後說一下我認同的正品程式設計師。銀神我很佩服，冰河我很欽佩，知乎/微博上的溫兆倫也不錯。
扯誰比誰厲害都沒意義，第一是因為山外有山，第二是因為術業有專攻。水貨和正品的區別不是水平而是態度。我認可的態度第一是打破沙鍋問到底，第二是有自己的想法，第三是有常識。
雲風那個樂觀悲觀鎖是個好的反面栗子，可以看看他的態度有多毛糙。
碰到效能問題，第一步是簡化場景，第二步是量化分析。簡化場景可以幫你更容易發現熱點，也更容易搭起測試環境，而不是靠線上程式的反應來查詢熱點。量化分析是效能問題的唯一解決方法，除此之外其它方法都是瞎蒙。
雲風兩件事都沒幹。他猜了下問題是lock的方式引起的，然後沒有任何測試資料依據就把cas改成了spinlock，最後根據線上程式的反應，說問題得到了解決。我不知道他怎麼能說服自己安心睡覺。
這個問題正確的解決方法如下。首先是把程式執行邏輯拆開成可以單獨profile的單元，根據profiling的結果找到熱點。然後把有問題的部分單獨提出到測試環境，用模擬的壓力測試重現問題。這是一個遞迴的過程，直到熱點的範圍能精確到原始碼某一兩行，甚至到某一兩條指令上。------這就叫常識。要在只有很少symptom的情況下，知道該做什麼以及怎麼做。
然後開始考慮這一兩條指令為什麼會引起效能問題。通常profiler的資料都會給出明確提示，這個效能問題其實是branch miss或者d$ miss或者i$ miss。但也有時候看不出明顯的原因，那你就得多想一點，是不是deadlock/livelock，是不是甚至可能不是performance而是correctness的一個表現方式，如果是的話，有什麼測試可以證明這個想法。通常這時候你不需要跟任何人討論，因為跟其他人思想同步的過程純屬浪費時間。-----這就叫有自己的想法。任何能用搜索引擎找到正確答案的問題都不是問題，但有些問題是在哪也找不到答案的，只有靠自己想。
有了自己的想法，接下來就是要獲得驗證。這裡必須搬出量化分析。換個姿勢再來一次，看看各種miss是否有穩定的減少，時間是否有穩定的降低，具體降低了百分之幾。更優的解法必須透過這個過程來獲得。但有些問題註定是無解的，因為效能問題最終都要回歸到trade-off上，而且需要trade out的部分甚至可能是correctness。
你回過頭再看看雲風是怎麼“解決”問題的。不知道根據什麼，匆匆得出個結論說“多核心無助於提高佇列的效能”，然後依據此結論推出spinlock比cas更高效。這種既沒有上下文，又沒有資料支援，又籠統的結論，連說服自己都難。
還有個沒提到的態度，是打破沙鍋問到底。你們可以翻翻我之前幾篇日記，其中之一提到了一個想法，就是有沒有可能在軟體裡借鑑bus的設計來做分散式系統。到目前為止沒有結果。歸其原因是我對bus瞭解的還太少了。bus protocol只是暴露出來的冰山一角，bus的atomicy也是一個虛擬的概念。實際當中，cache controller的state-machine有幾個transient的狀態，每條transaction的原子性也不是僅僅靠arbiter來解決的。不搞清楚這些內在的設計就不知道實現bus的黑魔法到底是怎麼回事。很有可能最後還是個dead end，但我必須把bus的設計搞清楚，另外directory-based的系統也同樣要搞清楚。
幹碼農這行就是得有這樣的動力，要分析效能嗎？那必須知道從register到LLC到memory bus的全部細節，要知道pipeline上所有hazard的全部細節，要知道store/load buffer是怎麼幹擾program order的，要知道out-of-order哪些情況下是不可避免的、哪些情況下是邪惡的。
要知道TCP狀態是怎麼跳轉的嗎？那麼不僅要讀幾乎所有的TCP rfc，還要把Linux/BSD的stack翻一遍--因為implementation和rfc是相互參照相互傾軋的。這不是你網上搜一個TCP FSM圖就能明白的。
口口聲聲talk is cheap, show me the code的人，Linus的話搬過來也壓不死人。程式碼只是記錄思想的工具，而且絕大部分程式碼都是廢話。看書比寫程式碼重要的多的多。
最後說一下我認同的正品程式設計師。銀神我很佩服，冰河我很欽佩，知乎/微博上的溫兆倫也不錯。