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

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

  回應
 
主題工具
kqalea
Major Member
 

加入日期: Dec 2004
文章: 131
引用:
作者physx
感恩恕刪
Many Thanks


閣下點出的就是Intel全世界第一當之無愧的地方

全世界最先進的量產半導體製程

有多厲害,假設明年Intel可以順利推出 22nm FinFET CPU
各位猜猜其他競爭對手要花多久才能追上

台積電說14nm 2014~2015才會導入 FinFET 22nm 2012~2013 只有HighK
GlobalFoundries 要2013 才能切到 20 nm 也許屆時全耗盡型SOI也會順利導入

但是 .... 據說IC性能可能還是打不過Intel 2012就可以推出的 22nm FinFET
Intel就是他X的這麼牛逼,可以用x86這麼畸形的架構靠著超強大製程打片天下無敵手
就像一個只會羅漢拳的武僧,靠著強大的內力照樣可以痛扁普通的降龍18掌

所以全世界沒有人會跟Intel 拼內力,沒人拼的的贏的
Intel最近沒那麼牛逼真的是因為x86太鳥了
ARM用落後兩個節點的製程都可以賣的嚇嚇叫,最近靠著台積電28nm,內力大為進步
再來就是之前助紂為虐的windows被天神賈不死的蘋果,跟辜狗的機器人打的滿頭包
竟然陣前倒戈投靠ARM集團,Intel之前找的Nokia沒料到是扶不起的阿斗
Meego做一做就跟windows一起投靠ARM

羅漢拳,終究是羅漢拳
Intel現在會如此尷尬,還非得拿出壓箱寶對付競爭者,無非是之前種下惡因,現得惡果
Larrabee 當初號稱是A/N兩家GPGPU的頭號殺手,可惜不但到2012只能達成50 cores
而且還是打不贏GPU

至於推土機會不會是笑能
我估計至少在同價位上會小贏一些吧,但是每瓦效能跟Single Thread 因該是輸
若能做到這樣Bulldozer就非常厲害了
     
      
舊 2011-07-29, 10:42 PM #151
回應時引用此文章
kqalea離線中  
ultraPC
*停權中*
 

加入日期: Apr 2007
文章: 1,106
intel製成很強沒錯,不過他做的晶片複雜度跟TSMC的根本不能比吧
TSMC做的電晶體數量例如GF100就已經是I7的幾倍了?
難度完全不在同個檔次∼∼
雖然應該還是INTEL的製成比較強一點,不過做的東西難度相差太多
到底誰強還很難說
 
舊 2011-07-29, 11:04 PM #152
回應時引用此文章
ultraPC離線中  
kqalea
Major Member
 

加入日期: Dec 2004
文章: 131
引用:
作者idleic2
這邊說的 decode 是指 Video decode 嗎 ?
假設是,

如下圖所示
http://www.cdrinfo.com/images/uploaded/AMD_UVD3.jpg

有些 hardware decode 並不完全 !
像 UVD 不支援 mpeg2 hardware decode
UVD2 支援 mpeg2 部分hardware decode
到 UVD3 才 完全hardware decode

另外 像IBM Cell
可以將 video decode 交給 SPE
or 未來可許可以 將 video decode 交給 GPGPU 的 SP

因為 Cell SPE 及 GPGPU 一樣需要 Software Program 才能運算解碼 ?
這樣算 hardware decode or software decode ?


Cell是Software Decode喔
部分硬解還是算軟解,因為bottleneck還是在CPU(演算法以及CPU運算能力)
如同你的理解,加上我的解釋"CPU 不參予解碼動作的才是Hardware decode"
這就是答案

引用:
作者idleic2
我知道 軟體上的 thread & process 的區別 ?

請教一下, 硬體上的 thread & process 是 ?
可有文章介紹 or google 的 keyword 是 ?
是 IntelR Hyper-Threading or SMT (Simultaneous multithreading) 嗎?
區別 是 ?


請問 這個video decode 的例子, 解釋 哪個觀念阿 ?


先引用一下閣下之前的文章

引用:
作者idleic2
以下是解釋
GPU效能是CPU的無限多倍的時候 可以增加CPU單執行緒效能至3.33倍
(註:GPU不管再怎麼強都不可能會讓CPU效能增益超過3.33倍)
由GPU loading 不到7% 這一點來看,在硬解上GPU效能的確蠻像CPU的無限多倍
(即便GPU效能只有CPU的40倍或80倍 增益的倍數也離3.33倍不遠)

把硬解(30:70的fusion程式)當作一個假想fusion範例:
一個小小的E-350 APU (2個bobcat+1個GPU) 總和效能就相當於6.66個bobcat的效能
fusion 運算法改革帶來的效能增益就是這麼誇張
(尤其是他可以用在單執行緒程式這一點很吸引人)


我只是想說,其實CPU"執行緒"的效能其實沒變
變的是cpu loading
不能這樣計算系統效能,因為目前openCL的部份可以完全由GPU執行
沒有道理會有人故意留個瓶頸擺在CPU脫慢系統效能
所以一般而言 如果GPU透過openCL執行某樣工作是CPU的數倍
那APU實作開GPU理當達成同樣的效能,而不會被CPU卡住
其實你可以看之前貼的bitcoin那篇,就可知道CPU效能在並不構成
GPU執行的瓶頸,除非CPU需要參予該工作,則該工作的效能瓶頸才會受CPU引響
而這就不是openCL的本意了

非常感謝
舊 2011-07-29, 11:06 PM #153
回應時引用此文章
kqalea離線中  
greenbay
*停權中*
 

加入日期: Apr 2008
文章: 860
偷偷告訴各位...以後AMD主機板上插CPU

AMD顯示卡上也可以插CPU

MB上一顆八核心+VGA上又一顆八核心

AMD Bulldozer CFX你們說有沒有搞頭啊
舊 2011-07-29, 11:07 PM #154
回應時引用此文章
greenbay離線中  
hskao
Power Member
 
hskao的大頭照
 

加入日期: Nov 2002
文章: 560
Cool

引用:
作者greenbay
偷偷告訴各位...以後AMD主機板上插CPU
AMD顯示卡上也可以插CPU
MB上一顆八核心+VGA上又一顆八核心
AMD Bulldozer CFX你們說有沒有搞頭啊


嗯...greenbay大是沒梗了嗎?

怎麼最近講的笑話都不好笑
舊 2011-07-29, 11:22 PM #155
回應時引用此文章
hskao離線中  
kqalea
Major Member
 

加入日期: Dec 2004
文章: 131
引用:
作者ultraPC
intel製成很強沒錯,不過他做的晶片複雜度跟TSMC的根本不能比吧
TSMC做的電晶體數量例如GF100就已經是I7的幾倍了?
難度完全不在同個檔次∼∼
雖然應該還是INTEL的製成比較強一點,不過做的東西難度相差太多
到底誰強還很難說


差多了
die size 跟 電晶體數量 不代表一定複雜阿
SRAM一顆也可以做到數十億個電晶體,但是不難啊XD
更何況,你把Intel XEON放到哪去

Intel Xeon E7 die (measures 513mm2 with 2.6 billion transistors)
10core-20thread 30mb shared L3 cache
舊 2011-07-29, 11:29 PM #156
回應時引用此文章
kqalea離線中  
greenbay
*停權中*
 

加入日期: Apr 2008
文章: 860
引用:
作者hskao
嗯...greenbay大是沒梗了嗎?

怎麼最近講的笑話都不好笑


資質太差...教也白搭

等著瞧吧...不出十年
舊 2011-07-29, 11:45 PM #157
回應時引用此文章
greenbay離線中  
idleic2
Master Member
 

加入日期: Mar 2004
您的住址: 亞洲.台灣.台北
文章: 2,054
引用:
作者kqalea
Cell是Software Decode喔
部分硬解還是算軟解,因為bottleneck還是在CPU(演算法以及CPU運算能力)
如同你的理解,加上我的解釋"CPU 不參予解碼動作的才是Hardware decode"
這就是答案


我認為/假設 Cell 的 PPE 才算是 CPU

那 video decode 交給 SPE 去做時,
由 PPE 的角度來看, 這是 Hardware decode !
可是 由 SPE 的角度來看, 這還是 Software decode !
它 需要run program

引用:
作者kqalea
先引用一下閣下之前的文章

你引用的文章 不是我的 !

引用:
作者kqalea
我只是想說,其實CPU"執行緒"的效能其實沒變
變的是cpu loading
不能這樣計算系統效能,因為目前openCL的部份可以完全由GPU執行
沒有道理會有人故意留個瓶頸擺在CPU脫慢系統效能
所以一般而言 如果GPU透過openCL執行某樣工作是CPU的數倍
那APU實作開GPU理當達成同樣的效能,而不會被CPU卡住
其實你可以看之前貼的bitcoin那篇,就可知道CPU效能在並不構成
GPU執行的瓶頸,除非CPU需要參予該工作,則該工作的效能瓶頸才會受CPU引響
而這就不是openCL的本意了

非常感謝


由 video decode 的例子來看

因為 將 video decode 交給 APU 的 GPGPU 去做,
APU 的 CPU loading 下降了 !

APU 的 CPU loading 下降了 有什麼好處 ?

因為 APU 的 CPU loading 下降了, 代表著 APU 的 CPU 不用很強 ?
所以可以朝 更省電的 CPU 架構前進 ?

APU 的 CPU 要省電並有著基本的運算能理力就好了 !

我這樣想對嗎?








另外我是這樣認為
引用:
多核心 與 平行處理 是有效提升 系統性能/per watt 的方法 !
可是 多核心CPU 並不是 平行處理 的最佳執行者
所以 異質核心 出現了
IBM/Sony/Toshiba 的 Cell , AMD 的 APU

此文章於 2011-07-29 11:52 PM 被 idleic2 編輯.
舊 2011-07-29, 11:50 PM #158
回應時引用此文章
idleic2離線中  
hskao
Power Member
 
hskao的大頭照
 

加入日期: Nov 2002
文章: 560
Red face

引用:
作者greenbay
等著瞧吧...不出十年


喔~ 大大要閉關十年苦練笑話能力

那就珍重再見了
舊 2011-07-29, 11:56 PM #159
回應時引用此文章
hskao離線中  
kqalea
Major Member
 

加入日期: Dec 2004
文章: 131
引用:
作者idleic2
我認為/假設 Cell 的 PPE 才算是 CPU

那 video decode 交給 SPE 去做時,
由 PPE 的角度來看, 這是 Hardware decode !
可是 由 SPE 的角度來看, 這還是 Software decode !
它 需要run program
你引用的文章 不是我的 !
由 video decode 的例子來看
因為 將 video decode 交給 APU 的 GPGPU 去做,
APU 的 CPU loading 下降了 !
APU 的 CPU loading 下降了 有什麼好處 ?
因為 APU 的 CPU loading 下降了, 代表著 APU 的 CPU 不用很強 ?
所以可以朝 更省電的 CPU 架構前進 ?
APU 的 CPU 要省電並有著基本的運算能理力就好了 !
我這樣想對嗎?

另外我是這樣認為


XD 抱歉抱歉,我眼睛太差

Cell的SPE也是CPU喔∼SPE只是比較特別的CPU 有128組暫存器 支援128bit SIMD 指令

CPU有CPU擅長的事情GPU有GPU擅長的事情
這個故事會很長,可能講個三天三夜也講不完
但簡單說,就是單一執行緒的效能已經達到極限
要讓軟體被執行的速度更加快速,唯一的方法就是大量平行化處理
而GPU的架構,正適合大量平行運算
所以開發者就想,與其我花大錢開發新CPU架構提升的性能也有限
我何不利用現有的架構,只是改變軟體就好

APU CPU的loading減少,除了省電以外,更重要的是CPU現在有更多CPU Time去處理
其他的事情,把CPU花在更有效率的地方,簡單說,就是一般軟體當作遊戲軟體那樣
CPU負責執行週期長,需要多次更新cache/memory/IO 或是特別的指令
GPU負責可以大量平行運算,不複雜但需要快速大量執行的指令

開發者只需要改變軟體的執行方式就好,不需要花大錢研發複雜新硬體架構,
就可以達成更省電,效能更強的CPU

所以APU的未來就是CPU大量強化decode,pipeline,running order,
resource manager ,run cycle
GPU則是更容易程式化,更好控制流程,更好的容錯機制

這樣可以大幅提高每瓦效能,並減少IC複雜度
所以APU的發展不只是未了省電,APU的發展更有利硬體與軟體的最佳化
讓軟體設計師去把軟體放到最適當的目標去執行
舊 2011-07-30, 12:31 AM #160
回應時引用此文章
kqalea離線中  


    回應


POPIN
主題工具

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

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



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


vBulletin Version 3.0.1
powered_by_vbulletin 2025。