因此，我們都知道，Java解釋緩慢且C的編譯和優化運行速度非?？臁?您可能知道，圖片截然不同。

TL; DR Java適用于星座，它的速度更快，在JIT上可以執行內聯，因為所有方法/功能都是可見的，而C編譯器無法在編譯單元（例如庫等）上執行優化。

AC編譯器將C代碼作為輸入，對其進行編譯和優化，并生成要執行的特定CPU或體系結構的機器代碼。 這導致可執行文件，無需進一步步驟即可直接在給定計算機上運行。 另一方面，Java有一個中間步驟：字節碼。 因此，Java編譯器將Java代碼作為輸入并生成字節碼，而字節碼基本上是抽象機的機器代碼。 現在，對于每個（流行的）CPU架構，都有一個Java Virual機器，該機器模擬此抽象機器并執行（解釋）生成的字節碼。 這聽起來很慢。 但是另一方面，字節碼是可移植的，因為相同的輸出將在所有平臺上運行，因此口號“ 一次寫入，隨處運行 ”。

現在，使用上述方法，它會變得“ 寫一次，到處等待 ”，因為解釋器會很慢。 因此，現代JVM要做的就是及時編譯。 這意味著JVM在內部將字節碼轉換為用于CPU的機器代碼。 但是由于此過程非常復雜，因此Hotspot JVM （最常用的一種）僅對經常執行的代碼片段執行此操作（因此命名為Hotspot ）。 除了更快地啟動（解釋器立即啟動，JIT編譯器根據需要啟動）之外，還有另一個好處：熱點JIT已經知道經常調用什么部分，什么不經常調用-因此它可以在優化輸出時使用它–這就是我們的例子發揮作用的地方。

現在，在查看我的完整示例之前，請注意，Java具有許多功能，例如動態調度（在接口上調用方法），它還帶有運行時開銷。 因此，Java代碼可能更容易編寫，但通常仍會比C代碼慢。 但是，當涉及純數字運算時，就像下面的示例一樣，有一些有趣的發現。

因此，無需進一步討論，這是示例C代碼：

test.c：

int compute(int i);int test(int i);int main(int argc, char** argv) {int sum = 0;for(int l = 0; l < 1000; l++) {int i = 0;while(i < 2000000) {if (test(i))sum += compute(i);i++;} }return sum; }

test1.c：

int compute(int i) {return i + 1; }int test(int i) {return i % 3; }

現在，主要功能的實際計算完全不重要。 關鍵是它經常調用兩個函數（測試和計算），并且這些函數在另一個編譯單元（test1.c）中。 現在讓我們編譯并運行程序：

> gcc -O2 -c test1.c> gcc -O2 -c test.c> gcc test.o test1.o> time ./a.outreal?? ?0m6.693s user?? ?0m6.674s sys?? ?0m0.012s

因此，此過程大約需要6.6秒 。 現在讓我們看一下Java程序：

Test.java

public class Test {private static int test(int i) {return i % 3; }private static int compute(int i) {return i + 1; }private static int exec() {int sum = 0; for (int l = 0; l < 1000; l++) {int i = 0; while (i < 2000000) {if (test(i) != 0) {sum += compute(i); }i++; }}return sum; }public static void main(String[] args) {exec(); } }

現在讓我們編譯并執行以下命令：

> javac Test.java> time java Testreal??? 0m3.411s user??? 0m3.395s sys???? 0m0.030s

因此，花費3.4秒的時間 ，Java可以輕松完成此簡單任務（甚至包括JVM的緩慢啟動）。 問題是為什么？ 當然，答案是JIT可以執行C編譯器無法執行的代碼優化。 在我們的例子中是函數內聯。 當我們在自己的編譯單元中定義了兩個微型函數時，編譯器無法在編譯test.c時內聯這些函數。另一方面，JIT擁有所有方法，并且可以執行主動內聯，因此編譯后的代碼速度更快。

那么，這是一個在現實生活中從未發生過的完全異國情調的虛構例子嗎？ 是的，沒有。 當然，這是一個極端的情況，但是請考慮一下代碼中包含的所有庫。 所有這些方法都不能在C語言中進行優化，而在Java中，字節碼的來源無關緊要。 由于所有JIT都存在于正在運行的JVM中，因此JIT可以對其核心內容進行優化。 當然，C語言有一個卑鄙的技巧可以減輕這種痛苦：Marcos。 在我看來，這就是市長的原因之一，為什么C中如此之多的庫仍然使用宏而不是適當的功能-伴隨著它們帶來的所有問題和麻煩。

現在就在火焰戰爭開始之前：這兩種語言都有其長處和短處，并且在軟件工程領域都占有一席之地。 撰寫這篇文章僅是為了吸引您的注意，并想知道現代JVM每天都在發生。

翻譯自: https://www.javacodegeeks.com/2016/02/c-code-always-runs-way-faster-java-right-wrong.html

總結

以上是生活随笔為你收集整理的C代码的运行速度总是比Java快，对吧？ 错误！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。