Fortran在Computer Language Benchmark Game上的表現出奇的糟糕。今天的結果使Fortran 14和11在兩個四核測試中，單核上的第七和第十。現在，我知道基準測試從來都不是完美的，但Fortran仍然被認爲是高性能計算的語言，看起來這種基準測試中使用的問題類型應該是Fortran的優勢。在計算物理一個最近的一篇文章，Landau (2008) wrote:Fortran的表現
然而，[爪哇]是效率不高或 以及支持HPC和並行 的處理是FORTRAN和C中， 後兩種具有高度發達 編譯器還有更多科學可用的子程序庫 。 FORTRAN反過來仍然是HPC的主要語言 ，而 FORTRAN 90/95是令人驚訝的 好的，現代的和有效的語言; 但唉，幾乎沒有任何 CS部門教授，編譯器可能是 昂貴。
僅僅是因爲編譯器使用的語言槍戰（英特爾的Linux免費編譯器）？
不，這不僅僅是因爲編譯器。
像這樣的基準測試（程序不同於基準測試與基準測試）主要是程序員在編寫任何特定程序時投入的精力（以及工作質量）。我懷疑Fortran在這個特定的指標方面處於明顯的劣勢 - 與C和C++不同的是，想要嘗試讓基準測試程序更好的程序員羣體非常小，而且與其他大多數情況不同，他們可能不覺得他們有什麼可證明的。所以，沒有人花費數天時間研究生成的彙編代碼並分析程序以使其更快運行的動機。
從得到的結果中可以清楚地看出這一點。一般來說，只要有足夠的編程工作量和合適的編譯器，C，C++和Fortran都不會比彙編代碼慢得多 - 除了病態情況外，最好不要超過5-10％。事實上，這裏得到的實際結果比這個更加變化，這表明我沒有花費足夠的編程工作量。
當你允許程序集使用向量指令但是不允許C/C++/Fortran使用相應的編譯器內在函數時，也有例外 - 自動向量化甚至不是完美的近似，也許永遠不會。我不知道這裏可能適用多少。
類似地，一個例外是像字符串處理這樣的事情，你在很大程度上依賴於運行時庫（它可能具有不同的質量; Fortran很少是快速字符串庫會爲編譯器供應商賺錢的情況！） ，以及「字符串」的基本定義以及它在內存中的表示方式。
考慮到他們沒有發佈他們用於英特爾Fortran編譯器的確切編譯器選項，我對他們的基準測試幾乎沒有信心。
我也會說英特爾的數學庫MKL和AMD的數學庫ACML都使用英特爾Fortran編譯器。
編輯：
我沒有找到編譯選項，當你點擊基準的名稱。結果令人驚訝，因爲優化級別似乎合理。這可能歸結爲算法的效率。
一些隨機的想法：
的Fortran用來做非常好，因爲它更容易識別哪些做了一些優化編譯器更容易循環不變。從此
restricted和const int const *p以及C++中的inline）。不知道90或95的fortran我不能說這些是否跟上了步伐。我看過這些測試。這不像編譯器是錯誤的或什麼的。在大多數測試中，Fortran與C++相差無幾，除了一些被毆打的因素爲10.這些測試只是反映了開始時應該知道的內容 - Fortran並不是一種全能的可互操作的編程語言 - 它適用於高效計算，有很好的列表操作&的東西，但例如IO吸吮，除非你用特定的類似Fortran的方法做 - 例如'unformatted'IO。
讓我舉一個例子 - 「反向補充」程序應該從stdin逐行讀取一個大的（大小爲10^8 B）文件，用它做一些事情&打印導致大文件到標準輸出。相當直接的Fortran程序在單個內核（〜10s）上比經過優化的C++（〜1s）慢約10倍。當您嘗試播放該程序時，您會看到只有簡單的格式化讀取&寫入需要8秒以上。以Fortran的方式，如果您關心效率，那麼您只需將一個未格式化的結構寫入文件&立即閱讀（這是完全不可移植的&東西，但無論如何誰在乎 - 高效的代碼應該是快速&針對特定機器進行了優化，無法到處運行）。因此，簡短的回答是 - 不用擔心，只是做你的工作 - 如果你想編寫一個超高效的操作系統，而不是抱歉 - Fortran並不是這種性能的方式。
這個基準是愚蠢的。
例如，它們測量the whole program to run的CPU時間。由於mcmint stated（可能實際上是這樣）Fortran I/O很糟糕。但誰在乎？在現實世界的任務中，讀取輸入的時間要比計算小時/天/月的時間長一些，最後在秒內寫入輸出。這就是爲什麼在大多數基準測試中，I/O操作被排除在時間測量之外（如果您當然不自己對I/O進行基準測試）。
Norber Wiener在他的書God & Golem，Inc.寫
渲染對人這是人類和事告訴了計算機的東西是計算機。
在我看來，而在任何編程語言實現算法的這一原則使用率就是：
寫的可讀性和簡單的代碼，你可以讓編譯器做了優化。
特別是它在現實世界（巨大的）應用程序中很重要。骯髒的伎倆（在許多基準中被大量使用），即使它們可能在一定程度上提高效率（5％，也許10％）不適用於真實世界的項目。
/* C/C++使用流I/O，但Fortran傳統上使用基於記錄的I/O。 Further reading。無論如何，基準測試中的I/O都是如此令人驚訝。標準輸入/標準輸出重定向的使用可能也是問題的根源。爲什麼不簡單地使用讀/寫由語言或標準庫提供的文件的能力？再次，這將是更現實的情況。
我想說的是，即使基準沒有爲FORTRAN帶來最好的結果，這種語言仍然會使用很長一段時間。使用的原因不僅僅是性能，還有一種稱爲易編程性的東西。很多在60年代和70年代學會使用它的人現在已經太老，無法進入新的東西，他們知道如何使用FORTRAN。我的意思是，要使用的語言有很多人爲因素。程序員也很重要。
對於Fortran來說，反向補碼似乎是一個特別糟糕的結果。 – Jimmy 2009-07-28 21:34:41
你會說什麼樣的處理「反向補充」呢？ – igouy 2009-07-30 17:14:12