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

看板Soft_Job作者lgd1008 (lgd1008)時間14年前 (2011/05/24 13:59)推噓1(1推 0噓 17→)

留言18則, 4人參與討論串42/52 (看更多)

※ 引述《Aurim (Who cares?)》之銘言： : ※ 引述《lgd1008 (lgd1008)》之銘言： : : 不要只把 VM, GC 算進 overhead, 而不同時考慮他們可能對效能產生的幫助, : 請試舉一例VM/GC對整體效能有幫助的例子。 : : CPU的指令己是VC++執行時的全部, 但並非 .net, Java執行時的全部 : 這句話在我聽來相當不切實際，莫非.net/java不需要CPU？ : 凡是以CPU執行的，最後都是要用CPU的指令去跑的， : 中間多做事情只是多花時間的，跑愈多指令去做一件事只是用更多時間去完成那事。 : 就假設所有指令都可以在單個clock內完成的RISC來說，執行每個指令都只要1 cycle， : 所有演算法的時間複雜度直接與跑了多少個CPU指令在統計上就是絕對正相關。 : 你可以爭論說，GC可以在某種程度上改善你跑的演算法花在釋放記憶體的代價； : 但是整體觀之，那不過是朝三暮四的效果，該做的事情最後還是都要做，而且付出了 : 更大的效能代價去做，因為你還要多花時間去爬垃圾堆，看是不是該清垃圾了， : 而不是在垃圾丟出來時就馬上清掉。 : IKVM.net的作者都會常常關注Java VM JIT生出來的code與他的IKVM將Java bytecode : 轉成IL code再生成原生code後的指令數差距、對CPU管線利用率的影響了。 : : 會拿看起來 VM, GC 是 overhead 的情況去看 Java, .net : : 那怎麼不拿非 VM, GC 存在不可的情況去看 VC++ 呢? : : 如果你真的完全不想這種可能性, 應該早就值疑上篇測試的結果作假了.. : 前面有人留言說愈快的CPU上那overhead應該愈低，我說在單純只是時脈提升的情形下， : 因為要跑的CPU指令數沒變，總cycle數也不會因為CPU用比較快的clock跑就會減少， : 那overhead percentagle還是沒變－本來是5%的就還是5%，本來是30%的就還是30%， : 除非JIT的最佳化做得更好，減少產生出來的指令數，用跑更快的指令排列去應用CPU的 : 管線最佳化，不然在單純CPU時脈提升的情形下，這些overhead的比例根本不會降，只會 : 讓實質的絕對差距愈拉愈大－直接編譯成原生碼的軟體可以利用這愈拉愈大的差距來做 : 更多事。 : 表面上，你看到VM跑的code與編譯為原生碼程式間的執行時間差隨著機器變快而減少， : 可是能處理的工作量的增長是如何呢？ : 為了方便計算，假設本來VM生出來的code跑一圈要2M cycle，編譯成原生碼跑一圈只要 : 1M cycle。在100MHz的CPU上執行時間比會是兩秒比一秒，在200MHz的CPU上會變成一秒 : 比半秒。你可以說，使用VM的語言與原生碼語言間的差距縮小了一倍，從一秒縮成半秒 : ；我也可以說，可是一樣的code在一秒內能處理的工作量差距拉大了，從本來的0.5件 : 比一件，變成一件比兩件，中間差距從0.5拉大到1。當CPU clock拉高到1GHz，這一秒內 : 可完成工作量的差距已經從100MHz時的0.5件工作拉大到1GHz的5件，中間差4.5件工作。 : 如果18個月後CPU時脈提高成2GHz，兩份code每秒完成工作量的差距會拉大到10件。 : 因為現實上看起來差距好像沒那麼大，所以對VM有著美夢的人還在繼續作夢。 : 5%的差距看起來好像沒什麼，可是已經足夠原生碼的新版程式多做一堆小動作了。 : 當這差距拉大到10%、20%、30%，又是個什麼樣的境地？你以為VM慢的真的只在IO與GC？ : iOS device用的CPU現在確實是還不太快，Android device用的CPU也沒比較好到哪去。 : 以後CPU clock會繼續往上拉，也許VM派的人會想：這中間時間差距不是縮小了嗎？ : 可是當我們回到現實看單位時間內能做的事情，原生碼能負擔的工作量成長比VM能做 : 的工作量成長要快，所以在許多小地方可以提供更好的表現。 : 那考慮CPU架構改善的場合，情形又是如何？ : 如果JIT沒與時俱進的配合CPU的改良來生出最佳化的code，根本享受不到這方面的好處。 : C/C++編譯器都得改版來加入配合新CPU特性的最佳化功能了。 : 大家一樣是用ARM based CPU，各家做CPU的巧妙各有不同，Java JIT真能對各家ARM : based CPU應用各CPU獨家的最佳化技巧？指令怎麼排列的執行速度都有差了，還要一家 : 一種排法，慢慢等比較快。 : .NET起碼還可以在安裝時先把IL code executable編譯一遍存一份native code image， : 離線的最佳化可以做更多事，Windows on ARM也大可真的配合各家CPU來做這種時候的 : 最佳化。Java哪時候要照著玩這招？ : 要不要把GPU與其他平行處理單元再考慮進來？ 1. CPU指令不是執行的全部, 我應該改成, 你所寫下的程式指令, 並不是執行時的全部. 就如同一隻程式, 你在windows裡執行時的效能是A, 改成linux版時的執行效能是B, 執行效能不一樣. why? 是什麼在影響? 是你選擇的OS影響了. OS會影響程式真正執行的方式 . 同樣的, 你對於 VM 的選擇採用也會影響真正執行方式, 就如同於你對不同 OS 的選擇 , 不同 API 的選擇. 2. GC 真的沒那麼罪惡, linux kernel 裡的 slab allocator 做的就是 GC 做的事, 也許你早己在用只是沒有發現. 但它是一個簡單的版本, 因為對於kernel的環境, 設計者覺得那樣夠用了. 而JVM裡的GC是一個更複雜的版本. GC 之類的行為, 只會成執行時 overhead? "朝三暮四" 地對於效能只減不增? 那也許你應該先問問 slab allocator 那派人的說法, 若是背景相近的故事應該比較能說服你. -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.43.9.124

→

francej

05/24 14:51, , 1^F

05/24 14:51, 1^F

→

francej

05/24 14:51, , 2^F

05/24 14:51, 2^F

→

francej

05/24 14:52, , 3^F

05/24 14:52, 3^F