看到JUST问的64位CPU的问题，我想说一下！

tonybuaa

其实可以做个x64的PISegment来试试，看看性能有多少提升。我现在跑的就是WindowsXP x64，用了一段时间，我觉得现在WindowsXP x64可以做绝大多数x86可以做的事。应该做个调查，看看有多少用64位CPU的愿意把操作系统改为64位的，然后来决定制作x64版的PISegment是否有意义。其实装个双系也没什么吧，如果用x64的Linux我也愿意。以前学汇编的时候就看出来了，64位比32位真的省不止一两条语句，性能提升是必然的。

JUST

引用 tonybuaa 在 2006-11-4 09:54 AM 时的帖子:
其实可以做个x64的PISegment来试试，看看性能有多少提升。我现在跑的就是WindowsXP x64，用了一段时间，我觉得现在WindowsXP x64可以做绝大多数x86可以做的事。应该做个调查，看看有多少用64位CPU的愿意把操作系统 ...

我以前做过一些在win2003 64bit（比64bit XP做得好很多，64bit XP的32位子系统效率比较低）下的试验
发现VS2005在64位模式下没有__asm的功能，只能写个.asm再链接，比较麻烦
这也是没有立刻做64位版本的原因之一

64位对32位的优势有多少，没做试验前不好计算
从已知的数据上分析大概10%到20%

目前的打算是等Vista 64bit基本普及后再做

BTW，tony几系的？

tonybuaa

呵呵，12系&辅修6系，难道JUST是6系的师兄？

JUST

引用 tonybuaa 在 2006-11-4 06:13 PM 时的帖子:
呵呵，12系&辅修6系，难道JUST是6系的师兄？

12系是英语系吧

我是6系的，大四

JUST

引用 xxeitx 在 2006-11-4 06:17 PM 时的帖子:
按理说64位比32位不止10%到20%的提升
我打算在近段时间就把系统换成XP 64位的，所以想找个64位的分布式项目来计算，可是找了那么久都没找到，如果PISegment做出64位的话，我立马算这个

不好意思，至少06年是不打算做64位的版本了

JUST

引用 xxeitx 在 2006-11-4 09:37 PM 时的帖子:
没事，反正我有其它的分布式程序在运行，何况电脑也只有一台，抽不出时间啊
并且你的程序好像还没稳定吧，我的建议是等程序稳定后开发一版64位的程序，主要的精力仍可放在32位，等到有关键性问题及更新的时间再把 ...

所见略同

目前32位版还算稳定，只是在4个CPU时有疑似BUG
其实不稳定因素都来自用户交互部分，核心还是经得起考验
打算等部署后，找些这方面的牛人重写界面部分

彬彬

严格来说，现在地球上任何一个已经推向实际实用的商业化 CPU 中，没有一个是真 64 位的。

因为如大家所说的， 64 位分运算和寻址两部分，只有两部分都是 64 位的才叫真 64 位。

而当前任何一个64 位 CPU 中，最多就只是 64 位运算，并没有 64 位寻址。

但问题是，没有 64 位寻址并不是什么技术上的大难题，只是当前根本还用不上。

现在一大堆 64 位 CPU 了，但为什么即使是服务器级的，也都说明最大支持 多少多少 G 内存呢? 而这个值往往不会超过 100G。这就是 CPU 并没有完全的 64 位寻址，所以根本支持不了理论上 64 位寻址所支持的极极极极大的内存量。

再问一次，为什么不让它支持 64 位寻址呢? 因为当前还不需要，PC 用不上，服务器也用不上。PC 不用说了，小东西绝对用不上。服务器为什么还不需要呢? 那是因为，假如有软件需要在单机上动用到 64 位寻址那么大的内存空间的话，那它对 CPU 运算能力的要求同样也是极度巨大的，但现在有哪个 CPU 能达到这样的巨大? 所以，单系统上对内存的极限支持并没有什么实际意义，因为CPU性能和内存容量需要有一个平衡点，平衡点过后，内存更大，对性能的影响并不会很高。反而通过分布式的并行运算，让运算能力增加这样会更好。而用到分布式后，每一个单机系统都有一个很好的性能和内存容量的平衡点了，组成群集后性能会更强。

而此时，将一个需要超强 CPU 运算能力的运算能力需求分布到大量独立的单系统中并行运算，满足了高性能的要求，那么对总体高内存容量的要求不是也能通过分布式来达到吗? 那既然单系统中不必有这么巨大的内存容量，还有什么原因去推动厂商推出有 64 位寻址能力的 CPU 呢?

常见的 CPU 中，AMD、INTEL 的普通 CPU 不用说了。即使是 INTEL 的安腾，也并没有 64 位内存寻址，但还是比其它的位数高。


有没有 64 位寻址对性能影响是不大的，因为内核还是以 64 位运算的。寻址位数的多少只与系统支持的最大内存容量有关。

随着时间的发展，当 CPU 性能越来越强，为了将性能和内存容量这个平衡点继续维持下去，那厂商就会将 CPU 的寻址数加大的了。市场是由需求来推动的。

[ Last edited by 彬彬 on 2006-11-5 at 17:59 ]

lostking

事实说明一切,我用的是Semprom64 3000+,在  vista_64bit+Boinc5.7.0 for XP_64bit  下的速度是比  win2003+Boinc5.4.11  下的快一点,具体快多少,有待观察.

tonybuaa

引用 lostking 在 2006-11-8 13:39 时的帖子:
事实说明一切,我用的是Semprom64 3000+,在  vista_64bit+Boinc5.7.0 for XP_64bit  下的速度是比  win2003+Boinc5.4.11  下的快一点,具体快多少,有待观察.

你的Boinc 5.7.0 x64是哪儿来的？Boinc Manager也是5.7.0么？我下载了一个BOINC client version 5.7.64，但是运行起来却写着for windows_intelx86，而且Boinc Manager也是5.4.11的。

Youth

你是说基准测试的成绩吗？这个应该没太大的参考价值的

引用 lostking 在 2006-11-8 13:39 时的帖子:
事实说明一切,我用的是Semprom64 3000+,在  vista_64bit+Boinc5.7.0 for XP_64bit  下的速度是比  win2003+Boinc5.4.11  下的快一点,具体快多少,有待观察.

tonybuaa

引用 xxeitx 在 2006-11-8 21:30 时的帖子:


5.7.0 x64是在Crunch3r的主页上提供下载的，网址在这里
请问实际运算效能有提高吗？

我用的就是从这里下载的版本，然后我用5.7.0的boincmgr.exe和boinc.dll替换5.4.11的对应文件，能够很好的运行。从任务管理器中可以看出，boinc.exe的确实64位的，但是boincmgr还是32位，而且最关键的是，似乎还没有什么项目是支持64位的，所以boinc平台用64位也没什么意义，速度不会有什么差别。