本文的核心思想是，編程語言的語法簡潔度和該語言的運行效率之間其實沒有必然的聯繫，沒有理由認為Python註定比C運行得慢。只要在LLVM層更好地實現針對硬件平臺的性能優化，Python的執行效率完全可以與C相媲美。（當然這種優化技術上並不簡單，所以目前還遲遲沒有實現，但是理論上是可行的。）
此文承接“超越C語言元編程的LAPACK”和“大大優於C++元編程的LAPACK”。這兩篇文章描述了使用編譯器為你生成高性能代碼的語言技巧。但是你真的需要編譯器嗎？
另一種方法是用普通的彙編程序設計。雖然它現在已經被吹到天上去了，但這種方法還是有兩個主要缺陷。
1.彙編代碼不可移植。
2.雖然使用現代工具變得更容易，但彙編程序設計仍然需要大量繁瑣的工作。
值得慶幸的是，我們都生活在二十一世紀，這兩個問題都已得到解決。
第一個解決方案是LLVM。 最初，它意味著“低級虛擬機”，這正是我們想要確保可移植性的原因。 簡而言之，它需要一些用非常低級別的硬件無關語言編寫的代碼，併為特定的硬件平臺返回一些高度優化的本機代碼。使用LLVM，我們既具有低級編程的強大功能，又具有面向硬件的微優化的自動化。
第二個問題的解決方案是您想要的任何“腳本”語言。Scheme，Python，Perl，甚至bash或AWK都可以。它們都是為了消除繁瑣的工作而誕生的。您每天用於自動化的所有內容都可用於生成高性能的代碼。
計劃
讓我們重複我之前在帖子中對C和C ++所做的相同實驗。讓我們生成一個完全內聯的完全展開的解決方案，並將其嵌入到基準測試代碼中。該計劃如下。
1.使用Clang為基準生成LLVM中間代碼，該基準應該測量名為solve_5的不存在的函數。
2.使Python在LLVM中生成線性求解器代碼。
3.使用Python腳本劫持基準，用生成的求解器替換solve_5調用。
4.使用LLVM靜態編譯器將中間代碼轉換為機器代碼。
5.使用GNU彙編器和Clang的鏈接器將機器代碼轉換為可執行的二進制文件。
這就是它在Makefile中的樣子：
Python部分
我們需要Python中的線性求解器，就像我們使用C和C ++一樣。 這裡是：
當我們用數字運行時，我們得到了數字。但我們想要代碼。因此，讓我們製作一個假裝成數字的對象來監視算法。寫下算法希望它在準備好組裝LLVM中間語言時執行的每個操作的對象。
現在，當我們使用這種對象運行求解器時，我們得到了一個用LLVM中間語言編寫的全功能線性求解器。然後我們將它放入基準代碼中，看它有多快。
LLVM中的指令已編號，我們希望保留此枚舉，因此將我們的代碼插入到我們的基準測試中的功能並非易事。但它也不是很複雜。
實現求解器的整段代碼提供了Python-to-LLVM層，代碼插入只有100行！ 你可以在GitHub上看到它。
基準
基準測試本身在C中。當我們運行Makefile時，它對solve_5的調用被Python生成的LLVM代碼所取代。
最值得注意的是Python腳本生成的超詳細中間代碼如何變成一些非常緊湊且非常有效的硬件代碼。它也是高度超級標量化的。但它是否足以與C和C ++解決方案競爭？
以下是三種情況的近似數字：帶有技巧的C，帶有技巧的C ++和帶有Python-LLVM。
C的技巧對Clang來說並不適用，因此測量GCC版本。 它平均運行大約70毫秒。
C ++版本是用Clang構建的，運行時間為60毫秒。
Python版本（此處描述的版本）僅運行55毫秒。
當然，這種加速並不是你想要追求的東西。但它表明你可以用Python編寫的程序勝過用C或C ++編寫的程序。您不必學習一些特殊語言來創建高性能的應用程序或庫。
結論
我認為快速編譯語言和慢速腳本語言之間的二分法是虛張聲勢。本機代碼生成可能不是核心功能，而是類似可插拔選項。像一個圖書館。就像Numba for Python一樣。想想它的好處：您可以用一種語言進行研究和快速原型設計，然後使用相同的語言生成高性能的代碼。
高性能計算沒有理由保留編譯語言的特權。編譯器只是用於代碼生成的軟機器。您可以使用您想要的任何語言生成代碼。我相信如果你願意，你可以教Matlab生成超快的LLVM代碼。
所有測量均在Intel（R）Core（TM）i7-7700HQ CPU @ 2.80GHz上進行，代碼使用clang版本3.8.0-2ubuntu4和g ++ 5.4.0編譯，-march = native -O2。基準測試的源代碼可在Github上獲得。
英文原文：https://wordsandbuttons.online/outperforming_everything_with_anything.html譯者：遊騎兵
閱讀更多 Python部落 的文章
