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

回到   PCDVD數位科技討論區 > 電腦硬體討論群組 > 效能極限
帳戶
密碼
瀏覽投票結果: [疑問]為什麼AMD XP不出512K L2 的CPU
可能是AMD認為256K就可以打的P4死死的 43 15.03%
可能是成本太高 30 10.49%
可能是良率會太低 63 22.03%
可能是架構還要修改 32 11.19%
可能是留著當殺手ㄐ一ㄢˇ等0.13出來再用 51 17.83%
可能是等K8再用 31 10.84%
可能是會讓存貨難賣 7 2.45%
可能是XP本身不支援 1 0.35%
可能是效能增加不多 23 8.04%
可能是????您覺得呢 5 1.75%
投票者: 286. 您不可以參加此投票

 

  回應
 
主題工具
idiot
*停權中*
 

加入日期: Jan 2002
文章: 1,214
引用:
Originally posted by Aloof

MCM?
So they use this kind of package technology.
I think the process-problem can be avoided by using this kind of package.

But Intel or AMD use the same package to combine core and cache?
If they don't, then they still have to face the process problem to deal with logic and memory at same time.

Maybe the redudancy-protect tech. can help some, I still have no not read it carefully. Is it popular in 業界 now?


you seem to have a huge misunderstanding in that peopleuse DRAMs for cache. People use SRAM in most cases, and there are no manufacturing problems associated with it.

Most of the high performance MPUs you can get your hands on have redanduncy protections in their cache arrays.


auroraice大大: 您還沒解釋快取大小與效能的關係的問題呢.
     
      
舊 2002-03-27, 01:04 AM #41
回應時引用此文章
idiot離線中  
apple333
Basic Member
 
apple333的大頭照
 

加入日期: Mar 2002
您的住址: 台北
文章: 10
Intel有二三十座的晶圓廠
AMD不到五座

技術怎麼比
錢又沒她多

慢慢等吧時間能證明一切

搞不好AMD直接跳過512

道時候所謂的K8內建1MB L2快取

嚇死Intel

然後Intel又耍賤 出Pentium 5

以上只是虛構

到時如果成真...純屬巧合
 
__________________
3dfx Voodoo萬歲
舊 2002-03-28, 06:16 PM #42
回應時引用此文章
apple333離線中  
P&W
Elite Member
 
P&W的大頭照
 

加入日期: Jul 2001
您的住址: Red Planet
文章: 4,277
引用:
Originally posted by apple333
Intel有二三十座的晶圓廠
AMD不到五座

技術怎麼比
錢又沒她多

慢慢等吧時間能證明一切

搞不好AMD直接跳過512

道時候所謂的K8內建1MB L2快取

嚇死Intel

然後Intel又耍賤 出Pentium 5

以上只是虛構

到時如果成真...純屬巧合


叫聯電或是台積電做也許蠻有可能的^^

記憶體越大,在資料多到時候可以緩衝,而接收的那一方如果來不及處理,可以將資料存於記憶體中,以免需要將資料重新讀取而浪費時間,效能的提升就有如386沒有快取記憶體,而架構相同的486效能卻倍增,就是差了快取記憶體(純粹以TI德州儀器的CPU做比較),但是較大的記憶體在低資料流量下,相較低記憶體的元件,兩相比較下,所增加的效能並不明顯.
__________________
The war is crates by fear and gap.
舊 2002-03-31, 02:44 AM #43
回應時引用此文章
P&W離線中  
Bon Jove
Registered User
 

加入日期: Aug 2001
文章: 64
Talking

加大L2效能不見得會大增? 那是指當L2已經很大的時候!!!


再加上快取設計的導向位元,舉個最簡單的例子!:

P3和賽揚, 賽揚128 就是幾乎於L2一半的P3,度龍也是和Athon相同

可是 L2 128KB賽揚,和P3效能的落差,卻絕對比度龍和Athon來的大

為什麼? 這就是因為L2導向的差異, Intel=256Bit AMD=64Bit

導向位元低,也間接代表著效率較差,也會影響快取命中率! 所以囉

以AMD L2=64Bit的目前狀況下,就算快取加大到1MB也只是浪費$$

但是不知道各位有無印象P3 512KB的效能無人可及!

除了快取加大,增大位元導向外,還要有軟體最佳化曾更能如虎添翼

以Athon來說 經過分析 再沒有軟體最佳化的時候 全速運轉時

仍然有一半~2/3的管線是處於無資料空轉狀態 以致於實際值遠小於理論值

因此 以現階段來說0.18 Athon XP根本沒有增大快取的價值

軟體上幾乎也都是針對P3,P4做最佳化,

再加上AMD製程遠輸於Intel,因此,成本也不可能容許,只能寄望在K8

在0.18下 AMD不太可能做L2 512來漲價來自己的腳
舊 2002-03-31, 05:16 AM #44
回應時引用此文章
Bon Jove離線中  
雲姬
Major Member
 

加入日期: Oct 2001
您的住址: 台中縣豐原市府前街28號
文章: 193
Re: 參考∼參考∼

引用:
Originally posted by e.bread
剛剛看了我一本舊的雜誌,RUN!PC 77期
在MSI K7T PRO的測試報導中有AMD處理器推出表格
列出了總共五個核心代號:
K75、Spitfire、Thunderbird、Mustang、Corvette
下面我列出Mustang的詳細規格
正式名稱:ATHLON ULTRA
研發代號:Mustang
L1快取:128kb
L2快取:1∼2MB,On-Die
L2與CPU時脈比:1:1(100%)
Gemini節電技術:支援
(註:表中Mobile ATHLON【Corvette】也支援,這應該是後來的Power now!)
市場地位:伺服器/工作站
推出日期:2000年第四季結束前

我想AMD本來也有要做512K以上的L2
但從推出日期來看,可能是難產了
也有可能是被換成現在的ATHLON MP

看了一下...小弟發現RUN!PC 77期似乎少列了一款Athlon核心,事實上在K75核心之前還有一款以.25um製程製作的Athlon(最早的那款,但核心名稱忘了).
舊 2002-03-31, 05:42 AM #45
回應時引用此文章
雲姬離線中  
雲姬
Major Member
 

加入日期: Oct 2001
您的住址: 台中縣豐原市府前街28號
文章: 193
引用:
Originally posted by apple333
Intel有二三十座的晶圓廠
AMD不到五座

技術怎麼比
錢又沒她多

慢慢等吧時間能證明一切

搞不好AMD直接跳過512

道時候所謂的K8內建1MB L2快取

嚇死Intel

然後Intel又耍賤 出Pentium 5

以上只是虛構

到時如果成真...純屬巧合

兩位對手(Intel與AMD)的晶圓廠實際數字是:
Intel---23座(據傳Intel還正在籌畫要建造數座12吋晶圓廠)
AMD---2座(若加上聯電的產能應該差不多等於有3座晶圓廠,另外AMD與聯電合資的
12吋晶圓廠[好像位於新加坡]預計於2005年開始啟用)
舊 2002-03-31, 05:51 AM #46
回應時引用此文章
雲姬離線中  
雲姬
Major Member
 

加入日期: Oct 2001
您的住址: 台中縣豐原市府前街28號
文章: 193
引用:
Originally posted by idiot


thats assuming the cache latency/access time will increase with size, and/or your target application exhibit very low locality or already fit in the exisiting cache. The last case is clearly not true in K7's case. And since we have a process shrink to work with as well, the L2 cache may not be the critical path even if it doubled in size.
再來請問AMD的副總裁在那裡自己說的,我非常的想要有一個出處資料歐謝謝




maybe, maybe not. But since increasing the FSB speed offers much performance increase, increasing the L2 size likely will be beneficial.



that and marketing for K8 will be the main reason.



512KB and 1024KB versions will be aviliable.




Do you know exactly what you are talking about here? Or did you pass 微處理器基礎 as a fluke?



You really seem to lack a good understanding on how cache works. Especially hitrate/size, and under what condition L2 is helpful.



L2 size and hitrate's balance point would be a L2 the size of the whole addressing space provided by the architecture. Its hitrate, cost and access time one tries to balance. And on chip caches for a consumer chip are usually bound by the cost.

其實同樣的道理應用在L1 chahe上也是大同小異的,舉個例子來講,Cyrix的6x86CPU
(後來改稱MII)為了增加效能而將L1 chahe加大到64K,但實際運作起來其整數效能還不及僅有16K L1 chahe的Pentium with MMX(至於AMD K6就更不用講了).
舊 2002-03-31, 06:01 AM #47
回應時引用此文章
雲姬離線中  
JET
Junior Member
 
JET的大頭照
 

加入日期: Jan 2001
您的住址: 好山好水
文章: 719
我覺得現在的主機板怎麼不多建快取
以前socket 7的板子還有出過1Mb的快取
舊 2002-03-31, 06:04 AM #48
回應時引用此文章
JET離線中  
雲姬
Major Member
 

加入日期: Oct 2001
您的住址: 台中縣豐原市府前街28號
文章: 193
引用:
Originally posted by JET
我覺得現在的主機板怎麼不多建快取
以前socket 7的板子還有出過1Mb的快取


以現在的CPU效能與架構而言,在主機板上On-board chahe並不會使效能增加多少(
如果記得沒錯的話...Socket7主機板上內建的chahe只能夠與系統匯流排同步,
如果CPU在On-Die L1 chahe[比如說CPU是K6-2 500]裡面找不到資料,就會到主機板On-board L2 chahe[K6-2 500的系統匯流排/外頻是100MHz]裡面去找,這下子效能馬上掉了400MHz,這樣一來,反而造成資料存取的效率低落,這樣說...您應該明白了吧!),只是徒增成本而已(這是小弟的想法,如果有錯誤或是各位大大有什麼要補充的還請不吝賜教).
另外,在Socket7CPU仍在風行的96~97年代,Socket7主機板還有出現過2MB L2-
chahe的終極版本,不過印象中...好像只有2家有出這類產品(記得一家是大眾,另外一家...忘記了[好像倒了]...).

此文章於 2002-03-31 06:35 AM 被 雲姬 編輯.
舊 2002-03-31, 06:30 AM #49
回應時引用此文章
雲姬離線中  
Kyocera
Power Member
 

加入日期: May 2001
文章: 512
引用:
我覺得現在的主機板怎麼不多建快取
以前socket 7的板子還有出過1Mb的快取

不是不建,而是沒法作
chipset中根本沒做cache controller
怎麼作?
舊 2002-03-31, 10:05 PM #50
回應時引用此文章
Kyocera離線中  


    回應


POPIN
主題工具

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

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



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


vBulletin Version 3.0.1
powered_by_vbulletin 2025。