喷下64位机器的弊端。。

中山野鬼 发布于 2012/07/03 14:08
阅读 519
收藏 0

最近在做网络算法库。不是INTENET。是图论的网络。传统的用链表描述结点关联再方便不过。我们可以注意一个事实,即便客观结点数量众多,但任意一个结点和超过上千万的结点直接关联的情况很少存在。甚至可以证明这种情况,计算复杂度无法用当前计算设备处理。

秉承一个共识,绝大多数情况下,一个结点或数据所直接的关联是有限的。因此一个大图可以拆分成不同的子图做局部计算再汇总。任意一个子图,可以集中在有限的存储空间,利用有限的代码片做高速计算。

但问题来了,用64位设备,一个指针就64位。一个描述关联的结点,至少3个指针吧。头、尾,和关联信息。例如一条马路,两端点的指针,和这个马路(作为边)的信息结点的指针。这就24个bytes。这什么概念,一个pages 4Kbytes。指针部分,64位相对16位多了4倍,等于只有原先1/4的可描述信息进行关联计算。

至少一个局部可计算的子图指向的空间并不需要64位下标寻址。如果换成32位,也可以更好些。悲剧的是无论高级语言还是OS,或者硬件的MMU,无法做到一个段程序片,在一个有限时间段内,可仅通过16位或32位指针在64位的环境中运行。。。最终仍然要映射

于是乎,多了一堆地址转索引(16位)的逻辑。

抱怨一下,64位的环境。64位下,指针这个数据结构,越来越区别于其他整型结构了。还是32位时代好,在我眼中,指针就是整型,32位整型就可以当指针用。。。

以上讨论仅限汇编和C,C++ ,JAVA之类高级语言,不存在我讨论和抱怨的概念。

加载中
0
逝水fox
逝水fox
受教.也不是说高等语言就沒这问题了,Java提供了压缩指针的选项来减少内存使用,以为这就解决内存增大的问题了.没考虑到性能方面的损耗,看来还是要再测试一下.
0
中山野鬼
中山野鬼

引用来自“逝水fox”的答案

受教.也不是说高等语言就沒这问题了,Java提供了压缩指针的选项来减少内存使用,以为这就解决内存增大的问题了.没考虑到性能方面的损耗,看来还是要再测试一下.
压缩指针,实际访问,处理还是要展开的。例如最简单的一个树,或者二叉树的遍历,64位下,我只有吭哧吭哧的使用偏移量做存储,采用间接寻址方式。而不是直接寻址。无非JAVA不需要面对C要面对的实际运行问题而已。
逝水fox
逝水fox
回复 @中山野鬼 : thx,受教
中山野鬼
中山野鬼
回复 @逝水fox : 间接寻址和直接寻址,目前的CPU架构,基本上面没什么太多时间上的差异。例如 *p 和 p[5] 速度基本差不多。主要是p本身的存储位太宽了。
逝水fox
逝水fox
看你说了之后,还是要具体测试一下,给上面的报告得有测试数据才有用的。应该是多了个移位运算和加法吧。
0
CheckStyle
CheckStyle

引用来自“逝水fox”的答案

受教.也不是说高等语言就沒这问题了,Java提供了压缩指针的选项来减少内存使用,以为这就解决内存增大的问题了.没考虑到性能方面的损耗,看来还是要再测试一下.
内存占用依然是大,处理速度也降低了
CheckStyle
CheckStyle
@逝水fox 恩,这个是32位的硬伤
逝水fox
逝水fox
当初考虑64位的时候,主要是因为32位最大堆只能1.5G左右。
0
mahone
mahone
话说。。。lz到底是在哪里工作的?工作内容都是那么高深的。。。
0
中山野鬼
中山野鬼

引用来自“mahone”的答案

话说。。。lz到底是在哪里工作的?工作内容都是那么高深的。。。
面向数据挖掘,做点工具而已。。。
返回顶部
顶部