RSS   



  可打印版本 | 推薦給朋友 | 訂閱主題 | 收藏主題 | 純文字版  


 
 123  3/9  <  1  2  3  4  5  6  7  8  >  >| 


 
主題: [求助] [已解決][問題]雙核心轉檔時其他軟體會lag嗎?   字型大小:||| 
  ☆★☆★ TWed2k 向你推薦這篇文章 ★☆★☆  
crazydark
金驢友〔初級〕
等級: 16等級: 16等級: 16等級: 16
貧窮金太郎

 . 積分: 1852
 . 精華: 2
 . 文章: 2767
 . 收花: 16315 支
 . 送花: 11203 支
 . 比例: 0.69
 . 在線: 2947 小時
 . 瀏覽: 49480 頁
 . 註冊: 7214
 . 失蹤: 0
 . Taiwan
#31 : 2007-2-28 10:47 PM     只看本作者 引言回覆


引用:
badcat寫到:
而 Linux 或 Unix 利害的地方就在將多個 CPU 在作業系統中仍當「『一個』極強的『虛擬』 CPU」(請注意,我強調的是一個!),CPU 的資源統籌分配就交給 Linux 或 Unix 作業系統去模擬及調控。(若說明不對,還請 Linux 或 Unix 高高手指正!)
Linux 或 Unix 底下的軟體只看見「一個極強的虛擬 CPU」,至於怎麼分配,是作業系統的問題,所以軟體「根本」不需考慮「多核心的最佳化程式碼」,只要 CPU 數量一多,程式自然會提升效能。(程式根本不知道有「多個 CPU」的事情!)
這樣「軟體」階層就能避開 Windows 作業系統中「軟體」對「單/雙/多核心」程式碼「最佳化」的問題,「軟體」不需特意為「多核心程式碼的最佳化會影響執行效能」去改寫程式而傷腦筋,畢竟那是 Linux 或 Unix 作業系統階層的問題。
「2顆/2=1 虛擬」跟「512顆/512=1 虛擬」,在 Linix 或 Unix 中對程式而言,都是當成一顆「虛擬」CPU,但效能在 Linix 或 Unix 中就會差很多,但 Linux 或 Unix「程式軟體」階層是不必重寫的。(是作業系統在傷腦筋嘛!)


我對本文存疑
理由如下:

多核心程式的問題是
你怎樣將你要做的工作與要處理的資料拆成多個部份
並交給不同的核心去做
麻煩就在於大部份的工作都很難拆成非常獨立的兩個部份
且一段工作的產出往往是另一段工作的待處理資料
因此在工作分配與資料的切割/共享上就會是一個很大的問題
工作loading分配不均....一核忙碌多核閒也不行
資料切割不佳....不停的在核心間傳送資料....效率不彰徒然浪廢I/O時間
這些問題是與你的程式要做的事息息相關(Job dependent)
連人腦都不容易搞好
所以我認為OS並沒有這麼神可以幫你做這些事

面對千百萬種的程式
如何拆解成多個工作....怎麼拆....拆開的工作間原來沒有的協調機制怎麼加
都是問題啊
如果你不能先把你的程式設計成可以讓多核協同工作
我想OS再強應該也很難將你的工作拆開並同時派遣給不同的核心一起處理

[crazydark 在  2007-2-28 10:52 PM 作了最後編輯]



[如果你喜歡本文章,就按本文章之鮮花~送花給作者吧,你的支持就是別人的動力來源]
本文連接  
檢閱個人資料  發私人訊息  Blog  快速回覆 新增/修改 爬文標記
badcat
銀驢友〔初級〕
等級: 12等級: 12等級: 12
壞喵

 . 積分: 541
 . 精華: 3
 . 文章: 837
 . 收花: 3874 支
 . 送花: 982 支
 . 比例: 0.25
 . 在線: 3330 小時
 . 瀏覽: 62312 頁
 . 註冊: 7213
 . 失蹤: 146
#32 : 2007-2-28 11:28 PM     只看本作者 引言回覆

版主 mocaca0918 : 於本帖中與其他會員有良好互動,且技術交流層面高,故予以加分鼓勵

評分:+5   
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> 平凡小任 說道:
> 您在先前不是說64bit不會是32bit的兩倍
> 但接下來又說轉檔要找64bit版本表現會較好

沒矛盾啊?
1. 運算效能不一定會兩倍
2. 64 bits 效能會比較好
3. 那 64 bits + 雙核心 轉檔程式在 Vista 提升個 1.5 倍算不算表現比 Windows XP 的 1 倍好。(沒超過兩倍嘛!1.5 倍是比喻啦!不一定是這個數。)


> 然而在控肉的新架構上卻完全只有趴掉的份

在同一製程下 (譬如 Intel & AMD 都用 60nm 製程)
那 AMD 的 Hyper Transport 絕對可以把 Intel Core 打趴。
因為 AMD 的 Hyper Transport 考慮的是「多核心」、「多匯流排」大型電腦的情況。(當初此架構是給高階伺服器電腦在用的,類似用高速網路的概成做成多核心 CPU 匯流排。)
而 AMD 下一代的 Hyper Transport 3.0 版下,光單一 CPU 的匯流排就有 5.2GT/s(20.8GB/s),而且可依 CPU 核心增加而增加匯流排數。(幾個 CPU 就可加幾個匯流排)
而 Intel 還一直停留在 PC 個人電腦的 CPU 系統匯流排架構。所有 CPU 核心共用同一匯流排。
在 Intel 沒有改善 CPU 到 北橋 或週邊匯流排 架構的情況下,總有一天 CPU 的系統匯流排會不敷使用。

但 AMD 的 製程一直不如 Intel 進步。一直是很難克服的地方。

小弟倒沒有品牌情結,在 Intel Pemtium 之前,Intel 一直都比 AMD 好 (但也貴)。
但現在 AMD 獲得大型電腦的 Hyper Transport 技術後,在同樣製程下,AMD 的效能比自然高,發展空間也會比較大。

等到 Intel 在整體層面超越 AMD 後 (技術/品質/效能/方便性...),價位也合理的情況下,自然會跳槽到 Intel。
P.S. 目前比較討厭的是,Intel 每換新一代 CPU 就要換新的主機版。(賺錢嘛!) 而 AMD 是 AM2 腳位撐到不夠用時才換 AM3,以 DIY 的角度來看。AMD 較划算。(當你夠有錢時就不用在意啦!)
  

> 至於您提到的unix轉檔程式?
> 老實說不會是什麼顯學
> 如果真的很棒的話
> 那麼轉檔專用機早就推unix了

對啊!所以我沒叫你學 Unix 轉檔,兩個作業系統的方向差太多了!(微軟獨大!哇哈哈!)


> 至於powernow上網查他的功能?
> 我想沒啥必要

至少你要知道你的東西在做什麼用的,不然有一天突然 CPU 效能沒有增加時,你還會怪 PowerNow! 怎麼沒有發揮效能?

不過東西是給人用的,當你發現 PowerNow! 可以提昇 CPU 效能時,那你就用它吧!反正有達到你的 目的 的,那就是好用的東西!



> crazydark 兄 說道:
> 我對本文存疑
> 多核心程式的問題是
> (中略....)
> 所以我認為OS並沒有這麼神可以幫你做這些事

嗯!存疑是好事!不知道的事,小弟也不敢講死!

的確,Linux 或 Unix 如何協調多核 CPU 及多工之間的關係,不是小弟「小小的腦袋」可以理解的,就我所知的說明也不敢保證一定準確,說不定也有如 crazydark 兄所說的問題存在。
一個是為了解決跨平台及多核心資源分配而犧牲了部份效能!
一個是為了效能而犧牲了跨平台。

小弟所說的是為了能解決:每增加新的 CPU 架構,就要考慮重寫一次新的程式的困擾! (程式設計師的因擾。)

個人認為多核 CPU 這個相關硬體的部份,應該交由「作業系統」階層來應付,而不要由「程式軟體」階層的程式設計師來處理。
第一. 太直接處理硬體 (缺乏彈性,硬體一變就要改程式)
第二. 不是每個程式設計師都能遵循多核心的最佳化標準來設計,很可能各自為政!
最後就是一堆 CPU 最佳化程式把多核心的 CPU 資源搞的一團糟!

所以小弟認為此問題最好能在硬體就解決,譬如內建多核心的晶片,到外部匯流排時,作業系統看到的就認為是一個 CPU 核心而已。(不過易缺乏彈性,比如說有很多個「多核晶片」串連 * n個時怎麼辦?)

所以從「作業系統」層面來解決,至少減少「軟體程式」層面要解決 CPU 硬體的問題,那程式在面對單/雙/多核時,都不用改寫程式,才不會每新增新的 CPU 硬體變動,「每套」軟體的最佳化都要改寫,才會有明顯效能改進的窘境。(這是理想啦!請別罵我啦!嗚!嗚!...)

P.S. 好像離題了?對不起!對不起!...

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1

iQA/AwUBRe1gZRl3yhBVZiD/EQKsmQCfblKuxMf6u2CbJZdsW116oy96IgIAoJDy
uG07EIRpYRypRGFPZb0j4ntB
=j1ZX
-----END PGP SIGNATURE-----

[badcat 在  2007-3-6 08:37 PM 作了最後編輯]



[如果你喜歡本文章,就按本文章之鮮花~送花給作者吧,你的支持就是別人的動力來源]
本文連接  
檢閱個人資料  發私人訊息  Blog  快速回覆 新增/修改 爬文標記
crazydark
金驢友〔初級〕
等級: 16等級: 16等級: 16等級: 16
貧窮金太郎

 . 積分: 1852
 . 精華: 2
 . 文章: 2767
 . 收花: 16315 支
 . 送花: 11203 支
 . 比例: 0.69
 . 在線: 2947 小時
 . 瀏覽: 49480 頁
 . 註冊: 7214
 . 失蹤: 0
 . Taiwan
#33 : 2007-2-28 11:42 PM     只看本作者 引言回覆

版主 mocaca0918 : 於本帖中與其他會員有良好互動,且技術交流層面高,故予以加分鼓勵

評分:+5   
回到樓主的問題上
"winavi下去轉mpeg成xvid格式,不過每次轉檔時有時都還會做其
他動作。例如:燒dvd,玩模擬器(Kawaks,mame32,pSX emulator..等),
看網頁,聽音樂,看xvid格式的動畫,玩玩H-GAME之類的"
我看起來樓主的作業上除了燒DVD外
大部份都是吃CPU或是一般工作的工作居多

轉檔是很吃運算效能的....
特別是使用越新的codec

而樓主如果是轉電視卡錄下的內容的話
轉檔的瓶頸絕對不會在硬碟的IO上
舉個例子好了
Deep blue這個HD的影片
沒記錯的話流量約在20Mbps上下
這在現今的視訊裡已是非常高水準的數字
然而20Mbits/sec = 2.5Mbytes/sec
現在的硬碟傳輸量早已遠大於這個數字
即使讓你20Mbps進20Mbps出好了
進出硬碟的資料吞吐量也不過5Mbytes/sec
更別提一般電視卡抓下來的低流量影片
除非是用raw picture去做壓縮
不然硬碟速度決不是問題

那加RAM有沒有效
如果你現在的記憶體使用率不到高水平甚至超過實體記憶體
那麼加RAM對你的效能幫助可能幾近於零
其實視訊壓縮對記憶體的依賴度也不高
以MPEG-1, MPEG-2, MPEG-4 part 2來說
在壓縮時大概會需要三張的空間
以2048x1024....YCbCr取樣為4:2:0來說
所需的frame buffer大概為2048x1024x1.5x3 = 9 Mbytes
對現今以512MB起跳的記憶體來說簡直是九牛一毛啊
就算再加一堆運算時需暫存的變數
我想離被稱為吃RAM的怪物應該還有一段距離才是

我認為樓主的問題是在運算上不夠力
所以如果樓主希望能在轉檔時也能讓其它工作的反應時間很短的話
換成更快的或是雙核的CPU對你一定會有幫助的
不管是轉檔時間或是其它程式的反應時間....
一定都會有所增進



[如果你喜歡本文章,就按本文章之鮮花~送花給作者吧,你的支持就是別人的動力來源]
本文連接  
檢閱個人資料  發私人訊息  Blog  快速回覆 新增/修改 爬文標記
平凡小任
金驢友〔中級〕
等級: 17等級: 17等級: 17等級: 17等級: 17


 . 積分: 2378
 . 文章: 8010
 . 收花: 19199 支
 . 送花: 18840 支
 . 比例: 0.98
 . 在線: 7367 小時
 . 瀏覽: 58690 頁
 . 註冊: 7934
 . 失蹤: 11
 . Taiwan
#34 : 2007-2-28 11:54 PM     只看本作者 引言回覆

版主 mocaca0918 : 於本帖中與其他會員有良好互動,且技術交流層面高,故予以加分鼓勵

評分:+5   
badcat 兄
您真的用過vista的64bit跑轉檔過嗎?
效能真的會有1.5倍的成長嗎?
就算是far cry好了
他出64bit版本後軟體還是重新再寫過
而不是直接"硬上"
而且就我自己的vista使用經驗
跟XP比起來效能遜色不說
連驅動程式的支援都很有問題
跑轉檔真的很強嗎?
懷疑中...

您還在講unix轉檔的確是頗奇妙的事
該不會網路上如nike老大都是用unix轉檔的吧?
不會吧?
既然您知道XP比較多人用
為何還去學那種比較冷門的東西
何況轉檔根本就不是他的強項
學了對轉檔又能如何呢?

再來powernow的問題
至少在你講的效能低落上我還沒有看過
我已經說過雙核心的妙用了
現在要同時看到兩個核心跑滿很難
之前3000+中毒時一開機就準備重開
連滑鼠移動都有困難的情況在雙核情況下已不復見
支援雙核心的病毒我也沒看過
再來就是就算邊轉檔邊看高畫質影片好了
雙核心可以辦到,單核不能

如果您只是根據自己的知識想像的話
為何不自己體驗看看呢
我自己從3000+過渡到現在的op170感受相當深刻
您呢?
還是以上只是您自己天馬行空的想像?

[平凡小任 在  2007-2-28 11:59 PM 作了最後編輯]



[如果你喜歡本文章,就按本文章之鮮花~送花給作者吧,你的支持就是別人的動力來源]
本文連接  
檢閱個人資料  發私人訊息  Blog  快速回覆 新增/修改 爬文標記
badcat
銀驢友〔初級〕
等級: 12等級: 12等級: 12
壞喵

 . 積分: 541
 . 精華: 3
 . 文章: 837
 . 收花: 3874 支
 . 送花: 982 支
 . 比例: 0.25
 . 在線: 3330 小時
 . 瀏覽: 62312 頁
 . 註冊: 7213
 . 失蹤: 146
#35 : 2007-3-1 12:00 AM     只看本作者 引言回覆

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> crazydark 兄說道:
> 回到樓主的問題上

嗯!小弟目前也是建議

1. 用 Windows XP SP2 並安裝前述的雙核心 CPU 修正程式,來提升一些雙核心 CPU 資源分配效能。(除非你能找到 64 bits + 雙核心 最佳化 轉檔程式,不然還是別想用 Vista 轉檔。效能還不一定會高!)
TWed2k - 心得教學區 - [分享]微軟-雙核心處理器修正程式 for Windows XP SP2 (by   一秒鐘幾十萬上下)
http://twed2k.org/redirect.php?tid=145748
2. 找一套高效能轉檔程式,最好是支援雙核心 CPU 最佳化及 SSE3 或 MMX+ 等擴充指令的轉檔程式。
3. 最好用高速的硬碟 (請自己想!如 SATA 或 RAID...),讀出和寫入不要同一台實體硬碟
4. 不要灌太多程式,不要同時執行太多軟體。(睡覺時候轉,最好找有排程轉檔的轉檔程式)
  P.S. 若真要一邊轉檔一邊玩,那就找可調整程式優先權的轉檔軟體,如 VirtualDubMod 可調成 Idle 狀態,在幕後轉,雖轉檔慢但較不影響其它程式運作。
5. 可加裝 SuperCache 等 Disk Cache 程式。
6. 如果 RAM 夠多,開個 RamDrive 來轉檔。(嗯...要很多才行!)

如同之前小弟所說的,把每一個細節做好,累積出來的效率提昇也是看的見的啦!
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1

iQA/AwUBReWo8hl3yhBVZiD/EQJLHQCghawqFj9T+CyyrQdYJExhUjHFYokAn3Du
tIh+6gyRg3PLVSuI6iiS9GHW
=MtnW
-----END PGP SIGNATURE-----

[badcat 在  2007-3-1 12:08 AM 作了最後編輯]



[如果你喜歡本文章,就按本文章之鮮花~送花給作者吧,你的支持就是別人的動力來源]
本文連接  
檢閱個人資料  發私人訊息  Blog  快速回覆 新增/修改 爬文標記
平凡小任
金驢友〔中級〕
等級: 17等級: 17等級: 17等級: 17等級: 17


 . 積分: 2378
 . 文章: 8010
 . 收花: 19199 支
 . 送花: 18840 支
 . 比例: 0.98
 . 在線: 7367 小時
 . 瀏覽: 58690 頁
 . 註冊: 7934
 . 失蹤: 11
 . Taiwan
#36 : 2007-3-1 12:21 AM     只看本作者 引言回覆

關於轉檔程式
大家都有聽過winavi吧
聽說轉檔速度很快
但是不管怎麼快法,轉出來的東西就是比不上慢工出細活的tmpgenc
轉檔是花時間且耗資源的動作
CPU的使命責無旁貸
我不認為為了屈就單核硬要多工調整優先權
導致轉檔時程的延後
對照直接買碗控肉飯來吃兩者之間前者會有較多的優勢
3000+我也玩過轉檔,我也調過優先權
硬碟我也不是IDE,是兩顆SATA2組RAID0
實際的使用上輸OP170頗多
有轉過檔的網友開工作管理員就知道
CPU會飆高,就算調低好了
在我看來也是滿高的,會影響到其他程式的使用(單核)...XD
但雙核時你管他
一開始先在程式裡設定超高
然後有需要的話開工作管理員指定核心
其他軟體照用,這樣不是很好嗎?
不過如果你一邊轉檔一邊玩COH小弟則不能保證效果很好
畢竟COH支援雙核且CPU LOADING頗高...XD

[平凡小任 在  2007-3-1 12:26 AM 作了最後編輯]



[如果你喜歡本文章,就按本文章之鮮花~送花給作者吧,你的支持就是別人的動力來源]
本文連接  
檢閱個人資料  發私人訊息  Blog  快速回覆 新增/修改 爬文標記
crazydark
金驢友〔初級〕
等級: 16等級: 16等級: 16等級: 16
貧窮金太郎

 . 積分: 1852
 . 精華: 2
 . 文章: 2767
 . 收花: 16315 支
 . 送花: 11203 支
 . 比例: 0.69
 . 在線: 2947 小時
 . 瀏覽: 49480 頁
 . 註冊: 7214
 . 失蹤: 0
 . Taiwan
#37 : 2007-3-1 02:08 AM     只看本作者 引言回覆


引用:
badcat寫到:
嗯!存疑是好事!不知道的事,小弟也不敢講死!

的確,Linux 或 Unix 如何協調多核 CPU 及多工之間的關係,不是小弟「小小的腦袋」可以理解的,就我所知的說明也不敢保證一定準確,說不定也有如 crazydark 兄所說的問題存在。
一個是為了解決跨平台及多核心資源分配而犧牲了部份效能!
一個是為了效能而犧牲了跨平台。

小弟所說的是為了能解決:每增加新的 CPU 架構,就要考慮重寫一次新的程式的困擾! (程式設計師的因擾。)

個人認為多核 CPU 這個相關硬體的部份,應該交由「作業系統」階層來應付,而不要由「程式軟體」階層的程式設計師來處理。
第一. 太直接處理硬體 (缺乏彈性,硬體一變就要改程式)
第二. 不是每個程式設計師都能遵循多核心的最佳化標準來設計,很可能各自為政!
最後就是一堆 CPU 最佳化程式把多核心的 CPU 資源搞的一團糟!

所以小弟認為此問題最好能在硬體就解決,譬如內建多核心的晶片,到外部匯流排時,作業系統看到的就認為是一個 CPU 核心而已。(不過易缺乏彈性,比如說有很多個「多核晶片」串連 * n個時怎麼辦?)

所以從「作業系統」層面來解決,至少減少「軟體程式」層面要解決 CPU 硬體的問題,那程式在面對單/雙/多核時,都不用改寫程式,才不會每新增新的 CPU 硬體變動,「每套」軟體的最佳化都要改寫,才會有明顯效能改進的窘境。(這是理想啦!請別罵我啦!嗚!嗚!...)

P.S. 好像離題了?對不起!對不起!...



OK....我們把事情分成兩部份講
1.現有程式在面對單/雙/多核時,要不要改寫程式
2.已支援多核程式面對不同的硬體架構的最佳化

1."現有程式在面對單/雙/多核時,要不要改寫程式"
現有的程式多為對應單核所撰寫的程式
先不說在多核這種跨不同執行實體間的溝通機制付之闕如
甚至連程式可不可以將工作拆解成二或多個部份都不知道
雙核或多核之所以難寫
是因為事前的分析規畫一但沒搞好
不要說1+1等於2或是1+1等於1.x
慘烈一點的還會把1+1搞到小於1呢
如果說用工具對程式碼分析改寫我還不敢講
不過如果交給OS來做並主動為這些單核程式新增這些機制
第一是OS面對的是已編譯完的程式....而非原始程式碼....分析難度高
第二是要在runtime時分析....不能花太多時間....
在這樣的條件下
我認為要叫OS來讓現有對應單核的程式在雙/多核CPU上使用到雙/多核
是幾近不可能任務

2."已支援多核程式面對不同的硬體架構的最佳化"
新的CPU硬體變動....程式不用改寫
只要不要整個指令集換掉....這個OK....
那新的CPU硬體變動....程式要不要為了最佳化而改寫

我以Intel的core 2 duo跟AMD的Athlon64x2來做個很粗淺的例子好了
因為Athlon64x2每次一傳資料
  a.Core2跟Core1要資料
  b.Core1從Core1的cache取值
  c.Core1傳給Core2
  d.Core2寫一份到Core2的cache中並工作
而在core 2 duo中
因為L2共用的關係
只要資料在L2中
Core2就可以直接取用
而Core1也不必多花時間把資料傳到Core2

也因此兩者在資料分派交換的規畫上就會不相同
一樣是雙核心
但我在做最佳化分析時
我可能會讓資料在Athlon64x2的核心間交換次數少於core 2 duo
而這就會影響多核程式的寫法
如果應要不管放任大量的資料交換在Athlon64x2雙核間發生的話
程式一定還是可以跑
但是跑起來可能會比把設計成簡少資料交換的程式來得慢

那麼老問題來了
面對不同規劃所設計出來的程式
如何分析並重組成針對另一架構最佳化的設計
用人腦面對高階程式語言都要花上一些時日了
如何奢望這件事能從OS端解決?

3.
如果我對badcat的說法認知沒錯的話
badcat的理想固然是所有程式設計師夢寐以求的境界(啊....寫OS的人除外....^_^....)
然而可惜的是實行上
個人淺見認為困難重重..幾近不可能....



[如果你喜歡本文章,就按本文章之鮮花~送花給作者吧,你的支持就是別人的動力來源]
本文連接  
檢閱個人資料  發私人訊息  Blog  快速回覆 新增/修改 爬文標記
chihiro
巨乳星人.版主
等級: 30等級: 30等級: 30等級: 30等級: 30等級: 30等級: 30等級: 30
巨乳もみ星人+馬尾屬性★

 . 積分: 1381
 . 文章: 1982
 . 收花: 6933 支
 . 送花: 6682 支
 . 比例: 0.96
 . 在線: 2267 小時
 . 瀏覽: 24971 頁
 . 註冊: 7975
 . 失蹤: 139
 . 女神親衛隊
#38 : 2007-3-2 11:19 AM     只看本作者 引言回覆

嗯...
看的出來一邊是用程式邏輯+電腦基礎概論在講.
另一邊是用經驗法則在講.

這篇真精彩.



[如果你喜歡本文章,就按本文章之鮮花~送花給作者吧,你的支持就是別人的動力來源]
本文連接  
檢閱個人資料  發私人訊息  Blog  快速回覆 新增/修改 爬文標記
killer00
銀驢友〔高級〕
等級: 14等級: 14等級: 14等級: 14


今日心情

 . 積分: 823
 . 文章: 942
 . 收花: 7508 支
 . 送花: 3026 支
 . 比例: 0.4
 . 在線: 3881 小時
 . 瀏覽: 7911 頁
 . 註冊: 6739
 . 失蹤: 2643
#39 : 2007-3-3 01:49 AM     只看本作者 引言回覆

crazydark、badcat 兩位講的其實都沒問題,只不過是站在不同角度看這件事情罷了。

Linux、Unix系統被設計成能善用多CPU架構,所以該煩惱的就是OS設計師,但一般程式要在這些OS上工作除了符合規範外,的確不需要考慮CPU使用的問題,因為這一切交給OS幫忙管理,這原本就是OS的工作,這也就是badcat的論點。

而crazydark講的部份其實也說不上問題不問題,就只是能不能利用到雙核心的特點,當然就常理來說,能用到雙核心的狀況只有:多工;不能發揮特點時,最多還是當各單核心在用,這也沒什麼,一般來說絕大時間不會有這樣的狀況,因為目前OS原本就朝著多工的方向邁進,只不過一般使用者以為核心多就代表速度一定會快,這不是絕對的,使用方向不對,想快也快不起來,多工才是它的特性,如果只為了加快單一工作使用雙核心,那完全是搞錯方向。(雙核心的原理、工作方式完全沒弄清楚,受到時脈的影響產生出比較高的效能卻誤會成是雙核心本身帶來的效果,這也正是一大問題)

我想crazydark講的第1點問題不是OS本身,而是程式語言,因為程式要對CPU做對應,會從程式語言下手,針對CPU的指令集做對應,基本上目前我還沒看到有哪版的程式語言已經開始應用雙核心的指令集(可能我接觸太少,如果有,請告訴我一下,我想玩玩看),正因為沒對應,所以目前軟體只有靠程式設計師本身的功力去補強程式語言的不足,程式改寫是程式語言會更改,而一般用程式語言的程式設計師頂多可能會多學幾指令(應該不至於,也許會用引入函式庫的方式),一般寫的軟體都是用高階語言所寫的,基本上更動不大,如果要針對雙核心做更動,應該是程式語言本身,他本身由低階語言組成,作為高階程式與硬體的橋樑,硬體出現更動,理所當然的他也必須相對的做出改變。

雙核心的問題在於工作的分派問題無法解決,但前面的人有的以為資料就像是水,CPU是尺寸固定的水管,核心越多,代表資料流過的越多,即使單個程序也可以用這樣的推論去跑,但其實完全不對。

單一程序無法被兩個核心同時運作(頂多是輪流分派),這點是絕對無庸置疑。

要知道CPU運作的方式是將程序從記憶體載入至CPU中開始運算,但如果把這個程序的資料分成兩邊做運算會有什麼下場?比如:t=2x*3y,ans=t/2,這樣一組運算式要被雙核心運算,可能拆成兩個部分算嗎?(t=2x*3給core A,ans=t/2給core B),不可能,對OS而言他是無法分辨這是數學運算式還是其它資料,他只會依照它的演算法去判斷這筆資料是否有關聯,沒有關聯性的才讓他被兩顆核心同時運作,但有關聯性的仍是單科核心運作,至於為何轉檔時可以看到兩顆核心都在運作,要知道CPU本身能存放的資料原本就不多,當然依照OS的演算法去推測,他可以先找出沒有相關聯性的部分分派出來,使得兩個CPU都可以處於工作狀態,但影像畢竟是一連串的資料,能分開處理的部分畢竟不再多數,所以能發會的空間自然不多。

PS:「時脈」不等於「運算速度」,相信現在大部份人都有共識了吧←badcat的講法我不是不知道,這講法也是有問題的,而且我想你誤解我的敘述,我並沒說「時脈」等於「運算速度」,而是說「時脈」高時脈的CPU轉檔效果會比較好,不然你可以看看市面上相同款式的CPU,哪一個會是時脈低的比時脈高的優秀(我講的是“同一款”,例如E6300、E6700,兩者時脈誰高?誰的效能好?),「時脈」調高,「運算速度」不見得能上去,這是瓶頸,但不代表時脈」調低,「運算速度」還能保持相同水準,當瓶頸不再是瓶頸時,你會認為呢?



[如果你喜歡本文章,就按本文章之鮮花~送花給作者吧,你的支持就是別人的動力來源]
本文連接  
檢閱個人資料  發私人訊息  Blog  快速回覆 新增/修改 爬文標記
chaeung
版主
等級: 30等級: 30等級: 30等級: 30等級: 30等級: 30等級: 30等級: 30
GOD

 . 積分: 264
 . 文章: 1337
 . 收花: 1379 支
 . 送花: 1 支
 . 比例: 0
 . 在線: 1321 小時
 . 瀏覽: 16502 頁
 . 註冊: 7974
 . 失蹤: 858
#40 : 2007-3-3 02:01 AM     只看本作者 引言回覆

個人獨斷的偏見:

無論單核雙核多核, 單工多工, 個人用和主機用根本沒有可比性.

1.32bit和64bit的差別僅在於定址最大範圍, 也就是說定址範圍愈大, CPU一次指令可處理的資料極限也就愈大, 理論上速度有差, 實際上還要看情形(OS+AP的配合度).
2.Windows這類GUI系統通常是個人使用, 有大量資源使用在GUI上, 本來速度就慢, 而且最主要是給人操作用的, 人的操作(閱讀)速度才是重點, 其實在圖形介面的後台也是以TEXT模式跑的; 而且, 快個幾分鐘或幾十分鐘應該只是個有參考價值的效能指標, 假設PC壽命3年不關機運作, 26280小時中像轉檔編碼這種密集運算能佔幾小時? 省下來的時間對個人而非公司而言有多少意義? 單人多工, 再怎麼多工也要等人, 除非人一直坐在電腦前從頭盯著螢幕看到尾, 否則程式跑完等人的這一等就把絕大部份節省下來的時間浪費掉了.
3.Unix/Unix-like等的TEXT模式介面系統雖然簡陋, 卻將資源完全用在實際運算上, 在相同硬體下先天就勝過GUI系統一大截, 所以比較正規或是有重要功能的主機幾乎都不會用Windows, , 本來就不是給人用... 呃... 給人長時間坐在電腦前面操作用, 所以也不用等人, 只要系統不crash, 就會不停運轉下去.
4.Unix/Unix-like最完美的結合典範是Mac OS X (FreeBSD+Mac GUI).

言歸正傳...

轉檔工作=從HDD讀取->送到RAM->CPU編碼->送到RAM->寫入HDD, 非3D就不提GPU了.
瓶頸還是在HDD, 目前主流7200rpm讀寫速度平均在55-65m/s, 意思就是, CPU轉碼再快, RAM再大, 都要受限於HDD的"內部速度", ATA-100/133和SATA-150/300都完全沒有意義, 不少RAID Card甚至還要受PCI Bus速度的限制, 只要HDD來不及寫入資料(有些系統還可以寫入資料後再verify一遍更慢), CPU/RAM都要停下來等待, 此時N核N位元N THz的CPU和N TB的RAM都沒用(RAM Disk除外), 如果同一時間還有其它程式要對HDD進行讀寫, HDD速度立刻腰斬再腰斬(磁頭移動耗時).

所以, 結論是,
1.規劃好動作, 不要讓多個程式同時對同一顆HDD進行讀寫(免成本).
2.轉檔編碼等大動作要快, 錢花在CPU/RAM上不如花在HDD上(如RAID 0或Multiplier).
3.如果預算夠, 市面有DDR2 2GB一條的RAM, 插滿4槽8GB, 在XP64下足夠開RAM Disk了, 技嘉的i-RAM也可以, 而RAM Disk一開... 本篇就沒什麼好繼續的了.

以上



[如果你喜歡本文章,就按本文章之鮮花~送花給作者吧,你的支持就是別人的動力來源]
本文連接  
檢閱個人資料  發私人訊息  Blog  快速回覆 新增/修改 爬文標記
平凡小任
金驢友〔中級〕
等級: 17等級: 17等級: 17等級: 17等級: 17


 . 積分: 2378
 . 文章: 8010
 . 收花: 19199 支
 . 送花: 18840 支
 . 比例: 0.98
 . 在線: 7367 小時
 . 瀏覽: 58690 頁
 . 註冊: 7934
 . 失蹤: 11
 . Taiwan
#41 : 2007-3-3 04:58 PM     只看本作者 引言回覆


引用:
chaeung寫到:
個人獨斷的偏見:

無論單核雙核多核, 單工多工, 個人用和主機用根本沒有可比性.

1.32bit和64bit的差別僅在於定址最大範圍, 也就是說定址範圍愈大, CPU一次指令可處理的資料極限也就愈大, 理論上速度有差, 實際上還要看情形(OS+AP的配合度).
2.Windows這類GUI系統通常是個人使用, 有大量資源使用在GUI上, 本來速度就慢, 而且最主要是給人操作用的, 人的操作(閱讀)速度才是重點, 其實在圖形介面的後台也是以TEXT模式跑的; 而且, 快個幾分鐘或幾十分鐘應該只是個有參考價值的效能指標, 假設PC壽命3年不關機運作, 26280小時中像轉檔編碼這種密集運算能佔幾小時? 省下來的時間對個人而非公司而言有多少意義? 單人多工, 再怎麼多工也要等人, 除非人一直坐在電腦前從頭盯著螢幕看到尾, 否則程式跑完等人的這一等就把絕大部份節省下來的時間浪費掉了.
3.Unix/Unix-like等的TEXT模式介面系統雖然簡陋, 卻將資源完全用在實際運算上, 在相同硬體下先天就勝過GUI系統一大截, 所以比較正規或是有重要功能的主機幾乎都不會用Windows, , 本來就不是給人用... 呃... 給人長時間坐在電腦前面操作用, 所以也不用等人, 只要系統不crash, 就會不停運轉下去.
4.Unix/Unix-like最完美的結合典範是Mac OS X (FreeBSD+Mac GUI).

言歸正傳...

轉檔工作=從HDD讀取->送到RAM->CPU編碼->送到RAM->寫入HDD, 非3D就不提GPU了.
瓶頸還是在HDD, 目前主流7200rpm讀寫速度平均在55-65m/s, 意思就是, CPU轉碼再快, RAM再大, 都要受限於HDD的"內部速度", ATA-100/133和SATA-150/300都完全沒有意義, 不少RAID Card甚至還要受PCI Bus速度的限制, 只要HDD來不及寫入資料(有些系統還可以寫入資料後再verify一遍更慢), CPU/RAM都要停下來等待, 此時N核N位元N THz的CPU和N TB的RAM都沒用(RAM Disk除外), 如果同一時間還有其它程式要對HDD進行讀寫, HDD速度立刻腰斬再腰斬(磁頭移動耗時).

所以, 結論是,
1.規劃好動作, 不要讓多個程式同時對同一顆HDD進行讀寫(免成本).
2.轉檔編碼等大動作要快, 錢花在CPU/RAM上不如花在HDD上(如RAID 0或Multiplier).
3.如果預算夠, 市面有DDR2 2GB一條的RAM, 插滿4槽8GB, 在XP64下足夠開RAM Disk了, 技嘉的i-RAM也可以, 而RAM Disk一開... 本篇就沒什麼好繼續的了.

以上

問題是
我自己網路上
論壇上
看到的
體驗到的
轉檔佔的時間多寡一直是CPU的指標能力之一
原因無他
轉檔耗的CPU實在太大
RAM再多、硬碟再猛,他們也不會變成CPU阿

我以前也以為裝上RAID0就會有多猛多猛
但事實上有灌RAID0的對於一些原本就吃CPU重的軟體
在遊戲讀取上根本沒有顯著效果
人家控肉20秒讀完BF2地圖,我要一分45秒(3000+)
以上題外話...

至於您提到的i-ram甚至是8GB的RAM
前者都拿來講說灌XP有多快、剛灌好XP時進WINDOWS有多猛等等
後者一般都是美工或者專業繪圖人士才有用到
譬如處理超大的PHOTOSHOP檔或是CAD檔才比較需要用到
真的裝到8G轉檔就會飛了嗎?
我不信...XD



[如果你喜歡本文章,就按本文章之鮮花~送花給作者吧,你的支持就是別人的動力來源]
本文連接  
檢閱個人資料  發私人訊息  Blog  快速回覆 新增/修改 爬文標記
BOBO
銀驢友〔初級〕
等級: 12等級: 12等級: 12


今日心情

 . 積分: 371
 . 精華: 1
 . 文章: 674
 . 收花: 1757 支
 . 送花: 1269 支
 . 比例: 0.72
 . 在線: 2401 小時
 . 瀏覽: 102651 頁
 . 註冊: 7192
 . 失蹤: 12
 .    
#42 : 2007-3-4 12:30 AM     只看本作者 引言回覆


引用:
chaeung寫到:
個人獨斷的偏見:

無論單核雙核多核, 單工多工, 個人用和主機用根本沒有可比性.

1.32bit和64bit的差別僅在於定址最大範圍, 也就是說定址範圍愈大, CPU一次指令可處理的資料極限也就愈大, 理論上速度有差, 實際上還要看情形(OS+AP的配合度).
2.Windows這類GUI系統通常是個人使用, 有大量資源使用在GUI上, 本來速度就慢, 而且最主要是給人操作用的, 人的操作(閱讀)速度才是重點, 其實在圖形介面的後台也是以TEXT模式跑的; 而且, 快個幾分鐘或幾十分鐘應該只是個有參考價值的效能指標, 假設PC壽命3年不關機運作, 26280小時中像轉檔編碼這種密集運算能佔幾小時? 省下來的時間對個人而非公司而言有多少意義? 單人多工, 再怎麼多工也要等人, 除非人一直坐在電腦前從頭盯著螢幕看到尾, 否則程式跑完等人的這一等就把絕大部份節省下來的時間浪費掉了.
3.Unix/Unix-like等的TEXT模式介面系統雖然簡陋, 卻將資源完全用在實際運算上, 在相同硬體下先天就勝過GUI系統一大截, 所以比較正規或是有重要功能的主機幾乎都不會用Windows, , 本來就不是給人用... 呃... 給人長時間坐在電腦前面操作用, 所以也不用等人, 只要系統不crash, 就會不停運轉下去.
4.Unix/Unix-like最完美的結合典範是Mac OS X (FreeBSD+Mac GUI).

言歸正傳...

轉檔工作=從HDD讀取->送到RAM->CPU編碼->送到RAM->寫入HDD, 非3D就不提GPU了.
瓶頸還是在HDD, 目前主流7200rpm讀寫速度平均在55-65m/s, 意思就是, CPU轉碼再快, RAM再大, 都要受限於HDD的"內部速度", ATA-100/133和SATA-150/300都完全沒有意義, 不少RAID Card甚至還要受PCI Bus速度的限制, 只要HDD來不及寫入資料(有些系統還可以寫入資料後再verify一遍更慢), CPU/RAM都要停下來等待, 此時N核N位元N THz的CPU和N TB的RAM都沒用(RAM Disk除外), 如果同一時間還有其它程式要對HDD進行讀寫, HDD速度立刻腰斬再腰斬(磁頭移動耗時).

所以, 結論是,
1.規劃好動作, 不要讓多個程式同時對同一顆HDD進行讀寫(免成本).
2.轉檔編碼等大動作要快, 錢花在CPU/RAM上不如花在HDD上(如RAID 0或Multiplier).
3.如果預算夠, 市面有DDR2 2GB一條的RAM, 插滿4槽8GB, 在XP64下足夠開RAM Disk了, 技嘉的i-RAM也可以, 而RAM Disk一開... 本篇就沒什麼好繼續的了.

以上

版大的意思是指轉檔時. CPU的處理速度會大於"55-65m/s"?
是以什麼樣的電腦來說呢?



[如果你喜歡本文章,就按本文章之鮮花~送花給作者吧,你的支持就是別人的動力來源]
本文連接  
檢閱個人資料  發私人訊息  Blog  快速回覆 新增/修改 爬文標記
badcat
銀驢友〔初級〕
等級: 12等級: 12等級: 12
壞喵

 . 積分: 541
 . 精華: 3
 . 文章: 837
 . 收花: 3874 支
 . 送花: 982 支
 . 比例: 0.25
 . 在線: 3330 小時
 . 瀏覽: 62312 頁
 . 註冊: 7213
 . 失蹤: 146
#43 : 2007-3-6 06:29 PM     只看本作者 引言回覆

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

killer00 和 crazydark 兄都有認真看小弟的文唷!跟小弟想表達的意思已接近十之八九了!感謝!感謝!

> killer00 說道:
> PS:「時脈」不等於「運算速度」,相信現在大部份人都有共識了吧←badcat的講法我不是不知道,這講法也是有問題的...
> (後略...)
http://twed2k.org/viewthread.php?tid=153575&page=3#pid1277854

嗯!關於這點 killer00 剛好又和小弟是不同的前題。
killer00 的前題是:「在同一製程及設計下,時脈愈高,運算速度愈快。」(Ex: Intel 用同一核心(設計),同一製程的 Core 2 Dou 時,時脈愈快,運算速度愈快!這是正確的!)
小弟 badcat 的前題是:「在兩個不同製程及設計下,同一時脈時,運算速度不見得一樣快。」(就像 Intel 和 AMD 的 CPU,在同樣 1.6GHz 時,運算速度不見得一樣!)
所以就會衍生出:「舊製程舊設計的 Intel 1.6Ghz 核心,運算速度可能反而會輸新製程的 AMD 1.5Ghz 核心!」
所以 Compaq Alpha 21264 雖然時脈比 Intel & AMD 的 CPU 慢,卻可打趴 Intel & AMD 在那時同期的時脈更高的 CPU。這就是具備優良設計及製程的好處,不用一昧的提升時脈來增加運算時速。(Q. Compaq Alpha 21264 是什麼?A. Google 一下吧!)


> chaeung 兄說道:
> 瓶頸還是在HDD, 目前主流7200rpm讀寫速度平均在55-65m/s, 意思就是, CPU轉碼再快, RAM再大, 都要受限於HDD的"內部速度", (後略...)

瓶頸在 HDD 這個前題必需是:「CPU 很閒,但 HDD 已滿載」。
怎麼判斷,很簡單,只要看你的 HDD 燈是否一直亮個不停,而 CPU 卻沒有滿載,只用到 30%..40% 的能力時。(30%..40% 是舉例,就是 CPU 很閒啦!)
那你的瓶頸就是「HDD」!
但如果是 CPU 接近 100%,而硬碟燈是偶而一閃一閃的。(HDD 匯流排根本沒灌滿!)
那你的瓶頸就是「CPU」!

當 CPU 愈慢時,那「CPU」成為瓶頸的機會較高!(HDD 在等 CPU 算完,這時 CPU 通常會滿載!)
當 CPU 愈快時,那「HDD」成為瓶頸的機會較高!(CPU 算好後在等 HDD 讀寫,這時 CPU 通常很閒,而硬碟燈很忙)

就小弟的經驗,目前「轉檔運算」最操的還是 CPU,再來才是硬碟 HDD,不要認為你的 CPU 運算很快,因為「轉檔運算」並不是「CPU 運算/幾張畫面像素」這麼簡單而已,為了僅一張畫面的漂亮轉換,中間的運算式運算式就可能很多很多了。
你的 CPU 轉檔運算是否最少能達到 24fps/sec,如果達不到,那你的 CPU 絕不可能灌飽你的 HDD。
很簡單的測法就是,試試看你要播放多快,要 x4, x8, x16 * 24fps 的播放量(連續不跳格),HDD 硬碟流量(硬碟燈)才能滿載?假設得要 x16 的播放速度才能餵飽 HDD (硬碟燈一直閃),那你的 CPU 至少要有 16*24=384fps/sec 的運算量才能餵飽 HDD。
想餵飽 HDD 讀寫速度 55-65MB/s 的影像資料量,得將 CPU 提升好幾個等級 (譬如說「八核的 CPU + 八核的轉檔軟體」),你才可能看到 CPU 尚未滿載,而 HDD 燈卻閃個不停的情況。(HDD 忙翻了!)
不然開個 RAM Disk 來轉檔,RAM Disk 每秒 1000 MB/s 以上 (看 CPU 及 RAM 之間的速度),那肯定「瓶頸」是 CPU!(CPU 一定滿載!RAM Disk 尚可算閒。)

所以找「對」瓶頸是很重要的,這樣可避免花冤枉錢、走冤枉路。


. . . . . . . (這是分隔線)

不知 nine86 樓主的問題解決了沒?(好像沒人在注意啦?)
還是回到主題。(回魂!回魂啦!...)

因為 nine86 兄的重點:「是轉檔時其他軟體會lag嗎?」,在稍不考慮「轉檔速度」的情況下。(轉檔時間可慢一點啦!)
不管你的 CPU 多強多快多少核心,只要「轉檔程式」統統都佔滿所有 CPU 資源時,那玩「線上遊戲」還是會 Lag 的,因為資源都被「轉檔程式」佔滿了!(不過「轉檔」會很快完成!)
建議 nine86 樓主在花錢之前,可以先使用 killer00 兄所建議的 Process Tamer 的這套軟體來試試吧!http://www.donationcoder.com/Software/Mouser/proctamer/index.html
雖然它不能提升 CPU 運算速度,但卻可以自動調節 Windows XP 程式的優先權,也可手動調整,以減少轉檔時其他軟體會 Lag 的現象,而且最重要是...不用錢!(Freeware)
所以 nine86 兄可以用 Process Tamer 自己手動將「轉檔程式」的優先權調低,而「線上遊戲」的優先權調高,雖然不能保證一定不會 Lag,但可大大減少 Lag 的現象。(不過轉檔時間就會變長,不過一好就沒二好!不然就換更快的 CPU 吧!)

最後還是要記得,儘量分配適當的資源給眾程式 (譬如用 Process Tamer),才不會造成資源的分配不均,該快的不快,可慢的卻不給慢,大家搶成一團,自然大家都會慢。
若你的電腦 Power 真的不夠強,要嘛同時間別跑太多程式 (一次跑一到二個大程式),就是去花錢做適當的升級吧!(記得找「對」瓶頸來買適當的裝備!)

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1

iQA/AwUBRe1iThl3yhBVZiD/EQK2mwCgkT3toZ+aQtjJNcKpFVVWlqdNxBcAniHj
1VuYKmf7zuFD54n/mP92xU8R
=7Hso
-----END PGP SIGNATURE-----

[badcat 在  2007-3-6 08:46 PM 作了最後編輯]



[如果你喜歡本文章,就按本文章之鮮花~送花給作者吧,你的支持就是別人的動力來源]
本文連接  
檢閱個人資料  發私人訊息  Blog  快速回覆 新增/修改 爬文標記
badcat
銀驢友〔初級〕
等級: 12等級: 12等級: 12
壞喵

 . 積分: 541
 . 精華: 3
 . 文章: 837
 . 收花: 3874 支
 . 送花: 982 支
 . 比例: 0.25
 . 在線: 3330 小時
 . 瀏覽: 62312 頁
 . 註冊: 7213
 . 失蹤: 146
#44 : 2007-3-6 08:32 PM     只看本作者 引言回覆

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

有興趣算了一下!

DVD 為 720 * 480 * 24bits 色 * 24fps(張) (其實也有 30fps,這裡用最低限 24fps)
DVD 1x = 1350 K/S / 1024 ~= 1.318 MB
HDD 讀寫流量 55 MB / 1.318MB ~= DVD 41.7x

DVD 41.7x * 24fps ~= 1001 fps/s

先自忖自己的 CPU 能不能播放到 1001fps /s,若可以那 CPU 的播放速度就可以把 HDD 流量塞滿。(還不包括解碼的時間,不然還達不到 1001fps/s)
而「轉檔程式」做的是「編碼」,「編碼」普遍比「解碼」慢,就更不可能算到 1001fps/s 張的流量給 HDD。(還是不包括編碼時間,不然會比「解碼」還慘!)
所以在一般的 CPU 下,通常都是 HDD 等 CPU 啦!等到你有一顆轉碼時能算到 1001fps/s 以上的 CPU 時,這時就是 CPU 等 硬碟 了!(已破 HDD 55MB/s 流量)

有興趣者可以試試 RAM Disk 讀取 DVD 的極限為幾倍 ???x ?及要多快的 CPU 運算 (?????fps/s) 才能把 RAM Disk 流量塞滿?(※注意小弟的文中 ?? 的數量。)

若你轉碼的過程當中,HDD 流量已滿,或許你應該檢查一下是什麼東西佔滿了你的硬碟流量?
建議可以用 Filemon.exe 追追看。http://www.sysinternals.com
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1

iQA/AwUBRe1fThl3yhBVZiD/EQK7TQCgzKuxwOO7u+hP73MqCFhyfTvx1xAAoKT7
kbB6+2nTFqaojssvJyqPiKRJ
=7jce
-----END PGP SIGNATURE-----



[如果你喜歡本文章,就按本文章之鮮花~送花給作者吧,你的支持就是別人的動力來源]
本文連接  
檢閱個人資料  發私人訊息  Blog  快速回覆 新增/修改 爬文標記
平凡小任
金驢友〔中級〕
等級: 17等級: 17等級: 17等級: 17等級: 17


 . 積分: 2378
 . 文章: 8010
 . 收花: 19199 支
 . 送花: 18840 支
 . 比例: 0.98
 . 在線: 7367 小時
 . 瀏覽: 58690 頁
 . 註冊: 7934
 . 失蹤: 11
 . Taiwan
#45 : 2007-3-6 09:23 PM     只看本作者 引言回覆

我找到一篇關於轉檔和CPU的報告
有興趣的大大可以參考參考
雙核心就算不想兩個核心全部跑轉檔也可以獨立指定核心跑轉檔
單核心能嗎?

又跑轉檔時CPU負荷頗重
一般跑轉檔都從CPU去改善
RAM就算衝8G+暴龍萬轉4顆組RAID0+IRAM
這樣跑轉檔就會飛了嗎?
懷疑懷疑...

[平凡小任 在  2007-3-6 09:27 PM 作了最後編輯]



[如果你喜歡本文章,就按本文章之鮮花~送花給作者吧,你的支持就是別人的動力來源]
本文連接  
檢閱個人資料  發私人訊息  Blog  快速回覆 新增/修改 爬文標記

 123  3/9  <  1  2  3  4  5  6  7  8  >  >| 
   

快速回覆
表情符號

更多 Smilies

字型大小 : |||      [完成後可按 Ctrl+Enter 發佈]        

溫馨提示:本區開放遊客瀏覽。
選項:
關閉 URL 識別    關閉 表情符號    關閉 Discuz! 代碼    使用個人簽名    接收新回覆信件通知
發表時自動複製內容   [立即複製] (IE only)


 



所在時區為 GMT+8, 現在時間是 2024-3-29 09:26 PM
清除 Cookies - 連絡我們 - TWed2k © 2001-2046 - 純文字版 - 說明
Discuz! 0.1 | Processed in 0.043713 second(s), 9 queries , Qzip disabled