Re: [問題] 有關古老程式跑在多核平台上的問題?

看板Programming作者 (ggg)時間16年前 (2009/08/02 16:57), 編輯推噓3(3推 0噓 24→)
留言27則, 3人參與, 最新討論串2/10 (看更多)
※ 引述《lkerr (kerr)》之銘言： : 標題: [問題] 有關古老程式跑在多核平台上的問題? : 時間: Sat Aug 1 23:44:56 2009 : : 不知道po在這個版上會不會不適合,由於有一些古老的程式, 沒有原始碼, : 程式沒有對多核心作最佳化, 那有沒有方法在作業系統之上, 建立一個虛擬 : 單核環境, 實際上這個虛擬環境卻有效利用多核心的效能, 這樣就能不用更 : 改程式卻能大大提升程式的效能, 作業系統可以是windows 或 linux : 不知有沒有這樣的解決方案, 感謝 ======== 用軟體方法讓單一的單核老程式在多核下變快, 目前應該沒啥現成的辦法. 如果是讓多個程式在多核心機下一起跑, 不因多程式分時而變慢, intel 是做了相當多的努力, 多段程式相互間亂序交錯跑, 塞滿可用資源的管線, 但不改各段原次序, 以硬體協助指令排程的做法, intel 是費力做了. 目 前則是改用 compiler 做指令預排程以減少硬體成本. Virtual Machine 是可能讓多個老程式在多核下一起跑, 但總耗費時間是 能界於單核單機與多機各跑其一之間. 這問題很有趣也很有挑戰性 ! 先要談可能性與做法存在否 ? 沒有 source program , 也是可以把機器碼當 source code 拿來轉換解譯, 所以, 可能性是存在的. 平行處理的要求就是片段程式與資料間沒有前後相依性, 先做後做不影響結 果的就行. Data parallel 就是其一, 如同在大圖內找東西, 可分成小圖, 各段各自處理. 這種方式的只要加前補後再用老程式就能平行變快, 但要考 慮現在的多核並非多處理機架構, 可能只是多個多種處理單元, 假如浮點運 算器只有一組, 資料若都靠浮點運算那也是架構對不攏. 其次是有前後次序性, 能用生產管線(pipleline)串接, 同時同步各做各 的工作, 矩陣迴圈通常有這種性質, 多少能用之再變快一點. 這種做法可能就是 run-time 才做 code parallel & optimization ! 資訊 不太足夠, 但要能學習與預測. : : -- : ※ 發信站: 批踢踢實業坊(ptt.cc) : ◆ From: 202.86.171.101 : → tinlans:就算有我想實用性也是堪慮。 118.160.109.251 08/02 03:48 : → freesamael:目前沒有 118.231.88.113 08/02 12:20 : → haryewkun:如果你的程式是單程的，那麼在不改程式 60.49.44.200 08/02 13:19 : → haryewkun:的前提下，在任何平台下執行都是單程的 60.49.44.200 08/02 13:20 : → haryewkun:，不可能說換了平台它就變成多核心的。 60.49.44.200 08/02 13:20 : → haryewkun:單機的游戲，不會因為換一換平台就變成 60.49.44.200 08/02 13:21 : → haryewkun:mmorpg啊…… 60.49.44.200 08/02 13:21 : 推 leicheong:核心轉換間context switching的 219.73.23.124 08/02 14:32 : → leicheong:overhead大概會把這樣做的好處消耗殆盡. 219.73.23.124 08/02 14:33 : → leicheong:這樣做沒有好處的... 219.73.23.124 08/02 14:33 各幹各的, 不要切換不就沒 context switching ? : 推 StubbornLin:要如何有效利用多核效能 這點很難 118.170.94.59 08/02 15:12 : → StubbornLin:什麼東西可以並行做 什麼不可以 118.170.94.59 08/02 15:12 : → StubbornLin:單行程的程式很難把它拆成平行的吧 118.170.94.59 08/02 15:13 : 推 sunneo:頂多把system call弄thread幫忙吧 118.171.80.193 08/02 15:20 想到病毒碼加掛於各程式, 還能各自同時隨著同時跑就令人激賞 ! 不改原程式也行 ! 沒限制不能複製一部份補綷加掛吧 ! 果真是超級挑戰的難題 ! 跟基因改造有拼 ! -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.115.4.12
→
08/02 17:18, , 1F
我覺得這一定有人會拿來發論文打嘴炮拿學
08/02 17:18, 1F
→
08/02 17:19, , 2F
位用，但是要實用的話可能性可說是沒有。
08/02 17:19, 2F
→
08/02 17:19, , 3F
而且九成九的機率一定是做苦力搞出來的。
08/02 17:19, 3F
→
08/02 17:39, , 4F
論文要有證明或模擬數據,資料平行最容易
08/02 17:39, 4F
→
08/02 17:43, , 5F
但大家都知,加綷轉譯是不說嘴高人幹的事!
08/02 17:43, 5F
→
08/02 17:45, , 6F
國內多核心計劃都在新竹幫的地盤轉!難免!
08/02 17:45, 6F
→
08/02 20:10, , 7F
新竹幫地區出論文的量與速,有目共睹吧!
08/02 20:10, 7F
推
08/03 23:49, , 8F
除了用functional prog. lang.寫的以外,
08/03 23:49, 8F
→
08/03 23:49, , 9F
一般程式沒多線程考量的話, 要在多核
08/03 23:49, 9F
→
08/03 23:50, , 10F
平行跑已經機會不大了... 還要要求沒
08/03 23:50, 10F
→
08/03 23:51, , 11F
context switching嗎? 這是在做會幫你
08/03 23:51, 11F
→
08/03 23:51, , 12F
自動重寫的AI嗎? :OOOOO
08/03 23:51, 12F
→
08/03 23:54, , 13F
病毒碼加載通常是透過hook的方式在呼叫
08/03 23:54, 13F
→
08/03 23:55, , 14F
API時被「順道」執行那樣? 要不就是直接
08/03 23:55, 14F
→
08/03 23:57, , 15F
以另一process執行... 不論那種方式都是
08/03 23:57, 15F
→
08/03 23:58, , 16F
本身已替多線執行的方式做了規劃才可
08/03 23:58, 16F
→
08/03 23:58, , 17F
成立吧...
08/03 23:58, 17F
========== 多核是多個 function unit , 多組 register set , 多個 instruction pointer 共同放在同一個 chip 之內. 為了省電, 配合 MOS Device 的 clock 不能那麼高速, 但多核的內部如同 RISC Processor 一樣, 也沒 必要讓 register set 與 FU 是隨各核完全分離的, 各核可以做到動態 配屬, 配不到資源就等. 假設有 四核 有四個 instruction pointer , 四個 ip 可指在同一程式 碼塊上, 但 data oprand 的 index base 起始值不同, 所以執行時, 是 取出不同記憶體的資料各自運算, 這是 data parallel. 這個多核是在 同一個 chip 內, 可以把 MIMP 當成 SIMP 使用, 就可以有 array computing 的效能, 這是偏計算. 若是夾雜著各種不同偏重的多工程序, 應該要能動態調配資源來用. 高階語言產生的 pattern 都是固定的形式, 老式程式在沒有 optimization 前是容易被辨識的. 多數矩陣就能被分割成 data parallel . 矩陣運算的 前後分叉合併點就可以用病毒碼方式的 patch code 完成. 這可能是苦功, 但要害的點就那幾處. 老式的病毒可以查出掛點, 還能去除 還原. 這個 optimization 則是改造程式碼, 若有多核可用就使用 data parallel, 沒有就照舊, 所以是基因改造. 可併行部份, 新式的可以讓 programmer 宣告, 老式的就靠自動檢視轉換與 標記, 對標記的後續處理與進一步轉換調派就可由 VMM 來做. 主要的重點是: 這是一件可持續發展的事業, 需求因多核硬體的來臨而存在. 實用就是要能從 嘴泡討論, 逐步變成可行, 可試, 值得一試, 可用. ※ 編輯: ggg12345 來自: 140.115.4.12 (08/04 12:04)
推
08/04 20:35, , 18F
因此, 我就說你這目標是寫出「可以自動
08/04 20:35, 18F
→
08/04 20:36, , 19F
重寫程式」的AI囉... 你說的這些跟製作
08/04 20:36, 19F
→
08/04 20:37, , 20F
interpreter的複雜度相差不遠, 你就認為
08/04 20:37, 20F
→
08/04 20:38, , 21F
這些動作在執行上的overhead不會比
08/04 20:38, 21F
→
08/04 20:38, , 22F
context switching大嗎? :P
08/04 20:38, 22F
推
08/04 20:41, , 23F
還有, 大部份病毒都不會去找掛點, 只是
08/04 20:41, 23F
→
08/04 20:42, , 24F
寫一個「殼」把病毒碼後的所有部份以
08/04 20:42, 24F
→
08/04 20:42, , 25F
LoadModule的形式載入並執行. 掛hook
08/04 20:42, 25F
→
08/04 20:43, , 26F
的相象也只是幾個常用的function call,
08/04 20:43, 26F
→
08/04 20:44, , 27F
不用想得太複雜的...
08/04 20:44, 27F
======= 這題本來就是 parallel compiler , 要稱 AI 也可. 先偷懶找特定的 pattern 先標記轉換. 執行時, 這部份就 自動trap 進入特殊的模組 (vmm), 由之先調派多核針對事先已對 array data 大迴圈標記好之處, 利用多核與多個功能單元, 完成平行與管線計算, 就可改善最主要部 份的效率. 老式解毒還原的技術不就類似上述的動作 ? 專針對少數 pattern , 事情就不會是那麼難解 ! 多核若只將多機的 processor unit 複製置於同一個 chip , 原本透 過 bus 共用記憶體的方式就變成是多核共用 cache , 這會使得 cache 的共用 bus 變得非常高速而更耗電. 若使用分隔的 cache 與各自銜接 的 bus 就無此問題, 但彼此互通轉送結果形成 pipleline 的效用就會 減弱. 多核對內部 register 與 cache , 各個 function unit 的配屬 終究會應需要而繼續演化, 從極端來看就是從多核的 MIMP 可以動態調 整成相當於一個單核的 SIMP 效果. 多機共用記憶體架構的對策是將 single process 變成 multi-thread, 是 task/thread level 的平行運算. 但從 MIMP 變成 SIMP 的運算就 相當於將長串多個指令碼轉化為少數幾個 VLIW 指令, 讓各個 function unit 在 instruction level 同時並行處理. 假如僅把多核內部資源都配屬於同一個程式, 那就沒有 context switch 的必要. 有了隨時將結果暫存的 register/cache 當緩衝, 可動態配屬與 調整的不等配置多核, 在每次存回結果下就能減化 context switching. 換言之, 多核的資源在動態可調整下, 形成一個相當於 單核的RISC處理 器, 擁有大部份的 register set 與 function unit 在 VLIW 的指令下 讓各個功能單元平行運作. ※ 編輯: ggg12345 來自: 140.115.4.12 (08/05 08:11)
‣ 更多 ggg12345 的文章
文章代碼(AID): #1ATLKBgP (Programming)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 2 之 10 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共10篇)
‣ 更多 ggg12345 的文章
文章代碼(AID): #1ATLKBgP (Programming)