基準測試本身就是一種藝術形式,通常很容易操縱結果以顯示您想要的任何內容。除了非常小的測試用例外,我不希望編譯器產生相同的結果,有時在那些小測試用例中,他們的結果要麼是相同的,要麼是有很大的不同,因爲測試已經公開了一種編譯器知道/使用的優化,其他沒有。我曾經用dhrystone跟蹤過這樣的事情(編譯器性能數字),但是在已知基準測試的情況下(不是dhrystone意味着很多,而是其他),你可能會發現一些編譯器正在調整自己到在基準測試下看起來不錯,也許會犧牲其他方面。
沒有正確的答案,沒有普遍的「最佳」,它全部在旁觀者眼中,你。哪種工具更容易使用,哪種更適合gui或漂亮的顏色或聲卡聲音或其他什麼。然後從那裏出發。
對於我已經測試過的應用程序,gnu編譯器通常不會產生代碼爲「快速」,這是我的基準測試,但有更多人使用免費的gnu工具,因此對它的支持相當寬由於網頁和論壇的數量和例子。 gnu也不會有大小限制,但它可能需要更多的學習或任何啓動和運行...
cortex-ms被拆分爲armv6m和armv7m系列,v6m(cortex-m0)只有少數thumb2擴展名,armv7m有大約150個thumbv2擴展名,所以你需要知道你的工具支持什麼,而不是在錯誤的芯片上使用錯誤的東西。然後,編譯器如果知道所有這些可能並將從相同的源代碼中產生不同的指令混合。進一步在使用不同命令行選項的相同編譯器或系列中,您可以/將獲得截然不同的代碼。除此之外,如果你有一個帶有緩存的cortex-m4,取決於代碼在緩存行中的方式,你可能會得到截然不同的性能,所以基準測試本身就是一個研究項目,你想要基準的C代碼。單個編譯器中的性能範圍可能會影響另一個編譯器,或者重疊可能足以無關緊要。
如果您有權使用這些工具,您可以通過學習使用競爭工具並能夠步入工作或工作中,從而專業地增加價值,選擇您認爲適合工作或行走的正確工具進入基爾的房子,並能立即工作或牛羚房子,並立即工作。如果你只是牛羚,那麼你可能會失去一份工作,而這份工作就是基爾的房子。
您最關心的是學習嗎?那你爲什麼關心編譯器的性能呢? Linaro和Yagarto是兩個版本的gcc(不同的庫)。我會選擇最後一個[你鏈接到的](https://launchpad.net/gcc-arm-embedded)。速度/大小數字總是基於綜合基準。採取/製作您的代碼並使用不同的編譯器進行編譯。通常他們的方式代碼將比編譯器更多地反映結果。即,具有不同'C'實現的相同算法。 –
我的主要關注點很明顯是學習,但是表現並不是一件壞事(並且很有趣)。不過,我會按照您的建議採取相同的代碼,以不同的編譯器,我會檢查哪一個我更熟悉。感謝您的評論 –
這個問題在學習環境之外同樣有效,所以請不要忽略它,「如果您正在學習,您選擇哪一個並不重要」。我沒有學習,但我的問題非常相似,我想知道商業選項是否在GNU ARM工具鏈中提供顯着的性能或代碼大小差異。 –