• 72

amd6核心或intel新cpu

darktasi wrote:
看起來《星際爭霸2》並不能發揮多個處理核心的優勢。

雖然雙核心現在已經成了絕對主流選擇,但在用戶中單核心仍然大量存在而且不要忘了《星際爭霸2》從2003年就投入開發了,而雙核心處理器直到2005年才出現而且剛開始的時候價格奇高,很少有人用得起,直到最近兩年才走入尋常百姓家。很顯然,《星際爭霸2》最初是面向單核心系統開發的
...(恕刪)

Windwaker wrote:
2. 大部分的程式都是Single Threading,雖然可以在Multi-threading的作業系統上跑,程式設計師要寫Multi-thread ready的 Single thread很簡單,但是要把自己的程式寫成兩個thread以上很有挑戰性,因為要把Task分成兩個以上很難,看SC的例子就知道了,問題根本不是技術上能不能分成四個Thread,而是你怎麼把程式的Load分給4個Computing unit.
...(恕刪)

從以前其他主題的討論,我知道Windwaker兄是有軟體經驗的(不過應該不是純軟體公司/ISV,而是硬體公司內的軟體部門),darktasi兄雖然不是搞軟體的,不過兩位的提出的"迷思"還是可以一次回答。

Windwaker兄應該不是寫多媒體程式或是遊戲程式的吧!以實作一個簡單的影音播放或錄影程式為例,基本上你的Video模組跟Audio模組,很自然而然的就會分成(至少)兩個執行緒,在大部分情況下這兩個執行緒進行的運算是不平衡的(Video計算複雜度一般較高),但是一般實作,不但會將Audio模組切成單獨一個執行緒(而非依附在Video執行緒下順便進行Audio編碼/解碼),甚至還會賦予給它較高的執行緒優先度,為什麼呢?(因為已經不是追求分工平均的問題了,而是人腦對於斷音的容忍度,比起video頓呆低很多很多)

上面為何說"至少"?即使是光從Video編碼/解碼執行緒去分析,都還有進一步評估再拆執行緒的空間,真正實務課題上如I/P frame跟B frame能不能拆執行緒分別處理?甚至評估B frame內部能不能切成幾塊分成不同執行緒去處理Motion Prediction/Motion Compensation?如果是Blu-ray 3D用到的H.264 MVC(沒有打錯,這邊本來就不是要講AVC)Video編碼格式,那就更有意思了,軟體實作時如果沒有切成至少兩個執行緒,那實驗室內驗證驗證就算了,基本上真的是上不了檯面拿來賣錢。還有例如未來的4K超高解析度Video應用呢?微軟正在嘗試幫其在企業視訊通訊/會議市場找應用的H.264 SVC格式呢?

這也回答了darktasi兄的問題,以星海爭霸2這類的"即時"戰略遊戲,為何要稱作為"即時"?以一場本機端三人對戰為例(一玩家、二電腦),程式該怎麼寫?你會把玩家跟電腦共三種部隊裡的各幾十個單位的處理,都寫在同一個執行緒中用一個迴圈大鍋炒嗎?那本機八方對戰怎麼辦?如果每一方都可以有上百個單位怎麼辦?如果是透過網際網路的多人對戰呢?程式該怎麼寫?網際網路的頻寬變數很多,要如何"盡可能"確保"即時"?

您說"《星際爭霸2》最初是面向單核心系統開發的",此一時彼一時,要說最終上市的星海爭霸二都沒有針對多核心趨勢進行多執行緒化最佳化,我真不知道該怎麼說.....如果您認為多執行緒程式最佳化的目的,只是為了把多核處理器的每一核都吃到滿滿滿的100%負荷............小弟只能說您測試程式/燒機程式跑太多,變吃重鹹了.....

回到專案分工的例子,一件專案的所有專案成員,分到的事情絕對很難做到完全公平,有些成員例如收發或助理在專案中,甚至可能只是"當你收到關於這個專案的文件時,絕對要優先處理、第一時間送上來"這種event-driven的角色,既然專案分工,不可能作到絕對平衡/公平,有些成員甚至工作loading輕/重相差懸殊,那為何還是要分工?

兩位不要掉入多執行緒化只是為了讓所有應用程式寫成多個執行緒後在每個核心的負荷必須都完全相同、或是每個核心都必須是被操到100%負載的迷思了,那是鑽牛角尖。

Windwaker wrote:
整個討論串錯誤很多
1. Bulldozer雖然號稱8C,但是只有四個浮點運算,所以嚴格來說相當於Intel版本的4C/8T,這也就是為什麼Intel說AMD算核心的方法不對, Bulldozer的效能應該接近i7系列,現有的PII X6/X4應該會留下來和i5對戰
...(恕刪)

錯了啦!Bulldozer(以Zambezi為例)有八個浮點運算單元,只有在處理256-bit AVX SIMD浮點指令時,才有單一模組內的兩個128-bit浮點單元會合併運算的狀況。

也不要用幾C幾T這種說法去硬套用到Bulldozer唷!那又是鑽牛角尖了,AMD的官方說法,就是Bulldozer是一個八執行緒的處理器(以Zambezi為例)。

ycweng wrote:
從以前其他主題的討論...(恕刪)


補充,幾C(Core)這玩意只有類似我這種工作(EE,BIOS,Driver)的朋友們才會去刻意去計較。
因為我們計算CPU的數量是用物理可辨別的數量。
雖然說還是有一些地方還是很嚴格的是用『幾顆』實體CPU在計算。
比如說兩顆8核心的CPU。有的地方是算『16顆』CPU,有得地方就是要算成『兩顆』CPU
至於幾T(Thread)就是前面朋友們爭論的了。OS底下的軟體執行層才會去計較這玩意。
一些基層存取的軟體還是忽略這不看的。
居然忘了01要當流量大的營利網站,而不是專業網站,我還囉唆雞婆個雕~一起喊無腦萬萬歲就行了呀,多省事。
plue2100 wrote:
很有趣的是再大的平行度,還是會遇到彼此依存而無法拆項的執行緒

那麼,每一次都在講究的指令集最佳化

再回頭看看新一代的CPU發展,好像還挺好玩的 :P
...(恕刪)

平行度大致可以有(某執行緒內)CPU指令level的平行度、資料處理層面的平行度、跟thread/process間task-level的平行度。

核心內部的Dynamic Execution,就是在嘗試找出(某執行緒內)CPU指令這個階層的平行度,再交由不同管線來平行處理。

資料處理層面的平行度,也可再分,像2D Bitblt、3D這種典型重複相同單調計算的平行度,固然也可以運用處理器提供的SIMD指令集,但更適合交由專屬、已針對特定用途最佳化的輔助處理器如2D GUI加速器、3D GPU來處理,讓CPU去做別的事。而例如Video解碼/編碼的Motion Compensation/Motion Prediction、DCT/iDCT、FFT快速演算法,則可以運用處理器提供的SIMD指令集來處理資料間的平行度,但還是要看程式設計師跟演算法設計的功力。

找出可拆成執行緒的task的平行度,也是考驗程式設計師的經驗跟功力(以及是否偷懶.....),舉個例子:例如使用也相當普遍的可平行下載的下載加速器,天生就蠻適合寫成多執行緒執行。

上述三種都不是互斥的,實務上有些應用可以被拆成多個執行緒(不管是處理相同task或不同task)平行執行、而每個執行緒都用到SIMD指令集處理計算資料層級的平行性,到了CPU內部,Dynamic Execution還是會嘗試分析進來的指令間的相關性,找出指令的平行排程,以將指令分配到不同管線執行。

蛙鳴之地 wrote:
補充,幾C(Core)這玩意只有類似我這種工作(EE,BIOS,Driver)的朋友們才會去刻意去計較。
因為我們計算CPU的數量是用物理可辨別的數量。
雖然說還是有一些地方還是很嚴格的是用『幾顆』實體CPU在計算。
比如說兩顆8核心的CPU。有的地方是算『16顆』CPU,有得地方就是要算成『兩顆』CPU
至於幾T(Thread)就是前面朋友們爭論的了。OS底下的軟體執行層才會去計較這玩意。
一些基層存取的軟體還是忽略這不看的。
...(恕刪)

懂您的意思,例如微軟的作業系統license.....以EE、BIOS、Driver中某些機制得要數人頭、但不在乎人頭是屬於大人還是小孩的角度來看,這就看AMD怎麼定義了,但最可能的還是Zambezi算成四"核",否則許多軟體的授權費就得跳一個等級......順便請問一下,目前AMD態度跟運作方向如何?

但從傳統計算機結構、作業系統、跟Intel跳腳()的角度來看,AMD的一個Module算成一核怪怪的,算成兩核又不對勁.....不過對於AMD來說,保持些"模糊空間",也就是某些網路討論中Bulldozer(Zambezi)會被描述成8"核"處理器、但如果軟體授權層面卻能維持4"核"幫客戶省錢,應該是面子裡子兼顧的作法。如果有人說8"核"打Intel 4C8T勝之不武,AMD也可以說Zambezi是四個"模組",進可攻、退可守.....
ycweng wrote:

錯了啦!Bulldozer(以Zambezi為例)有八個浮點運算單元,只有在處理256-bit AVX SIMD浮點指令時,才有單一模組內的兩個128-bit浮點單元會合併運算的狀況。

也不要用幾C幾T這種說法去硬套用到Bulldozer唷!那又是鑽牛角尖了,AMD的官方說法,就是Bulldozer是一個八執行緒的處理器(以Zambezi為例)。


這種東西是白紙黑字可以查的
http://www.xbitlabs.com/news/cpu/display/20101026234515_AMD_Calls_New_FPU_Flex_FP_Defends_Dual_FMAC_Approach.html

The beauty of the Flex FP is that it is a single 256-bit FPU that is shared by two integer cores. With each cycle, either core can operate on 256 bits of parallel data via two 128-bit instructions or one 256-bit instruction, or each of the integer cores can execute 128-bit commands simultaneously.

基本上浮點運算單元只有一個256bit的FPU
只是給兩個整點單元運算
到頭來所謂的一個Bulldozer所謂的一個Module
等於是Intel有HT一個Core
只是可以說 Bulldozer在資源分配的方法可能比Hyperthreading更有效率
我真的看不出來怎麼可以Bulldozer一個模組裡面可以說有兩個Core
頂多說兩個整點運算單元...

簡單來說AMD的一個Bulldozer模組效能應該相當於i7的1C2T
如果AMD不讓我們失望的話...
ycweng wrote:
Windwaker兄應該不是寫多媒體程式或是遊戲程式的吧!以實作一個簡單的播放或錄影程式為例,基本上你的Video模組跟Audio模組,很自然而然的就會分成(至少)兩個執行緒,在大部分情況下這兩個執行緒進行的運算是不平衡的,但是一般實作,不但會將Audio模組切成單獨一個執行緒(而非依附在Video執行緒下順便進行Audio編碼/解碼),甚至還會賦予給它較高的執行緒優先度,為什麼呢?


我想你沒搞清楚這邊所謂的多線程的意義
不光只是把遊戲裡面的音效,畫面,邏輯分開來
大部分的遊戲90%的CPU用量都會在畫面/遊戲邏輯上
最簡單的方法可能就是把這兩個線程分配載兩個不同的Thread/Core

現在所為大部分的多線程程式
都是把簡單的計算/轉檔變成一個個小的Work Task/Order
然後每一個Order都可以轉做一個Thread
所以要轉檔軟體/繪圖軟體/商業軟體支援多線程
比遊戲簡單很多

基本上多線程遊戲的程式設計
乃是把畫面/遊戲邏輯變成兩個不同的Threads
這在Xbox360/PS3剛開始開發成本和難度都遠高於過去
很大的原因就是這個多線程的遊戲設計難度高很多
PS3的Core比360多當年開發的難度也是高出許多
反而只有一個Core的Wii簡單不少
這和底下的OS一點關係都沒有....


Windwaker wrote:
基本上浮點運算單元只有一個256bit的FPU
只是給兩個整點單元運算
到頭來所謂的一個Bulldozer所謂的一個Module
等於是Intel有HT一個Core
...(恕刪)

看你要從128-bit FMAC或是256-bit FMAC的角度去看嘍!一個模組內,有兩個128-bit FMAC單元,可以分別執行不同的SSE/x87指令。AMD官方的架構圖,是標示兩個128-bit的FMAC。



http://blogs.amd.com/work/2010/10/25/the-new-flex-fp/
===========================================================
The Flex FP unit is built on two 128-bit FMAC units. The FMAC building blocks are quite robust on their own. Each FMAC can do an FMAC, FADD or a FMUL per cycle. When you compare that competitive solutions that can only do an FADD on their single FADD pipe or an FMUL on their single FMUL pipe, you start to see the power of the Flex FP – whether 128-bit or 256-bit, there is flexibility for your technical applications. With FMAC, the multiplication or addition commands don’t start to stack up like a standard FMUL or FADD; there is flexibility to handle either math on either unit. Here are some additional benefits:
===========================================================

Windwaker wrote:
只是可以說 Bulldozer在資源分配的方法可能比Hyperthreading更有效率
...(恕刪)

AMD的寫法很"委婉"......AMD技術行銷人員的"文章"這次確實"作的不錯",難怪Intel要跳腳.......

簡單這麼說吧!那個"彈性"跟"效率"的意義是:如果是含有AVX指令的執行緒,4C8T的Sandy Bridge可以同時執行8個,Zambezi只能執行4個。

AMD早先SSE指令集的實作,也不是一次處理128-bit的寬度,而是拆成兩個64-bit前後處理,所以SSE程式一測,就比較尷尬了。

Windwaker wrote:
我想你沒搞清楚這邊所謂的多線程的意義
不光只是把遊戲裡面的音效,畫面,邏輯分開來
大部分的遊戲90%的CPU用量都會在畫面/遊戲邏輯上
最簡單的方法可能就是把這兩個線程分配載兩個不同的Thread/Core
...(恕刪)

咦!quote我的部份我是在講影音播放/錄影/編碼程式例如KMPlayer或MediaCoder這類,您這邊怎麼跳成遊戲?不過紅色部分,至少回答了darktasi兄的問題。

絕大部分的程式都不只兩個執行緒(分工是否均勻先不論,有些工作是天生無法平均分配,但分工平行進行仍有其意義),這從工作管理員就看得出來了。與其憑空想像多難多難,開個工作管理員看看現況,不就知道了?

職業棋手能夠以一般人覺得不可思議的程度,思考整盤棋的布局,旁人覺得很難,但對於棋手來說,那是他們專業的必備技能,

Windwaker wrote:
現在所為大部分的多線程程式
都是把簡單的計算/轉檔變成一個個小的Work Task/Order
然後每一個Order都可以轉做一個Thread
所以要轉檔軟體/繪圖軟體/商業軟體支援多線程
比遊戲簡單很多
...(恕刪)

darktasi兄,可以參考這段。

Windwaker wrote:
基本上多線程遊戲的程式設計
乃是把畫面/遊戲邏輯變成兩個不同的Threads
這在Xbox360/PS3剛開始開發成本和難度都遠高於過去
很大的原因就是這個多線程的遊戲設計難度高很多
PS3的Core比360多當年開發的難度也是高出許多
反而只有一個Core的Wii簡單不少
這和底下的OS一點關係都沒有....
...(恕刪)

遊戲邏輯部分,以星海爭霸類的即時對戰遊戲,較好的作法是再拆thread,變成每一對戰方至少有各自的thread處理,如果操控者一方有數個不同作戰單位的group,每個group,也可以有自己的thread,這些都還落在您說的"遊戲邏輯"範圍內。

==============================================================================
[懶人包]:因為接下來六百多樓鬼打牆將會非常嚴重,對於非資訊相關科系的網友來說將很不容易讀,簡單提供現階段懶人包如下,702樓還有比較詳細的懶人包:

Windows核心內部有系統排程程式專職負責程式執行緒的排程以及處理器核心資源分配,由於W大師討論到這時,心中還沒有系統Scheduler的基礎觀念,因此以為多執行緒程式自己必須負責、就有權力能夠分派指定自己的某個A執行緒到A核心執行、B執行緒到B核心執行....等等,而與作業系統無關。不同的大大將會持續指出W大的基礎錯誤,而W大師將會一路用Google惡補、猛找資料,然後到235樓時將會鬧個大笑話,把Windows內建的Task Scheduler工作排程器公用程式(用來星期一重組、星期二掃毒等.....),誤認成是執行緒排程器來試圖自圓其說。235樓大師已經自爆了,不過236樓sambad大有護貝。
ycweng wrote:
看你要從128-bit FMAC或是256-bit FMAC的角度去看嘍!一個模組內,有兩個128-bit FMAC單元,可以分別執行不同的SSE指令。


我不喜歡同樣的東西一直貼但是你沒看到.....

這個還是你自己給的Link......

http://blogs.amd.com/work/2010/10/25/the-new-flex-fp/

The beauty of the Flex FP is that it is a single 256-bit FPU that is shared by two integer cores. With each cycle, either core can operate on 256 bits of parallel data via two 128-bit instructions or one 256-bit instruction, or each of the integer cores can execute 128-bit commands simultaneously.

一個模組內,有一個256bit的FPU給兩個整數核心共用,可以同時執行一個256bit的資料或是兩個128bit的資料,或是兩個整數核心同時執行各一128bit的資料

簡單來說就是兩個線程加上一個256bit浮點運算單元
不論怎麼看就是一個Intel的1C2T的核心,只不過內部效率可能有所提升

但是到頭一個bulldozer模組其實就是一個核心...說甚麼多一倍核心只是AMD行銷部門的說法而已



ycweng wrote:

遊戲邏輯部分,以星海爭霸類的即時對戰遊戲,較好的作法是再拆thread,變成每一方至少有各自的thread處理,如果操控者一方有數個不同作戰單位的group,每個group,也可以有自己的thread,這些樓還落在您說的"遊戲邏輯"範圍內。



沒那麼簡單,光是每個Thread的Sync就難搞得要死....
而且大部分的情況下
最需要拆開來的都是畫面的部分....
Windwaker wrote:
一個模組內,有一個256bit的FPU給兩個整數核心共用,可以同時執行一個256bit的資料或是兩個128bit的資料,或是兩個整數核心同時執行各一128bit的資料

簡單來說就是兩個線程加上一個浮點運算單元
不論怎麼看就是一個Intel的1C2T的核心,只不過內部效率可能有所提升

但是到頭一個bulldozer模組其實就是一個核心...說甚麼多一倍核心只是AMD行銷部門的說法而已
..(恕刪)

我也不喜歡您選擇性看文呀!一個"256-bit的FPU"可以同時執行兩個不同的128-bit SSE指令,您要從外功角度看進來說它是一個256-bit FPU也成,我從程式設計角度跟CPU內部的scheduler角度看,它就是可以同時平行執行兩個不同的x87/128-bit SSE浮點指令的兩個管線/運算單元!連AMD的架構圖都是這樣畫的!!要怪,也只能怪Bulldozer為何被定義成雙重人格,SSE年代的故事又換個面貌重演一次.....

Windwaker wrote:
沒那麼簡單,光是每個Thread的Sync就難搞得要死....
而且大部分的情況下
最需要拆開來的都是畫面的部分....
..(恕刪)

不過我相信Blizzard的優秀團隊有作到!若遊戲邏輯只包成一個thread,程式的Responsiveness哪能被稱作優秀的"即時"戰略遊戲.....在公堂上"相信"一下,應該不犯法吧!..........不過您說了這麼多難難難,不如這封公文幫大家大聲念出來.....不......是開個工作管理員看看唄!

ycweng wrote:
我也不喜歡您選擇性看文呀!一個256-bit的FPU可以同時執行兩個不同的128-bit SSE指令,您要從外功角度看進來它是一個256-bit FPU也行,我從程式設計角度或CPU內部的scheduler角度看,它就是可以同時平行執行兩個不同的x87/128-bit SSE浮點指令!


到頭來還是在模組內分享一個 256bit的FPU,也只就是說跑256bit的 FPU指令和Intel一個Core一樣
只是一個模組的多功效率可能比Intel的HT高上一點
以效能來說,頂多就是跟Intel一個Core一樣
當然你要說AMD兩個打Intel一個平手也可以啦....

但是我覺得對消費者最簡單就是一個模組就是一個核心
這樣比較能理解Bulldozer 8 Core 4 module的大概效能在i7 4C8T哪邊...

ycweng wrote:
不過我相信Blizzard的優秀團隊有作到!遊戲邏輯只包成一個thread,那哪能稱作"即時"戰略,在公堂上"相信"一下,應該不犯法吧!....
您說了這麼多難難難,開個工作管理員看看唄!


SC的精隨在於網路上能把各個Player的 State準確在網路上交換
這可是有論文可以查到的
可不是他的效能管理
我甚至覺得Blizzard就是把畫面和邏輯各包一個Thread
也就是為什麼超過二核心沒有甚麼效能增進
  • 72
內文搜尋
X
評分
評分
複製連結
請輸入您要前往的頁數(1 ~ 72)
Mobile01提醒您
您目前瀏覽的是行動版網頁
是否切換到電腦版網頁呢?