不支援多核的軟體，都是用單核在跑的嗎? (第4頁)

kamuy
個人積分：32分
文章編號：50720042

32分

31樓

2014-06-20 17:20

Whistle Blow wrote:
(恕刪)
CMT/Module的架構理念，跟RISC/CISC沒有太大關係

呃...
我想你大概誤會我的意思了

上面原本想談的就是與OOOE有關的東西，尤其是Micro-ops的處理方式
嚴重影響SMT的效率，而那才是Bulldozer與後來新出的架構，跟AMD以往的CPU最大不同的地方
尤其是跟Alpha的相似之處...

然後Linux的Kernel對這方面做了不少努力去最佳化
微軟的做法則是把AMD的半對稱架構當成HT，所以我才會說微軟對這方面的最佳化
真的有待加強
滾來滾去

Whistle Blow

Whistle Blow
個人積分：1394分
文章編號：50720321

1394分

32樓

2014-06-20 17:39

kamuy wrote:
上面原本想談的就是與OOOE有關的東西，尤其是Micro-ops的處理方式
嚴重影響SMT的效率，而那才是Bulldozer與後來新出的架構，跟AMD以往的CPU最大不同的地方
尤其是跟Alpha的相似之處...
...(恕刪)

嚴格說來，AMD沒有SMT，而是CMT（Cluster-Based Multi-threading），AMD研發人員申請的專利原文，就是用Cluster這個稱呼，跟以往學界/業界稱呼是一樣的，後來到了上市階段行銷人員介入，才迸出Module這個名詞。CMT/模組架構概念也不複雜，就是怎樣以較低的成本/不真正實作多個獨立核心的方式，試圖貼近多個獨立核心的執行效益，這是節流；SMT的概念則是既然核心內已經存在這些強悍的管線了，怎樣透過同時執行來自多個執行緒的指令來提高管線使用率、盡量不閒置，並增加IPC，算是開源，故兩者出發點不同。

kamuy wrote:
但個人認為最大的問題在於Windows對AMD的SMT架構的最佳化，真的不怎麼好
不知道是微軟不爽幫AMD最佳化，還是AMD給的錢跟資源太少
然後Linux的Kernel對這方面做了不少努力去最佳化
...(恕刪)

您可以說說Linux的Kernel還做了什麼加強是Windows沒做的嗎？因為您的發言偏向表象的主觀"敘述"，卻少了客觀從內向外、Linux kernel真正改了什麼/最佳化了什麼的闡述。如果Linux 3.1針對推土機是沒tune好/有bug因而造成效能七折八扣的版本、而Linux 3.5是把bug解掉/把該有的效能tune回來呢？要如何確定這種可能性是不存在的呢？

kamuy

kamuy
個人積分：32分
文章編號：50720954

32分

33樓

2014-06-20 18:27

Whistle Blow wrote:
(恕刪)
您可以說說Linux的Kernel還做了什麼加強是Windows沒做的嗎？因為您的發言偏向外圍的"敘述"，卻少了從內向外、Linux kernel真正改了什麼/最佳化了什麼的闡述。如果Linux 3.1針對推土機是沒tune好/有bug造成效能七折八扣的版本、而Linux 3.5是解掉bug/把該有的效能tune回來呢？要如何確定這種可能性是不存在的呢？

我也不確定到底Linux Kernel到底做了什麼，畢竟我沒有去看過那些Source Code
所以在此我先跟您說聲抱歉。但我也可以告訴您為何我會這麼想

若您手邊有AMD Bulldozer架構的CPU的話，建議您可以測試一下
在Windows, Linux與各版Kernel之間，一些非綜合性測試的跨平台Benchmark

像我當時是測C-Ray跟p7z，平台是家裡的Intel i5-2400跟AMD的FX-6300，兩邊都用GCC編譯
都以預設時脈的狀況下

Linux在Kernel 3.1中，不意外的i5-2400可以輕易地幹掉FX-6300
但是如果將Kernel 升級及 3.5.x ，FX-6300卻居然可以幹掉i5-2400

但在Windows下卻沒有這個狀況，怎麼測都是i5-2400樂勝
即使我已經打了微軟放出的Hotfix也是如此

我想這個經驗，不知道能不能回答你的問題呢？
不過我當時沒抓圖，所以沒圖沒真相就是

Whistle Blow

Whistle Blow
個人積分：1394分
文章編號：50721749

1394分

34樓

2014-06-20 19:43

kamuy wrote:
若您手邊有AMD Bulldozer架構的CPU的話，建議您可以測試一下
在Windows, Linux與各版Kernel之間，一些非綜合性測試的跨平台Benchmark
像我當時是測C-Ray跟p7z，平台是家裡的Intel i5-2400跟AMD的FX-6300，兩邊都用GCC編譯
都以預設時脈的狀況下
Linux在Kernel 3.1中，不意外的i5-2400可以輕易地幹掉FX-6300
但是如果將Kernel 升級及 3.5.x ，FX-6300卻居然可以幹掉i5-2400
但在Windows下卻沒有這個狀況，怎麼測都是i5-2400樂勝
...(恕刪)

依您的描述，變因越來越多了，這種情況下，還要看GCC compiler版本、所下的編譯參數、以及是否i5的表現在新版反而被劣化了。

0931779549

0931779549
個人積分：1464分
文章編號：50725432

1464分

35樓

2014-06-21 0:03

kamuy wrote:
像我當時是測C-Ray跟p7z，平台是家裡的Intel i5-2400跟AMD的FX-6300，兩邊都用GCC編譯
都以預設時脈的狀況下
Linux在Kernel 3.1中，不意外的i5-2400可以輕易地幹掉FX-6300
但是如果將Kernel 升級及 3.5.x ，FX-6300卻居然可以幹掉i5-2400
但在Windows下卻沒有這個狀況，怎麼測都是i5-2400樂勝

水喔，3.5.x時候，i5-2400表現有退步嗎?
這麼神奇...

eszerfrm

eszerfrm
個人積分：31分
文章編號：50820503

31分

36樓

2014-06-26 22:05

Whistle Blow wrote:
嚴格說來，AMD沒有SMT，而是CMT（Cluster-Based Multi-threading），AMD研發人員申請的專利原文，就是用Cluster這個稱呼

的確，我承認這個架構並不新穎
但是我想說的是
當時這個架構是被暫時棄置的（因為AMD把資源全力投注在當時的K8上）
之後才重新挖出來
所以並不新穎，但是肯定跟以往不同

另外，我敢確定多處理器的目的一定有部分是為了功耗比（除非課本上教的是錯的）
裡面大概是說有個東西叫功能障蔽，就是時脈速率跟功耗增加的速率不成比例，
應該說增加功耗也上不去
所以後來就用比較簡單的核心，但是核心數比較多，來達成較高的效率（現在的預設時脈還是3出頭）
舉例而言

Pentium 4 Willamette (2001) 電耗75.3(W) 時脈速率2000(MHZ)
Pentium 4 prescott (2004) 電耗103(W) 時脈速率3600(MHZ)
Core 2 Kentsfield (2007) 電耗95(w) 時脈速率2667(MHZ)

來源:Computer-Organization-and-Design-4ed figure 1.15

不過不可否認的，我覺得也有跟製程有關，所以不能單單說核心數跟電源的...相關性

kamuy

kamuy
個人積分：32分
文章編號：51086678

32分

37樓

2014-07-13 16:34

原來還有人回應，文章洗太快幾乎忘了這篇

0931779549 wrote:
水喔，3.5.x時候，i5-2400表現有退步嗎?
這麼神奇...

Whistle Blow wrote:
依您的描述，變因越來越多了，這種情況下，還要看GCC compiler版本、所下的編譯參數、以及是否i5的表現在新版反而被劣化了。

個人自認為還蠻清楚科學方法中的操縱變因、控制變因及應變變因的差異
特地拿劣化的成績來說嘴，我覺得是相當愚蠢的事情

所以之前測試的時候，還有對照過i5及FX-6300在各別新舊版Kernel的分數
測了三次誤差都在4%上下，i5-2400的benchmark在新版Kernel下的成績並沒有劣化
而FX-6300在測試中有效能增進的，也有變慢的，不過總結來說效能仍然是有顯著的增進

而且當初會這樣測試，除了剛好手邊有Intel及AMD的系統以外
有很大部份是因為看了這兩篇的國外的測試：
AMD Bulldozer Performance On Ubuntu 12.10

AMD FX-8350 "Vishera" Linux Benchmarks

第一篇雖然有約一半的測試在新版Kernel都變慢，但仍可看到7-zip及C-Ray
這兩個個人在工作及一般使用上會用到的用途測試，卻幾乎有4%及20%的效能增長
4%的部份就算了，但20%的部份不太可能是系統誤差

後來去Linux Kernel的開發者論壇及bugzilla爬文
看到有人回報說新版Kernel 執行緒排程器，有對推土機架構作了部份的最佳化
印象中那篇bugzilla的PO文Source Report還是AMD的官方人員回饋的，至於文章在哪我可能還要再找一下

第二篇則是FX-8350與i5 2400S、i5-2500K及其他CPU在Ubuntu 12.10的測試
雖然Intel整體來說仍然是遠勝AMD，但某些測試(像我上面提及的7-zip及C-Ray)
AMD的推土機卻很奇妙的有速度上的優勢

其他的部份先不提，先看壓縮軟體這個部份來討論
其實非破壞性的壓縮幾乎都跟演算法有關(尤其是最小二元樹)，算是我的吃飯工具
與CPU暫存器的效率相當有關系，且就過去的經驗來說
Intel的暫存器效率是非常恐怖的，不禁開始懷疑這測試到底是否為真

就算再怎麼不堪
沒道理花5.5K買的i5會輸給3.3K的Piledriver
才動手自己來測試，只是結果出乎我意料與文章中寫的差不多

所以我才會說如果有AMD的CPU，不妨可以測試一下
說不定會得到一些有趣的結果呢
滾來滾去

Whistle Blow

Whistle Blow
個人積分：1394分
文章編號：51095922

1394分

38樓

2014-07-14 9:38

kamuy wrote:
而且當初會這樣測試，除了剛好手邊有Intel及AMD的系統以外
有很大部份是因為看了這兩篇的國外的測試：
AMD Bulldozer Performance On Ubuntu 12.10

AMD FX-8350 "Vishera" Linux Benchmarks

第一篇雖然有約一半的測試在新版Kernel都變慢，但仍可看到7-zip及C-Ray
這兩個個人在工作及一般使用上會用到的用途測試，卻幾乎有4%及20%的效能增長
4%的部份就算了，但20%的部份不太可能是系統誤差
...(恕刪)

第二篇我有看過，第一篇先前沒看過，但其中有一句話剛好印證我前面提到的測試變數問題：
=================================================================
變因越來越多了，這種情況下，還要看GCC compiler版本、所下的編譯參數、以及是否i5的表現在新版反而被劣化了。
=================================================================

i5的部份您有說明了；編譯參數在第一篇中有說明是一樣的；問題就出在GCC compiler版本不一樣。

---------------------------------------------------------------
For some of the common computational benchmarks, Ubuntu 12.10 on the AMD Bulldozer FX-8150 is faster than Ubuntu 12.04.1 LTS, largely due to upstream GCC improvements.
---------------------------------------------------------------

作業系統執行緒排程針對模組架構的可改進處，我有貼在28F，之前Windows 7針對推土機釋出的KB2645594補丁，就是做這件事情，另外一個KB2646060補丁是處理FX模組架構的Core Parking。

大部分在Windows下進行的FX打補丁前/打補丁後的測試，是用同樣版本的測試應用程式（也就是沒有應用程式是否重新編譯的問題），把變因控制在作業系統的更動；但是像您的第一篇所提到的，Linux核心更新了，GCC編譯器版本卻也更新了（測試應用程式也被重新編譯過）。

如果要比較Linux跟Windows的測試結果以斷言微軟是否作得不夠，那麼Windows端也該用打補丁前/打補丁後的作業系統，分別搭配沒針對FX最佳化的編譯器以及針對FX最佳化過後的編譯器來進行測試，變因才算統一、才有可比較性。

yinhell

yinhell
個人積分：16分
文章編號：51096114

16分

39樓

2014-07-14 9:50

kamuy wrote:
雖然Intel整體來說仍然是遠勝AMD，但某些測試(像我上面提及的7-zip及C-Ray)
AMD的推土機卻很奇妙的有速度上的優勢

原來如此當時我還以為是錯覺

當時同版本win7 + 同版本7z 解壓縮同一套source code

FX8350 硬是比 E3-1230V3 還少約20% 的時間

Whistle Blow

Whistle Blow
個人積分：1394分
文章編號：51096283

1394分

40樓

2014-07-14 10:01

yinhell wrote:
原來如此當時我還以...(恕刪)

針對Entropy Coding的壓縮類程式，可以試試關閉Core Parking功能，曾經有人試過在Hyperthreading的2600K上關掉Windows 7的Core Parking功能，而Cinebench 11.5的分數從8.52變成8.70（第59樓）。

http://www.overclock.net/t/1180334/xtremehardware-it-core-parking-on-windows-7/50

影響最大的是WinRAR，關掉Core Parking會使2600K的WinRAR多執行緒測試成績從3980KB/s三級跳到5591KB/s。

http://www.overclock.net/t/1180334/xtremehardware-it-core-parking-on-windows-7

要關掉Core Parking，可以直接改registry，如果要再打開Core Parking，改回來便可以。

http://forum.cakewalk.com/tm.aspx?&m=1861804&mpage=1
http://global.hkepc.com/forum/viewthread.php?tid=1736488