印尼語翻譯 I/O
這個Benchmark利用了各種數據類型測試數學和三角函數,簡單的文件I/O。 所有測試都在運行Windows XP的Pentium 4機器上完成。
這是個小範圍的基準測試,觸及9種現代說話或其變種:Java 1.3.1翻譯社 Java 1.4.2,利用gcc 3.3.1編譯的C,Python 2.3.2,利用 Psyco 1.1.1 編譯的Python,四種Visual Studio .NET 2003支撐的語言:Visual Basic, Visual C#, Visual C++和Visual J#翻譯
int 這裡是 測試代碼 翻譯 Java
1.3.1, Java 1.4.2和Visual J#利用的是不異代碼。 Visual C++和gcc
C使用幾乎不異代碼。 C程序在Cygwin下用gcc編譯。Psyco:增加import
psyco和psyco.full()到Python代船埠部翻譯 四個Microsoft語言的測試在Microsoft Visual Studio
.NET 2003下完成翻譯 I/O: 編譯及優化等選項: 第 二,Microsoft傳播鼓吹同樣的程式,用任何一種.NET說話編寫然後編譯到不異的MSIL後,終究能以不異的速度運行--這個說法確切很誘 人,Christopher固然想磨練一下翻譯 這個基準測試的代碼相當簡單,這麼做才能包管各種.NET說話編寫的例程在功能上是同等的。 這四種語言是 不是真的速度相同呢? math | long 第四,看看semi-compiled語言和完全注釋語言的不同,後者的代表是Python,Perl和PHP。 而今有種概念是跟著硬件速度愈來愈快,價錢愈來愈廉價,天成翻譯公司們會發現編譯型說話的速度優勢會大大無用翻譯 執行每一個測試前,Christopher都收拾整頓了硬盤,重啟機械,並封閉了不需要的後台辦事翻譯 每一個測試都運行了至少3遍,選用了最好效果。 啟動時間未較量爭論在內。 測試的硬件情況是: | double TOTAL | ||||
Visual C++ | 9.6 | 18.8 | 6.4 | 3.5 | 10.5 | 48.8 |
Visual C# | 9.7 | 23.9 | 17.7 | 4.1 | 9.9 | 65.3 |
gcc C | 9.8 | 28.8 | 9.5 | 14.9 | 10.0 | 73.0 |
Visual Basic | 9.8 | 23.7 | 17.7 | 4.1 | 30.7 | 85.9 |
Visual J# | 9.6 | 23.9 | 17.5 | 4.2 | 35.1 | 90.4 |
Java 1.3.1 | 14.5 | 29.6 | 19.0 | 22.1 | 12.3 | 97.6 |
Java 1.4.2 | 9.3 | 20.2 | 6.5 | 57.1 | 10.1 | 103.1 |
Python/Psyco | 29.7 | 615.4 | 100.4 | 13.1 | 10.5 | 769.1 |
Python | 322.4 | 891.9 | 405.7 | 47.1 | 11.9 | 1679.0 |
設 計傑出的測試案例的確是fiendishly difficult。 Christopher只測試了數學運算(32位整數算術運算,64位整數算術,64位浮點算術,64位三角運算),以後是按次訪 問的文件I/O。 測試其實不復雜,沒有涉及字符串處置,圖形,對象創建與辦理(對面向對象語言),複雜數據結構,收集訪問,數據庫拜候。 測試雖簡單,不 過能給出各類說話效力到底若何的大致印象。
第三,想看看Java或.NET到底比完全編譯的C慢幾何。 Christopher起頭測驗考試了把CLR從 Visual C++ benchmark中剝離出來--用#pragma unmanaged預處置指令封閉託管特征,不外沒有成功,性能未見任何改良翻譯之後Christopher把VC程序用gcc從新編譯,以便讓C能真正的 享受當地代碼,不託管,不依靠CLR的好處。
結果:
Python/Psyco 了局剔除在外--因為數字太大^_^
單元:秒
數值越小越優異翻譯
點擊產看全尺寸圖表
740)this.width=740″ border=undefined>
32位整數運算:
使用32位循環計數器和32位整數操作數,輪回從1到100萬。 忽略餘數。
1 – 1 + 2 * 3 / 4 – 5 + 6 * 7 / 8 – … – 999,999翻譯社997 + 999翻譯社999,998 * 999,999翻譯社999 / 1,000,000,000
64位整數運算:
算法同上,換為使用64位輪回計數器和操作數。 循環從100億到110億。
64位浮點算術:
和64位整數算術算法不異,不外利用64位浮點輪回計數器和操作數,不疏忽餘數。
64位浮點三角函數:
利用64位浮點循環計數器,計較從1到1萬萬的所有值的sin,cos,tg,基於10的對數和平方根。
第
一,他很好奇Java 1.4.2--最新的官方Java發布版--和Microsoft的.NET 2003
系列說話誰的性能更好。 Java和.NET
說話都是semi-compiled或說semi-interpreted的。 源碼都被編譯成中心代碼,然後與诠釋器或JIT編譯器一同運行翻譯 對
Java來講,中央代碼就是字節碼,解釋器/編譯器就是Java虛擬機JVM;.NET世界裡的源碼被編譯成Microsoft中央語言MSIL,運行
在.NET公共說話運行時引擎上翻譯
除了具有令Java廣受迎接的特性比如主動資源辦理,垃圾搜集和類型平安外,.NET還有些新特征,好比跨說話調試,簡易的GUI設計和極為直白的應用部
署方式。 不過,這些特性會帶來性能損失嗎? 在對其編程模式增添了複雜的層次佈局後,Microsoft是不是抛卻了其對Java的速度優勢?
Christopher的設法是,Microsoft供給的J#是一個Java 1.1.4規範的Java實現,仿佛可以用這玩意來和Java比照,後果應該可以反映出SUN和Microsoft的運行時系統開銷。
闡明:
第一,Java(最少1.4.2的Java)和.NET
2003系列說話比,在大大都測試中浮現都很不錯。 除了三角計較,Java事實上和VC--Microsoft最快的說話--一樣快翻譯 不外Java的
三角也太差了,連注釋履行的Python都不如。 讓人利誘的是1.3.1的三角浮現不錯翻譯
第二,Microsoft宣稱的所有的4種.NET說話都編譯成MSIL仿佛確有其事--最少對數學函數。 整數算術運算的成績4種說話幾近溝通翻譯 長整
數,雙精度和三角成果:VC#,VB和VJ#相同,不外C++編譯器輸出了令人印象深入的快速代碼翻譯 可能C++能更好地利用Pentium
4的SSE2 SIMD擴大完成算術和三角運算--僅是猜想。 I/O測試兩極分化,Visual Basic 和Visual
J#明顯在利用I/O例程上效力比VC#和VC低。 很顯明,功能不異的代碼並沒有編譯成相同的MSIL代碼。
第三,Java 1.4.2和gcc C一樣優異乃至更好--除三角較量爭論外。 這是此次測試裡最讓人受驚的地方翻譯 平常合乎人人邏輯的猜想是在JVM中運行字節碼會帶來某種機能損失--和當地機械碼比較。 在這次測試中,這個推斷明顯不知為什麼不成立。
第四,全诠釋履行的Python,和推想的一樣,比任何全編譯或半編譯的說話都慢良多--又是乃至有1/60的差距。 不過I/O機能
上,Python和最快的說話也屬於統一陣營,並且比VB和VJ#快。 Psyco編譯器能為Python締造奇蹟,為數學和三角計較削減了10%到
70%的時候--和未經Psyco編譯的Python比。 和把Psyco 包括到Python中的簡單比擬,這個機能晉升是多麼驚人啊。
第五,Java 1.4.2比Java 1.3.1在算術上快良多。 不外,前面提過,三角運算則掉隊了翻譯 Christopher
猜想1.4.2中應該還有不同的,更有用地調用三角函數的方式。 還有一種可能是1.4.2更留意精確而不是速度,所以新函數更準確然則速度更慢翻譯
最後,Christopher想看看Java前後不同版本之間的差別--這壞小子翻譯 SUN關於1.4.2機能提升的大牛皮早就吹出來了,所以我們這次也測測Java 1.3.1到底和1.4.2差別有多大。
來自: http://blog.udn.com/DreamYeh/8597936有關各國語文翻譯公證的問題歡迎諮詢天成翻譯公司02-77260931
留言列表