Re: [請益] java的效能!?

看板Soft_Job作者Aurim (Who cares?)時間13年前 (2011/05/26 00:35)推噓0(0推 0噓 27→)

留言27則, 2人參與討論串49/52 (看更多)

※ 引述《sniffer (again)》之銘言： : GC 把記憶體物件化, 其實很容易平行處理, 甚至專門有硬體來進行 GC, : 所以 GC 在實做上可以視為幾乎沒有效能代價, 卻有重大方便, 不用開發人員去寫code操心是一回事，拿native code debugger去看GC thread又是另一回事，方便是方便啦，我沒辦法同意GC可以視為幾乎沒有效能代價這回事。 : IL 跟 java 根本是一樣的 stack machine, 你比較的只是 M$ 跟某些 Java 廠商的 : compiler, 而不是兩種技術的優劣, : M$ compiler 好不好, 看 WM 跟 android 比較就知道, 不多說這我倒是疑惑了，如果不比較這兩個平台的實作與其compiler/JIT所產生出來的code，那要比什麼？我同意gcc有些地方最佳化可以做得比VC++好，不過我不同意Java各版本的JIT生出來的X86 code的最佳化有普遍勝過.NET的JIT。 : 先 compile 一份 native code 就會拖慢安裝時間, 還會占好幾倍空間, : browser 明顯不太適用, 說不定 user 一輩子只用一次這程式, : 而 java 也一樣有先 compile 的作法存在, 只是手機記憶體有限, : 所以沒有人使用這個方法, 光 byte code 就塞不夠了還管 native code, : 尤其 RISC 的 native code 一般是 x86 兩倍大在以後，這些問題會愈來愈小，RAM成本降很快，flash memory也是。佔空間在PC上已經不是問題了，在手持裝置上也會愈來愈不是問題。 : 離線最佳化一定比不過即時, 沒跑過怎知道哪個變數才是熱點, : 哪一種作法好, 只是執行效能跟 compile/profile 代價的數字遊戲如果你的CPU暫存器數與記憶體充足的情況下，你會擔心哪裡才是熱點嗎？即使是在64-bit X86的環境下，都常常可見大量運用暫存器來傳變數了。在整天都在看反組譯後的機械碼的我來看，我實在看不出來「離線最佳化一定比不過即時」這說法在最終被執行的原生碼層次的效能上如何能成立；當然兩邊要付出的代價不同，考量也會不一樣。 : : 要不要把GPU與其他平行處理單元再考慮進來？ : GPU 的 code 都是 JIT 的, 除非你綁死某一款 GPU, 不然準備幾十種 precompile 太誇張只有某個層次以上是JIT的，而且指令集的差異也沒有到幾十種的程度，架構上世代變革造成的指令集不相容沒有那麼頻繁發生；不過那是外界所碰觸不到的地盤了，也不是我前文想說的事。 Java眾所皆知的，做VM的就那麼幾家，然後所謂新VM功能與新API的成形都是透過JSR 先提出來。比起來，.NET是M$說了就算數，以LINQ與lambda expression來說，都很有希望在之後的某個時間點被加上丟去GPU跑的功能；以M$與三大家CPU/GPU廠商的合作關係，那是彼此開開會就可以決定是不是要透過現有的API或另開新API出來做這事。我真的不知道做Java VM各家公司哪天才能統一出一個介面，與各CPU/GPU廠商溝通好一個統一管道來做些平行處理的事。也許很有希望透過Open CL來做啦，不過還不知道要等到哪天，想玩的人大概都自己透過JNI先行了。Java在這方面一定是最慢跟上的。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.32.10.18

→

Lordaeron

05/26 01:44, , 1^F

05/26 01:44, 1^F

→