→ tinlans:我覺得這一定有人會拿來發論文打嘴炮拿學118.160.109.251 08/02 17:18
→ tinlans:位用，但是要實用的話可能性可說是沒有。118.160.109.251 08/02 17:19
→ tinlans:而且九成九的機率一定是做苦力搞出來的。118.160.109.251 08/02 17:19
→ ggg12345:論文要有證明或模擬數據,資料平行最容易 140.115.4.12 08/02 17:39
→ ggg12345:但大家都知,加綷轉譯是不說嘴高人幹的事! 140.115.4.12 08/02 17:43
→ ggg12345:國內多核心計劃都在新竹幫的地盤轉!難免! 140.115.4.12 08/02 17:45
→ ggg12345:新竹幫地區出論文的量與速,有目共睹吧! 140.115.4.12 08/02 20:10
推 leicheong:除了用functional prog. lang.寫的以外, 219.73.23.124 08/03 23:49
→ leicheong:一般程式沒多線程考量的話, 要在多核 219.73.23.124 08/03 23:49
→ leicheong:平行跑已經機會不大了... 還要要求沒 219.73.23.124 08/03 23:50
→ leicheong:context switching嗎? 這是在做會幫你 219.73.23.124 08/03 23:51
→ leicheong:自動重寫的AI嗎? :OOOOO 219.73.23.124 08/03 23:51
→ leicheong:病毒碼加載通常是透過hook的方式在呼叫 219.73.23.124 08/03 23:54
→ leicheong:API時被「順道」執行那樣? 要不就是直接 219.73.23.124 08/03 23:55
→ leicheong:以另一process執行... 不論那種方式都是 219.73.23.124 08/03 23:57
→ leicheong:本身已替多線執行的方式做了規劃才可 219.73.23.124 08/03 23:58
→ leicheong:成立吧... 219.73.23.124 08/03 23:58
==========
多核是多個 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)
推 leicheong:因此, 我就說你這目標是寫出「可以自動 219.73.23.124 08/04 20:35
→ leicheong:重寫程式」的AI囉... 你說的這些跟製作 219.73.23.124 08/04 20:36
→ leicheong:interpreter的複雜度相差不遠, 你就認為 219.73.23.124 08/04 20:37
→ leicheong:這些動作在執行上的overhead不會比 219.73.23.124 08/04 20:38
→ leicheong:context switching大嗎? :P 219.73.23.124 08/04 20:38
推 leicheong:還有, 大部份病毒都不會去找掛點, 只是 219.73.23.124 08/04 20:41
→ leicheong:寫一個「殼」把病毒碼後的所有部份以 219.73.23.124 08/04 20:42
→ leicheong:LoadModule的形式載入並執行. 掛hook 219.73.23.124 08/04 20:42
→ leicheong:的相象也只是幾個常用的function call, 219.73.23.124 08/04 20:43
→ leicheong:不用想得太複雜的... 219.73.23.124 08/04 20:44
=======
這題本來就是 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)