TACLeBench中內(nèi)核程序循環(huán)級(jí)推測(cè)并行性分析

孟慧玲，王耀彬*，李 凌，楊 洋，王欣夷，劉志勤

（1.西南科技大學(xué)計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院，綿陽四川 621010；2.四川省計(jì)算機(jī)研究院，成都 610041）

（*通信作者電子郵箱wangyaobin@foxmail.com）

0 引言

當(dāng)前多核平臺(tái)加速串行程序時(shí)，存在數(shù)據(jù)依賴限制以及資源利用率低等問題［1-2］，線程級(jí)推測(cè)（Thread-Level Speculation，TLS）技術(shù)［3-4］可開發(fā)出更多可用的線程級(jí)并行性，保證程序正確性的同時(shí)，提高程序性能，成為有效利用多核處理器的途徑之一。該技術(shù)將需要執(zhí)行的串行程序分為一個(gè)非推測(cè)線程和多個(gè)推測(cè)線程，使多個(gè)線程并行執(zhí)行［5］；同時(shí)保持程序的原始順序，打破線程間的數(shù)據(jù)依賴對(duì)線程并行執(zhí)行造成的影響，減少程序執(zhí)行時(shí)間，提高加速比。

威斯康星大學(xué)首次將Multiscalar［6］作為線程級(jí)推測(cè)方案提出后，各種不同的線程級(jí)推測(cè)方案開始陸續(xù)出現(xiàn)。例如斯坦福大學(xué)研發(fā)的Hydra 技術(shù)方案［7］、Hammond 等［8］提出的TCC（Transactional Coherence and Consistency）技術(shù)方案、卡內(nèi)基梅隆大學(xué)提出的STAMPede技術(shù)方案［9］等。目前，劉斌等［10］提出了一種基于性能推測(cè)的線程循環(huán)選擇方法，最終Olden 基準(zhǔn)測(cè)試集加速比性能平均提升了12.34%；李美蓉等［11］提出了一種自適應(yīng)的循環(huán)并行粒度調(diào)節(jié)方法，提升了SPEC CPU 基準(zhǔn)測(cè)試集性能，并減少了推測(cè)開銷；Salamanca 等［12］對(duì)硬件事務(wù)內(nèi)存（Hardware Transactional Memory，HTM）支持與線程級(jí)推測(cè)（TLS）的循環(huán)并行化的應(yīng)用進(jìn)行了詳細(xì)分析，并描述了在此類機(jī)器中HTM 上實(shí)現(xiàn)TLS 的仔細(xì)評(píng)估，實(shí)驗(yàn)結(jié)果表明，某些循環(huán)加速比可達(dá)到3.8。可以看出，TLS技術(shù)已在多種串行程序并行化工作中得到有效應(yīng)用。

TACLeBench［13］是來自全球多個(gè)不同研究小組和工具供應(yīng)商的基準(zhǔn)測(cè)試程序集合。文獻(xiàn)［14］使用TACLeBench 基準(zhǔn)，通過仿真多核ARM（Advancd RISC Machine）處理器來驗(yàn)證mcQEMU 模擬器時(shí)間模型，實(shí)驗(yàn)結(jié)果表明，與四核NXP i.MX6Quad 處理器相比，mcQEMU 的時(shí)間估計(jì)誤差平均僅為15%；文獻(xiàn)［15］利用TACLeBench 基準(zhǔn)對(duì)GCC（GNU Compiler Collection）與LLVM（Low Level Virtual Machine）進(jìn)行比較，結(jié)果顯示，LLVM 在88%的實(shí)驗(yàn)中編譯速度更快，而在51%的實(shí)驗(yàn)中，GCC 與LLVM 產(chǎn)生的二進(jìn)制大小幾乎相同；文獻(xiàn)［16］利用TACLeBench 基準(zhǔn)驗(yàn)證設(shè)計(jì)的重用檢測(cè)方法，并針對(duì)不同數(shù)據(jù)的訪問進(jìn)行表征，發(fā)現(xiàn)優(yōu)化后，最壞情況下數(shù)據(jù)訪問的時(shí)間可減少到6.5%。但目前，TACLeBench 內(nèi)核基準(zhǔn)仍未在線程級(jí)推測(cè)方面得到有效分析。

本文主要目的是分析將TLS 技術(shù)應(yīng)用于TACLeBench 中內(nèi)核基準(zhǔn)程序時(shí)，程序循環(huán)結(jié)構(gòu)在推測(cè)并行化中的性能提升潛能。在TACLeBench 用于實(shí)現(xiàn)小型內(nèi)核功能的基準(zhǔn)中，選取7 個(gè)具有代表性的程序，設(shè)計(jì)了一種動(dòng)態(tài)剖析機(jī)制，結(jié)合核心數(shù)據(jù)結(jié)構(gòu)計(jì)算循環(huán)部分讀寫時(shí)間，分析程序線程粒度、并行區(qū)域覆蓋率、線程間數(shù)據(jù)依賴特征對(duì)程序加速比大小的影響，并綜合程序加速比與資源利用率判斷內(nèi)核基準(zhǔn)程序適宜處理器核心數(shù)目范圍。

1 推測(cè)模型和剖析機(jī)制

1.1 推測(cè)模型

線程推測(cè)方案對(duì)象通常為程序循環(huán)結(jié)構(gòu)或子程序。由于循環(huán)迭代獨(dú)立性較強(qiáng)，可反復(fù)執(zhí)行導(dǎo)致循環(huán)結(jié)構(gòu)所需執(zhí)行時(shí)間較長(zhǎng)，并且循環(huán)結(jié)構(gòu)確定線程的開始和結(jié)束相對(duì)容易［17］，因此目前推測(cè)并行技術(shù)主要針對(duì)程序循環(huán)結(jié)構(gòu)進(jìn)行分析，本文也針對(duì)程序循環(huán)結(jié)構(gòu)展開研究。

循環(huán)推測(cè)［17-18］將每個(gè)循環(huán)部分分別作為推測(cè)對(duì)象，循環(huán)推測(cè)并行執(zhí)行時(shí)，只需維持一個(gè)非推測(cè)線程，其余推測(cè)線程在非推測(cè)線程執(zhí)行結(jié)束后，得到非推測(cè)權(quán)限，從而成為下一個(gè)非推測(cè)線程來維護(hù)程序正確性。圖1 展示了傳統(tǒng)的串行執(zhí)行方式，程序按照順序依次執(zhí)行。圖2 為循環(huán)結(jié)構(gòu)的推測(cè)執(zhí)行方式，在推測(cè)執(zhí)行過程中，當(dāng)有線程產(chǎn)生時(shí)，頭處理器首先響應(yīng)該線程，并分發(fā)“Loop_Start”的信號(hào)告知其他處理器加載循環(huán)的各個(gè)迭代。當(dāng)頭處理器處理完當(dāng)前線程后，邏輯上的下一個(gè)處理器成為新的頭處理器繼續(xù)處理該線程。當(dāng)最后一個(gè)處理器處理完成后，會(huì)發(fā)送“Loop_End”信號(hào)結(jié)束當(dāng)前線程的循環(huán)迭代執(zhí)行。為保證剖析機(jī)制的速度與開銷，以及開發(fā)程序線程級(jí)推測(cè)并行性，本文的推測(cè)模型為與平臺(tái)無關(guān)的理想機(jī)器模型，在該模型中，線程的生成、提交和回退沒有開銷。

圖1 串行執(zhí)行模型Fig.1 Serial execution model

圖2 循環(huán)結(jié)構(gòu)推測(cè)執(zhí)行模型Fig.2 Loop structure speculative execution model

1.2 剖析機(jī)制

利用剖析技術(shù)對(duì)程序運(yùn)行時(shí)特征進(jìn)行剖析操作能提高線程推測(cè)的成功率，在一定程度上對(duì)程序進(jìn)行正確性維護(hù)，從而保證程序運(yùn)行的正確性，并提高程序并行效率。該技術(shù)在程序預(yù)執(zhí)行后，搜集相關(guān)信息并反饋給編譯器，令編譯器進(jìn)行線程劃分。本文設(shè)計(jì)了針對(duì)程序循環(huán)結(jié)構(gòu)的剖析工具Proloop，利用該工具剖析程序可得到程序并行區(qū)域覆蓋率、線程粒度、數(shù)據(jù)間依賴等信息。

本文相關(guān)剖析方案如圖3 所示：首先使用GNU Prof 工具對(duì)程序進(jìn)行初始化分析，得到函數(shù)運(yùn)行時(shí)間，選取程序運(yùn)行時(shí)間超過5%的部分為候選程序代碼片段，并在其循環(huán)結(jié)構(gòu)中插入剖析標(biāo)識(shí)；隨后使用交叉編譯工具對(duì)選中的片段進(jìn)行交叉編譯操作，得到剖析工具可識(shí)別的文件；最后利用ProLoop對(duì)所選中的片段進(jìn)行剖析，使用ThreadList鏈保存推測(cè)線程相關(guān)信息，hash 表保存訪存操作相關(guān)信息。結(jié)合剖析所得線程粒度、線程間數(shù)據(jù)依賴程度等數(shù)據(jù)與程序源碼進(jìn)行對(duì)比分析后，得出綜合分析結(jié)果。

圖3 循環(huán)結(jié)構(gòu)剖析方案設(shè)計(jì)Fig.3 Loop structure analysis scheme design

程序循環(huán)標(biāo)識(shí)如圖4 所示，在程序循環(huán)結(jié)構(gòu)中，插入的兩個(gè)循環(huán)標(biāo)識(shí)分別為profiling_loop_start 和profiling_loop_end。其中profiling_loop_start 接收循環(huán)標(biāo)識(shí)以及循環(huán)變量地址，而profiling_loop_end則代表循環(huán)結(jié)構(gòu)結(jié)束。在程序執(zhí)行過程中，循環(huán)id被保存在4號(hào)寄存器中，循環(huán)變量地址則保存在5號(hào)寄存器中。

圖4 循環(huán)標(biāo)識(shí)示意圖Fig.4 Schematic diagram of loop identifier

循環(huán)結(jié)構(gòu)剖析的核心數(shù)據(jù)結(jié)構(gòu)如圖5 所示，首先將程序所有循環(huán)分解為iteration_list_entry_t，再將得到的每個(gè)iteration_list_entry_t分為多個(gè)iteration_t，該數(shù)據(jù)結(jié)構(gòu)用于存儲(chǔ)程序循環(huán)結(jié)構(gòu)中的循環(huán)id、循環(huán)變量值以及循環(huán)展開開始執(zhí)行與結(jié)束時(shí)間。剖析中所有熱點(diǎn)循環(huán)串行執(zhí)行的時(shí)間，與整個(gè)程序串行執(zhí)行時(shí)間的比值，即為程序并行區(qū)域覆蓋率。此外，hash_list 記錄存儲(chǔ)器寫入操作，hash_next 記錄下一次循環(huán)展開對(duì)存儲(chǔ)器操作的地址指針，hash_pre 記錄上一次循環(huán)展開對(duì)存儲(chǔ)器操作的地址指針。當(dāng)剖析工具檢索到程序后續(xù)代碼讀取某一存儲(chǔ)單元時(shí)，會(huì)對(duì)其進(jìn)行攔截，對(duì)比該程序存儲(chǔ)單元最后一次寫入時(shí)間與當(dāng)前讀取時(shí)間，將當(dāng)前時(shí)間設(shè)置為其中較大的一個(gè)，程序推測(cè)時(shí)間與該程序串行運(yùn)行時(shí)間的比值即為程序最終加速比。

圖5 循環(huán)結(jié)構(gòu)剖析的核心數(shù)據(jù)結(jié)構(gòu)Fig.5 Core data structures for loop structure analysis

1.3 性能影響因素

TLS 性能影響因素有推測(cè)并行區(qū)域覆蓋率、線程粒度規(guī)模、線程間數(shù)據(jù)依賴等。根據(jù)Amdahl 定律，程序可并行區(qū)域覆蓋率越高，最終加速比越好。線程粒度為程序一個(gè)循環(huán)迭代的指令條數(shù)，線程粒度太小會(huì)使程序能耗開銷增大，過大又會(huì)使處理器緩存溢出。線程間數(shù)據(jù)依賴也是TLS重要影響因素，文獻(xiàn)［18］將線程間依賴關(guān)系看作生產(chǎn)者和消費(fèi)者之間的關(guān)系，如圖6 所示。生產(chǎn)距離為線程開始執(zhí)行到線程對(duì)特定內(nèi)存單元最后一次寫入操作之間的指令數(shù)，消費(fèi)距離則是線程開始執(zhí)行到線程對(duì)特定內(nèi)存單元第一次讀操作之間的指令數(shù)。通過程序消費(fèi)距離和生產(chǎn)距離的比值，可以得到線程間數(shù)據(jù)依賴數(shù)值。將消費(fèi)距離比上生產(chǎn)距離，若比值范圍為（0，0.6］，說明產(chǎn)生了數(shù)據(jù)依賴沖突，將此時(shí)的數(shù)據(jù)依賴定義為致命依賴，并且數(shù)值越小產(chǎn)生的數(shù)據(jù)依賴沖突越嚴(yán)重；若比值在（0.6，1.0］的范圍內(nèi)，認(rèn)為此時(shí)會(huì)發(fā)生數(shù)據(jù)依賴沖突，將該依賴定義為危險(xiǎn)依賴；若比值大于1.0，則定義為安全依賴，認(rèn)為此時(shí)不會(huì)發(fā)生數(shù)據(jù)依賴沖突。

圖6 生產(chǎn)距離與消費(fèi)距離Fig.6 Production distance and consumption distance

2 實(shí)驗(yàn)數(shù)據(jù)分析

選取TACLeBench 的1.9 版本中用于實(shí)現(xiàn)小型內(nèi)核功能的基準(zhǔn)中7個(gè)具有代表性的程序，所選應(yīng)用程序如表1所示。

表1 基準(zhǔn)測(cè)試程序集說明Tab.1 Description of benchmark test programs

本實(shí)驗(yàn)平臺(tái)為基于Linux的Ubuntu 14.04開發(fā)版本；指令集為Simplescalar工具集中的PISA（Programme for lnternational Student Assessment）指令集；編譯器為Simplescalar 工具集中提供并改進(jìn)的gcc-2.7.2.3；剖析器為Simplescalar的功能模擬器sim-fast修改擴(kuò)充版本。

2.1 性能影響因素分析

并行區(qū)域覆蓋率如圖7 所示，并行區(qū)域覆蓋率越高越利于使用線程級(jí)推測(cè)分析，由于TACLeBench 內(nèi)核基準(zhǔn)程序的并行區(qū)域覆蓋率都為100%，因此并行區(qū)域覆蓋率對(duì)內(nèi)核基準(zhǔn)程序加速比影響較小。

圖7 并行區(qū)域覆蓋率Fig.7 Parallel area coverage

本文所選程序線程粒度如圖8 所示，大小在101～103范圍內(nèi)，由于Hydra 項(xiàng)目組提出了線程粒度最適宜的范圍是在以102～104條指令為單位的規(guī)模為宜，因此設(shè)計(jì)內(nèi)核程序的推測(cè)多核處理器時(shí)，推測(cè)緩存容量應(yīng)比通用設(shè)計(jì)降低一個(gè)量級(jí)，以避免增大程序開銷。

圖8 線程粒度Fig.8 Thread granularity

線程間的數(shù)據(jù)依賴結(jié)果如圖9 所示。除filterbank 以及binarysearch 致命依賴較高，其余程序致命依賴都在1%以下，程序致命依賴所占比值越高，最終得到的加速比數(shù)值越低，因此，filterbank 以及binarysearch 致命依賴過高是導(dǎo)致其加速比低的重要原因之一。

圖9 線程間數(shù)據(jù)依賴Fig.9 Data dependency between threads

綜合各程序并行區(qū)域覆蓋率、線程粒度以及線程間數(shù)據(jù)依賴結(jié)果分析發(fā)現(xiàn)：內(nèi)核基準(zhǔn)大部分程序并行區(qū)域覆蓋率較高，線程粒度適中，但大部分程序存在不同程度的致命依賴以及危險(xiǎn)依賴。

2.2 加速比分析

本文選取TACLeBench 中7 個(gè)具有代表性的內(nèi)核基準(zhǔn)程序，對(duì)比程序在2 核、4 核、8 核、16 核、32 核、64 核和無限核下的加速比情況，分析程序在循環(huán)級(jí)推測(cè)并行化中的性能提升潛能。不同核數(shù)即為循環(huán)設(shè)置不同數(shù)量的推測(cè)線程，由空閑處理器同時(shí)加載并運(yùn)行各個(gè)線程。無限核為程序同一循環(huán)結(jié)構(gòu)中所有推測(cè)線程設(shè)置相同的起始時(shí)間，使所有線程同步執(zhí)行。

bsort程序加速比結(jié)果如圖10（a）所示，核數(shù)從2核增加到64 核時(shí)，加速比接近線性增長(zhǎng)，64 核時(shí)，接近峰值。對(duì)其性能影響因素分析可知，程序覆蓋率達(dá)到100%，線程粒度較其他程序偏高，但程序致命依賴以及危險(xiǎn)依賴占比都為0%，因此最終程序加速比結(jié)果非常理想，達(dá)到20.79。

對(duì)lms進(jìn)行剖析，所得加速比如圖10（b）所示，核數(shù)在4核到64 核之間時(shí)，加速比基本穩(wěn)定在2.4 左右，核數(shù)從64 核增加到無限核時(shí)，加速比突然提升。由程序源碼可得，lms 運(yùn)行時(shí)間占比最大的循環(huán)迭代次數(shù)遠(yuǎn)超過64 核時(shí)提供的最大推測(cè)線程數(shù)，無限核時(shí)，所有迭代才能并行執(zhí)行，從而避免處理器閑置時(shí)間，因此，加速比在利用有限核加速時(shí)，加速效果不如無限核加速效果。綜合實(shí)驗(yàn)結(jié)果分析發(fā)現(xiàn)，該程序并行區(qū)域覆蓋率達(dá)到100%，程序線程粒度為53，由于程序運(yùn)行時(shí)間占比最大的函數(shù)中，存在指針變量以及函數(shù)調(diào)用，導(dǎo)致程序存在致命依賴，但致命依賴占比較小，并且函數(shù)整體循環(huán)結(jié)構(gòu)較多，所以該程序最終加速比結(jié)果很好。

從圖10（c）可以看出，st的加速比在2核到16核之間增長(zhǎng)幅度較大，16 核之后增長(zhǎng)緩慢，32 核時(shí)加速比接近峰值。通過程序源碼分析發(fā)現(xiàn)，st 為計(jì)算兩個(gè)大小為1 000 的數(shù)字?jǐn)?shù)組的總和、均值、方差和標(biāo)準(zhǔn)差，程序總體較為復(fù)雜，并且循環(huán)迭代次數(shù)較多。在程序運(yùn)行時(shí)長(zhǎng)稍短的函數(shù)中，存在較多指針數(shù)據(jù)結(jié)構(gòu)，但運(yùn)行時(shí)長(zhǎng)占比較大的函數(shù)中沒有產(chǎn)生依賴，因此程序沒有產(chǎn)生致命依賴，并且危險(xiǎn)依賴比值較少，最終程序加速比結(jié)果較好。

cosf程序加速比結(jié)果如圖10（d）所示，程序在2 核到32 核之間，加速比增長(zhǎng)較快，32 核之后，增長(zhǎng)逐漸緩慢，程序并行區(qū)域覆蓋率達(dá)到100%，線程粒度適中。對(duì)程序源碼進(jìn)行分析發(fā)現(xiàn)，程序較為復(fù)雜，盡管程序循環(huán)較少，但循環(huán)部分包含在程序運(yùn)行時(shí)間占比較大的結(jié)構(gòu)中，并且程序不存在指針以及循環(huán)嵌套等結(jié)構(gòu)，導(dǎo)致cosf 的致命依賴以及危險(xiǎn)依賴占比都為0%，因此最終加速比結(jié)果仍達(dá)到4.19。

從圖10（e）可得，matrix1 在2 核到16 核之間，加速比呈線性增長(zhǎng)，并于16 核時(shí)達(dá)到程序加速比峰值，考慮資源合理利用，對(duì)matrix1 程序應(yīng)選擇2 核到16 核使用以避免造成資源浪費(fèi)。通過對(duì)程序性能影響因素分析發(fā)現(xiàn)，該程序線程粒度大小適中并且不存在致命依賴，因此程序整體加速比表現(xiàn)較好，但由于該程序循環(huán)迭代次數(shù)較少，16 核時(shí)分配的推測(cè)線程足以讓所有迭代同步執(zhí)行，因此在16 核時(shí)，便達(dá)到了程序的并行執(zhí)行限度。

filterbank 在不同核數(shù)下的加速比如10（f）所示，核數(shù)由2核增加到4 核時(shí)，加速比得到了最大限度的提升，隨后加速比趨于穩(wěn)定，雖然該程序并行區(qū)域覆蓋率達(dá)到100%，程序線程粒度為47，但程序致命依賴過高，通過對(duì)程序源碼分析發(fā)現(xiàn)，程序循環(huán)次數(shù)較少，并且程序多個(gè)循環(huán)結(jié)構(gòu)中存在函數(shù)嵌套調(diào)用，導(dǎo)致程序危險(xiǎn)依賴達(dá)到63%，因此4 核之后加速比沒有隨著核數(shù)繼續(xù)增加。

由圖10（g）可得，隨著核數(shù)的增加，binarysearch 的加速比沒有發(fā)生改變。通過性能影響因素分析，該程序線程粒度達(dá)到515，造成其程序能耗開銷較大，并且該程序致命依賴達(dá)到78%，對(duì)程序代碼分析可得，該程序?yàn)?5 個(gè)整數(shù)元素的二進(jìn)制搜索，程序整體循環(huán)次數(shù)較少，函數(shù)運(yùn)行時(shí)間占比最大的函數(shù)中不存在循環(huán)結(jié)構(gòu)，此外，該函數(shù)在運(yùn)行時(shí)長(zhǎng)較短的函數(shù)循環(huán)中被調(diào)用，導(dǎo)致程序致命依賴嚴(yán)重。因此，程序最終加速效果較差。

圖10 程序在不同核數(shù)下的加速比Fig.10 Program speedup ratios with different cores

利用TLS 技術(shù)對(duì)TACLeBench 內(nèi)核基準(zhǔn)程序進(jìn)行最大潛能挖掘，對(duì)比各程序加速比結(jié)果，除binarysearch 外，其余程序最大加速比都在2以上，其中bsort程序加速效果最好，最大加速比超過20，通過其他方法對(duì)其進(jìn)行加速［19］，加速結(jié)果在5以下，因此，bsort適合利用循環(huán)級(jí)推測(cè)開發(fā)并行性。

對(duì)程序性能影響因素與加速比綜合分析發(fā)現(xiàn)，當(dāng)程序代碼存在函數(shù)嵌套調(diào)用等原因造成函數(shù)致命依賴嚴(yán)重時(shí)，即使程序并行區(qū)域覆蓋率較高，線程粒度適當(dāng)，程序最終加速效果也不理想，如filterbank；對(duì)致命依賴嚴(yán)重，線程粒度過大的程序，使用TLS 技術(shù)基本沒有加速效果，如binarysearch；對(duì)致命依賴占比較低的程序，最終加速效果也較好，如bsort、lms、st、cosf、matrix1。因此，在程序三個(gè)性能影響因素中，數(shù)據(jù)依賴影響最嚴(yán)重。

2.3 數(shù)據(jù)歸一化分析

對(duì)本實(shí)驗(yàn)所有程序加速比進(jìn)行歸一化分析結(jié)果如圖11所示，大部分程序隨著核數(shù)的增加，加速比增長(zhǎng)幅度逐漸變小。其中binarysearch 程序由于循環(huán)結(jié)構(gòu)過少、線程粒度過大并且致命依賴過高導(dǎo)致最終加速效果較差，利用TLS 技術(shù)對(duì)其進(jìn)行分析效果不理想，其余大部分程序在4 核到16 核之間加速比提升所占比重較大，因此對(duì)內(nèi)核基準(zhǔn)程序進(jìn)行推測(cè)并行分析時(shí)，綜合考慮性能提升與資源浪費(fèi)，核心數(shù)目應(yīng)盡量選擇4核到16核之間。

圖11 程序加速比歸一化分析Fig.11 Normalized analysis of program speedup ratio

3 結(jié)語

本文利用TLS 技術(shù)對(duì)TACLeBench 中內(nèi)核基準(zhǔn)中的部分程序進(jìn)行循環(huán)級(jí)線程推測(cè)分析，對(duì)比各程序加速比結(jié)果，除binarysearch 外，其余程序最大加速比都在2以上，綜合加速比與各性能影響因素，總結(jié)出以下結(jié)論：

1）本文使用線程級(jí)循環(huán)推測(cè)技術(shù)可以使TACLeBench 中的內(nèi)核測(cè)試基準(zhǔn)程序性能得到較好提升，大部分程序加速結(jié)果較好，其中bsort程序加速比最好，能達(dá)到20.79。

2）對(duì)于TACLeBench，大部分程序核心數(shù)目在4核到16核之間時(shí)，加速比增加幅度在50%以上，因此內(nèi)核基準(zhǔn)在選擇程序核數(shù)來進(jìn)行分析時(shí)，應(yīng)盡量將核數(shù)控制為4 核到16 核以避免造成資源的浪費(fèi)。

本實(shí)驗(yàn)選取TACLeBench 內(nèi)核基準(zhǔn)中較適合作循環(huán)推測(cè)的程序進(jìn)行分析，由于線程級(jí)推測(cè)也可應(yīng)用于子程序分析上，因此后續(xù)將利用TLS 技術(shù)，設(shè)計(jì)針對(duì)子程序的剖析機(jī)制對(duì)TACLeBench 內(nèi)核基準(zhǔn)進(jìn)行分析，并將最終加速結(jié)果與本文作對(duì)比，分析哪種推測(cè)并行方式更適合內(nèi)核基準(zhǔn)程序。