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

zylthinking

hy036630 發(fā)表于 2011-12-22 08:08
的確是這樣的，我覺得也不應(yīng)該是忙等的問題，應(yīng)為機(jī)器是16線程的機(jī)器，按照道理至少有8個(gè)獨(dú)立線程同時(shí)跑，
...

http://www.72891.cn/thread-3626809-1-1.html 看看這個(gè)會(huì)不會(huì)有幫助

hy036630

zylthinking 發(fā)表于 2011-12-22 10:17
http://www.72891.cn/thread-3626809-1-1.html 看看這個(gè)會(huì)不會(huì)有幫助

謝謝啊!
這個(gè)問題我注意到了，上文說得cache偽共享問題，是說如果多個(gè)線程同時(shí)需要更新同一cache行 那么根據(jù)MESI（緩存一致性協(xié)議）一個(gè)線程對(duì)cache行修改，會(huì)導(dǎo)致其他核的該cache行無效，同時(shí)還要write-back本cache行的數(shù)據(jù)。這樣速度可能比不用cache還慢。
不過我的程序共享的數(shù)據(jù)是不會(huì)更新的，也就是只讀的，是不是說不會(huì)牽涉到這個(gè)問題。

zylthinking

hy036630 發(fā)表于 2011-12-22 11:42  謝謝啊!  這個(gè)問題我注意到了，上文說得cache偽共享問題，是說如果多個(gè)線程同時(shí)需要更新同一cache行 那 ...

你每線程的對(duì)列中的變量更新呢

hy036630

zylthinking 發(fā)表于 2011-12-22 13:11
你每線程的對(duì)列中的變量更新呢

{:3_187:}
哎 一個(gè)人的想法還是有很多漏洞啊  先不說這里有沒有問題 至少我以前沒有考慮這個(gè)方面。謝了

hy036630

我測(cè)試了一把，沒什么效果，在隊(duì)列的本身的數(shù)據(jù)中間每個(gè)字段中間加上了56個(gè)字節(jié)，加上自己8個(gè)字節(jié)，每個(gè)數(shù)據(jù)占一條緩存行，其實(shí)隊(duì)列的吞吐非常大，在我測(cè)試的PCServer上有打敗100W/s的吞吐。
但是處理數(shù)據(jù)1個(gè)線程是3W/thread 10個(gè)線程差不多只有3000/thread  隊(duì)列應(yīng)該不是主要問題，
應(yīng)該是處理的過程出了問題，處理的代碼就在上面，都不超過100行
什么東西能夠如此影響性能，{:3_186:}

zylthinking

hy036630 發(fā)表于 2011-12-22 14:21
我測(cè)試了一把，沒什么效果，在隊(duì)列的本身的數(shù)據(jù)中間每個(gè)字段中間加上了56個(gè)字節(jié)，加上自己8個(gè)字節(jié)，每個(gè)數(shù)據(jù) ...

如果是這個(gè)原因， 加任何padding都不可能有用， 因?yàn)闊o論你加什么padding, 也改變不了2個(gè)核心同時(shí)訪問一個(gè)變量的事實(shí)； 要命的是， 你的 Bqueque變量 AB 共用， Cqueue, BC共用， Dqueue CD共用。。。。。。。

zylthinking

應(yīng)該是處理的過程出了問題，處理的代碼就在上面，都不超過100行

如果處理過程出了問題， 我想不出為什么多進(jìn)程反而不出問題的理由

hy036630

是啊 正如你所說的  這個(gè)是不能改變的
隊(duì)列的影響真有這么大么{:3_185:}  畢竟只是一個(gè)指針隊(duì)列，那要如何避免呢

moseslg

數(shù)據(jù)大 可以考慮寫內(nèi)存

zylthinking

hy036630 發(fā)表于 2011-12-22 15:15
是啊 正如你所說的  這個(gè)是不能改變的
隊(duì)列的影響真有這么大么  畢竟只是一個(gè)指針隊(duì)列，那要如何 ...

只是懷疑而已， 你需要驗(yàn)證到底是不是這個(gè)原因才能決定下一步啊