Re: [請益] java的效能!?
※ 引述《Aurim (Who cares?)》之銘言:
: ※ 引述《sniffer (again)》之銘言:
: : GC 把記憶體物件化, 其實很容易平行處理, 甚至專門有硬體來進行 GC,
: : 所以 GC 在實做上可以視為幾乎沒有效能代價, 卻有重大方便,
: 不用開發人員去寫code操心是一回事,
: 拿native code debugger去看GC thread又是另一回事,
: 方便是方便啦,我沒辦法同意GC可以視為幾乎沒有效能代價這回事。
這是因為你只看某些特定產品, 而忽略掉規格本身可以做到的程度,
以及硬體可以做到的加速, 就像 permutation 對 cpu 看起來很複雜,
但是對硬體來說完全是 zero, 線拉一拉就好
: : IL 跟 java 根本是一樣的 stack machine, 你比較的只是 M$ 跟某些 Java 廠商的
: : compiler, 而不是兩種技術的優劣,
: : M$ compiler 好不好, 看 WM 跟 android 比較就知道, 不多說
: 這我倒是疑惑了,如果不比較這兩個平台的實作與其compiler/JIT所產生出來的code,
: 那要比什麼?我同意gcc有些地方最佳化可以做得比VC++好,不過我不同意Java各版本
: 的JIT生出來的X86 code的最佳化有普遍勝過.NET的JIT。
你自己說 arm, 現在又跑到 x86 去了, 那怎不說 mono,
mono 比 sun jit 爛, 等同於 IL 比 JVM 爛嗎?
各版本, IL 有硬體版本嗎?
: : 先 compile 一份 native code 就會拖慢安裝時間, 還會占好幾倍空間,
: : browser 明顯不太適用, 說不定 user 一輩子只用一次這程式,
: : 而 java 也一樣有先 compile 的作法存在, 只是手機記憶體有限,
: : 所以沒有人使用這個方法, 光 byte code 就塞不夠了還管 native code,
: : 尤其 RISC 的 native code 一般是 x86 兩倍大
: 在以後,這些問題會愈來愈小,RAM成本降很快,flash memory也是。
: 佔空間在PC上已經不是問題了,在手持裝置上也會愈來愈不是問題。
你先認為 vm 吃掉的效能很嚴重, 現在又說硬體越來越進步, 你的論點到底是?
: : 離線最佳化一定比不過即時, 沒跑過怎知道哪個變數才是熱點,
: : 哪一種作法好, 只是執行效能跟 compile/profile 代價的數字遊戲
: 如果你的CPU暫存器數與記憶體充足的情況下,你會擔心哪裡才是熱點嗎?
: 即使是在64-bit X86的環境下,都常常可見大量運用暫存器來傳變數了。
暫存器數充足?
暫存器越多, task switch 代價越大, cpu 暫存器數量不會無限制上昇的,
除非你的 loop 只跑九九乘法, 哪有暫存器數充足的 cpu 存在
: 在整天都在看反組譯後的機械碼的我來看,
: 我實在看不出來「離線最佳化一定比不過即時」這說法在最終被執行的原生碼層次
: 的效能上如何能成立;當然兩邊要付出的代價不同,考量也會不一樣。
: : GPU 的 code 都是 JIT 的, 除非你綁死某一款 GPU, 不然準備幾十種 precompile 太誇張
: 只有某個層次以上是JIT的,而且指令集的差異也沒有到幾十種的程度,
沒作過不要亂講, 就算同指令集, 光是 core 數不同就要重新 compile
: 架構上世代變革造成的指令集不相容沒有那麼頻繁發生;
: 不過那是外界所碰觸不到的地盤了,也不是我前文想說的事。
: Java眾所皆知的,做VM的就那麼幾家,然後所謂新VM功能與新API的成形都是透過JSR
: 先提出來。比起來,.NET是M$說了就算數,以LINQ與lambda expression來說,都很有
: 希望在之後的某個時間點被加上丟去GPU跑的功能;以M$與三大家CPU/GPU廠商的合作
: 關係,那是彼此開開會就可以決定是不是要透過現有的API或另開新API出來做這事。
: 我真的不知道做Java VM各家公司哪天才能統一出一個介面,與各CPU/GPU廠商溝通好
: 一個統一管道來做些平行處理的事。也許很有希望透過Open CL來做啦,不過還不知道
: 要等到哪天,想玩的人大概都自己透過JNI先行了。Java在這方面一定是最慢跟上的。
廠商又在打廣告, 現在果然護航文章特多, 還都是不懂的人亂蓋
java 都有一堆 asic, arm 也有 java coprocessor 標準, 這些都很久了,
FPGA 還有 java 模組可以直接做來玩, 版上就有人賣過 kit
也早就有 java opencl, 不像 WM 都是據說會有, 可能會有
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 122.116.218.88
→
05/26 13:20, , 1F
05/26 13:20, 1F
有, 主要用途都是當 firmware, 控制硬體, 反正都隱藏在機器裡,
手機晶片也有, 但是baseband打不過q跟t, 所以最後都用他們, 重點不在cpu
※ 編輯: sniffer 來自: 122.116.218.88 (05/26 13:52)
推
05/26 14:03, , 2F
05/26 14:03, 2F
ti omap 都是 ARMxxxE-J, J 就是 java 加速
※ 編輯: sniffer 來自: 122.116.218.88 (05/26 14:23)
→
05/26 15:14, , 3F
05/26 15:14, 3F
j2me 產品就有用到, 當然 android 沒有, 架構不同, 執行效能沒 JIT 快,
但是對需要啟動快的 browser or BD-J 還是很有用, 並不是 android 沒在用就都沒用,
nokia symbian 手機一大堆, BD 播放機一大堆, 觀點不要太狹窄
※ 編輯: sniffer 來自: 122.116.218.88 (05/26 17:55)
→
05/26 21:52, , 4F
05/26 21:52, 4F
→
05/26 21:53, , 5F
05/26 21:53, 5F
→
05/26 21:54, , 6F
05/26 21:54, 6F
→
05/26 21:55, , 7F
05/26 21:55, 7F
→
05/26 21:55, , 8F
05/26 21:55, 8F
→
05/26 21:56, , 9F
05/26 21:56, 9F
→
05/26 21:57, , 10F
05/26 21:57, 10F
→
05/26 21:59, , 11F
05/26 21:59, 11F
→
05/26 21:59, , 12F
05/26 21:59, 12F
→
05/26 21:59, , 13F
05/26 21:59, 13F
→
05/26 22:00, , 14F
05/26 22:00, 14F
→
05/26 22:03, , 15F
05/26 22:03, 15F
→
05/26 22:03, , 16F
05/26 22:03, 16F
→
05/26 22:04, , 17F
05/26 22:04, 17F
→
05/26 22:06, , 18F
05/26 22:06, 18F
→
05/26 22:12, , 19F
05/26 22:12, 19F
→
05/26 22:16, , 20F
05/26 22:16, 20F
→
05/26 22:17, , 21F
05/26 22:17, 21F
→
05/26 22:18, , 22F
05/26 22:18, 22F
→
05/26 22:19, , 23F
05/26 22:19, 23F
→
05/26 22:19, , 24F
05/26 22:19, 24F
→
05/26 22:20, , 25F
05/26 22:20, 25F
→
05/26 22:20, , 26F
05/26 22:20, 26F
→
05/26 22:21, , 27F
05/26 22:21, 27F
→
05/26 22:21, , 28F
05/26 22:21, 28F
討論題目是java效能, 接者變成GC好不好, 然後有腦殘一邊說GC/VM不好一邊稱讚IL,
接下來又跳出個堅持本串只能討論server效能的, 原PO是說Java物件會不會影響效能,
這又不是作文考試, 前後有對話到就可以了
說到大型主機, 誰在IBM 390跑.NET呀, 那直接剃除.NET先,
IBM 390沒有所謂native, 以前他是用 PPC, 後來用 x86, 一直以來,
大型主機都是VM的天下, VM是必須的, 因為銀行沒人敢改已經上線的程式,
現在推雲端, 也是一堆VM, 寫程式方便, 管理方便勝過效能的重要,
這是某些老闆的看法
另一方面, google 新的雲端中心卻開始用embedded, 這說明另一類老闆,
覺得效能最重要, 接下來可能自己的cpu就會出爐了
該用哪一種, 效能不好又不能長久不換的顯然是最糟糕, 所以 .NET 可以安息了,
向下相容差, 跨平台差, 又是 VM, 這玩意高不成低不就, 丟掉就對了
→
05/26 22:21, , 29F
05/26 22:21, 29F
→
05/26 22:22, , 30F
05/26 22:22, 30F
→
05/26 22:23, , 31F
05/26 22:23, 31F
→
05/26 22:23, , 32F
05/26 22:23, 32F
→
05/26 22:26, , 33F
05/26 22:26, 33F
→
05/26 22:27, , 34F
05/26 22:27, 34F
→
05/26 22:28, , 35F
05/26 22:28, 35F
※ 編輯: sniffer 來自: 112.104.13.209 (05/27 01:31)
→
05/27 01:39, , 36F
05/27 01:39, 36F
390指令集沒有真的CPU還在賣, 這種古董CISC指令集誰去做CPU, 高速cpu以x86最便宜,
所以ibm早做了x86的z/OS, 比 osx for x86 還久
→
05/27 07:20, , 37F
05/27 07:20, 37F
→
05/27 07:21, , 38F
05/27 07:21, 38F
→
05/27 07:22, , 39F
05/27 07:22, 39F
→
05/27 07:23, , 40F
05/27 07:23, 40F
→
05/27 07:24, , 41F
05/27 07:24, 41F
→
05/27 07:25, , 42F
05/27 07:25, 42F
→
05/27 07:26, , 43F
05/27 07:26, 43F
→
05/27 07:27, , 44F
05/27 07:27, 44F
→
05/27 07:28, , 45F
05/27 07:28, 45F
→
05/27 07:28, , 46F
05/27 07:28, 46F
閱讀能力不好的人, 總是抓不到重點
重點是要效能就要用native+embedded arm
要省事就使用可以活幾十年的VM指令集, 例如IBM 390, java,
那種除了windows沒有平台可跨的IL到底拿來幹嘛用?
※ 編輯: sniffer 來自: 122.116.218.88 (05/27 12:48)
→
05/27 20:41, , 47F
05/27 20:41, 47F
→
05/27 20:43, , 48F
05/27 20:43, 48F
→
05/27 20:43, , 49F
05/27 20:43, 49F
這看誰跟誰比, x86比power系列很多cpu來得快, IBM也有用x86做super computer,
apple放棄ppc, M$開始用arm, IBM 放棄CISC改用power, alpha跟sparc消失,
沒有哪個cpu可以永生, 只有老程式必須繼續用下去
※ 編輯: sniffer 來自: 112.104.13.209 (05/28 00:08)
→
05/28 01:00, , 50F
05/28 01:00, 50F
以前P/390, 390 IS這些產品賣了很多銀行, 通常搭配OS/2 terminal,
現在新的z/OS才沒有去推x86, 但是IBM有用x86做390是事實, 你大概都只看過新機器
→
05/28 01:01, , 51F
05/28 01:01, 51F
→
05/29 21:24, , 52F
05/29 21:24, 52F
→
05/29 21:26, , 53F
05/29 21:26, 53F
→
05/29 21:30, , 54F
05/29 21:30, 54F
你不要把intermediate code跟最後的object code搞混了,
寫過dsp的人都知道不同並行指令數, 最佳化的code就是不一樣,
不知道你看得是誰家??
※ 編輯: sniffer 來自: 122.116.218.88 (05/30 18:18)
討論串 (同標題文章)
Soft_Job 近期熱門文章
PTT職涯區 即時熱門文章
54
152