現在把目光移到benchmark上面來，它其實也是由MariaDB團隊開發的，並加了壹下額外的說明。這篇博客提到了壹個有趣的地方：把MYSQL5.6的線程數壹直增加到16，性能都很好，但是超過了16的話，盡管性能也有提升壹點點，但比較發現，遠不如其他版本(包括MairaDB-5.5.28a和MairaDB-10.0.1;參考文章頂部的性能測試圖）。這在單核計算機裏面試圖達到多核多線程的效果的並行程序時，都會有此類的通病。如果算法設計得當，隨著CPU核心數的增加，性能也會跟著提升。當然問題是，妳必須在並行程序中處理好2個方面：(1)跨多核的多線程問題(2)矢量化。這也是當前面向多核編程的兩個方向，妳編寫的必須能很好的控制這兩個方面。
如果沒有正確的編寫代碼將會得到壹個***同的結果，即在用8到16個線程的開始妳就想看到好的結果，但在這些線程運行之後妳不會看到妳期望的結果。妳將會看到這個問題，這意味這可能是算法問題。(這也不是超線程或是硬件線程造成的)這就是我們在這裏看到MySQL 基準的問題。對於我來說，這就是MySQL規模化產生問題的跡象，這也是令人擔心的原因之壹。MariaDB在同樣的基準中也有壹些小問題，但是比MySQL要輕微的多，只能說是勉強吧；我推測這個問題在並行計算中可能不會出現。
我也不知道在測試中怎樣才能很好的根據不同機器指定不同的編譯器來與之匹配。當妳為Intel編譯代碼時，妳需要為目標機器編譯生成合適的SIMD代碼；如果不匹配，妳將不會得到妳所期望執行的矢量代碼。為了能正確處理，妳需要在代碼中插入正確的編譯指示代碼，然後要寫下正確的矢量算法，最後在選擇合適的編譯器。我知道這樣看起來很愚笨，但我看過壹個發行產品用錯誤的編譯器所造成的結果是妳無法想象的。好歹，很明顯，MySQL代碼在多核和矢量化中的優化沒有MariaDB好。
(我真正想看到的是，MySQL或MariaDB的壹個分支為Intel Xeon Phi處理器核心做壹個特別的編譯，使代碼轉移到61 核心協處理器，並且有人能嘗試加速所有244個線程。可惜我沒有接觸過這樣的機器。同樣的，如果妳想學習更多關於向量化和並行方式編寫代碼方面的知識，檢索最近Intel公司 James Jeffers 與 James Reinders寫的文章“Intel Xeon Phi 協處理器高性能編程”。）
原文鏈接：parison