按照現在硬體發展的速度，是否還需要高效的代碼？

01-29

程序員多套一個循環，硬體就要追個4，5年，性能才能抵過來。好機器，頂不過濫代碼。

還是要優化，只是不用那麼變態的優化了。

高效代碼和低效代碼的差距是指數級別的，通常我們不會把性能提高10%的稱為高效的，與其這樣還不如在規範上下點功夫使得維護性更好。而指數級別的差距，你要在硬體上多花多少錢？？？

有些行業對代碼的效率依然要求很高，比如遊戲行業，代碼效率高，會用更少的cpu時間片，更少的流量。這樣玩家的手機不會過熱，不會平頻繁充電。不用買更多的流量包。對於一個用戶可能效果沒那麼明顯，但當用戶基數達到一定量收益是非常可觀的。

同樣的，像百度，淘寶這樣的，用戶搜索量都是按幾億數量級，如果做為程序員優化程序，節省的能源價值遠遠超過僱傭程序員的費用。

Apple watch被吐槽的一點就是續航能力，程序優化的效果在其中的重要程度也不需要我多廢話吧。

所以說程序的架構，優化層次完全是通過客戶的需求來的。不是程序員自己能定的。

如果常數上的差別，比如i++和++i的效率差別（當然這個目前很多編譯器都能優化掉，只是舉例），那可以比較簡單的用硬體的提升來彌補。

然而如果是演算法本身的差異導致了時間複雜度的差別，那就很難用硬體彌補了。

比如01背包問題，我們當然可以用DFS來得到結果，時間複雜度是O(2^n)，而如果用DP完成，時間複雜度只有O(nv)，n很大時耗時差距不是硬體提升能追回來的。

安迪比爾定律，問比爾咯。

我覺得完全是成本的問題，你大可以權衡一下是請優秀的程序員花的錢多，還是買高性能硬體花的錢多

把耗時業務放在UI線程里處理，再好的硬體也白搭。

更強大的計算能力意味著更大的計算需求可以被滿足，而目前的計算需求顯然是遠遠沒達到上限的…

優化肯定是要做的，但硬體的進步肯定會改變優化的方向。哪裡成了瓶頸哪裡就是優化的重點。

不能覺得硬體進步了所以優化就白做了，那是因為新的需求還沒有被挖掘出來…

如果答案是不需要的話我上學期的【high performance computing】白上了？

需要。

不然怎麼會有那麼些人的電腦被一個阿里的安全服務拖慢呢～

高效總比不高效的好吧...

不思進取會墜入馬爾薩斯陷阱的。

樓主的數據結構與演算法分析白上了

題主知道什麼叫演算法時間複雜度嗎？

當然要，最近在用js寫圖像處理，不管效率，分分鐘完蛋