烏克蘭文翻譯

這裡是 測試代碼 翻譯 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下完成翻譯
Java的log() 函數使用e為底算天然對數，其他說話都用10為底算對數。很奇異Java沒有基於10的log函數，這可能會影響性能。

第 二，Microsoft傳播鼓吹一樣的程式，用任何一種.NET說話編寫然後編譯到溝通的MSIL後，終究能以相同的速度運行－－這個說法確實很誘 人，Christopher固然想檢驗一下翻譯 這個基準測試的代碼相當簡單，這麼做才能保證各類.NET語言編寫的例程在功能上是同等的。 這四種說話是 不是真的速度相同呢？

闡發：
第一，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更留意切確而不是速度，所以新函數更準確可是速度更慢翻譯

I/O：
寫100萬行80個字符的數據到文本文件，然後讀回內存翻譯

第四，看看semi-compiled說話和完全诠釋說話的差別，後者的代表是Python，Perl和PHP。 目下當今有種概念是隨著硬件速度愈來愈快，價錢愈來愈便宜，天成翻譯公司們會發現編譯型說話的速度優勢會大大無用。

I/O
mathdouble
促使Christopher做這個測試的理由有5個：

後果：
Python/Psyco 成效剔除在外－－因為數字太大^_^
單元：秒
數值越小越優秀。

第 一，他很好奇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的運行時系統開消。

math

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的對數和平方根。

TOTALVisual C++9.618.86.43.510.548.8Visual C#9.723.917.74.19.965.3gcc C9.828.89.514.910.073.0Visual Basic9.823.717.74.130.785.9Visual J#9.623.917.54.235.190.4Java 1.3.114.529.619.022.112.397.6Java 1.4.29.320.26.557.110.1103.1Python/Psyco29.7615.4100.413.110.5769.1Python322.4891.9405.747.111.91679.0

點擊產看全尺寸圖表
740)this.width=740″ border=undefined>

第三，想看看Java或者.NET到底比完全編譯的C慢幾許。 Christopher開始測驗考試了把CLR從 Visual C++ benchmark中剝離出來－－用#pragma unmanaged預處置懲罰指令封閉託管特征，不外沒有成功，機能未見任何改善翻譯之後Christopher把VC法式用gcc重新編譯，以便讓C能真正的 享受當地代碼，不託管，不依賴CLR的好處。

履行每個測試前，Christopher都整頓了硬盤，重啟機械，並封閉了不需要的後台辦事。 每一個測試都運行了至少3遍，選用了最好後果。 啟動時候未計算在內。 測試的硬件情況是：
Type: Dell Latitude C640 Notebook
CPU:
Pentium 4-M 2GHz
RAM: 768MB
Hard Disk: IBM Travelstar 20GB/4500RPM
Video: Radeon Mobility 7500/32MB
OS: Windows XP Pro SP 1
File System: NTFS