Chinaunix首页 | 论坛 | 博客
  • 博客访问: 135331
  • 博文数量: 13
  • 博客积分: 431
  • 博客等级: 下士
  • 技术积分: 166
  • 用 户 组: 普通用户
  • 注册时间: 2010-05-18 14:59
文章分类

全部博文(13)

文章存档

2012年(9)

2011年(4)

分类: LINUX

2012-01-03 09:22:43

4.2.3 哈希表基准测试
    下面是哈希链表查找的基准测试结果,参与测试的锁有:全局自旋锁,全局读写锁,哈希桶(bucket)专有自旋锁、哈希桶专有读写锁和Linux的大读锁(big reader lock,译注:谁有更好的译名?这个看起来太别扭了)。测试结果很出人意料,尤其对于号称并发性的读写锁,但是也证实了前两节的说法:锁指令的开销阻碍了并行性。

(译注:ideal - 无锁的理想情况,global - 全局自旋锁,globalrw - 全局读写锁,bkt哈希桶专有自旋锁,bktrw - 哈希桶专有读写锁,brlock - 大读锁)
(译注:为什么大读锁的性能比读写锁更好呢?)
    原因很简单,见图9:获取、释放读写锁花费了大量的时间(回忆一下高速缓存行反弹),事实上临界区的代码并没有并行执行(译注:并行性比较差)。

(译注:由于作者没有给出测试代码和本次测试的读写锁实现代码,我们无法判断导致整体性能如此差的原因,但是如果临界区的代码太短的话,读写锁本身的开销可能会导致其性能比自旋锁更差)
阅读(3854) | 评论(2) | 转发(0) |
给主人留下些什么吧!~~

Heartwork2012-01-04 13:47:24

Bean_lee: hash表的这种锁的性能也是我比较关心的东西,我们是应用层面上的hash,多线程条件下,一个大锁就不合时宜了,需要对每个桶加锁。 我现在想做的事情是,首先测量.....
哈希表用的不是太多,用哈希表意味着要对问题集有一定的了解,以此来写出比较好的哈希函数;还要根据预测的数据量来确定哈希桶数组的大小;即便如此,还是需要做单独的性能测试来验证其实际效果,因为哈希表在最坏情况下会导致O(n)的时间复杂度。

对哈希表使用什么样的锁也是个问题,如你所言,可能模拟现场环境给出具体的测量值是最有说服力的。

总之,使用这玩意绝对是个体力活。

我一般就偷懒使用红黑树+读写锁这种组合对付密集型的读写访问,特别是对于那种准实时的应用。

Bean_lee2012-01-03 10:28:26

hash表的这种锁的性能也是我比较关心的东西,我们是应用层面上的hash,多线程条件下,一个大锁就不合时宜了,需要对每个桶加锁。 我现在想做的事情是,首先测量下一个大锁,花在等锁的时间是多少,然后改成小锁后,测量性能改进情况。 目前查到NPTL 提供了PTT工具,来测量线程锁的相关性能。 呵呵想做的事情太多,一旦牵扯到工作,就没那么容易。