推 ltytw: 好奇怪喔 為什麼不是程式設計師把軟體寫114.33.46.227 10/14 13:47
※ 編輯: TRFgee (42.76.104.35 臺灣), 10/14/2023 13:48:12
推 ltytw: 成n核心 但也只是告知軟體能使用幾個核心 114.33.46.227 10/14 13:54
→ ltytw: 而並不是寫死說哪個部份指定core1 哪個部份 114.33.46.227 10/14 13:55
→ ltytw: 指定core2 114.33.46.227 10/14 13:55
→ ltytw: 要讓軟體使用哪個核心由AMD/intel寫調度器 114.33.46.227 10/14 13:56
→ ltytw: 塞進OS 由OS指派 114.33.46.227 10/14 13:56
→ ltytw: 萌新如我有這個疑問 114.33.46.227 10/14 13:57
→ ltytw: 也就是說 誰要擔這個調度大任？ 應用 114.33.46.227 10/14 13:59
→ ltytw: 軟體商還是CPU廠商 還是作業系統廠商？ 114.33.46.227 10/14 13:59
→ ltytw: 萌新如我有這個疑問 114.33.46.227 10/14 13:59
推 onnie: 軟體控制的話 n個軟體就要寫n次 1.200.135.162 10/14 14:19
→ onnie: 如果改架構可能又要改一次 成本太高 1.200.135.162 10/14 14:19
→ ILike58: 當然OS廠商去調度啊，只有他有辦法看到全 111.71.88.221 10/14 14:20
→ ILike58: 局的需求，只是這些都還是要吃硬體資源， 111.71.88.221 10/14 14:20
→ ILike58: 這種大小核的調度應該也只是對非常多工有 111.71.88.221 10/14 14:20
→ ILike58: 明顯助益吧，個人使用沒那麼多繁雜工作， 111.71.88.221 10/14 14:20
→ ILike58: 看起來這種機制未必是好事。 111.71.88.221 10/14 14:20
推 atpx: 軟體寫成多執行緒有一堆同步與控制問題 1.163.130.166 10/14 14:25
→ atpx: 能不做就不做 1.163.130.166 10/14 14:25
→ ILike58: 這種設計策略用在伺服器上應該很好，甚至 111.71.88.221 10/14 14:32
→ ILike58: 排程上直接用最簡單的需求類型去指派大小 111.71.88.221 10/14 14:32
→ ILike58: 核，太複雜的排程策略是不是真有那個效益 111.71.88.221 10/14 14:32
→ ILike58: 都還是問號，個人需求要的就是快速回應， 111.71.88.221 10/14 14:32
→ ILike58: 當然手上有的硬體資源盡可能的砸下去，畢 111.71.88.221 10/14 14:32
→ ILike58: 竟你不會在打電玩還要想著服務其他人的需 111.71.88.221 10/14 14:32
→ ILike58: 求，通常手上同時進行三項工作就很多了， 111.71.88.221 10/14 14:32
→ ILike58: 其中有項吃了九成的資源大概已經是個人對 111.71.88.221 10/14 14:32
→ ILike58: 電腦使用的盡的狀況了，這時什麼排程進來 111.71.88.221 10/14 14:32
→ ILike58: 也沒意義。 111.71.88.221 10/14 14:32
推 a1234567289: 是OS調度沒錯 OS當然能知道誰是大 101.12.31.113 10/14 14:32
→ a1234567289: 核誰是小核.. 最晚2011 ARM引入big 101.12.31.113 10/14 14:32
→ a1234567289: LITTLE的時候 當時Linux kernel已經 101.12.31.113 10/14 14:32
→ a1234567289: 能透過table調度大小核了 101.12.31.113 10/14 14:32
推 atpx: 對軟體商來說,多執行緒還會有QA問題,除非能 1.163.130.166 10/14 14:37
→ atpx: 賣錢,不然都是丟給底層處理就好 1.163.130.166 10/14 14:37
→ atpx: 應用層比較少自找麻煩 1.163.130.166 10/14 14:37
推 luke72: 給一樓，先去查查為什麼會有OS 111.71.10.98 10/14 15:06
→ spfy: 高階語言可以寫多執行緒 但很少管核心吧?203.121.243.239 10/14 15:18
推 chchwy: 一樓大概沒寫過程式 114.34.94.191 10/14 15:23
推 a2935373: Server就沒在用大小核的吧? 114.32.245.58 10/14 15:27
推 aegis43210: server只有超執行緒 223.140.175.54 10/14 15:28
→ dildoe: 馬農都說threading沒SIMD香，還搞異質thre 93.91.80.6 10/14 15:46
→ dildoe: ading嗎?XD 93.91.80.6 10/14 15:46
推 ltytw: 樓上某樓對不起 我的確沒寫過多線程的程式 114.33.46.227 10/14 15:53
推 ltytw: 只有寫過單線程100行左右的hello world 114.33.46.227 10/14 15:56
→ ltytw: 有請C大賜教 114.33.46.227 10/14 15:56
→ hn9480412: 那AMD的吃土機呢？ 42.73.192.189 10/14 16:25
推 deflife: linux有eas排程演算法 有興趣可以看看 39.15.33.156 10/14 16:32
推 SHR4587: 我比較好奇AMD版本的大小核那種狀況會怎 220.136.15.129 10/14 16:51
→ SHR4587: 樣 220.136.15.129 10/14 16:51
噓 bhmagic: 你雙路OS不用管NUMA? 寫一些大便 76.82.233.154 10/14 17:08
→ bhmagic: OS不只要管大小核 誰誰共多少快取都要管 76.82.233.154 10/14 17:11
→ bhmagic: 還有些架構和新指令集都不一樣 76.82.233.154 10/14 17:12
推 aasssdddd: 大小核單核快 多線程是一般的比較快 1.34.231.24 10/14 17:28
推 birdy590: 呃 原po這個是有分大小核之前的觀念 115.43.53.170 10/14 17:41
推 kamichu: ？？？你在說什麼 36.232.161.236 10/14 17:41
→ birdy590: 開始有區分以後, OS 就必須有對應的設計 115.43.53.170 10/14 17:42
→ birdy590: Intel+Win11 就是靠 Thread Director 115.43.53.170 10/14 17:44
→ birdy590: 本來 Linux 是領先的, 現在變成落後了 115.43.53.170 10/14 17:46
→ birdy590: 完整方案不只排程 還包括資源分配 和省 115.43.53.170 10/14 17:55
→ birdy590: 電有關的部份 一定是先有硬體再去支援 115.43.53.170 10/14 17:55
推 sokayha: 感覺就類似筆電的主顯和內顯的調度分配， 106.104.70.198 10/14 18:04
→ sokayha: 寫不好的遊戲就有可能自己跑去用內顯 106.104.70.198 10/14 18:04
→ sokayha: 都有符合新規範的遊戲/開發平台之後應該 106.104.70.198 10/14 18:05
→ sokayha: 是就不會遇到類似的調度問題 106.104.70.198 10/14 18:05
推 lc85301: 說到排程器只好 @jserv 223.138.47.180 10/14 18:36
→ commandoEX: 軟體決定最多有幾個執行緒可以同時跑 118.171.131.70 10/14 19:29
→ commandoEX: 但是給誰跑是OS決定的 118.171.131.70 10/14 19:29
→ commandoEX: 除非你寫死指定哪個核心跑哪個執行緒 118.171.131.70 10/14 19:32
噓 la8day: 不信 118.231.217.26 10/14 19:39
推 Litfal: 我看你是不懂喔 對稱多cpu os都有numa 1.34.131.99 10/14 19:44
推 linjrming: 就算沒有大小核也有雙路問題需要OS排程 61.230.99.2 10/14 19:52
→ birdy590: 前一次大改是為了 SMT, CPU table 必須 115.43.53.170 10/14 19:57
→ birdy590: 有辦法區分實體和邏輯處理器的對應 115.43.53.170 10/14 19:57
→ birdy590: 分大小核以後變更複雜 因為沒有標準答案 115.43.53.170 10/14 20:00
→ friedpig: 13gen以後有直接做CPU理了八 125.228.96.10 10/14 20:05
→ friedpig: CPU會稍微判斷一下要分到大核還小核 125.228.96.10 10/14 20:05
→ friedpig: 雖然最後用最暴力最有效的做法是前景大 125.228.96.10 10/14 20:06
→ friedpig: 核 背景小核 大約87%時間是對的 125.228.96.10 10/14 20:06
→ SPDY: 就Intel的說法 是會盡可能的向OS提供資訊啦 1.171.209.158 10/14 20:25
→ SPDY: 畢竟相較AMD的c核就只是同構縮快取和降時脈 1.171.209.158 10/14 21:05
→ SPDY: 玩更大的Intel的玩 是P+E+LP異構在不同晶片 1.171.209.158 10/14 21:05
→ SPDY: 所謂Threadirector是內建評分機制給OS看 1.171.209.158 10/14 21:05
→ SPDY: 該機制可以韌體更新 搞不搞得定 實機再看了 1.171.209.158 10/14 21:08
推 johnjohnlin: 比效能的程式的確要針對架構優化啊 1.34.40.114 10/14 21:49
→ johnjohnlin: ，不是總是無關架構的 1.34.40.114 10/14 21:49
推 peal: OS存在有個最大目的就是分配資源（分配cpu資 1.173.43.50 10/14 22:16
→ peal: 源）。 1.173.43.50 10/14 22:16
推 Fezico: 現在玩這種異種核架構不管是i還是a都會遇 106.64.97.35 10/14 22:24
→ Fezico: 到同一個問題，怎樣讓os/軟體知道哪顆是大 106.64.97.35 10/14 22:24
→ Fezico: 核哪個是小核，對機器來說都一樣是核心。 106.64.97.35 10/14 22:24
→ SPDY: 必須韌體/OS/軟體全都要更新且之間良好配合 1.171.209.158 10/14 22:37
→ SPDY: 然而x86+Win這既是資產也是包袱的相容性... 1.171.209.158 10/14 22:39
→ SPDY: 連ARM生態較封閉更替較快也才即將切掉32bit 1.171.209.158 10/14 22:40
→ SPDY: 等P+E+LP多重異構甚至跨晶片的實機慢慢調吧 1.171.209.158 10/14 22:43
→ Fezico: 有暴力解就全調動，不管資源分配也不管設 106.64.97.35 10/14 22:45
→ Fezico: 備因素，全核操起來。但使用體感會爛的跟 106.64.97.35 10/14 22:45
→ Fezico: 泥漿一樣就是 106.64.97.35 10/14 22:45
→ SPDY: 全開? 那Intel就失去搞SoC裡設LP核的意義了 1.171.209.158 10/14 22:52
→ SPDY: 而且多重異構的IPC落差 也沒辦法全開就解決 1.171.209.158 10/14 22:53
→ Fezico: arm我記得某個版本搞過這個，結果核炸。 39.12.41.21 10/14 22:58
推 birdy590: ARM 其實比較簡單 像手機上前景就給大核 115.43.53.170 10/14 23:04
→ birdy590: Windows 也差不多... 像Linux這種就難了 115.43.53.170 10/14 23:04
→ birdy590: 哪裡分的出什麼前景背景? 最好程式要求 115.43.53.170 10/14 23:05
→ birdy590: 知道哪個大核哪個小核不難啊 加欄位已經 115.43.53.170 10/14 23:06
→ birdy590: 問題是知道了以後要怎麼辦 這個有夠複雜 115.43.53.170 10/14 23:06
→ SPDY: 畢竟手機常見狠狠的乾脆 凍結不在前台的App 1.171.209.158 10/14 23:06
→ birdy590: 弄不好就是體驗爛到屎 逼人把小核關了 115.43.53.170 10/14 23:06
→ birdy590: 跟省電還會連動 想要省電可能得關大核 115.43.53.170 10/14 23:07
→ SPDY: 而PC跑編碼之類的工作 開瀏覽器打發時間 1.171.209.158 10/14 23:10
→ SPDY: 正事被扔去小核會令人不爽但OS哪懂何謂正事 1.171.209.158 10/14 23:10
→ SPDY: 最好的解是軟體能表明自己是正事要最大效能 1.171.209.158 10/14 23:12
→ Fezico: 這樣搞就是每個軟體都指名要大核惹，這東 39.12.41.21 10/14 23:13
→ Fezico: 西神麻煩 39.12.41.21 10/14 23:13
→ SPDY: 所以又是韌體/OS/軟體都要配套得好的事情了 1.171.209.158 10/14 23:13
→ hanshsu: p?f=296&t=6485684&p=1 感覺m01這篇討論 111.249.83.197 10/14 23:33
→ hanshsu: 回答的蠻完整的 111.249.83.197 10/14 23:33
推 birdy590: 人人都是VIP~ 那就是沒有VIP 115.43.53.170 10/15 00:07
推 moon52016: 哪有軟體會報自己不重要… 61.231.6.106 10/15 00:27
→ commandoEX: 軟體要的資源都是喊多不喊少 118.171.131.70 10/15 00:29
→ SPDY: 調用硬解的影音播放可以喊少 就問題是肯嗎? 1.171.209.158 10/15 00:44
→ SPDY: 最近Intel才秀14代 刻意關P和E核硬解播8K60 1.171.209.158 10/15 00:49
推 SPDY: 影片特地強調 這只使用SoC的那2顆 小小LP核 1.171.209.158 10/15 00:58
推 kuninaka: 這篇看到第一行就笑了 61.227.111.248 10/15 07:46
→ Arbin: 奇文共賞 223.139.185.92 10/15 08:51
推 Glacier319: 照m01那篇的說法 12-13代的小核根 1.162.115.45 10/15 10:05
→ Glacier319: 本和arm的大小核不同 只是塞滿湊數 1.162.115.45 10/15 10:05
→ Glacier319: 用的 更不用說一個windows要包各種 1.162.115.45 10/15 10:05
→ Glacier319: 規格CPU了 客製化的條件不同 1.162.115.45 10/15 10:05
噓 scott260202: 現實沒有課本上講的簡單，別誤導人 36.224.4.163 10/15 13:14
→ ILike58: 知道哪顆是大核哪顆是小核不難吧，難的是 111.71.88.221 10/15 16:12
→ ILike58: 哪個行程該用大核哪個該用小核才難。 111.71.88.221 10/15 16:12
推 AmigoSin: @jserv111.250.179.122 10/15 16:24
推 yymeow: 會有問題都是在指令派發出去之後，實際的 114.37.36.165 10/15 16:53
→ yymeow: 執行時間與預測的有差異。好比我們把難的 114.37.36.165 10/15 16:54
→ yymeow: 專案給老鳥，簡單的給菜鳥。預計兩者的完 114.37.36.165 10/15 16:54
→ yymeow: 成時間應該差不多。結果可能專案難度與預 114.37.36.165 10/15 16:54
→ yymeow: 期有差，或是執行因素。結果實際完成時間 114.37.36.165 10/15 16:55
→ yymeow: 與預計產生了不小的落差。那剛好又牽涉到 114.37.36.165 10/15 16:55
→ yymeow: 資源釋放問題，就變成誰非得停下來等誰。 114.37.36.165 10/15 16:56
→ yymeow: 然後就很容易進入worst case了 114.37.36.165 10/15 16:56
→ dildoe: 有問題請問SW marketing仔不是比較專業嗎? 93.91.80.6 10/15 18:20
→ dildoe: 真心不騙!XD 93.91.80.6 10/15 18:20
推 kira925: 這最大的問題就 每個軟體都希望自己最大 220.135.86.145 10/15 19:18
→ kira925: 沒有人要老實 220.135.86.145 10/15 19:19
→ ekgs: 1F 先去看一下作業系統+計算機組織 61.230.81.169 10/15 21:59
→ ekgs: 多核心 多執行緒 同步問題 affinity ... 61.230.81.169 10/15 22:03
→ ekgs: 太多了 61.230.81.169 10/15 22:03
推 ltytw: ok 125.224.81.93 10/16 10:05
