多线程OR多进程-访存密集型应用

zylthinking

blake326 发表于 2011-12-29 11:50
回复 9# hy036630

lz 的多半是 x86 架构， 是保证顺序写可见的， 倒不用担心乱序执行； 不过编译器乱序倒是真的不能保证。。。。。。。。。

hy036630

zylthinking 发表于 2011-12-29 12:02
lz 的多半是 x86 架构， 是保证顺序写可见的， 倒不用担心乱序执行； 不过编译器乱序倒是真的不能保证。 ...

是啊 说的太好了，我也不知道能不能保证gcc不乱序优化。
不过测试了这么久 好像没有发现问题
lockfree也不知道能不能保证

hy036630

blake326 发表于 2011-12-29 11:50
回复 9# hy036630

恩 说的很好，解决问题是替换了处理中的一部分，发现一个函数对并行性影响极大，具体是那个库函数，还在测试中，
CPU乱序执行应该没问题，但是编译器的乱序优化不能保证，

hy036630

写个C++程序 还要把计算机系统学一遍  好难啊

qsc555

再仔细看了楼主的代码，环形缓冲区处理得很有技巧， if (Push_Count > Pop_Count)应该可以避免可能的“编译器的乱序优化”问题吧。忙等姑且不管，我这里的问题是：吞吐量你是什么概念？25w个events每秒是指8个线程处理的总event数（2个线程处理同一个event算2个evnet)，还是一秒钟内有25w个不同被处理？因为我什么看，串行都不可能提高吞吐量。是不是程序都没什么问题，而是我们对统计概念的理解偏差导致以为是写了“错误”的程序？每个线程4w吞吐量，8个线程就是8*4 == 32w？我现在怀疑这个公式

hy036630

回复 76# qsc555


吞吐量是指每一秒从环形队列中pop出的event的数量 一个线程对应一个队列4W/s  8个线程的总数就是32W/s个了

还有  不能并行的库函数是mktime这个函数  fuck 这个函数内部加了锁 具体大家可以看glibc的实现

zylthinking

hy036630 发表于 2011-12-29 17:39
回复 76# qsc555

那也不对啊， 之前你说单线程的只有3w, 怎么现在流水线后就是 4w了， 除非3w是所有的处理在一个线程内全部做完是3w, 而4w 是每秒做 4w 个 1/8, 那么加起来， 你8个线程总的吞吐还是 4w, 而不是32w

hanzhenlll

我感觉你多线程这种方式 失去了应该有的效率， 加锁反到能提升你效率。。。

流程估计写的有问题.......  

hy036630

回复 78# zylthinking
修改了一些统计流程，所以单线程速度提上去了  
关键是并行性能提高了  现在发现8个线程比1个线程的单线程能力还要高

   

zylthinking

hy036630 发表于 2011-12-29 18:30
回复 78# zylthinking
修改了一些统计流程，所以单线程速度提上去了  
关键是并行性能提高了  现在发现8 ...

你这话说的， 8个核的8个线程能不比一个线程高么， 问题是你 ／8 以后相比单线程性能有没有下降， 以及下降的能否可忍受