支持JITed語言（例如C＃和Java）的參數是它們可以更好地執行優化，因爲虛擬機的運行時分析可以比靜態優化的C++代碼更好地優化代碼。用於優化性能的C++虛擬機
但是，我想知道我們是否也可以使用虛擬機在運行時爲C++優化代碼，或者更確切地說任何類似的語言。例如，我們可以採用由LLVM編譯器生成的IR，並創建一個解釋，JIT和優化代碼的虛擬機，與Java和C＃的情況類似。
當然，不會有垃圾回收，但優化因子會在那裏。有沒有人在此工作。是否有任何文件，工具？這種方法有多好？
從理論上講，是的，JIT可以用於C++。它可以利用底層體系結構中的一些優勢來積極優化代碼。它也會帶來使應用程序花費更長時間在運行時加載的缺點。
當然，不會有垃圾回收，因此會產生開銷，但優化因素會在那裏。有 任何人都在此工作。是否有任何文件，工具？這種方法有多好？ ？
這裏有一個很大的誤解。爲每個用戶定義的類型在整個板上實施GC是主要的開銷。這是Android，iOS和Windows移動已經轉向使用C/C++的高性能應用的原因之一，儘管它最初只嘗試使用託管虛擬機。
當然，額外的間接級別意味着GC可以自由地執行緊湊內存等操作，但優化的C/C++程序從一開始就已經使用了緊湊的內存。這也意味着內存開始時會更加分散，對於C++擅長的高性能應用程序來說，這是一種性能殺手（它可以處理大型連續的緩衝區，例如視頻處理，光線追蹤或音頻處理）。
同時將每個UDT實例轉換爲引用意味着所有內容都位於堆上，這有效地將原本只有幾個時鐘週期的操作轉換爲數百個。這就是說，爲了得到你的問題的核心，當然，C++代碼可以使用JIT構建，但是你可能會發現沒有真正如此令人信服的理由來做這樣的事情，人們通常使用C++代碼。
通過說「沒有垃圾回收，因此會產生開銷」，我說因爲沒有垃圾回收，開銷會更少。你以另一種方式閱讀它:)！ – MetallicPriest 2012-02-29 20:07:57
@MetallicPriest哦，我的糟糕，我認爲這句話意味着會有開銷，因爲缺乏GC。我習慣於C＃/ Java愛好者經常聲稱GC以某種方式使事情變得更快。確實，當我們不在尋找時，它可以壓縮內存，但我們首先需要質疑爲什麼它需要這樣做，而在C++中，我們可以創建用戶定義類型的連續緊湊數組（如矩陣）的權利從一開始。 – stinky472 2012-02-29 20:17:16
LLVM包含一個JIT編譯器lli，Clang已經可以從C++生成位碼。我沒有嘗試過，但我假設你可以在生成的位碼文件上使用lli（你可能必須告訴它在哪裏找到要鏈接的C++ lib文件）以及運行時的JIT C++。您甚至應該能夠將libC++構建爲位代碼，以便它可以被JIT控制。
Google的Native Client有一個子項目Portable Native Client，我認爲LLVM IR發送給客戶端，而不是x86二進制文件，以便在客戶端進行連接。
這是一個有缺陷的論點。是的，虛擬機可以使用更多的信息 - 但與編譯器相比，它們的時間和空間也大大減少。
另外，是的，絕對你可以做到這一點，如果你真的想。但是沒有人會這樣做，所以它通常不會發生。至少，不是出於優化的原因，你可以做沙盒。
您可以像Clang那樣將C++預編譯爲字節碼，此時您可以進行許多優化。 – Xeo 2012-02-29 20:10:41
@Xeo：理論上是的。但是C/C++優化器非常陳舊（以計算機方式），而且做得相當好。所以也許任何額外的性能收益可以忽略不計。很高興看到有人發表論文（可能他們已經嘗試過發現它沒有結果）。 – 2012-02-29 20:25:37
[谷歌搜索「Clang」+「JIT」]（https://www.google.com/search?q=clang+jit）提取大量信息。 – ruakh 2012-02-29 20:01:29
Google在更新Chrome時會做一些有趣的事情...程序會部分反編譯，以便獲得某種符號形式，然後將更新作爲該形式的補丁應用，然後將其編譯回來。而且，在那些日子裏，人們會編寫多態程序，在運行時重寫自己（例如，當他們檢測到「if」條件永遠不會是錯誤的時候，他們只會用「nop」替換指令）。所以，沒有理由不可行。我甚至不提「可能」，因爲我們知道是這樣。 – 2012-02-29 20:12:29
他們確實可以優化得更好，但他們不會。 – 2012-02-29 20:13:19