多線程OR多進(jìn)程-訪存密集型應(yīng)用

zylthinking

blake326 發(fā)表于 2011-12-29 11:50
回復(fù) 9# hy036630

lz 的多半是 x86 架構(gòu)， 是保證順序?qū)懣梢?jiàn)的， 倒不用擔(dān)心亂序執(zhí)行； 不過(guò)編譯器亂序倒是真的不能保證。。。。。。。。。

hy036630

zylthinking 發(fā)表于 2011-12-29 12:02
lz 的多半是 x86 架構(gòu)， 是保證順序?qū)懣梢?jiàn)的， 倒不用擔(dān)心亂序執(zhí)行； 不過(guò)編譯器亂序倒是真的不能保證。 ...

是啊 說(shuō)的太好了，我也不知道能不能保證gcc不亂序優(yōu)化。
不過(guò)測(cè)試了這么久 好像沒(méi)有發(fā)現(xiàn)問(wèn)題
lockfree也不知道能不能保證

hy036630

blake326 發(fā)表于 2011-12-29 11:50
回復(fù) 9# hy036630

恩 說(shuō)的很好，解決問(wèn)題是替換了處理中的一部分，發(fā)現(xiàn)一個(gè)函數(shù)對(duì)并行性影響極大，具體是那個(gè)庫(kù)函數(shù)，還在測(cè)試中，
CPU亂序執(zhí)行應(yīng)該沒(méi)問(wèn)題，但是編譯器的亂序優(yōu)化不能保證，

hy036630

寫個(gè)C++程序 還要把計(jì)算機(jī)系統(tǒng)學(xué)一遍  好難啊

qsc555

再仔細(xì)看了樓主的代碼，環(huán)形緩沖區(qū)處理得很有技巧， if (Push_Count > Pop_Count)應(yīng)該可以避免可能的“編譯器的亂序優(yōu)化”問(wèn)題吧。忙等姑且不管，我這里的問(wèn)題是：吞吐量你是什么概念？25w個(gè)events每秒是指8個(gè)線程處理的總event數(shù)（2個(gè)線程處理同一個(gè)event算2個(gè)evnet)，還是一秒鐘內(nèi)有25w個(gè)不同被處理？因?yàn)槲沂裁纯�，串行都不可能提高吞吐量。是不是程序都沒(méi)什么問(wèn)題，而是我們對(duì)統(tǒng)計(jì)概念的理解偏差導(dǎo)致以為是寫了“錯(cuò)誤”的程序？每個(gè)線程4w吞吐量，8個(gè)線程就是8*4 == 32w？我現(xiàn)在懷疑這個(gè)公式

hy036630

回復(fù) 76# qsc555


吞吐量是指每一秒從環(huán)形隊(duì)列中pop出的event的數(shù)量 一個(gè)線程對(duì)應(yīng)一個(gè)隊(duì)列4W/s  8個(gè)線程的總數(shù)就是32W/s個(gè)了

還有  不能并行的庫(kù)函數(shù)是mktime這個(gè)函數(shù)  fuck 這個(gè)函數(shù)內(nèi)部加了鎖 具體大家可以看glibc的實(shí)現(xiàn)

zylthinking

hy036630 發(fā)表于 2011-12-29 17:39
回復(fù) 76# qsc555

那也不對(duì)啊， 之前你說(shuō)單線程的只有3w, 怎么現(xiàn)在流水線后就是 4w了， 除非3w是所有的處理在一個(gè)線程內(nèi)全部做完是3w, 而4w 是每秒做 4w 個(gè) 1/8, 那么加起來(lái)， 你8個(gè)線程總的吞吐還是 4w, 而不是32w

hanzhenlll

我感覺(jué)你多線程這種方式 失去了應(yīng)該有的效率， 加鎖反到能提升你效率。。。

流程估計(jì)寫的有問(wèn)題.......  

hy036630

回復(fù) 78# zylthinking
修改了一些統(tǒng)計(jì)流程，所以單線程速度提上去了  
關(guān)鍵是并行性能提高了  現(xiàn)在發(fā)現(xiàn)8個(gè)線程比1個(gè)線程的單線程能力還要高

   

zylthinking

hy036630 發(fā)表于 2011-12-29 18:30
回復(fù) 78# zylthinking
修改了一些統(tǒng)計(jì)流程，所以單線程速度提上去了  
關(guān)鍵是并行性能提高了  現(xiàn)在發(fā)現(xiàn)8 ...

你這話說(shuō)的， 8個(gè)核的8個(gè)線程能不比一個(gè)線程高么， 問(wèn)題是你 ／8 以后相比單線程性能有沒(méi)有下降， 以及下降的能否可忍受