PCDVD數位科技討論區

PCDVD數位科技討論區 (https://www.pcdvd.com.tw/index.php)
-   系統組件 (https://www.pcdvd.com.tw/forumdisplay.php?f=19)
-   -   劍指i7:AMD推土機型號、詳細規格首曝 (https://www.pcdvd.com.tw/showthread.php?t=923308)

alexgti2604 2011-03-18 11:05 PM

引用:
作者physx
如果SNB的單線程是100分的話,同時脈PII就只有60~65分(別懷疑就是這麼低)

推土機沒意外會是在80~90分中間,但是推土機時脈應該會比SNB高,所以有機會打平,但要贏應該有困難

但影響單執行緒最關鍵的還是解碼器這部分,AMD一直都很保密不對外公開任何資訊,只能等東西出來才知道了


如果單線程在80~90分之間.應該也相當1156 I3/I5了.然後開版新聞文中說
FX4000~FX8000都有turbo加速.以及不鎖倍頻來看.假如FX4000定價在4K
~4K5之間(然後AM3+ MB一樣像AM3平價)應該能下打I3系列.上打I5 2300/
2400(甚至2500也難倖免.畢竟沒K的都不能超)

而FX6000的價格/效能對手則是從I5 2500K~I7 2600.從前面新聞文說到
平台價格700美金不知道是從FX6000開始?還是從FX4000開始?希望FX4000
的平台價格是在500~600美金

physx 2011-03-18 11:08 PM

引用:
作者alexgti2604

然後推土機的架構2M4T跟3M6T的2M/3M的模塊"大小".及"功耗"上是否分別
只稍大於X2/X3?


不口能....

因為推土機不是"省電取向"的架構,而是"效能取向"的架構

(1)四模塊八核心快取L2+L3有16MB,是i7-2600K(8MB)的兩倍

(2)晶片面積估計300mm2(X6為346mm2)

如果推土機是節省資源的架構,為何要用到這麼大的緩存跟Die Size?

推土機應該是"避免浪費資源"跟"最大效率運用資源"的架構

簡單來說PII是IE8、SNB是Firefox、推土機是chrome

前面那篇真的是打的太急了,錯字一堆+語意矛盾 :nonono:

orakim 2011-03-18 11:56 PM

引用:
不知道我有沒有會錯意.以上來看1C單線程的效能是只比同時脈的PII
稍強

同時脈的話Bulldozer稍弱,但Bulldozer時脈 一定會比K10高一些(即便沒有TC 2.0)
如果加上TC 2.0,單執行緒下時脈提昇會蠻明顯的 (maybe 4G?)
在這個情形下Bulldozer單執行緒 是會比Phenom II強

引用:
然後推土機的架構2M4T跟3M6T的2M/3M的模塊"大小".及"功耗"上是否分別
只稍大於X2/X3?
假設如果一樣是3.2G相比.FX4000 2M4T/FX6000 3M6T 在模塊大小/功耗
只稍大於X2 555 3.2G/X3 450 3.2G

功耗部份由於牽扯到TC 2.0 ,效能 耗電 差距都會拉大 不過最後都會控制在TDP(125W/95W)以下 應該不會管幾M 除非關掉TC 2.0
http://blogs.amd.com/work/2011/01/3...t=Google+Reader

引用:
作者physx
否則四個模塊=160%*4=640% 只比現在X6多不到10%性能

這就是為什麼我上一篇貼的那個AMD網址的行銷手法
數字上很漂亮但拿12核去比6核Opteron,數字會誇張也是應該的

50%"或許"也只是行銷手法 當然這是很差的行銷手法 但還是不能排除這個可能性
例如:650%(多了50%單核心效能) 而不是600%*150%=900%
以他的架構 及總總官方釋出消息 這個數字過於誇張不實(除非時脈高到很誇張接近 5G)

AMD認為整數運算是CPU主要的部份,FPU強弱影響有限 不是主導CPU效能的因素
所以才把整數運算部份獨立出來,FPU採用彈性分享機制
即便FPU再強,大部分的運算還是在整數部份
應該是不會拿FPU來當主要效能標的砸自己的腳

另外AMD的重點不在犧牲單執行緒效能來塞更多核心,而是有效率的運用
他認為原本K10三組的整數運算,第三組是很沒有效率的(耗電跟帶來的效能不成比例) 所以才砍掉
而不是單純的為了簡化而簡化 或者為了多核心而簡化
刪掉第三組整數運算,可以有效率的應用如此而已

K8FX 2011-03-19 12:53 AM

假如Fusion 3.5G相當於PII-3.2G~3.4G,C2Q-2.8G L2=12MB
2M4T推土機比自家四核快~說不定多緒和1055T有拼喔!

以INTEL效能等級
由優到劣 i7-2600,i5-2500,i7-950,i5-750,i3-2100,i3-540

2M4T各位認為在哪呢?!

艾克萊爾 2011-03-19 03:19 PM

我覺得就算以現有資料去算推土機的性能推估還是變數過大,在模組內的資源調動機制與效率未確實明瞭前,搞不好相同應用領域裡換個軟體就大翻轉跌破一卡車專家眼鏡的結果都有可能... :jolin:

我是因為模組的硬體調度機制做好點,不然真的會很劣勢...

pepd65 2011-03-19 04:35 PM

對今年Zambezi(Bulldozer)持保留態度,免得期待越高失望越高
"新架構+新製程" 的風險過高
即使架構成功,搞不好也會被GF初期32nm製程不成熟所拖累
如果太耗電、時脈上不去也是枉然...

明年Komodo(Enhanced Bulldozer)倒是可以期待一下
據說Trinity(第二代APU)的CPU也會改用Enhanced Bulldozer
屆時架構跟32nm製程應該都比較成熟...

physx 2011-03-19 05:29 PM

說實話一個新架構優不優良、能有多少發展潛力,基本上剛出來就會知道了

向飛龍1代出來那種鳥樣,2代也沒能好到哪裡去
剛出來打不贏core i,後面在怎麼提高時脈加核心數就是贏不了core i

Fermi 剛出來耗電量就爆高,二代耗電量也一樣下不去
效能比HD5000稍高,二代也就比HD6000稍高,成本多一截,到二代成本還是比ATI多一截

所以新架構這種東西看似未來變化很大,其實不然,有多少實力剛出來馬上就能預測的到了

如果推土機出來就大贏2600K,那ivy也就別想翻身,2013以前intel只有1356能壓制AMD
同理,推土機剛出來就輸2600,那在下個新架構出來以前就會一直輸下去
明年贏不了,後年22nm也贏不了,不論怎麼改良只要是推土機架構就不可能贏。


引用:
作者K8FX
假如Fusion 3.5G相當於PII-3.2G~3.4G,C2Q-2.8G L2=12MB
2M4T推土機比自家四核快~說不定多緒和1055T有拼喔!
以INTEL效能等級
由優到劣 i7-2600,i5-2500,i7-950,i5-750,i3-2100,i3-540
2M4T各位認為在哪呢?!


大概在i5-750~i5-2500之間

推土機最基本該有的性能,預設3.5G/Turbo 4.2G,跟同樣3.5G的X4 970比

單線程要多30%、多線程要多100%,沒到這種程度就是"設計失敗",沒達到應有的理論值。

marinese six 2011-03-19 05:40 PM

引用:
作者physx
說實話一個新架構優不優良、能有多少發展潛力,基本上剛出來就會知道了

...

分析的很精闢,如當年K7 打P4 打一整個世代

firmware 2011-03-19 05:58 PM

我用total AMD platform 好幾年了, 一直不覺得AMD能翻盤, intel家大業大這賣香腸的阿伯都知道, 即便intel故意放槍2次AMD都未必能把市佔率拉到5/5波...

AMD在 "效能級產品" 上只要做一個所謂的 fast follower 快速跟隨者就夠了, 小輸為贏, 別被拉開太大就好, 其他級距的產品(Fusion series)我是覺得賣像都不錯.

當年ATI/AMD在GPU效能爭霸戰落敗後, 一路被看雖, 但事實證明中階+低階產品的大賣仍不失為一個 "敗中求勝" 的好方法...

K8FX 2011-03-19 06:52 PM

引用:
作者firmware
我用total AMD platform 好幾年了, 一直不覺得AMD能翻盤, intel家大業大這賣香腸的阿伯都知道, 即便intel故意放槍2次AMD都未必能把市佔率拉到5/5波...

AMD在 "效能級產品" 上只要做一個所謂的 fast follower 快速跟隨者就夠了, 小輸為贏, 別被拉開太大就好, 其他級距的產品(Fusion series)我是覺得賣像都不錯.

當年ATI/AMD在GPU效能爭霸戰落敗後, 一路被看雖, 但事實證明中階+低階產品的大賣仍不失為一個 "敗中求勝" 的好方法...


就算推土機贏了市占率也不能翻盤阿,
k8全盛時期也拿不到三成市占率,產能差太多了!

效能不翻盤的話,成本很吃緊阿~
不翻盤下代不知何時了!

這算時間只能塞核心加快取拉頻率~
成本比人家貴,效能比人家低,這牌怎麼打 :jolin:
當年K8散步龍快取也才K7巴頓的四分之一效能照樣贏!

APU方面也能直升推土機嗎?
應該還是中低階主力~覺得只會整合到兩模耶!

第二代推土機才是真正的APU阿!!


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

vBulletin Version 3.0.1
powered_by_vbulletin 2025。