Board logo

標題: [業界消息] [AMD] 人才流動是十常八九 [打印本頁]

作者: Puff    時間: 2012-8-1 23:46     標題: [AMD] 人才流動是十常八九

是的,AMD RIP...









才怪。看友台的人們啊。


前幾日傳出 AMD 有 一位 之前負責 Trinity 既 System Architect 走左去 Apple,
今日就傳出有 一位 Cheif Architect 從 Apple 回歸 AMD,投入到 CPU cores development.


人才流動是十常八九,看友台的人們啊。

[ 本帖最後由 Puff 於 2012-8-1 23:49 編輯 ]
作者: qcmadness    時間: 2012-8-1 23:50

佢除左係K7/K8 architect, 仲係Apple A4 / A5既architect
作者: Puff    時間: 2012-8-1 23:52

引用:
原帖由 qcmadness 於 2012-8-1 23:50 發表
佢除左係K7/K8 architect, 仲係Apple A4 / A5既architect
其實呢單野新聞價值唔高


佢影響得到既 project 最少都要 2015/16 年見。
13/14 年已經仆晒鎚。

[ 本帖最後由 Puff 於 2012-8-1 23:53 編輯 ]
作者: jackli    時間: 2012-8-1 23:52

1 - 1 != 0
作者: qcmadness    時間: 2012-8-1 23:53

引用:
原帖由 Puff 於 2012-8-1 23:52 發表

其實呢單野新聞價值唔高


佢影響得到既 project 最少都要 2015/16 年見。
13/14 年已經仆晒鎚。
15-16年都好可能影響唔大

諗下佢1998-1999係AMD, K8係2003年先出
作者: Puff    時間: 2012-8-1 23:59

引用:
原帖由 qcmadness 於 2012-8-1 23:53 發表

15-16年都好可能影響唔大

諗下佢1998-1999係AMD, K8係2003年先出
架構係既。最多咪郁下 D l2 cache size 呀 load queue size 呀,同埋搞埋 long-term future 既 roadmap 咁囉。


[ 本帖最後由 Puff 於 2012-8-2 00:00 編輯 ]
作者: qcmadness    時間: 2012-8-2 00:01

引用:
原帖由 Puff 於 2012-8-1 23:59 發表

架構係既。最多咪郁下 D l2 cache size 呀 load queue size 呀,同埋搞埋 long-term future 既 roadmap 咁囉。
Bulldozer / Trinity L2 cache size太大
作者: Puff    時間: 2012-8-2 00:19

引用:
原帖由 qcmadness 於 2012-8-2 00:01 發表

Bulldozer / Trinity L2 cache size太大
如果要搞屎棍,唔係學 Intel 黎個 three-level cache system,就係 multi-banked L2 了。


[ 本帖最後由 Puff 於 2012-8-2 00:21 編輯 ]
作者: qcmadness    時間: 2012-8-2 00:21

引用:
原帖由 Puff 於 2012-8-2 00:19 發表

如果要搞屎棍,唔係學 Intel 黎個 three-level cache system,就係 multi-banked L2 了。
Bulldozer module既慳die size理念俾2MB L2 cache摧毀左
作者: Puff    時間: 2012-8-2 00:25

引用:
原帖由 qcmadness 於 2012-8-2 00:21 發表

Bulldozer module既慳die size理念俾2MB L2 cache摧毀左
雖然話 benefits *some* server applications,但係 Intel 全能樣樣俱到喎...


[ 本帖最後由 Puff 於 2012-8-2 00:26 編輯 ]
作者: qcmadness    時間: 2012-8-2 00:26

引用:
原帖由 Puff 於 2012-8-2 00:25 發表

雖然話 benefits *some* server applications,但係 Intel 全能萬萬俱到喎...
唔係全能, 而且呢個方法有一定缺憾, 不過Bulldozer實在implementation做得太差 (Trinity執執地已經明顯比Bulldozer competitive)
作者: Puff    時間: 2012-8-2 00:32

引用:
原帖由 qcmadness 於 2012-8-2 00:26 發表

唔係全能, 而且呢個方法有一定缺憾, 不過Bulldozer實在implementation做得太差 (Trinity執執地已經明顯比Bulldozer competitive)
我全能既意思係,errm. 各方面都比特地做左 trade-off 既 BD 優異.
最好就 Steamroller 分開唔同 cache size 既 client/APU & server version 啦,L2 cache 唔 share 更好。

作者: qcmadness    時間: 2012-8-2 00:36

引用:
原帖由 Puff 於 2012-8-2 00:32 發表

我全能既意思係,errm. 各方面都比特地做左 trade-off 既 BD 優異.
最好就 Steamroller 分開唔同 cache size 既 client/APU & server version 啦,L2 cache 唔 share 更好。
...
L2 cache一定shared
作者: Puff    時間: 2012-8-2 00:42

引用:
原帖由 qcmadness 於 2012-8-2 00:36 發表

L2 cache一定shared
... errr 係既。不過 shared, associativity 同 capacity 要平衡... err.

[ 本帖最後由 Puff 於 2012-8-2 00:44 編輯 ]
作者: qcmadness    時間: 2012-8-2 00:51

引用:
原帖由 Puff 於 2012-8-2 00:42 發表

... errr 係既。不過 shared, associativity 同 capacity 要平衡... err.
Intel經過左Netburst, cache一定做得好
作者: dom    時間: 2012-8-2 01:58

AMD RIP

作者: hegel    時間: 2012-8-2 10:11

引用:
原帖由 qcmadness 於 2012-8-2 00:51 發表

Intel經過左Netburst, cache一定做得好
咁宜家推土機問題係咩
制程?
作者: qcmadness    時間: 2012-8-3 07:25

引用:
原帖由 hegel 於 2012-8-2 10:11 發表

咁宜家推土機問題係咩
制程?
其中一部分design
作者: hegel    時間: 2012-8-3 11:24

引用:
原帖由 qcmadness 於 2012-8-3 07:25 發表

其中一部分design
唔知有無希望汁汁佢就有得番生
好似肥龍1->2咁
作者: qcmadness    時間: 2012-8-3 21:08

引用:
原帖由 hegel 於 2012-8-3 11:24 發表

唔知有無希望汁汁佢就有得番生
好似肥龍1->2咁
肥1同埋Bulldozer主要都係over-design同埋freq未到預定lv
Pilediver應該唔太差 (Trinity已經睇到同BD有顯著分別)

不過IVB係有一定freq headroom的
作者: hegel    時間: 2012-8-3 21:17

引用:
原帖由 qcmadness 於 2012-8-3 21:08 發表


肥1同埋Bulldozer主要都係over-design同埋freq未到預定lv
Pilediver應該唔太差 (Trinity已經睇到同BD有顯著分別)

不過IVB係有一定freq headroom的
Trinity base on 推土機架構?
但我又見佢出 athlon 系列 好亂
作者: qcmadness    時間: 2012-8-3 21:18

引用:
原帖由 hegel 於 2012-8-3 21:17 發表

Trinity base on 推土機架構?
但我又見佢出 athlon 系列 好亂
Trinity係用Pilediver同Bulldozer之間的架構
作者: hegel    時間: 2012-8-3 21:23

引用:
原帖由 qcmadness 於 2012-8-3 21:18 發表

Trinity係用Pilediver同Bulldozer之間的架構
類似sb-> ivy 果種進步
作者: qcmadness    時間: 2012-8-3 21:24

引用:
原帖由 hegel 於 2012-8-3 21:23 發表

類似sb-> ivy 果種進步
SB > IVB有轉製程
你當佢係肥1 > 肥2果種咁, 就已經好好
作者: hegel    時間: 2012-8-3 21:27

引用:
原帖由 qcmadness 於 2012-8-3 21:24 發表

SB > IVB有轉製程
你當佢係肥1 > 肥2果種咁, 就已經好好
真係有咁大進步
低價市場有望復蘇
作者: qcmadness    時間: 2012-8-3 21:28

引用:
原帖由 hegel 於 2012-8-3 21:27 發表

真係有咁大進步
低價市場有望復蘇
不過就算Trinity A8 / A10快過i3 (而家A8已經係),
d人都係會買Intel...
作者: hegel    時間: 2012-8-3 21:30

引用:
原帖由 qcmadness 於 2012-8-3 21:28 發表

不過就算Trinity A8 / A10快過i3 (而家A8已經係),
d人都係會買Intel...
我指既低價真係h61 g530果個低價市場
果陣靠肥龍二開核 市佔曾經都追番唔少 (好似係)
作者: qcmadness    時間: 2012-8-3 21:30

引用:
原帖由 hegel 於 2012-8-3 21:30 發表

我指既低價真係h61 g530果個低價市場
果陣靠肥龍二開核 市佔曾經都追番唔少 (好似係)
一日AMD唔整細粒die, 一日都唔會去到G530咁平
作者: hegel    時間: 2012-8-3 21:34

引用:
原帖由 qcmadness 於 2012-8-3 21:30 發表

一日AMD唔整細粒die, 一日都唔會去到G530咁平

身邊既朋友好多都投懷h61 + g530既懷抱
宜家既amd前景我實在睇唔到有咩方向
作者: qcmadness    時間: 2012-8-3 21:41

引用:
原帖由 hegel 於 2012-8-3 21:34 發表


身邊既朋友好多都投懷h61 + g530既懷抱
宜家既amd前景我實在睇唔到有咩方向
G530... 用多2-3年就知咩事
作者: hegel    時間: 2012-8-3 21:46

引用:
原帖由 qcmadness 於 2012-8-3 21:41 發表

G530... 用多2-3年就知咩事

之後幾年應付唔到軟件需求
作者: Puff    時間: 2012-8-3 22:12

刨左下 linkedin... BD family 疑似係 one leap per 2 gen. BD-PD 一對, SR-XV 一對.
15 年既野未上檯面,下年再講。SR-XV 終於可以算係一個 tick-tock 啦...
另外搵到疑似係 Jagaur 後繼人士既 codename - Margay



[ 本帖最後由 Puff 於 2012-8-3 22:18 編輯 ]
作者: dom    時間: 2012-8-4 02:51

引用:
原帖由 hegel 於 2012/8/3 21:34 發表


身邊既朋友好多都投懷h61 + g530既懷抱
宜家既amd前景我實在睇唔到有咩方向
身為 AMD Fan
我既方向係 擁抱 APU
Socket FM2 + A85
作者: qcmadness    時間: 2012-8-4 17:54

引用:
原帖由 hegel 於 2012-8-3 21:46 發表


之後幾年應付唔到軟件需求
相信唔駛幾年
作者: cheungmanhoi    時間: 2012-8-4 18:17

引用:
原帖由 qcmadness 於 2012-8-4 17:54 發表

相信唔駛幾年
g530用家揮揮手
作者: qcmadness    時間: 2012-8-4 18:18

引用:
原帖由 cheungmanhoi 於 2012-8-4 18:17 發表

g530用家揮揮手
打機係咪覺得其他野好慢呢
作者: hegel    時間: 2012-8-4 19:10

引用:
原帖由 qcmadness 於 2012-8-4 17:54 發表

相信唔駛幾年
i3 咁咪仲尷尬
作者: qcmadness    時間: 2012-8-4 22:33

引用:
原帖由 hegel 於 2012-8-4 19:10 發表

i3 咁咪仲尷尬
係架
作者: cheungmanhoi    時間: 2012-8-4 22:54

引用:
原帖由 qcmadness 於 2012-8-4 18:18 發表

打機係咪覺得其他野好慢呢
1999 WOR
作者: dom    時間: 2012-8-5 02:24

AMD A8 打機多工無問題既人路過




歡迎光臨 HKSpot (https://bbs.hk-spot.com/) Powered by Discuz! 6.0 Lite