benchmark和性能評估綜述(編輯修改稿)

　

【文章內容簡介】 都是從內存中讀或者寫；而JIT將指令轉化為本地碼，內存的操作轉化成寄存器操作。l 分支預測虛函數是面向對象語言實現繼承的方法，在編譯階段無法確定跳轉的地址，導致編譯成為間接跳轉指令。跟條件分支指令相比，間接跳轉難于預測，因為條件分支只有一個目標地址而間接跳轉有多個。對比解釋模式和JIT模式下的分支預測率，JIT下比較好，因為JIT將虛函數轉化為內聯函數的形式，減少了間接跳轉的次數l 。3）Java server benchmark Java技術發展得非常快，不僅在客戶端，用Java語言編寫的應用在服務器端也對以前的技術有很大的沖擊，但是需要benchmark來衡量他的性能。主要衡量的方面包括數據庫服務，web服務等）VolanoMark 97年發布，歷史上第一個測試Java server JVM性能的benchmark。它是一個聊天室程序，主要用來發現Java服務器運行多個線程時候的問題。雖然能夠反映一些問題，但是不夠全面。）jBOB amp。 pBOBjBOB(Business object benchmark for Java)是一個用來衡量簡單的事務型應用的Java服務器的性能。它使用TPCC的模型，也就是說模擬的是在線事務處理（OLTP）類型的應用，但是它和TPCC側重點不同：TPCC衡量包括客戶端，網絡，服務器在內的整個系統的軟件和硬件的最大性能，但是jBOB只通過計算事務的吞吐量衡量服務器端的性能。模擬三層模型，第一層客戶端，遵循TPCC的模型，中間層Java程序是第三層數據庫服務器(JDBC)的前端。pBOB(portable business object benchmark)是設計來衡量服務的處理器存儲子系統，以及相應的軟件性能。與jBOB類似，pBOB也是根據TPCC的模型設計的。pBOB更注重純粹的Java環境的性能，為此他將第三層的數據庫表換成了Java的類和記錄，同時用Java線程替代客戶端進行輸入。）SPECjbb2000 SPECjbb2000是SPEC的第一個用來衡量Java服務器端的benchmark。SPECjbb2000也根據TPCC模型設計的。它跟pBOB類似，是一個三層的系統，主要著重于中間層也就是商業邏輯和對象操作，而客戶端用線程代替，數據庫用二叉對象樹代替。只注重服務器端的性能。軟件方面，測試JVM，JIT，garbage collection，線程，以及操作系統的一部份性能硬件方面測試CPU，cache，memory，memory，可擴展性（SMP）。）SPECjAppServer200xSPECjAppServer20012004是衡量Java Enterprise Application Servers 性能的client/server的benchmark。通過結合SPECjvm98和SPECjbb2000，利用了J2EE的API建立了一個完整的端到端 的web應用，它衡量整個系統的性能而不僅僅客戶端或者服務器端。測試Java Enterprise Application Server，JVM，SUT,RDBMS,Web Server讓通用處理器增加處理多媒體應用的能力并不是一件容易的事，因為多媒體應用跟桌面應用有非常大的不同，包括下面一些方面：l 實時響應：多媒體應用例如視頻會議需要實時響應。例如，為了達到一個穩定的輸出，跳過幾個frame的方法比為了顯示所有frame從而降低吞吐率的方法更好。l 連續的多媒體數據類型：多媒體應用的輸入一般是從模擬信號中采集出來的，很多連續的多媒體的整型數據僅僅是8bit或16bit，這對通常的桌面應用的32bit或64bit的數據寬度是個很大的浪費l 細粒度的數據并行性：對于信號處理和圖形圖像應用，數據并行性是天生的。因為有很多小的數據單元，例如象素。大都利用SIMD的方法提取細粒度的數據并行性。l 線程級并行性：大多數的多媒體應用含有多于一個的線程，例如video解碼譯碼，audio解碼譯碼以及后臺線程l 指令局部性：信號和圖像處理通常包含一些小的循環和kernel級的算法，它們在總的處理時間上占很大部分。l 需要大的存儲帶寬：一般的多媒體應用的輸入集都比較大，需要大的存儲帶寬，同時cache性能因為沒有數據局部性比較少而降低l 高的網絡帶寬：處理器的時鐘頻率或者memory帶寬的發展可能跟不上網絡速度的發展，所以可能需要新的硬件和指令集來支持。l 數據重組的能力：如果沒有數據重組的能力，即使有SIMD指令，也不能得到很大的性能的提高。因為處理器需要適應不同的數據流的格式。1） Intel Media BenchmarkIntel推出MMX指令集后，發布了Intel Media Benchmark。它的發布是因為當時并沒有足夠的工業標準的多媒體benchmark。但是并沒有發布源碼，所以不能用來MMX和其他多媒體指令集的差別。2） UCLA MediaBenchUCLA MediaBench 是為正在出現的多媒體和通信系統的應用設計的benchmark。這些應用和相應的輸入集的選擇是根據作者的經驗和市場的驅動。，包括圖像壓縮，視頻壓縮，語言編碼，語音識別，加密，圖文顯示，3D顯示。UCLA MediaBench設計中遵循的很重要的一個概念就是數據集和應用是一樣重要的。3） Berkeley Multimedia Workload在UCLA MediaBench工作基礎上建立的Benchmark，也遵循UCLA MediaBench的數據集和應用一樣重要的原則。選擇應用主要的動機是為了覆蓋更多的多媒體處理，主要考慮應用的使用人數，代碼質量(性能，魯棒性)和可維護性。4） 多媒體應用表現在體系結構方面的特點本節主要參考《Desgin and Characterization of Berkeley Multimeida Workload》。l 指令分析Berkeley multimedia workload和UCLA MediaBench和SPEC95指令的比較，這里用的是標準的編譯器，而不是針對多媒體應用的編譯器。相比之下，SPEC95偏重于浮點指令而多媒體的應用偏重shift/logical操作。l 數據寬度多媒體指令集中使用SIMD指令的原因是多媒體數據類型的寬度比較小。我們將比較SPEC95和Berkeley multimediabenchmark中數據的寬度，當然也是用的標準的編譯器，計算數據寬度的方法是看操作數前面有多少個0，然后用操作數的寬度減去0的數量。相比SPEC95，Berkeley Multimedia workload的曲線更像“膝蓋”的形狀，特別video應用的曲線，從11bit開始到32bit基本保持水平，也就說長度為1132bit的操作數基本沒有。l 局部性作者對運行Berkeley multimedia workload對cache性能進行了驗證。并沒有將指令cache和數據cache分開，而是使用的單一的cache，出人意料的是表現出來的cache缺失率跟其他應用相比是最好的，跟前面的數據局部性差似乎有沖突，我覺得可能是因為指令局部性比較好，從而使cache總體的性能比較高。l 分支預測對分支預測也做了比較，但是沒有通過誤預測率的方法，而是通過連續的taken或者not taken的次數做比較，例如對于一個分支序列“NNTTTTNNTTT”，連續的次數分別是2，4，2，3，文章中將其定義為run length可以看出Multimedia workload平均的run length更長，也就是更容易預測。但是這個結果跟以前的研究以及UCLA MediaBench的結論是不同的。但是誤預測率和平均run length之間到底是什么關系呢？是不是平均run length越大，誤預測率越低？ 網絡處理器隨著internet和網絡技術的發展，對網絡接口的要求變得越來越復雜。以前 ，網絡通信的瓶頸是帶寬，但是帶寬的主要問題已經通過光纖解決了，主要的瓶頸移到了網絡節點上。網絡應用對帶寬的需求越來越大，同時對性能，靈活性，可靠性也提出要求，例如Qos(quality of service),包解碼譯碼，動態帶寬處理等應用。這就讓我們在選擇通用