引用:
|
作者Stonehendge
從70年代miroporcessor發展以來,從來就是CPU設計師對硬體設計作優化
而不是對programmer作要求,不論是APP還是OS
現代處理器設計浪費電晶體搞一堆有的沒有的(OoOE,cache,pipeline......etc)就是為了要減輕programmer還要浪費時間去對軟體做優化的心力
如果近代CS要走另外那條路線的話,當初VLIW架構早就興起統一天下了
那種設計4bit/8bit簡單uP的不算,現在世界上能設計出高性能CPU的也就intel/AMD/IBM/SUN的幾個團隊
(進年來的ARM有急起直追的態勢)
不過會用高階語言寫software的人全世界千千萬萬,兼懂CPU底層架構的卻很少,更別提要優化
所以讓這幾些作CPU的少數人勞心一點很合理,這樣大部份人比較輕鬆  |
你說的那應該都是80386之前的事了
最早的x86確實是像你說的這個樣子
但是到了80386後，CPU架構變化巨增
理論上軟體都一樣可以動，沒有相容性問題
例如80286 --> 80386的性能的改進相當大
但是對一般人來說，80386只是一個速度更快的80286而已
並無法在軟體應用面上讓開發者發揮更多的創意
其實雖然現在一大堆多媒體指令集
你可以把它想成以前學生考試，OPEN BOOK的查表函數
將一些通用的計算結果公式化起來，縮短CPU運算的時間
其實現在寫程式做優化，大部分都是交給編譯器來做
99%以上的環境，編譯器幾乎都可以很好的針對CPU架構優化程式性能
少部分例如H.264/H.265會更依賴hand code
也就是手工代碼，這才需要真正理解cpu架構
這樣的方式好處是性能會比編譯器自動優化更強
例如NVIDIA的Tegra2，它居然沒有SIMD
性能非常差，無法順暢的播放H.264等的一些壓縮視訊
後期解決，靠的也是研究Tegra2架構之後寫出來的手工代碼
同樣的工作，在沒有SIMD的情況下是另一套不同於原本的優化方式
但是這種手工代碼的壞處在於
寫給Tegra2的，就只有同架構下的cpu能用
所以每一種架構都要寫一次
現在移動設備越來越多了
很多寫android程式的人
其實根本不懂優化
不過這其實也不難理解
只會寫JAVA的人本來就比較不會去注意程式優化的部份
因為那是VM的事情
所以之前才會有那種拿20年的quake老code
說JVM下byte code比原本的c/c++ native code還快
然後說JAVA比C/C++還快的笑話發生
但是現在很多基於NDK的程式
問題就相對很多，不同的SoC都要特別編譯
因為基本上android都幾乎快要變成高通貨三星的天下
自然而然，很難讓第三家SoC正常生存
因為超過一半以上的開發人員根本不知道原來編譯器還要打patch
才編譯出可以在別平台正常執行的程式