PTT職涯區 / Stock (股票)

Re: [轉錄] 高通放出影片嗆聲聯發科「真八核」：量已回收

看板Stock (股票)作者 (恩登)時間12年前 (2013/09/03 06:33), 編輯推噓16(16推 0噓 87→)
留言103則, 17人參與, 最新討論串6/10 (看更多)
※ 引述《yamiyodare (shantotto)》之銘言： : 1. 多工寫得好的軟體會先偵測核心數, 執行緒數目通常跟核心數目成正比. : 如果軟體在高通四核稱得上有用, 八核就更有用. : 反之如果八核利用率很低, 那四核利用率也不會高到哪去. 現實是你找得到一些heavy threaded的應用 大概多半是偏重並行運算 PC game即使到現在也是支援四核為主 以上的好像還沒聽說 如果真的在軟工領域待過些時日的人應該很清楚多核心有多麻煩 軟體業跟大多數產業一樣是疊床架屋出來的 現階段大家願意花資源去支援四核已經是謝天謝地惹 : 2. 高通常自豪於自己設計 CPU 的技術, 不過它的效能不見得有那麼好. : 比如說這裡有人討論 Snapdragon S4 上 NEON (平行處理) 指令效能的問題 : https://developer.qualcomm.com/forum/qdevnet-forums/general-discussion/19061 你談這幹嘛? 消費者會去管嗎? 現實就是krait早A15不只一年 現在A15還是被壓著打 : 3. 聯發科要推八核心, 除了跑分之外, 得多找/寫一些多工好的軟體當樣本. : 手機軟體開發的困境之一是高低階效能差距太大 : http://browser.primatelabs.com/android-benchmarks : 很多吃 CPU 的軟體沒在手機上出現是因為很多手機跑太慢, 耗電又很誇張. : 像遊戲廠商就不太可能開發一個只有頂級手機才能跑得順的遊戲. 同樣的問題PC也有 頂級手機的cpu效能放到平板大概中高階 另外通常頂級遊戲主要關鍵反而變成GPU部分 這跟四核八核關聯性又更小惹 MTK八核從頭到尾就是噱頭第一 大陸這個大市場顯然就是吃這噱頭 QCOM最大的問題是目標毛利60% MTK只要40% 然後同級CPU qcom die size還更大 這個才是真正的問題 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 50.156.64.159
推
09/03 08:06, , 1F
高手出手
09/03 08:06, 1F
→
09/03 08:12, , 2F
obov還在AMD嗎? ARM的計劃死了嗎?XD
09/03 08:12, 2F
→
09/03 08:15, , 3F
不過 你這樣說AMD自己的八核...好嗎?XD
09/03 08:15, 3F
推
09/03 08:26, , 4F
感謝指教, 因這裡是股版, 我就不佔用篇幅只推文.
09/03 08:26, 4F
→
09/03 08:26, , 5F
1. 一個已經四核優化的軟體要對八核優化並不會很
09/03 08:26, 5F
→
09/03 08:26, , 6F
花功夫. 花的功夫在於實測各程式片段啟動 N 條執
09/03 08:26, 6F
→
09/03 08:26, , 7F
行緒是否真的比 N+1 條快. 如果不是, 那就對特定
09/03 08:26, 7F
→
09/03 08:27, , 8F
程式片段設個執行緒上限. 程式設計師可能會犯的
09/03 08:27, 8F
→
09/03 08:27, , 9F
錯誤是大量耗用系統資源而且與執行緒成正比.
09/03 08:27, 9F
→
09/03 08:27, , 10F
比如說一條執行緒的工作吃 100MB, 八條吃 800MB,
09/03 08:27, 10F
→
09/03 08:27, , 11F
很難往上加. 不過有了經驗之後, 就會盡量把資料
09/03 08:27, 11F
→
09/03 08:27, , 12F
跟處理切開提高 scability.
09/03 08:27, 12F
→
09/03 08:27, , 13F
2. NEON 是軟體優化時被大量運用的指令集, 重要性
09/03 08:27, 13F
→
09/03 08:27, , 14F
不下於多執行緒. 像 FFMPEG 這個解碼器它就有特別
09/03 08:27, 14F
→
09/03 08:27, , 15F
提供 NEON 優化的版本. 一個高度 NEON 優化的軟體
09/03 08:27, 15F
→
09/03 08:28, , 16F
快個三四倍是有可能的. 不過你會發現它在高通的
09/03 08:28, 16F
→
09/03 08:28, , 17F
Snapdragon S4 上加速就是比其它 A9 少. 當然消費
09/03 08:28, 17F
→
09/03 08:28, , 18F
者不會知道這些細節, 倒是程式設計師比較傷腦筋,
09/03 08:28, 18F
→
09/03 08:28, , 19F
當他發現自己寫的軟體只有 Snapdragon S4 跑不順
09/03 08:28, 19F
→
09/03 08:28, , 20F
3. 我同意您的看法, 這些問題在 PC 上也會發生.
09/03 08:28, 20F
→
09/03 08:28, , 21F
許多軟體應用是 CPU 夠力之後才開始實用普及,
09/03 08:28, 21F
→
09/03 08:28, , 22F
比如說現在常見的全景接圖, 拿到老舊一點的手機上
09/03 08:28, 22F
→
09/03 08:29, , 23F
跑頗痛苦. 八核或許可以讓我充份壓榨 CPU 的效能,
09/03 08:29, 23F
→
09/03 08:29, , 24F
做到四核跑不順的事. 但也因為只有八核跑得順,
09/03 08:29, 24F
→
09/03 08:29, , 25F
除非我不想賺了, 我不會寫這樣的軟體.
09/03 08:29, 25F
推
09/03 08:33, , 26F
抱歉, 最前面寫錯. 啟動 N+1 條執行緒是否比 N 條快
09/03 08:33, 26F
→
09/03 09:14, , 27F
不要純講理論 對八核優化是要花時間跟$$的
09/03 09:14, 27F
→
09/03 09:16, , 28F
pc進入多核主流時代也有七八年惹
09/03 09:16, 28F
→
09/03 09:16, , 29F
一堆東西優化還是沒做好 這就是現實
09/03 09:16, 29F
→
09/03 09:17, , 30F
為什麼沒做好 因為小軟體公司沒錢也沒人
09/03 09:17, 30F
推
09/03 09:20, , 31F
硬體普遍都是2~4核的時候 沒有人會真對八核優化的
09/03 09:20, 31F
→
09/03 10:19, , 32F
M也有60%的年代好嗎
09/03 10:19, 32F
推
09/03 10:25, , 33F
誰說要最佳化不同核心數很簡單 你要搞動態分thread
09/03 10:25, 33F
→
09/03 10:29, , 34F
非平型運算的部分你要搞預期分歧中獎率又有多高呢?
09/03 10:29, 34F
→
09/03 10:31, , 35F
懶人版就會遇到負載不平衡 你等我我等你
09/03 10:31, 35F
→
09/03 10:32, , 36F
多出來的核心當空氣
09/03 10:32, 36F
→
09/03 10:33, , 37F
而且請把Q收保護費的部門拿掉 看看毛利率還剩多少
09/03 10:33, 37F
推
09/03 10:35, , 38F
長知識推~
09/03 10:35, 38F
→
09/03 10:36, , 39F
八核心只對所需的運算量可以平行運算時較佔優勢
09/03 10:36, 39F
還有 24 則推文
推
09/03 11:07, , 64F
等ap跟os都到位再説
09/03 11:07, 64F
→
09/03 11:08, , 65F
但沒有計算量分別計算需求的，搞不好只要單核就行
09/03 11:08, 65F
推
09/03 11:10, , 66F
邊際效用遞減,效能瓶頸最終都會卡在同步上
09/03 11:10, 66F
→
09/03 11:11, , 67F
在這種需求佔多數的前提下，單核表現越快越佳
09/03 11:11, 67F
→
09/03 11:12, , 68F
需要運算量的最終都會由vector processors來處理
09/03 11:12, 68F
→
09/03 11:13, , 69F
與其期望軟工提供多核支援，不如期望支援多執行緒
09/03 11:13, 69F
→
09/03 11:14, , 70F
這種情況下，最佳解是intel，其次才是Q
09/03 11:14, 70F
推
09/03 11:53, , 71F
外行人問一個問題： 那真八核有比較快 跟 省電 嗎?
09/03 11:53, 71F
→
09/03 11:57, , 72F
如可容許較不佳的單一程式執行的體會感受，八核ok
09/03 11:57, 72F
→
09/03 11:58, , 73F
但較高時脈的四核，也許能提供更好的service
09/03 11:58, 73F
→
09/03 12:00, , 74F
多核心並不麻煩，麻煩的是很多程序設計員的腦子還停
09/03 12:00, 74F
→
09/03 12:00, , 75F
留在sequential programming的時代..
09/03 12:00, 75F
→
09/03 12:06, , 76F
vector processor有那麼神 就不會gpgpu喊那麼久還是
09/03 12:06, 76F
→
09/03 12:06, , 77F
沒什麼應用
09/03 12:06, 77F
→
09/03 12:26, , 78F
懶人解法能準時下班 而且產出率高 成本低...
09/03 12:26, 78F
→
09/03 12:27, , 79F
如果是軟工 除非客戶要求 不然幹嘛自找麻煩
09/03 12:27, 79F
→
09/03 12:32, , 80F
j大都不care power的 intel這麼強怎麼手機輸好幾條街
09/03 12:32, 80F
→
09/03 12:32, , 81F
然後scalability差，沒事擴充就要翻修架構..
09/03 12:32, 81F
→
09/03 12:33, , 82F
把軟工當成本看待實在是..
09/03 12:33, 82F
→
09/03 12:39, , 83F
維護需要成本 架構太複雜 投入的軟工人數均值就拉高
09/03 12:39, 83F
→
09/03 12:40, , 84F
原本一個軟工支援三個projects變成支援兩個,成本上升
09/03 12:40, 84F
→
09/03 14:23, , 85F
沒太注意intel的手機cpu那麼弱，只是覺得intel solut
09/03 14:23, 85F
→
09/03 14:23, , 86F
ion是裡面最好的，至於如何實現那是intel的問題
09/03 14:23, 86F
→
09/03 14:26, , 87F
但如果製程跟不上或解決不了過熱或耗電的問題的話
09/03 14:26, 87F
→
09/03 14:27, , 88F
那還是擺在實驗室裡當作改善的目標也好
09/03 14:27, 88F
→
09/03 14:33, , 89F
只是憑印象中的i7覺得手機的cpu同樣解法應該同樣出
09/03 14:33, 89F
→
09/03 14:33, , 90F
色才是，但如果是搭配win OS才在桌機市場表現出色的
09/03 14:33, 90F
→
09/03 14:33, , 91F
話
09/03 14:33, 91F
→
09/03 14:34, , 92F
那麼換到手機上被海電那也只是實作能力的問題
09/03 14:34, 92F
推
09/03 18:29, , 93F
Lexington很弱，不過BayTrail以上就還不錯。
09/03 18:29, 93F
推
09/06 23:19, , 94F
難得推你一下..而且die size大非常多..這連帶也會
09/06 23:19, 94F
→
09/06 23:20, , 95F
影響省電問題和cost問題..高通毛利高是因為光收3G
09/06 23:20, 95F
→
09/06 23:20, , 96F
權利金就收到爽了..反之未來4G時代若是專利防火牆沒
09/06 23:20, 96F
→
09/06 23:20, , 97F
建好...就會被MTK整個打在地上再起不能
09/06 23:20, 97F
→
09/06 23:21, , 98F
intel solution是最好的一個你是去哪邊聽來的(笑)
09/06 23:21, 98F
→
09/06 23:22, , 99F
順便跟你講intel solution是目前最耗電的
09/06 23:22, 99F
→
09/06 23:22, , 100F
一點都不會比MTK和Qcom好用
09/06 23:22, 100F
推
10/17 22:30, , 101F
謝謝...最後一段
10/17 22:30, 101F
→
08/13 01:43, , 102F
提供 NEON 優化的 https://muxiv.com
08/13 01:43, 102F
→
09/15 21:54, , 103F
外行人問一個問題： 那 https://daxiv.com
09/15 21:54, 103F
‣ 更多 obov 的文章
文章代碼(AID): #1I9H9FrH (Stock)
討論串 (同標題文章)
本文引述了以下文章的的內容：
以下文章回應了本文：
完整討論串 (本文為第 6 之 10 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共10篇)
Stock 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 obov 的文章
文章代碼(AID): #1I9H9FrH (Stock)