大數運算用低階語言實做會比高階語言快? 這是直覺, 但不一定正確的想法 舉例來說, 若把一個大數加在另一個大數身上 組語寫出的的結果, 假設是100個 x86 指令 但一個支援大數運算高階語言 compile 出來的結果, 只是 add A, B 1個 VM 指令而己 不過若是要在 x86 中執行它, 卻可能需要 110個 x86 指令... 110 > 100 所以組語快 10%, 是這樣嗎? 若是該 VM 發現該電腦上有特別的硬體, (如Java Chip) 或是發現 現在所執行的CPU的有支援某些 SSE 指令 或是連發現有裝 顯示卡 ,把顯卡也拿來運算 或是異想天開地, 丟給最近很紅的 ....天邊一朵雲 去計算 或是我所沒寫出來的, 更多種種的可能 原本讓人覺得是 "overhead" 的 VM 卻讓100個指令的組語, 變成反而可能是 "最慢" 的了 當然, 聽到這裡, 可能有人就會想, 再用組語追逐上面提的種種可能... 甚至底下提到的GC, 自己也可以去實做出取代它的功能 但那就只是自己去實做出了一部份的高階語言, 或VM , 或Java罷了 個人淺見 ----- 另外幾百個人一起寫code現實中是有的 不過如果其中每一個人的code, 都會跟另外幾百人有關聯 或是一個錯誤發生, 幾百人都要一起找bug ...那這種案子算是很特別 ※ 引述《Aurim (Who cares?)》之銘言： : 不同時期的人有不同看法吧。 : 當你的工作是OS/driver或比較大型的軟體系統時，看到底下的#1，我想問： : 哪時候才會沒有問題發生呢？ : 小公司一個專案的bug編號了不起三位數、四位數，我會說你說得還好。 : 大公司一個長期維護的產品bug編號會是六、七位數以上，每天幾百個人一起改code， : 幾乎每天都有固定數量以上的bug被提報，沒問題發生就是要發生大事了。 : 如果你的工作大半都是在別人幾天前、幾星期前、幾個月前寫的code上抓bug， : 某個程度上，你一定要知道別人、編譯器、作業系統、硬體到底幹了哪些事情的啊， : 只是搞得多清楚的差別。 : ※ 引述《lgd1008 (lgd1008)》之銘言： : : 另外不必事事知道底層的例子, 可以參考自己與身旁同事的 program integration : : 你何時需要知道同事的實作細節? 太概就只有 : : 1.問題發生的時侯, 2.交接的時侯, 3.想找東西學習的時侯... : 你底下說的不一定，我都幹過了，所以我不認為弄半天也沒辦法弄出那樣的效能； : 當然這感受是因人而異的。我會說那並不是什麼大不了的事情。 : 舉個簡單的例子，我高中時曾經用幾個不同語言寫階乘計算的小東西來磨練自己， : 目標是能夠算出電腦記憶體能夠允許的最多位數的階乘。 : 這是個小題目，可是可以讓一個人在已經做好的東西不斷再去加強效能， : 思考怎樣可以讓它跑得更快，比較各種手法的不同效率。 : 因為高階語言的overhead，大數計算用組語作在執行效能上仍然會是最快的。 : 即使是今日，幾乎天天在看微軟的編譯器生出來的機械碼，我的意見不會改變。 : 凡事都有邊際效益的差別，同樣做個對照，低階語言 vs. 高階語言，C vs. Java： : Java JIT再怎麼強，跟C/C++生的原生code就是有效能差異。 : 就算單純是一個固定比例的差異，10%來講，當CPU時脈愈來愈高， : pipeline內能夠同時執行的指令愈多，差那10%，可能代表的就是0.1 GFLOPS的差別。 : 實際上是差更多，我看過的一些案子就是，實際上處理的資料量明明就沒那麼大， : 可是因為garbage collection沒辦法那麼有效消化垃圾，應該是幾台高檔PC當server : 跑起來應該要OK的東西，搞到要用很貴的機器來讓客戶覺得效能能夠令人接受。 : （幾億元的機器來跑，效能仍然令人不滿意，只是可以接受而已） : 關鍵在於你犧牲那些效能，能提高多少生產力，節省多少開發時間， : 會不會有別的問題伴隨而來？上面就提到了garbage collection的問題。 : 不同工具，適合的工作也不同。 : 我只是組語摸了20年，幾個高階語言跟VM的runtime library內部實作看透透， : 在幾個不同領域待過，一點淺見而已。 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 220.133.27.102