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

[sniffer (again)]

※ 引述《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
→ iincho:啊..java那堆硬體加速真的有人用嗎?
有, 主要用途都是當 firmware, 控制硬體, 反正都隱藏在機器裡,
手機晶片也有, 但是baseband打不過q跟t, 所以最後都用他們, 重點不在cpu
※ 編輯: sniffer         來自: 122.116.218.88       (05/26 13:52)
推 reiasu:arm好像就有了？
ti omap 都是 ARMxxxE-J, J 就是 java 加速
※ 編輯: sniffer         來自: 122.116.218.88       (05/26 14:23)
→ iincho:ARM有是有，能不能舉幾個軟體實作有用到這個feature的?
j2me 產品就有用到, 當然 android 沒有, 架構不同, 執行效能沒 JIT 快,
但是對需要啟動快的 browser or BD-J 還是很有用, 並不是 android 沒在用就都沒用,
nokia symbian 手機一大堆, BD 播放機一大堆, 觀點不要太狹窄
※ 編輯: sniffer         來自: 122.116.218.88       (05/26 17:55)
→ iincho:你講的是手機這塊，問題在非embedded system這塊JVM...
→ iincho:基本上討不到便宜，我想這邊會幹起來的原因只是如此...
→ iincho:而且前面討論的ˇㄉ範圍看起並不是你講的這些東西，這樣另
→ iincho:開戰場來叫人眼光不要這麼窄我覺得不大厚道...
→ iincho:我會挑那句來問的理由很簡單，大型主機的實作上我還沒見過
→ iincho:這些Java Chip有什麼可以大書特書的功能，而且實際上在大型
→ iincho:軟體上我認為Aurim講的並沒有太大錯誤。
→ iincho:而且，你舉的這些產品會動到這個功能主要原因是CPU不夠力
→ iincho:過去我們也針對特定的應用做過ASIC，但是後來發現在目前越
→ iincho:來越快的CPU的發展下，這些東西基本上沒有太大好處...
→ iincho:所以不同情況下有不同結論應該是很正常的...
→ iincho:而且這塊Microsoft本來就沒有放太多心力下去，過去WM的主力
→ iincho:所以拿這段去打IL沒有甚麼道理....
→ iincho:因為WM之前的主力根本不是.NET...這種問題還是等等再說吧
→ iincho:嘛..打這麼多錯字我先道歉XD, 總之...差不多就是這樣
→ Lordaeron:大型主機是指mainframe? 還是指?
→ iincho:我用字不大精確，就當CPU快RAM多到爆的那種機器吧...
→ iincho:這種機器上搞特定HW加速大部份的功能都會變雞肋, 所以我很
→ iincho:懷疑這樣的使用環境下討論Java硬體加速是否有意義....
→ iincho:而且這裡有些字義的問題，當你的硬體直接support VM某些功
→ Lordaeron:CPU 最快就3G Hz, 再多,也就512顆for single OS support
→ iincho:能的時候，這些code到底算不算native code....?
→ iincho:OK，你說CPU就只這麼快，那請問這種環境下哪一個商用軟體
→ Lordaeron:而java 晶片,從j2me 出來後,就有一陣子(不到一年)
→ iincho:的賣點是"我們支援JVM加速"?
討論題目是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, 這玩意高不成低不就, 丟掉就對了
→ Lordaeron:在吵得很熱鬧,因為可以用在手機, 晶片卡等等的地方
→ iincho:問題在於脫離了CPU很慢的狀況，很少人會拿Java加速當賣點啊
→ Lordaeron:應該是沒有吧
→ iincho:前面擺明的就不是在講這種環境不是? 所以拿這個去打沒意思
→ iincho:這串從扯手機開始就偏掉了，然後後面當然越來越鬼打牆...
→ iincho:因為.NET的主力有很長一段時間不是這塊....
→ iincho:所以到底IL好不好，恐怕還要等WP出來再一陣子才能評估
※ 編輯: sniffer         來自: 112.104.13.209       (05/27 01:31)
→ Lordaeron:mainframe 還是power pc 有用x86? 你是哪家IBM?
390指令集沒有真的CPU還在賣, 這種古董CISC指令集誰去做CPU, 高速cpu以x86最便宜,
所以ibm早做了x86的z/OS, 比 osx for x86 還久
→ iincho:我真的覺得這是張飛打岳飛..XD....
→ iincho:VM一定會影響效能，只是帶來的好處值不值得這樣換
→ iincho:你講不影響效能又扯到硬體，問題是再那種環境下幾乎沒人
→ iincho:和你提硬體加速，所以這並不能證明是因為效能好所以用VM..
→ iincho:不過我倒是對.NET和Java在一般x86的peformance比較有點好奇
→ iincho:另外，你舉的例子我看不出來用VM和效能有什麼關係...
→ iincho:所以實在不知道你要表達甚麼，IL很爛?
→ iincho:而且你提的硬體例子幾乎都是為了某些特殊功能再最佳化的
→ iincho:case，拿來戰一般使用環境的東西沒有太大意義....
→ iincho:就算Google開始用embedded那也不代表甚麼，真的...
閱讀能力不好的人, 總是抓不到重點
重點是要效能就要用native+embedded arm
要省事就使用可以活幾十年的VM指令集, 例如IBM 390, java,
那種除了windows沒有平台可跨的IL到底拿來幹嘛用?
※ 編輯: sniffer         來自: 122.116.218.88       (05/27 12:48)
→ Lordaeron:Z/OS for x86 跟x86 版的mainframe 是兩件事
→ Lordaeron:mainframe 是除了OS 以還包括硬體,而你講的叫
→ Lordaeron:softwaremainframe, 就硬體的效能來說就不是IBM的主力
這看誰跟誰比, 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)
→ Lordaeron:請問哪一家買了IBM 的x86 mainframe?
以前P/390, 390 IS這些產品賣了很多銀行, 通常搭配OS/2 terminal,
現在新的z/OS才沒有去推x86, 但是IBM有用x86做390是事實, 你大概都只看過新機器
→ Lordaeron:還有,alpha 跟sparc 沒消失, 是你沒遇到而已
→ Aurim:我看過的GPU driver source code還真沒按core數在改JIT的。
→ Aurim:硬體改良時，增加的單位時間所能處理工作量本來就是原生>VM
→ Aurim:Intel的新鮮事，我就先不說了。
你不要把intermediate code跟最後的object code搞混了,
寫過dsp的人都知道不同並行指令數, 最佳化的code就是不一樣,
不知道你看得是誰家??
※ 編輯: sniffer         來自: 122.116.218.88       (05/30 18:18)