PCDVD數位科技討論區
PCDVD數位科技討論區   註冊 常見問題 標記討論區為已讀

回到   PCDVD數位科技討論區 > 電腦硬體討論群組 > 系統組件
帳戶
密碼
 

  回應
 
主題工具
poqlll
Major Member
 

加入日期: Feb 2006
文章: 252
不考慮超頻的問題
我自己會挑E8200
畢竟45nm帶來的低耗電和低溫還是很吸引人的
     
      
舊 2008-02-04, 02:52 AM #11
回應時引用此文章
poqlll離線中  
dts0069
Elite Member
 

加入日期: Feb 2003
您的住址: 台灣
文章: 4,086
這幾年便宜的cpu用習慣了,高價位cpu就不考慮了.

那種價位cpu個人真要花錢買,會挑q6600的就是,不過如果有人要送我,希望收到e8200.

性價比在於個人的需求,所以想什麼就買什麼吧!不用在意別人.
 
舊 2008-02-04, 05:13 PM #12
回應時引用此文章
dts0069離線中  
Adsmt
Golden Member
 
Adsmt的大頭照
 

加入日期: Feb 2004
您的住址: 從來處來
文章: 2,761
引用:
作者fann
小離題一下...
之前E6850跟Q6600(G0版)以相同價位8900
元台幣上市時,不少人認為四核心處理器時代
還沒到,好超高頻的6850才是玩家首選,但短
短數個月過去,更好超的E8系列出現,前者的
二手價已經跌破6000,而Q66仍可有7500左
右的行情,真的是時也運也命也..

E6 會跌是因為 E8 出來
Q6 未跌是因為 Q94 還沒出來,如果今天順序轉換,Q94 先出,我想 Q6 的下場也是相同。

還有多執行序不代表在多核表現就會較佳,還得看各執行序的負載是否平均。例如有一支程式有十個執行序,其中一個佔了 80% 的負載,剩下的分 20%, 那就算是千核萬核,運算起來也不會比雙核快。因為再多核都要停下來等那個佔 80% 的執行序。

以目前而言,能四個以上平均負載執行序的軟體並不多,主要還得看運算性質。至於以後會不會比較好?這很難講,沒有一個一個去證明難以論斷,但可以確定的是,這世界上無解的難題多的是。
舊 2008-02-04, 05:45 PM #13
回應時引用此文章
Adsmt離線中  
anshley
*停權中*
 

加入日期: Sep 2003
文章: 74
多核起碼就是介定你CPU的最高潛力吧
四核發揮不好的程式
難道雙核就可以發揮得很好?
想得到答案就得把問題單純化.
所有的物理公式也都是如此
單就選擇CPU而言, 當然Q6600總運算能量最高,
選他一點錯都沒有.
沒辦法完全發揮它是你的運用問題
不是Q6600的價值問題

你若要再考慮其他阿里不達的因素
這根本就沒有答案了

此文章於 2008-02-04 06:58 PM 被 anshley 編輯.
舊 2008-02-04, 06:56 PM #14
回應時引用此文章
anshley離線中  
HigH
Golden Member
 
HigH的大頭照
 

加入日期: Nov 2000
您的住址: 戰星卡拉狄加
文章: 3,822
引用:
作者anshley
四核發揮不好的程式
難道雙核就可以發揮得很好?

同價位的雙核與四核, 雙核時脈比較高是不爭的事實
舊 2008-02-04, 08:46 PM #15
回應時引用此文章
HigH離線中  
Adsmt
Golden Member
 
Adsmt的大頭照
 

加入日期: Feb 2004
您的住址: 從來處來
文章: 2,761
引用:
作者anshley
多核起碼就是介定你CPU的最高潛力吧
四核發揮不好的程式
難道雙核就可以發揮得很好?
想得到答案就得把問題單純化.
所有的物理公式也都是如此
單就選擇CPU而言, 當然Q6600總運算能量最高,
選他一點錯都沒有.
沒辦法完全發揮它是你的運用問題
不是Q6600的價值問題

你若要再考慮其他阿里不達的因素
這根本就沒有答案了

我想你要先了解一下計算機演算法,不是所有問題都有解的。
甚至證明他無解也是一種解,但世界上有很多問題被證明「可能有解,也可能無解」,至於有沒有解,無人可知,這就是有名的 NP-Complete 的問題(嚴格來說,是有沒有最佳解)

至於四核不能發揮的好,雙核能不能?答案是能!
而且容易得多。
要把一件工作平均分割成兩份,比平均分割成四份容易多了。
而且執行序愈多,愈容易有 deadlock, race condition....等等問題產生,為了解決這些問題,往往必須有一些效能的犧牲。以及某些運算先後順序的問題(必須得到 A 的答案,才能繼續下一步的運算),這將使得其它執行序停下來等待。

要把工作分得愈平均,難度將愈高。

這樣好了,給個簡單的作業,下面是 PI 的運算公式,看有沒有人能寫個四執行序的程式,使運算速度大約變四倍。(或者變 3 倍以上就好)且要能運算到 32m 位數。
http://en.wikipedia.org/wiki/Brent-Salamin_algorithm

寫得出來,你就可以跟 Super PI 的作者嗆聲了....
(其實我自己也沒想過,所以也不知道有沒有解,但我覺得有實力的人可以試試,寫出來公開在網路上,讓台灣人發揚光大。
舊 2008-02-04, 10:41 PM #16
回應時引用此文章
Adsmt離線中  
qwert12345
Power Member
 
qwert12345的大頭照
 

加入日期: Jan 2004
文章: 607
就在下使用的經驗 , 現在的情形 , 重點不在幾核..... 是在硬碟 .

就算多功能力強 , 沒弄個萬轉和RAID , 多工也是沒有預期的驚喜 , 甚至使用感覺不如高時脈的單核...

如果有錢 , 不如考慮一下傳輸系統的補強 .

至於省電和低溫 , 這是非要不可 , 早已是趨勢了 , 但是目前看來應付多核心所使用的硬碟系統 , 反而越來越背道而馳啊 ...
舊 2008-02-04, 11:49 PM #17
回應時引用此文章
qwert12345離線中  
aa6813
Basic Member
 
aa6813的大頭照
 

加入日期: Apr 2003
您的住址: 台灣的某處
文章: 23
感謝!各位高手先進!抽空回覆!又多學習不同的經驗知識~小弟獲益良多

已經有大致上的概念了!!!感恩感恩
舊 2008-02-05, 01:02 AM #18
回應時引用此文章
aa6813離線中  
strategicweapon
Regular Member
 

加入日期: Jan 2005
文章: 84
引用:
作者Adsmt
我想你要先了解一下計算機演算法,不是所有問題都有解的。
甚至證明他無解也是一種解,但世界上有很多問題被證明「可能有解,也可能無解」,至於有沒有解,無人可知,這就是有名的 NP-Complete 的問題(嚴格來說,是有沒有最佳解)

至於四核不能發揮的好,雙核能不能?答案是能!
而且容易得多。
要把一件工作平均分割成兩份,比平均分割成四份容易多了。
而且執行序愈多,愈容易有 deadlock, race condition....等等問題產生,為了解決這些問題,往往必須有一些效能的犧牲。以及某些運算先後順序的問題(必須得到 A 的答案,才能繼續下一步的運算),這將使得其它執行序停下來等待。

要把工作分得愈平均,難度將愈高。

這樣好了,給個簡單的作業,下面是 PI 的運算公式,看有沒有人能寫個四執行序的程式,使運算速度大約變四倍。(或者變 3 倍以上就好)且要能運算到 32m 位數。
http://en.w...


說得很好 一堆人以為4核就是好 真是很無言
浪費地球能源又沒發揮到多工能力
真的能因4核改善效能的人真的是少之又少
還不如雙核45nm省一省電
舊 2008-02-05, 02:57 AM #19
回應時引用此文章
strategicweapon離線中  
惡魔印記666
Master Member
 

加入日期: Jul 2004
文章: 1,846
引用:
作者strategicweapon
說得很好 一堆人以為4核就是好 真是很無言
浪費地球能源又沒發揮到多工能力
真的能因4核改善效能的人真的是少之又少
還不如雙核45nm省一省電


我也愛地球啊
所以我也換了45nm的了
只是............我換得不是E8X00
.......我換得是現今45nm最高檔的QX9650罷了
搭配SCSI萬轉組RAID 0+8G RAM+XP-64bit系統
速度喵的快勒....
所以我說E8我不放在眼裡
反正我不超頻
一口氣衝最高的省時省力更不用費心挑大雕

不過.....要我選這兩顆
我會選Q66
畢竟我習慣多工環境下工作(沒音樂無法工作啊)
也有一堆影片要轉換
所以我會選Q66
畢竟多核已經是必行的趨勢了
__________________
玩硬體就像是瞌藥一樣
很容易上癮.....胃口也漸漸變大
想撩進去的人要三思啊 orz

此文章於 2008-02-05 03:45 AM 被 惡魔印記666 編輯.
舊 2008-02-05, 03:38 AM #20
回應時引用此文章
惡魔印記666離線中  


    回應


POPIN
主題工具

發表文章規則
不可以發起新主題
不可以回應主題
不可以上傳附加檔案
不可以編輯您的文章

vB 代碼打開
[IMG]代碼打開
HTML代碼關閉



所有的時間均為GMT +8。 現在的時間是07:37 AM.


vBulletin Version 3.0.1
powered_by_vbulletin 2025。