負荷分配不當 AMD銳龍?zhí)幚砥饔螒虮憩F(xiàn)不如英特爾

騰訊數(shù)碼訊（文心）據Ars Technica網站報道，業(yè)內人士對于AMD采用Zen內核架構的Ryzen處理器的反應可謂參差不齊。它售價不足500美元(約合人民幣3450元)，卻集成有8個內核、支持16個線程，意味著它在運行多種負載方面的表現(xiàn)都不含糊，例如編譯軟件、對內核數(shù)量要求較高的視頻壓縮等計算密集型任務。AMD的定價使得Ryzen確實非常有吸引力。

但游戲性能讓用戶對Ryzen頗為不滿。AMD承諾大幅提升每周期能執(zhí)行的指令數(shù)量(以下簡稱“IPC”)，業(yè)內普遍認為，Ryzen在這方面與英特爾Broadwell內核相當。雖然Broadwell是數(shù)年前的技術，采用它的芯片最早在2014年9月發(fā)售，這樣的比較仍然是恰當?shù)?。英特爾集成有大量內核的處理器——集成?、8或10個內核的高端臺式機處理器和面向多路服務器的各種至強處理器，仍然采用Broadwell內核。

實際上，沒有人預期Ryzen能成為游戲性能最高的處理器。我們已經知道，Broadwell也不是游戲性能最高的處理器，Skylake和Kaby Lake在多款游戲中的表現(xiàn)超過Broadwell，即使Skylake和Kaby Lake處理器至多只集成有4個內核、支持8線程。對于許多或大多數(shù)游戲，高IPC和高時鐘頻率對于高性能至關重要，而這正是Kaby Lake的特性。

雖然如此，互聯(lián)網上的評測文章、帖子和推文，給人的感覺是：許多人希望或期望Ryzen在某種程度上全面勝過英特爾。一種普遍看法是，Ryzen在某種意義上來說是一款糟糕的游戲處理器。但這一觀點通常伴隨著一種說法，某些“優(yōu)化”措施將提升這款處理器性能，AMD用戶只需再等上數(shù)個月，Ryzen的威力將能全部發(fā)揮出來。

這兩種觀點都大有瑕疵。

Ryzen其實是一款出色的游戲處理器

Ryzen的游戲性能不如英特爾處理器是事實。如果用戶只關心游戲性能，英特爾Kaby Lake i7-7700K是市場上最好的處理器，其價格與最廉價的Ryzen型號相當。甚至高端的Ryzen 1800X也不是7700K對手。

但7700K是目前市場上速度最快的游戲處理器。不過，“不像7700K那樣快”，并不意味著一款處理器“不適合”玩游戲，這只意味著其運行速度不如有史以來最快的游戲處理器。

在大多數(shù)情況下，處理器之間的差別只是理論上的。在幾乎所有情況下，Ryzen和Kaby Lake之間的差別是，一款處理器提供的幀率略低于另外一款。如果性能測試表明英特爾處理器在運行游戲時幀率總是高于60fps，而AMD處理器運行游戲的幀率總是低于60fps，一個合理的結論就是，英特爾處理器能提供流暢的游戲體驗，而AMD處理器則不能。

但通常而言，情況并非如此。即使差距相當大，例如《古墓麗影：崛起》(Rise of the Tomb Raider)，在Kaby Lake i7-7700K和Broadwell-E i7-6900K(8核/16線程)上運行時幀率都能達到135fps，而在1800X上運行幀率則可以達到110fps，這樣的幀率對于玩游戲來說還是相當不錯的。Tech Report發(fā)現(xiàn)了更極端的差距，那就是在OpenGL模式下運行《毀滅戰(zhàn)士》(Doom)時，7700K幀率達到170fps，而1800X僅為123fps。Tech Report沒有對6900K進行測試，但6950K(10核/20線程)幀率達到156fps。1800X能提供的幀率確實略低，但可玩性仍然是相當高的。換用更新的Vulkan API而非OpenGL后，它們在幀率之間的差距就不復存在了，7700K和1800X的平均幀率都達到了165fps。6950X稍微遜色一些，幀率為161fps。

這是我們認為1800X是Broadwell-E 6900X“優(yōu)秀備胎”的原因——它以不到一半的價格提供了與后者相當?shù)男阅堋＜词箤τ谟螒蚨裕?800X也是有力的競爭者：Ryzen“足夠出色，用戶可能樂意在運行一些軟件時承受略低的性能，以在運行其他軟件時享受性能的大幅提升”。

目前，1800X非常適合玩游戲，那么未來呢？隨著游戲對處理能力要求不斷提升，可能有一天7700K正好處于“可接受的幀率”臨界點上，而1800X則無法提供“可接受的幀率”，這會使1800X成為一款不劃算的處理器嗎？

對未來進行預測是一門不確切的科學，要確定未來的游戲什么樣是不可能的。在承認Ryzen有一些使它顯得不同尋常特性的同時，我們可以做一些合理的推測。

最常見的觀點是：目前的軟件沒有針對Ryzen進行優(yōu)化，不過這種觀點是不正確的。不是軟件沒有針對Ryzen進行優(yōu)化，而是它采用的軟件優(yōu)化模式與實際軟件不符。游戲確實沒有針對Ryzen進行優(yōu)化，不過它們也沒有針對Broadwell、Skylake或Kaby Lake進行優(yōu)化。它們只是進行了一般的優(yōu)化，以提升在所有平臺上的運行速度。

缺省設置影響性能

當讓媒體對Ryzen處理器進行測試和評測時，AMD提供了一些令人頗感意外的說明：其一，Windows電源設置選項應當設置為“高性能”模式，這一設置使處理器處于火力全開的P0狀態(tài)。在P0狀態(tài)，處理器時鐘頻率最高。在“平衡”模式中，處理器只有在負荷高的情況下才處于P0狀態(tài)。在負荷較輕的情況下，處理器處于P1、P2等狀態(tài)，這些狀態(tài)下處理器時鐘頻率會降低，因此能耗也會大幅度下降。

但這一技術也存在缺點：在P1(或速度更低的狀態(tài))和P0之間切換，會帶來一些性能開銷。與在P0狀態(tài)中和完全由處理器內部完成小幅度時鐘頻率調節(jié)不同的是，各種P狀態(tài)之間的切換要求操作系統(tǒng)介入，需要以毫秒計的時間。另外，如果Windows阻塞一個內核，使之處于休眠狀態(tài)，把它喚醒、恢復運行也需要時間。這些操作的影響甚至在性能測試中也能顯現(xiàn)出來，只是原因尚不清楚。

這是讓人感到意外的，因為人們預計，合理的處理器性能測試軟件，應當使處理器始終處于P0狀態(tài)。但游戲并不均衡地使用多個內核和多個線程，它會讓部分內核處于空閑狀態(tài)，Windows會使這些內核進入休眠狀態(tài)，在以后需要時再喚醒它們。

AMD表示，測試者應當關閉主板的“高精度事件定時器”(以下簡稱“HPET”)，稱它會削弱系統(tǒng)性能。HPET是Windows能用來設置內部警報和事件的數(shù)個定時器之一。HPET導致性能開銷并非沒有先例，過去，糟糕的實現(xiàn)被認為能造成性能問題，尤其對于音頻應用。

Ryzen的高速緩存層次結構也有些與眾不同。Ryzen和即將發(fā)布的Naples服務器處理器的基礎構件是AMD稱之為“Core Complex”(簡稱為“CCX”)的模塊，CCX集成有4個內核，每個內核集成有2MB的Level 3緩存。緩存在CCX內部是可以共享的，每個內核能訪問其他內核緩存中的數(shù)據，但訪問時間并不一致，內核訪問自己緩存的速度要快于訪問另外3個內核的緩存。

一個Ryzen處理器集成有2個CCX和Infinity Fabric。一個CCX模塊中的內核能訪問其他CCX中的Level 3緩存，但比訪問同一CCX模塊中的緩存速度慢：一個CCX模塊中的Level 3緩存帶寬為逾170GB/s。AMD曾表示Infinity Fabric帶寬僅為22GB/s。因此，跨CCX訪問緩存的時間開銷更大。對于主存中的數(shù)據，這一差距是不存在的。內存控制器不屬于任一CCX，而屬于北橋，也與Infinity Fabric相連。

在某種程度上，Ryzen運行方式與帶有前端總線的傳統(tǒng)SMP系統(tǒng)相似，只是Infinity Fabric代替了總線。在這類系統(tǒng)中，處理器通過總線與其他處理器和內存控制器通信。如果一個處理器訪問的內存數(shù)據能由其他處理器通過緩存提供，其他處理器會直接發(fā)送數(shù)據。否則，內存讀取操作必須由內存控制器處理。兩個處理器對內存控制器有相同的訪問權限。

通常情況下，一個線程被允許一直在同一個內核上運行時，系統(tǒng)性能最高，這種情況下緩存存儲有線程所需數(shù)據的可能性最大。否則，Windows應當優(yōu)先使線程在同一CCX的內核上運行，最后才會把線程切換到另外的CCX上。我們知道，在選擇運行線程的內核時，Windows會考慮超線程和內存位置，目前尚不清楚Windows是否考慮緩存安排。Ryzen應當會考慮緩存安排，因為在CCX間遷移線程是有開銷的。

電源管理問題也可能會影響性能。Level 3緩存的運行速度與CCX中最快的內核相當，如果CCX運行速度因所有內核處于空閑狀態(tài)而放慢，其他CCX中線程訪問其緩存的速度甚至會低于正常水平。在“高性能”模式下，即使處于空閑狀態(tài)的CCX緩存也始終全速運行。

Ryzen還是AMD首款提供細粒度同步多線程(SMT，與英特爾超線程技術相似)的處理器。雖然AMD上一代架構Bulldozer，可以在邏輯內核之間共享資源，每個邏輯內核有自己完整的整數(shù)單元，至少對于整數(shù)負載來說，它們可以被近似認為是“完整”的物理內核。在Ryzen中——如同在英特爾處理器中那樣，資源共享的程度要大得多。這也會影響到緩存使用——同一物理內核上的兩個線程共享Level 1和Level 2緩存，以及能提供最優(yōu)性能的線程數(shù)量。

在同一內核上運行兩個計算密集型線程，它們會競爭相同的共享執(zhí)行資源，影響彼此的性能。線程通常應當分布在不同內核上。這要求操作系統(tǒng)對邏輯和物理內核間的資源共享有更好理解。

Ars Technica表示，綜合考慮上述因素，意味著系統(tǒng)可能不能以最優(yōu)方式利用Ryzen處理器。

關閉HPET的效果似乎是微不足道的。德國網站ComputerBase發(fā)現(xiàn)，關閉HPET能使系統(tǒng)性能提升0.5%，與“高性能”模式相比，“平衡”模式降低幅度為0(使每個內核始終處于P0狀態(tài)的游戲)-15%(不能使每個內核始終處于P0狀態(tài)的游戲)。

新系統(tǒng)建議關閉HPET讓人略感意外，通過驅動程序或固件更新包解決這些小問題是可行的。對Ryzen的測試清楚地表明一點：系統(tǒng)固件剛發(fā)布不久。事實上，它發(fā)布時間確實很短，主板廠商都在抱怨Ryzen上市銷售過急，沒有進行正常水準的測試工作。

電源管理問題略有些棘手，它也似乎是Windows 7和Windows 10表現(xiàn)差距大的原因。Windows 7喜歡交替阻塞線程，在每個內核上保留一個沒有阻塞的線程；Windows 10則采取“恰當?shù)拇胧?，同時阻塞一個空閑內核上的兩個線程，而非只阻塞一個。這意味著Windows 10有助于延長系統(tǒng)電池續(xù)航時間，但也意味著喚醒一個內核時增加系統(tǒng)開銷的可能性更高。

對于英特爾處理器來說，休眠和喚醒內核也不是免費的。在P狀態(tài)間切換時英特爾芯片同樣需要操作系統(tǒng)干預，因此導致的“電源管理”問題并非是Ryzen特有的。

除非微軟修改Windows設計，使之不積極地讓內核轉入休眠狀態(tài)，這仍然會是個小問題。AMD曾表示，4月份發(fā)布的更新包將“優(yōu)化‘平衡’模式下的電源管理策略參數(shù)，提升正常使用狀態(tài)下臺式機的性能”。想必這意味著不再快速阻塞處理器。

人們希望無論什么樣的改變都不會影響移動芯片和服務器版Ryzen的節(jié)能表現(xiàn)。移動芯片受到更大的能耗限制，服務器處理器的總體能耗可能大于臺式機處理器，但每個內核的能耗要小得多。在臺式機系統(tǒng)上正確的設置，在其他類型計算設備上就可能是錯誤的。

至于調度程序，AMD表示，它研究了Windows 10調度程序行為，發(fā)現(xiàn)它運行正常，因此Windows似乎沒有在CCX間不必要地遷移線程，并恰當?shù)乩昧送蕉嗑€程技術。

這一難題的另一個元素是游戲本身。AMD表示，它已經發(fā)現(xiàn)“部分能提升游戲對‘Zen’內核/緩存拓撲結構理解的修改”，不過它不會披露相關細節(jié)。操作系統(tǒng)可能運行正常，但它不會審視每個線程的負載，因此它仍然可能犯錯。

例如，如果兩個線程在相同的共享數(shù)據集上運行，它們應當分配到同一個CCX，避免它們通過相對較慢的連接傳輸數(shù)據。Windows不容易發(fā)現(xiàn)共享的數(shù)據，不會發(fā)現(xiàn)兩個線程花過長時間等待內存數(shù)據。如果存在足夠多的計算密集型線程，Windows必須在兩個CCX上調度線程，兩個線程可能被分開，一個CCX上有一個線程。但是，應用開發(fā)者可以采取措施，把兩個線程分配到一個CCX或另外一個CCX上，確保它們始終位于Infinity Fabric連接的同一端。

更為復雜的是，根據應用類型，正確的策略可能多種多樣。需求更多帶寬的軟件可能最好將部分線程分配在一個CCX上，部分線程分配在另一個CCX上，使得兩套線程能利用Level 3緩存的全部帶寬。但是，對延遲高度敏感的軟件，可能最好將所有線程分配在一個CCX上，對另外一個CCX“視而不見”。采取正確的措施，將要求對軟件、緩存使用方式、線程和內存進行仔細的檢查。

同理，雖然Windows無疑理解SMT，在調度線程時不會使忙碌的線程在同一個物理內核上運行，但游戲的表現(xiàn)在某種程度上則參差不齊。雖然許多游戲在開啟和關閉SMT情況下的表現(xiàn)幾乎沒有差別，數(shù)款游戲在開啟SMT的情況下表現(xiàn)有所提升，少數(shù)幾款游戲的表現(xiàn)則有相當大程度的惡化。出現(xiàn)這種情況的一個可能原因是，游戲能檢驗硬件，“看到”16個內核，并創(chuàng)建16個計算密集型線程。這會迫使線程競爭資源。對游戲進行更新，使它能知道SMT處于開啟狀態(tài)，并因此少創(chuàng)建一些線程，可能能夠解決這個問題。

即使游戲開發(fā)者根據AMD的建議針對Ryzen設計對游戲進行優(yōu)化，也不要預期游戲性能會有大幅度提升。雖然未來驅動程序可能會有小的改進，但根據以往的經驗判斷，Ryzen未來運行游戲的表現(xiàn)將與目前基本相當。

ComputerBase過去的數(shù)據提供了一些線索。它以非常低的分辨率對游戲進行測試，使處理器的負載達到最大，使對顯卡的影響最小化。

2012年，當時剛發(fā)布的FX 8350處理器(采用AMD的Piledriver內核)，性能相當于英特爾Sandy Bridge i5-2500K的85%，與兩款處理器搭檔的是GTX 680顯卡。2015年，通過利用速度快得多的顯卡——集成有6GB顯存的GTX Titan，兩者的性能差距有所收窄，但幅度非常小：8350性能相當于i5-2500K的87%。

對于沒有更新或更新幅度很小的游戲，這并不讓人感到太意外。這些游戲絕不會針對Ryzen進行“優(yōu)化”，雖然顯卡驅動程序或AMD 神秘的“內核/緩存拓撲結構”建議可能略微提升性能，它們不足以大幅降低游戲對計算能力的需求。嚴重依賴1或2個計算密集型線程的游戲，絕不可能很好地支持Ryzen的8個內核和16個線程。把負載分配到這些內核上，要求重寫部分游戲代碼，以充分利用Ryzen的能力。開發(fā)者對已經發(fā)布的一款游戲“大動干戈”很罕見。

對于未來的游戲，或極少數(shù)發(fā)布后得到大幅升級的游戲，Ryzen的未來似乎更光明。但對于AMD來說令人遺憾的是，Broadwell-E，甚至是英特爾尚未發(fā)布的Skylake-E，前景也很光明。

Ars Technica與數(shù)家游戲開發(fā)商就優(yōu)化游戲和Ryzen的未來進行了溝通。一些話題很清楚：高性能游戲基本上是利用C++語言開發(fā)的，微軟Visual C++是應用最廣泛的開發(fā)工具。開發(fā)者似乎對手工利用匯編語言開發(fā)針對具體處理器的代碼缺乏興趣。

這也帶來了一些后果。與任何優(yōu)秀的C++編譯器一樣，Visual C++會努力優(yōu)化它生成的代碼。例如英特爾處理器能一次譯碼4條指令：3條“簡單”指令和第四條“復雜”指令，譯碼后的部分指令能“融合”在一起，這意味著它們能在一個運算單元上執(zhí)行，而非必須使用多個運算單元。

如果編譯器生成兩條緊挨的“復雜”指令，它們都將競爭復雜譯碼器，其中一個就必須進入等待狀態(tài)。如果編譯器生成連續(xù)的復雜-簡單-簡單-簡單、復雜-簡單-簡單-簡單指令序列，所有譯碼器可以得到同時利用。同樣，如果譯碼器嘗試優(yōu)先生成能融合的指令，這會釋放更多運算單元——它們可以被用來執(zhí)行更多指令。

過去，Visual C++的優(yōu)化選項包括針對具體微架構優(yōu)化代碼的能力。這意味著，除遵循最優(yōu)指令譯碼的一般規(guī)則外，偏好某些特定指令序列。例如，當為奔騰4處理器編譯代碼時，編譯器可能會嘗試避開“分支”指令——原因在于奔騰4較長的管道、預測錯誤后頗高的開銷，而使用“條件轉移”指令——它根據第三個寄存器的結果，把一個值由一個寄存器賦予另外一個寄存器，不要求使用分支操作。

但是，當前版本的Visual C++編譯器不提供針對特定架構生成代碼的能力。其他編譯器——例如gcc，還保留著這一能力。但Visual C++旨在生成通用代碼。鑒于過去10年英特爾和AMD處理器相似的約束條件，這是合理的，但也產生了一個后果：如果Ryzen在指令調度方面有任何特定要求，這些要求可能都無法滿足。開發(fā)者相信他們的編譯器是明智的，他們不會以手工方式利用匯編語言開發(fā)游戲引擎，以充分發(fā)揮編譯器無法利用的處理器性能。

這會對性能產生重大影響：AMD K8處理器中分支預測器的不足，要求不同尋常的解決方案，以達到最高性能。如果Ryzen存在相似的問題，無法生成針對Ryzen優(yōu)化的代碼，會影響到系統(tǒng)性能。

但開發(fā)者在更高層次上考慮他們針對的處理器的能力。由Oxide Games和Stardock Entertainment開發(fā)的《奇點灰燼》(Ashes of the Singularity)，被微軟和AMD作為利用先進技術的游戲范例。這款游戲是DirectX 12的早期采用者，經常被用來展示DirectX 12使游戲引擎可以把負載更高效地分配到多個內核，從而降低處理器開銷和提供最高性能的能力。

很自然，Oxide對Ryzen有興趣。該公司開發(fā)人員向Ars Technica表示，通過把大型軟件任務分拆成能并行處理的更小部分，Nitrous引擎能分布到多個內核上運行。對于給定的3D場景，系統(tǒng)集成的內核越多，每個任務的規(guī)模就越小。Nitrous引擎能自動把更大任務分拆成更小任務。

未來

Ars Technica稱，未來，影響游戲性能的一大因素，可能是游戲引擎智能地將負荷分配在大量內核上的能力。Stardock首席執(zhí)行官布拉德·瓦德爾(Brad Wardell)向Ars Technica表示，Nitrous游戲引擎開發(fā)者就面臨選擇：致力于提高在更少內核上運行的速度還是將負荷分解成能并行運行的模塊。由于擁有更多內核，Ryzen有助于推動游戲引擎的開發(fā)走向后一個方向。其他游戲開發(fā)公司可能會跟風。

Oxide的蒂姆·基普(Tim Kipp)也向Ars Technica表示，在運行不能并行運行的引擎方面，內核多的系統(tǒng)表現(xiàn)更好，解決這些問題“對內核數(shù)量少的系統(tǒng)也有好處”。

Oxide喜歡能廣泛提升系統(tǒng)性能的算法優(yōu)化。大多數(shù)C++代碼相對地獨立于處理器特性，對一種系統(tǒng)有幫助的技術——例如對數(shù)據打包使之能更好地存儲在緩存中，也對其他系統(tǒng)有幫助，當Oxide提出新技術時，新技術將面向更廣泛的系統(tǒng)。

至于使軟件在某種處理器上性能高于其他處理器的技術，想都別想。Oxide高管蒂姆·基普(Tim Kipp)向Ars Technica表示，他們努力避免手工編寫匯編語言代碼，因為維護成本太高。至于像SSE2和AVX這樣的矢量指令——Nitrous廣泛使用了這類指令，基普更愿意使用編譯器內聯(lián)函數(shù)。由于內聯(lián)函數(shù)能自由地與普通C或C++代碼混用，使用它們比使用匯編語言編寫的代碼要容易得多，又能提供匯編語言代碼的大部分性能。

游戲引擎也提供了一些使用Ryzen特性的途徑。瓦德爾和基普向Ars Technica表示，他們尚沒有機會充分了解Nitrous在Ryzen上運行的性能，不過他們表示，Nitrous有自己的內存管理器和向內核分配負荷的調度程序。大體上，它們會避免跨CCX內存共享，有利于發(fā)揮Ryzen的優(yōu)勢。

《奇點灰燼》和EA DICE的《戰(zhàn)地1》(Battlefield 1)等游戲，已經能高效地利用大量內核，把負載均衡地分配在多個內核上。其他游戲——例如《古墓麗影：崛起》，只能使1或2個內核高負荷地運行，不能高效地利用Ryzen和Broadwell-E提供的多個內核。

未來數(shù)年，Ars Technica預計高性能游戲不能充分利用多個內核的尷尬將成為歷史。雖然它們只能利用2或4個線程，支持多線程的一個合理方法，是創(chuàng)建數(shù)個不同的、定義明確的任務，使每個任務在各自的線程中運行，例如，一個線程用于渲染畫面，一個線程用于處理音效，一個線程用于處理人工智能……。但是，隨著開發(fā)者需要考慮同時利用的線程增加到數(shù)十個，這種方法就無能為力了，像Nitrous中那樣的系統(tǒng)——把畫面渲染負載分配到所有內核的任務由游戲引擎本身完成，就至關重要了。游戲沒有16個相互平衡、定義明確的任務需要完成。它需要分解負載，充分利用系統(tǒng)能提供的內核。

《模擬城市(2013)》(2013 SimCity)的基本限制之一是，核心的模擬引擎只能在一個線程上運行，圖像和音效引擎則能利用多個線程。但是，由于模擬引擎只能在一個內核上運行，這款游戲很快遭遇性能障礙。

較新的游戲也沒有能擺脫這一問題：《文明VI》在Kaby Lake系統(tǒng)上運行的性能遠高于Broadwell-E或Ryzen。線程負載不均衡，部分內核很忙，部分則比較空閑。

把負載分配在多個線程上很困難，因為每個決策——人工智能攻擊這個還是那個單元、游戲角色應該完成這件還是那件工作，都取決于它之前的所有決策，如果在各自線程上運行的兩個游戲角色選擇同時完成相同的任務，《模擬城市》就亂套了。雖然可以利用鎖機制確保只有一個游戲角色完成任務，由此引發(fā)的開銷可能抵消多進程帶來的潛在好處。

在有些游戲中，一定程度上不遵守這一要求是可能的，但《文明VI》這類游戲，要求人工智能控制的角色具有確定性：在地圖和單元相同的情況下，人工智能應當每次都做出相同的決策。這對于網游更是必不可少的：所有游戲玩家都需要人工智能游戲角色一視同仁，否則每個游戲玩家的游戲玩法將互不相同。

集成有大量內核的系統(tǒng)未來更光明。Ars Technica預計，在新游戲引擎設計、DirectX 12和Vulkan普及推動下，未來2年將出現(xiàn)能高效在4個內核、8個線程上運行、畫面精美的游戲，這無疑對Ryzen有利。未來，Windows，甚至游戲本身，將會改版，以與Ryzen略不同尋常的緩存結構和諧的方式運行。但是，部分多線程癥結將依舊存在，這對于AMD和英特爾處理器來說可能會繼續(xù)是個問題。

來源：Ars Technica