好吧,既然您這麼說鵝就先送上兩條線幫信物十份,預祝您十個月後被十頭母牛外加十頭小牛追著跑 ....

母牛? 不是說讓美女懷孕嗎? 怎麼變成母牛了?
不過母牛的懷孕期也大約是280天, 和人一樣.....

弟用CPUMark99這老程式測了一下手邊的FX4100，
當執行緒/核心滿載時，FX4100一個模組的效能，
約略是一個完整核心的73%，雖然比超行性緒的約60%好，
但真的多工吃重的話，不用說自家的龍二 X4，
甚至是APU A8系列，可能都比FX 4000系列還強...

anderson老大，因為你忽略了『資料相依』跟『負載平衡』的問題。
用嘴巴寫multi-thread當然恨輕鬆

以懷胎十月零件說為例。
首先不可能同時懷胎在組合，因為身體這個主零件的尺寸未知。
如果不先長個身體出來確定尺寸，
到時候發生胸腔太小，放了肺臟就塞不進心臟。或是大腿骨太細，勉強鑲進骨盆也是一天到晚脫臼。
這個問題正是『資料相依』。

而因為『資料相依』的困擾，所以導致前一個月十個孕婦只有一個在生產身體，其他九個閒置。
子宮的利用率太差了，這個問題則是『負載平衡』。

實際上multi-thread的環境很早就成熟了。(我吃飯傢伙的VS2005 七年前就可以輕易達成)
但是『資料相依』跟『負載平衡』只能靠人腦去解決。
而且人腦安排好是一回事，實際上機跑又是另外一回事。
真的是用嘴巴開發最容易阿

to foxtm大

您說的是,的確用嘴巴來寫程式是最容易的 , 這我不否認...

您提到的 Data Dependency or Thread Loadbalance 其實也沒那麼嚴重啦...
要跑thread base program 之前,Programmer必須把thread 程式給做好一定的規劃
當然要餵給thread的資料必須要進行標準化 , 標準化從何而來? 當然還是要預先把資料
經過一定的程序,先將彼此之間無關的資料拉出來,做好整理再交給每一個thread 去跑運算
這過程就是降低Data Dependency , thread loadbalance 這個topic到目前應該比較不成問題

因為以前還是單核心CPU為主的年代, 這個topic就很重要 , 以免被某個thread給佔住CPU resource 太多的時間
而現在呢? 情況恰好相反 , 多核心CPU滿街跑 , 所以這個topic只要注意如何分配時間給thread
控制好就可以了 , 拜半導體之賜 , 這個問題幾乎可以不算是問題了!!

所以回到10個孕婦這個例子,在生這個小孩之前,當然可以預先規劃出生的這個小孩身高
體重/手長/腳長/血液重量/五臟大小等等之類的項目,都可以先做好規劃,或許用汽車生產線
來做比喻會更為洽當!! 所以,這個就降低了Data Dependency 問題...

現在最大的問題是,有多少Programmer 能夠不透過相關thread tool ,而能夠設計thread base程式 ??
我為何會問這個問題?? 很簡單,因為我敢說 , 沒幾個人真正認清thread base程式的真正面貌 !!

PS: 以前我還曾看過,有人把Process 當做thread 來看待 , 說實在還差蠻多的....
在這個Subject之下,我只想強調的是 thread清楚的觀念是非常重要的 ,很可惜沒有多少人很清楚!!

Process Thread 差異性 只在於定址差異性
Process下創建Thread會使用同樣的上位定址

單一程序需要多工時 完全都看寫程序的人規劃
怎樣減少跟錯開必要性的公用記憶體鎖定次數 這就是高手跟庸才的差異
作業系統 其實幫不上什麼忙.....

基本上，低相依資料的問題，
編譯器就可以幫你解決了，甚至抓得比人腦徹底。
被遺漏在程式碼中邊邊角角的變數都抓得出來。

問題是，高相依的資料還是只能靠人腦去排。
而且有很大的效能問題，雙核心四核心跟六核心架構指令集等，都會造成差異

當你訂下這些邊界條件的時候，就如同FPS遊戲只能朝前後左右射擊，
也只會被前後左右四個角度來的子彈命中。
這樣可以掛保證thread非常好寫
但這樣的FPS遊戲好玩嗎
Process及thread只是對作業系統資源應用的差異而已，
只要寫的好，運作的順暢，資源分配的合理。
Google Chrome一堆Porcess不也是運作的開開心心的