Henry

引用:

原帖由 qcmadness 於 2012-4-15 23:30 發表

其實... IPC都係1.0左右

咁點解BD慢咁多啊.....

qcmadness

引用:

原帖由 Puff 於 2012-4-15 23:33 發表

Good point. 有 paper 做過呢樣野。但係問題係 Prefetching for GPU 值唔值得你咁做，當你有 1000k 個 work-items 加埋係 scattered data 諸如此類。

所以我咪話GPU既shader可以為CPU所用, 就可以hide latency, 不過都唔係呢2-3年做到既野

qcmadness

引用:

原帖由 Henry 於 2012-4-15 23:34 發表

咁點解BD慢咁多啊.....

front-end出事

Puff

引用:

原帖由 Henry 於 2012-4-15 23:33 發表

而家CPU都唔係得一個Core,SMT都有,但結果點?
好似SB-E咁,一個CPU就16-24條Thread,但都唔算得上latency tolerant(Cache independent)
得8個Core點解要20MB L3?

當你達到 4-way, 8-way 甚至 16-way 既時候咪得。
當你有 2-way SMT 既時候，就等於要 Cover 既 Latency 減半，不過相對黎講 Execution Time 多一倍咁解。

而且對於 Serial Workload 無好處。

qcmadness

引用:

原帖由 Puff 於 2012-4-15 23:35 發表

當你達到 4-way, 8-way 甚至 16-way 既時候咪得。
當你有 2-way SMT 既時候，就等於要 Cover 既 Latency 減半，不過相對黎講 Execution Time 多一倍咁解。

而且對於 Serial Workload 無好處。 ...

8-way暫時只fujitsu (?)

Henry

引用:

原帖由 Puff 於 2012-4-15 23:33 發表

Good point. 有 paper 做過呢樣野。但係問題係 Prefetching for GPU 值唔值得你咁做，當你有 1000k 個 work-items 加埋係 scattered data 諸如此類。

所以GPU個RAM頻寬奇廣,就係餵唔夠就出事.
個人覺得,GPU個384/512bit GDDR5某程度係Cache多過RAM.

qcmadness

引用:

原帖由 Henry 於 2012-4-15 23:38 發表

所以GPU個RAM頻寬奇廣,就係餵唔夠就出事.
個人覺得,GPU個384/512bit GDDR5某程度係Cache多過RAM.

不過係high-latency cache

Puff

引用:

原帖由 qcmadness 於 2012-4-15 23:34 發表

所以我咪話GPU既shader可以為CPU所用, 就可以hide latency, 不過都唔係呢2-3年做到既野

但我 doubt 既就係「GPU 既 shader 可以為 CPU 所用」。或者話，就算唔好似你咁搞法都可以為 CPU 所用。
用係邊樹用黎做乜又係個問題。AMD 自己都比左三大類 workload 出黎啦。

qcmadness

引用:

原帖由 Puff 於 2012-4-15 23:40 發表

但我 doubt 既就係「GPU 既 shader 可以為 CPU 所用」。或者話，就算唔好似你咁搞法都可以為 CPU 所用。
用係邊樹用黎做乜又係個問題。AMD 自己都比左三大類 workload 出黎啦。 ...

取代SSEx / AVX / FMA部分, 留番truncate / align 之類workload俾番CPU做

Henry

引用:

原帖由 Puff 於 2012-4-15 23:35 發表

當你達到 4-way, 8-way 甚至 16-way 既時候咪得。
當你有 2-way SMT 既時候，就等於要 Cover 既 Latency 減半，不過相對黎講 Execution Time 多一倍咁解。

而且對於 Serial Workload 無好處。 ...

我真係想知幾時會見到CPU個RAM頻寬好似GPU咁多,然後Parallelism就開始推上去好似GPU咁.
但就保持CPU應有既IO同其他各種指令既處理能力.

qcmadness

引用:

原帖由 Henry 於 2012-4-15 23:46 發表

我真係想知幾時會見到CPU個RAM頻寬好似GPU咁多,然後Parallelism就開始推上去好似GPU咁.
但就保持CPU應有既IO同其他各種指令既處理能力.

memory pad用既die size唔小, Intel / AMD唔會咁放資源落去

Henry

引用:

原帖由 qcmadness 於 2012-4-15 23:48 發表

memory pad用既die size唔小, Intel / AMD唔會咁放資源落去

既然Puff講到Parallelism應該可以減低Latency個效能損失,L2/3應該可以唔洗放咁多,從而減少Die size.
Memory pad就頂上L2/3個位.

Puff

引用:

原帖由 Henry 於 2012-4-15 23:52 發表

既然Puff講到Parallelism應該可以減低Latency個效能損失,L2/3應該可以唔洗放咁多,從而減少Die size.
Memory pad就頂上L2/3個位.

... data reuse & temporal locailty. 而且 parallelism 同 latency 無直接關係。係遠因同後果。

qcmadness

引用:

原帖由 Henry 於 2012-4-15 23:52 發表

既然Puff講到Parallelism應該可以減低Latency個效能損失,L2/3應該可以唔洗放咁多,從而減少Die size.
Memory pad就頂上L2/3個位.

以前d人話K8係有好大既L3 cache (memory)
但當K10/Nehalem出左之後, 就無人咁講了

Puff

引用:

原帖由 qcmadness 於 2012-4-15 23:42 發表

取代SSEx / AVX / FMA部分, 留番truncate / align 之類workload俾番CPU做

由頭再睇返上黎，引發點係 GPU supports C/C++. 我想講，GPU supports high-level language 係一個 scheduled feature... 唔係我既 speculation. virtual function, syscall, page fault, etc 一樣. 至於你講既果種 Fusion，我只係保留 doubtful 既態度，我最初想做既係 near-team 既 speculation.