google.sparsegroup 可以更好
来源:互联网 发布:伯乐猎头 知乎 编辑:程序博客网 时间:2024/06/11 12:05
sparsegroup 是 google.sparseXXXX (sparsehashmap)系列中最底层的一个数据结构,sparseXXX 的互相依赖如下:
-sparsegroup
- sparsetable
- sparsehashtable
- sparse_hash_map
- sparse_hash_set
因此,sparsegroup 实现的性能直接关系到整个 sparseXXXX 系列。
先看 sparsegroup 的一段代码:
sparsegroup 只包含 3 个数据成员:
group
bitmap
num_buckets
当 GROUP_SIZE 是默认值 48 时,bitmap+num_buckets 刚好对齐到 pointer-size,如果是64位环境,整个 sparsegroup 刚好 16 bytes,即两个指针宽度。
我重点要说的是:
sparsegroup 把计算 popcount(bitmap, idx) 看成是一个昂贵的操作,然而,在现代 cpu 中,这是错误的!popcount 在大多数主流cpu中都有直接的硬件支持。
num_buckets 实际上是一个冗余数据,因为 num_buckets == popcount(bitmap),本来在 sparsegroup 中增加 num_buckets 成员只是为了加速,避免对整个bitmap 计算 popcount。然而在支持硬件 popcount 的 cpu 中,num_buckets 的存在反而大大降低了性能!因为它使得整个 bitmap的尺寸不能按机器字对齐,从而计算 popcount 时要多一个bitmask 操作,并且,取 num_buckets 也可能比 popcount(int64)还要慢。如果直接改成:
google 实现的 popcount(bitmap, pos) 要比硬件支持的__builtin_popcountll(bitmap & ~-1LL<<pos)慢几百倍,他们当然也有理由——popcount并非在所有系统上都有编译器和硬件支持!
对 GROUP_SIZE==64 这个典型值,这样的优化版明显比 google 版好得多,不但简单,而且更快。如果要增大 GROUP_SIZE,应直接增加一倍或两倍,GROUP_SIZE 不宜过大,以免对 group 数组的添加、删除操作代价太高,64也许是一个最佳值。
- google.sparsegroup 可以更好
- popcount & google.sparsegroup
- 可以更好~
- 更好的使用GOOGLE
- 怎么更好使用google
- 更好利用Google搜索
- 更好的访问google
- 希望自己可以更好
- 其实你可以更好
- 只知道google protocol buffer?Boost serialize 可以更好解决STL序列化 反序列化 附小例子
- 如何更好的使用google
- 分页算法,还可以更好
- 分页算法,还可以更好
- 我可以做的更好
- 更好地使用Google的服务
- 在哪里工作更好?Facebook大胜Google
- 在哪里工作更好?Facebook大胜Google
- QUIC:Google开发的更好的TCP
- linux od 命令使用
- SharePoint2007 产品和技术配置向导 与 Office2010 Beta2 冲突
- VC获取系统特殊文件夹的路径
- 开源信息系统开发平台之 OpenExpressApp框架.pdf
- 一个人久了,会上瘾的...
- google.sparsegroup 可以更好
- 多线程算法(—)
- MyEclipse中JDBC连接SQLSERVER2005学习总结
- C#.NET实体代码生成工具,支持Access,MSSQLServer!实现数据库所有操作!
- 在工作中怎样和领导、同事沟通
- C# 编码规范
- Python标准库-traceback模块
- 优先级
- linux下scp的使用