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

hy036630

moseslg 發(fā)表于 2011-12-22 15:29
數(shù)據(jù)大 可以考慮寫內(nèi)存

直接寫內(nèi)存么 不經(jīng)過緩存？
怎么實現(xiàn)呢？

hy036630

zylthinking 發(fā)表于 2011-12-22 15:39
只是懷疑而已， 你需要驗證到底是不是這個原因才能決定下一步啊

恩
我還在想怎么測試呢

ks9960

憑感覺在說，如果問題都沒有看懂請包涵。

引用“然后每個線程查看數(shù)據(jù)（不會修改）”，以這個為前提條件。

如果業(yè)務(wù)線程都只是read為什么還要“流數(shù)據(jù)的指針在不同的處理單元串行流動”串行處理了，從3w/s下降到3k/s也說明了串行處理帶來了性能下降。

建議數(shù)據(jù)單元增加一個處理標(biāo)志位，所有業(yè)務(wù)線程都并行的讀取數(shù)據(jù)單元，完成處理后設(shè)置處理標(biāo)志位；數(shù)據(jù)單元維護線程移除掉已完成處理的數(shù)據(jù)單元。 標(biāo)志位根據(jù)業(yè)務(wù)線程個數(shù)來設(shè)計，比如長度16bit，每個業(yè)務(wù)線程用一個bit。

hy036630

ks9960 發(fā)表于 2011-12-22 18:53
憑感覺在說，如果問題都沒有看懂請包涵。

引用“然后每個線程查看數(shù)據(jù)（不會修改）”，以這個為前提條件 ...

其實這里用到了流水線的思路
每一個線程是一個流水線結(jié)點，單個線程看似是串行，整體上看是并行
每個線程關(guān)心不同的地方，做不同的處理，所以用了很多線程read流數(shù)據(jù)

xhl

hy036630 發(fā)表于 2011-12-21 14:58
不好意思 可能我上面沒有說清楚
我用的是下面這個環(huán)形隊列  無鎖的實現(xiàn)一個進程讀，一個進程寫，沒有牽涉 ...

先不說性能問題， 你用這樣的環(huán)形隊列實現(xiàn)lockfree肯定有問題， 因為你的push_count, push_index, pop_count, pop_index沒有原子操作保護。

多個線程下， 可能會出現(xiàn)問題的。


而且按你的思路， 你的生產(chǎn)消費關(guān)系不應(yīng)該是兩邊死循環(huán)的一個push, 一個get, 這個是非常不經(jīng)濟的。

你應(yīng)該讓讓一邊一直生產(chǎn)， 一邊每間隔一段時間， 取出一批循環(huán)處理， 這樣才能真正發(fā)揮多核心生產(chǎn)線的優(yōu)勢。 你的模型大部分時間多個線程之間都沒在做有意義的事情， 都在輪訓(xùn)判斷那個隊列是否可取或者可以放。

所以我認為你的模型沒必要用lockfreequeue, 直接用普通mutex就可以了， 最好做到批量生產(chǎn)， 批量消費， 不要上鎖做業(yè)務(wù)， 把一批做完， 上鎖掛一批指針， 取也是， 上鎖取一批指針， 然后死循環(huán)做業(yè)務(wù)。

鎖的機會很少， 保證多個線程幾乎能同跑做業(yè)務(wù)。

zylthinking

xhl 發(fā)表于 2011-12-22 22:49 先不說性能問題， 你用這樣的環(huán)形隊列實現(xiàn)lockfree肯定有問題， 因為你的push_count, push_index, po ...

你不說我還沒注意到， 你一說我還學(xué)到了樓主的處理技巧了， 樓主實現(xiàn)是絕對沒有線程安全問題的，至于所謂空轉(zhuǎn)浪費時間， 也不見得是比睡眠喚醒這類通用處理方式差， 相反恐怕還要好些

zylthinking

xhl 發(fā)表于 2011-12-22 22:49 先不說性能問題， 你用這樣的環(huán)形隊列實現(xiàn)lockfree肯定有問題， 因為你的push_count, push_index, po ...

你的建議感覺不可行，原因很簡單， 樓主是很可能做網(wǎng)絡(luò)測量的，而你只是個做游戲的， 背景不同， 考慮的側(cè)重點也不一樣。

hy036630

xhl 發(fā)表于 2011-12-22 22:49
先不說性能問題， 你用這樣的環(huán)形隊列實現(xiàn)lockfree肯定有問題， 因為你的push_count, push_index, po ...

首先謝謝你的回復(fù)啊
環(huán)形隊列在一個線程讀，一個線程寫的情況下是沒有問題的，linux內(nèi)核2.6也用到了環(huán)形緩沖區(qū)。
空轉(zhuǎn)浪費時間（的確是這樣的，可以用條件量和喚醒來解決，這個不是主要問題，現(xiàn)在主要問題是性能問題），我是在測試機器上面跑的，就我一個人跑（16個線程的機器，32G內(nèi)存），我只跑了8個線程，但是性能下降的趨勢是每個線程只能處理單線程的1/8。
本來認為這是一個比較好的線程模型，如果能夠解決這個性能問題就好了。

l_walker

看看看看

xhl

hy036630 發(fā)表于 2011-12-23 08:22
首先謝謝你的回復(fù)啊
環(huán)形隊列在一個線程讀，一個線程寫的情況下是沒有問題的，linux內(nèi)核2.6也用到了環(huán)形 ...

仔細看了一下那個隊列， 貌似沒問題。主要是利用數(shù)組跟最大長度機制保證了非原子不安全性。

我沒太明白LZ你的意思， 你說的性能不行， 到底是啥意思。

我的理解是， 你不是想把一個線程可以做到事情， 拆分成多個功能塊， 然后用多個線程流水線的模式去做增加并發(fā)效率嗎。

那首先你得弄清楚你每個流水線的做到事情是否壓力平衡， 如果某個節(jié)點特別慢， 再加上你的輪訓(xùn)一個一個事件取出來處理， 勢必導(dǎo)致你多線程不如單線程快。

所以我的建議是， 你可以批量做， 第一個線程循環(huán)做一批數(shù)據(jù)， 然以吧這批數(shù)據(jù)給下個流水線程繼續(xù)循環(huán)做， 自己繼續(xù)做下批數(shù)據(jù)， 這樣即使你某個節(jié)點操作慢， 也沒多大關(guān)系。

總之， 你應(yīng)該利用多線程在SMP下利用多核心去最大限度利用CPU做業(yè)務(wù)。


你說的“空轉(zhuǎn)是浪費時間， 可以用條件變量來解決“， 我認為你的誤區(qū)就在這里， 首先你是希望讓多個線程都跑起來的吧， 不會一個等一個的。
所以我們必須讓多個線程都轉(zhuǎn)起來（但不是空轉(zhuǎn)）， 轉(zhuǎn)起來是做業(yè)務(wù)。 條件變量就會讓生產(chǎn)者跟消費者之間停等了。

另外， 我只是針對你的流水線模型討論如何增加效率， 至于你的業(yè)務(wù)需求是否采用這種模式最理想， 那個就是你們設(shè)計的問題了。
其實我覺得如果你都是只讀的數(shù)據(jù)， 就直接用多線程并發(fā)， 每個線程獨立吧業(yè)務(wù)從頭做到尾， 模型簡單， 而且容易實現(xiàn)。