- 第 1 页 -
大内存(>=4GB)和64位系统讨论
最近看到不少帖子讨论大内存和64位系统/音频软件，我说一下自己理解
现在大家普遍用的32位系统，包括32位OS，CPU和应用程序，所谓32位，主要是寻址能力
32位系统下，一个内存指针长32个bit，2^32=4294967296=4GB，也就是说32位指针最多可以访问4GB内存
而大多数的系统设备，比如IDE/SATA/RAID控制器，网卡，声卡等，也是32位，有些用DMA直接访问内存的设备，比如硬盘，也只能访问最多4GB内存
但以上这个限制只是理论值，实际最大内存还要看操作系统，比如XP 32位版里每个应用程序最多可以使用2GB内存，如果在boot.ini中打开3GB模式的话，可以最多使用3GB
而之前看到黑毛前辈的帖子"winxp-64单进程内存使用极限测试。"中提到内存使用3.75GB时(3GB物理内存)系统报警，并且反映迟缓，原因是内存需求超过物理内存时，系统开始不断换页(paging，把物理内存里不用的内容写到硬盘交换文件上)，大量的硬盘访问造成的。而且这个3.75GB使用量，也不是Cubase一个进程吧？应该还有很多系统进程和后台进程。没有理解错的话Cubase使用的内存量应该不会超过2GB的
现在出来64位系统了，包括使用AMD 64或Imtel EM64T技术的处理器，这些处理器可以同时运行32位和64位的应用程序。
如果使用64位内存指针，理论上的最大内存是2^64(16 exabyte，很大的一个数目哦)，不过只有专为64位设计的应用程序(我知道有x64版的Sonar，官方说支持1024GB内存)才可能享受这个待遇。不过根据Cakewalk FAQ，Sonar x64版要求插件必须是64位，其中DX,DXi的设计就是支持64位，所以所有这些插件可以继续使用，而32位的VST，VSTi就无法继续用了
如果在64位系统中运行旧的32位程序，比如Cubase，那仍然只能访问2GB内存，因为程序的二进制代码还是32位的，对那些应用程序，64位版操作系统不会带来任何提升
而且64位系统还有诸多其他限制，比如驱动程序要求都是64位
另外一个假象是用户以为CPU，操作系统，驱动都是64位的，就算是完全的64位系统了，其实不然，因为其他硬件设备也有32位和64位的分别
据个例子，很多版载的SATA RAID控制器就是32位的。我们这里几十台Opteron服务器，主板是大厂TYAN的服务器版，用AMD芯片组，但是版载的Silicon Image 3114 SATA RAID芯片就是32位的。
有什么影响呢？之前说过硬件设备通过DMA直接访问内存的话受到32位指针影响，也就是说32位的RAID控制器只能访问4GB内存
当内存超过4GB时需要通过一种叫IOMMU的技术做映射(AMD64独有，Intel EM64T不支持，需要操作系统软件方法完成)，具体做法是从4GB范围内专门分配一部分内存给32位设备叫做Aperture。当这些设备需要访问超过4GB的内存时就先写到这个Aperture里面，然后再复制到超过4GB的内存里。不过因为像RAID之类的设备通常数据流量非常大，这个Aperture会占用很多内存。而且反复的内存复制操作也会影响性能
我们这里做过试验，双Opteron，6GB内存，分配每个CPU 1GB Aperture，导致只有4GB可用内存，仍然会出现IOMMU不够用的错误。
结论是，连价格昂贵的高端服务器主板都使用廉价组件(市场上一般SATA RAID卡几百元一张，而标明64位PCI的卡超过两千)，民用主板就不用说了。
不过现在用超过4GB内存的个人用户屈指可数，所以大家都没想到这个问题吧
最后个人意见，64位系统，还有很长路要走
开放源码的系统，比如Linux，因为可以方便地将应用程序重新编译成64位代码，可能会快Windows一步
Windows用户，就只能干等软件厂商跟进了
现在大家普遍用的32位系统，包括32位OS，CPU和应用程序，所谓32位，主要是寻址能力
32位系统下，一个内存指针长32个bit，2^32=4294967296=4GB，也就是说32位指针最多可以访问4GB内存
而大多数的系统设备，比如IDE/SATA/RAID控制器，网卡，声卡等，也是32位，有些用DMA直接访问内存的设备，比如硬盘，也只能访问最多4GB内存
但以上这个限制只是理论值，实际最大内存还要看操作系统，比如XP 32位版里每个应用程序最多可以使用2GB内存，如果在boot.ini中打开3GB模式的话，可以最多使用3GB
而之前看到黑毛前辈的帖子"winxp-64单进程内存使用极限测试。"中提到内存使用3.75GB时(3GB物理内存)系统报警，并且反映迟缓，原因是内存需求超过物理内存时，系统开始不断换页(paging，把物理内存里不用的内容写到硬盘交换文件上)，大量的硬盘访问造成的。而且这个3.75GB使用量，也不是Cubase一个进程吧？应该还有很多系统进程和后台进程。没有理解错的话Cubase使用的内存量应该不会超过2GB的
现在出来64位系统了，包括使用AMD 64或Imtel EM64T技术的处理器，这些处理器可以同时运行32位和64位的应用程序。
如果使用64位内存指针，理论上的最大内存是2^64(16 exabyte，很大的一个数目哦)，不过只有专为64位设计的应用程序(我知道有x64版的Sonar，官方说支持1024GB内存)才可能享受这个待遇。不过根据Cakewalk FAQ，Sonar x64版要求插件必须是64位，其中DX,DXi的设计就是支持64位，所以所有这些插件可以继续使用，而32位的VST，VSTi就无法继续用了
如果在64位系统中运行旧的32位程序，比如Cubase，那仍然只能访问2GB内存，因为程序的二进制代码还是32位的，对那些应用程序，64位版操作系统不会带来任何提升
而且64位系统还有诸多其他限制，比如驱动程序要求都是64位
另外一个假象是用户以为CPU，操作系统，驱动都是64位的，就算是完全的64位系统了，其实不然，因为其他硬件设备也有32位和64位的分别
据个例子，很多版载的SATA RAID控制器就是32位的。我们这里几十台Opteron服务器，主板是大厂TYAN的服务器版，用AMD芯片组，但是版载的Silicon Image 3114 SATA RAID芯片就是32位的。
有什么影响呢？之前说过硬件设备通过DMA直接访问内存的话受到32位指针影响，也就是说32位的RAID控制器只能访问4GB内存
当内存超过4GB时需要通过一种叫IOMMU的技术做映射(AMD64独有，Intel EM64T不支持，需要操作系统软件方法完成)，具体做法是从4GB范围内专门分配一部分内存给32位设备叫做Aperture。当这些设备需要访问超过4GB的内存时就先写到这个Aperture里面，然后再复制到超过4GB的内存里。不过因为像RAID之类的设备通常数据流量非常大，这个Aperture会占用很多内存。而且反复的内存复制操作也会影响性能
我们这里做过试验，双Opteron，6GB内存，分配每个CPU 1GB Aperture，导致只有4GB可用内存，仍然会出现IOMMU不够用的错误。
结论是，连价格昂贵的高端服务器主板都使用廉价组件(市场上一般SATA RAID卡几百元一张，而标明64位PCI的卡超过两千)，民用主板就不用说了。
不过现在用超过4GB内存的个人用户屈指可数，所以大家都没想到这个问题吧
最后个人意见，64位系统，还有很长路要走
开放源码的系统，比如Linux，因为可以方便地将应用程序重新编译成64位代码，可能会快Windows一步
Windows用户，就只能干等软件厂商跟进了
感谢楼主这么详尽的解释。
我测试中的3.75G内存占用，除了Cubase这一个进程之外，其余的一共占用了大约240M左右吧。（新装的系统，非常干净）
我今天已经将工作环境全部部署完毕，完全工作在64BIT系统中了。所有的驱动就只差MOTU midi接口了。我查了一下，目前好像只有罗兰接口有64BIT驱动。但我现在主要是用软件音源，所以问题不大。
Steinberg宣称，3系列的Cubase/Nuendo是完全支持64BIT的。
我用的就是TYAN的服务器版，版载Silicon Image 3114 SATA RAID芯片，性能上没有苛刻的去跟SCSI RAID比较过，CPU占用率肯定是不会太节省。不过，SCSI RAID实在是太贵了。
说“64位系统，还有很长路要走”，我不太同意，因为我已经正式用于工作了。
我测试中的3.75G内存占用，除了Cubase这一个进程之外，其余的一共占用了大约240M左右吧。（新装的系统，非常干净）
我今天已经将工作环境全部部署完毕，完全工作在64BIT系统中了。所有的驱动就只差MOTU midi接口了。我查了一下，目前好像只有罗兰接口有64BIT驱动。但我现在主要是用软件音源，所以问题不大。
Steinberg宣称，3系列的Cubase/Nuendo是完全支持64BIT的。
我用的就是TYAN的服务器版，版载Silicon Image 3114 SATA RAID芯片，性能上没有苛刻的去跟SCSI RAID比较过，CPU占用率肯定是不会太节省。不过，SCSI RAID实在是太贵了。
说“64位系统，还有很长路要走”，我不太同意，因为我已经正式用于工作了。
前辈客气了，我因为平时工作相关，而且又有感兴趣，才提出来探讨
关于内存占用，操作系统自己的一些进程和系统缓存应该也占用不少内存，这些资源管理器进程表里面不会显示的
另外，我想问Cubase一个进程占用了多少？因为理论上这是个32位程序，应该还有2GB限制，原因如下
在32位模式下内存指针一共可以访问4GB，XP 32位版的虚拟内存限制，操作系统保留2GB自己用，2GB给应用程序
微软的文件说某些32位程序(支持"Large Address Aware")可以用boot.ini中的/3GB选项开启3GB支持，不知道Cubase算不算其中
另外有文件说在XP x64下这些程序可以支持到最多4GB，也就是完全利用32个bit的内存指针，可惜我没有条件考证
Steinberg宣称的没错，不过支持64-bit和为64-bit优化还是有差别的
照理说按照AMD 64的设计，32-bit应用程序绝大多数可以直接在64-bit下面运行，只不过这样无法享受64-bit的好处，比如更多内存，64位优化指令，和更多更大的寄存器
如果他们推出64-bit代码版本的Cubase，代价是现有的32位VST全都没法用了，必须等其他厂商也跟进
TYAN这个SIL3114芯片我查资料说其实是软RAID，校验之类RAID相关运算是通过驱动在CPU上执行的，对CPU一定有影响
我们这里的服务器，磁盘I/O大的时候文件系统进程占用近100%
而高档卡通常都自带运算芯片和缓存，毕竟一分价钱一分货，TYAN这样大概做也是考虑到用SATA RAID的用户一般不会用超过4GB内存，32-bit PCI设备就够了，不然就用SCSI RAID了
说还有很长路要走，抱歉我没说清楚
我觉得这是XP x64版做音频应用相对于其他OS和应用领域来说的
比如Linux做科研，网络，数据库等，因为Linux软件通常开放源码，用户自己重新编译就可以享用64-bit的好处
我们这里的Opteron群集，原来用32位系统有2GB限制，而工作经常要处理数GB数据，写程序经常内存不够用
换了64位系统，因为软件是自己写的，重新编译一下就解决了，性能也有提升
而大多Windows软件，特别是音频软件，就只有等厂商更新
另外由于32和64位代码无法混用(出现在一个进程里面)，加上不同厂商推出64位更新进度不同，会造成很多不便
比如64位DAW没法用32位插件，64位媒体播放器没法用32位解码器，64位浏览器没法用32位Flash插件等等
[ 本帖最后由 sinisa 于 2006-4-22 07:03 编辑 ]
关于内存占用，操作系统自己的一些进程和系统缓存应该也占用不少内存，这些资源管理器进程表里面不会显示的
另外，我想问Cubase一个进程占用了多少？因为理论上这是个32位程序，应该还有2GB限制，原因如下
在32位模式下内存指针一共可以访问4GB，XP 32位版的虚拟内存限制，操作系统保留2GB自己用，2GB给应用程序
微软的文件说某些32位程序(支持"Large Address Aware")可以用boot.ini中的/3GB选项开启3GB支持，不知道Cubase算不算其中
另外有文件说在XP x64下这些程序可以支持到最多4GB，也就是完全利用32个bit的内存指针，可惜我没有条件考证
Steinberg宣称的没错，不过支持64-bit和为64-bit优化还是有差别的
照理说按照AMD 64的设计，32-bit应用程序绝大多数可以直接在64-bit下面运行，只不过这样无法享受64-bit的好处，比如更多内存，64位优化指令，和更多更大的寄存器
如果他们推出64-bit代码版本的Cubase，代价是现有的32位VST全都没法用了，必须等其他厂商也跟进
TYAN这个SIL3114芯片我查资料说其实是软RAID，校验之类RAID相关运算是通过驱动在CPU上执行的，对CPU一定有影响
我们这里的服务器，磁盘I/O大的时候文件系统进程占用近100%
而高档卡通常都自带运算芯片和缓存，毕竟一分价钱一分货，TYAN这样大概做也是考虑到用SATA RAID的用户一般不会用超过4GB内存，32-bit PCI设备就够了，不然就用SCSI RAID了
说还有很长路要走，抱歉我没说清楚
我觉得这是XP x64版做音频应用相对于其他OS和应用领域来说的
比如Linux做科研，网络，数据库等，因为Linux软件通常开放源码，用户自己重新编译就可以享用64-bit的好处
我们这里的Opteron群集，原来用32位系统有2GB限制，而工作经常要处理数GB数据，写程序经常内存不够用
换了64位系统，因为软件是自己写的，重新编译一下就解决了，性能也有提升
而大多Windows软件，特别是音频软件，就只有等厂商更新
另外由于32和64位代码无法混用(出现在一个进程里面)，加上不同厂商推出64位更新进度不同，会造成很多不便
比如64位DAW没法用32位插件，64位媒体播放器没法用32位解码器，64位浏览器没法用32位Flash插件等等
[ 本帖最后由 sinisa 于 2006-4-22 07:03 编辑 ]
双核，多核，以及多处理器方面，牵涉到很多软件内部实现的细节
而各大DAW厂商，通常都是宣称支持多核，很少有提供技术细节或性能测试结果
所以要我说多核的作用，其实也说不上啥，以下都是根据我对多线程技术的理解和我自己猜测
首先要搞清楚，操作系统处理多个进程的原理
以前的单CPU电脑，一次只能运行一个程序，要同时运行多个进程，操作系统会不停切换使用CPU的进程，使每个进程得到一部分CPU时间
而由于切换速度很快，只要不是很大系统负荷，一般用户不会察觉切换的过程
那个时代的程序，通常以一个进程运行，现在放到多处理器的电脑上运行，在他的生命周期里面，也不可能同时在两个CPU上运行。唯一的区别是，在单处理器系统上，这个进程要和其他进程共享一个CPU，而在多处理器系统上，其他进程可以使用空闲的CPU，使这个进程减少被切换出CPU的机会。
所以经常听到的误解，以为两个CPU，程序的运行时间自动变成原来的一半，4个的话变成1/4，这样的理解是不对的
原来设计成单进程的程序，在100个CPU系统上运行和在一个同样CPU系统上运行没有太大差别
现代操作系统还区别进程(process)和线程(thread)的概念
两个都是不同程序代码共享CPU的单元，都可以通过OS的切换分到CPU时间
区别是每个进程在内存里有独立的数据空间，而一个进程可能有一个或多个线程，这些线程共享同一段数据空间
举个例子，一个数据库程序，读了500MB数据到内存里，然后建立5个线程服务不同用户，这五个线程就可以共享500MB数据，不需要重复读五次
如果拿DAW举例子，有可能就是一个DAW读了一个500MB的project到内存里，整个project用了50个插件，理论上DAW可以建立50个线程，一个插件用一个
那样这些插件就可以通过操作系统的多线程机制同时在不同CPU上运行，但实际上DAW不会这样做，原因是
首先进程越多，用在计算进程切换上的CPU资源也不少
其次，有些运算必须要顺序执行的，比如一个轨上的两个插件，第二个一定要等第一个完成才能运算，他们无论如何没法同时运行
还有就是，很多线程的话，操作系统调度不一定能保证他们能同时完成。比如DAW每个轨取了1ms音频处理，最快完成的线程就要等到最后一个完成才能混合播放出来
根据以上推论，我觉得以前的DAW处理插件运算，还是每个轨取很小一段sample，在一个进程里循环每个插件运算，再将处理过的信号混合
而现在很多DAW开始支持多核心
我自己用的Nuendo有一个Multi-Processing的选项，Pro Tools M-Powered 7可以选择用1或2个CPU处理RTAS
我的推测是DAW内部会建立数个线程，每个对应一个处理器，然后将没有依赖关系的插件放到不同线程里运算，可能还要估计不同插件的运算量来调度，这种做法能最好利用多处理器
不过以上这些只对实时效果有用。非实时的破坏性处理，比如Pro Tools里AudioSuite，因为只运算一个插件，是没法同时在多个CPU上运行的，所以性能也不会有很大提升
结论就是双核，多核做音频应用，还是依赖音频软件内部的算法
要是各位有兴趣的话，我们可以组织一些测试，考察多核心在各个DAW里面的效能
而各大DAW厂商，通常都是宣称支持多核，很少有提供技术细节或性能测试结果
所以要我说多核的作用，其实也说不上啥，以下都是根据我对多线程技术的理解和我自己猜测
首先要搞清楚，操作系统处理多个进程的原理
以前的单CPU电脑，一次只能运行一个程序，要同时运行多个进程，操作系统会不停切换使用CPU的进程，使每个进程得到一部分CPU时间
而由于切换速度很快，只要不是很大系统负荷，一般用户不会察觉切换的过程
那个时代的程序，通常以一个进程运行，现在放到多处理器的电脑上运行，在他的生命周期里面，也不可能同时在两个CPU上运行。唯一的区别是，在单处理器系统上，这个进程要和其他进程共享一个CPU，而在多处理器系统上，其他进程可以使用空闲的CPU，使这个进程减少被切换出CPU的机会。
所以经常听到的误解，以为两个CPU，程序的运行时间自动变成原来的一半，4个的话变成1/4，这样的理解是不对的
原来设计成单进程的程序，在100个CPU系统上运行和在一个同样CPU系统上运行没有太大差别
现代操作系统还区别进程(process)和线程(thread)的概念
两个都是不同程序代码共享CPU的单元，都可以通过OS的切换分到CPU时间
区别是每个进程在内存里有独立的数据空间，而一个进程可能有一个或多个线程，这些线程共享同一段数据空间
举个例子，一个数据库程序，读了500MB数据到内存里，然后建立5个线程服务不同用户，这五个线程就可以共享500MB数据，不需要重复读五次
如果拿DAW举例子，有可能就是一个DAW读了一个500MB的project到内存里，整个project用了50个插件，理论上DAW可以建立50个线程，一个插件用一个
那样这些插件就可以通过操作系统的多线程机制同时在不同CPU上运行，但实际上DAW不会这样做，原因是
首先进程越多，用在计算进程切换上的CPU资源也不少
其次，有些运算必须要顺序执行的，比如一个轨上的两个插件，第二个一定要等第一个完成才能运算，他们无论如何没法同时运行
还有就是，很多线程的话，操作系统调度不一定能保证他们能同时完成。比如DAW每个轨取了1ms音频处理，最快完成的线程就要等到最后一个完成才能混合播放出来
根据以上推论，我觉得以前的DAW处理插件运算，还是每个轨取很小一段sample，在一个进程里循环每个插件运算，再将处理过的信号混合
而现在很多DAW开始支持多核心
我自己用的Nuendo有一个Multi-Processing的选项，Pro Tools M-Powered 7可以选择用1或2个CPU处理RTAS
我的推测是DAW内部会建立数个线程，每个对应一个处理器，然后将没有依赖关系的插件放到不同线程里运算，可能还要估计不同插件的运算量来调度，这种做法能最好利用多处理器
不过以上这些只对实时效果有用。非实时的破坏性处理，比如Pro Tools里AudioSuite，因为只运算一个插件，是没法同时在多个CPU上运行的，所以性能也不会有很大提升
结论就是双核，多核做音频应用，还是依赖音频软件内部的算法
要是各位有兴趣的话，我们可以组织一些测试，考察多核心在各个DAW里面的效能
太好了，让人受益匪浅的讨论
Cubase以32bit兼容模式运行，这一点是肯定的，因为以前32bit插件都运行正常，同时，进程中也写得很清楚。而且，“看门狗”的驱动也是32bit的。
目前的实际意义是：32bit winxp中，Cubase无法调用超过大约1.7GB的内存，但在64bit winxp中就可以用到3.4GB。原来的瓶颈不是运算性能，而是单进程内存使用。使用大量软件音源的人都会深有感触，当CPU资源仅用到60%左右的时候，就有可能因为内存调用超过1.7GB而无法继续加载其他插件。64bit winxp就解决大问题了。
另外请sinisa讲一讲，为什么64bit系统中运行的驱动实际上是32bit的，但原来的32bit驱动却不能正常安装使用，非要新的64bit驱动？
还有，请sinisa推荐一个察看详细子进程的工具软件。
附上两张图
Cubase以32bit兼容模式运行，这一点是肯定的，因为以前32bit插件都运行正常，同时，进程中也写得很清楚。而且，“看门狗”的驱动也是32bit的。
目前的实际意义是：32bit winxp中，Cubase无法调用超过大约1.7GB的内存，但在64bit winxp中就可以用到3.4GB。原来的瓶颈不是运算性能，而是单进程内存使用。使用大量软件音源的人都会深有感触，当CPU资源仅用到60%左右的时候，就有可能因为内存调用超过1.7GB而无法继续加载其他插件。64bit winxp就解决大问题了。
另外请sinisa讲一讲，为什么64bit系统中运行的驱动实际上是32bit的，但原来的32bit驱动却不能正常安装使用，非要新的64bit驱动？
还有，请sinisa推荐一个察看详细子进程的工具软件。
附上两张图
[quota]另外请sinisa讲一讲，为什么64bit系统中运行的驱动实际上是32bit的，但原来的32bit驱动却不能正常安装使用，非要新的64bit驱动？[/quota]
这句话我不太理解，是不是说那个Steinberg USB狗？
正版的用户用原来32-bit的驱动可以在XP x64上面用，而用H2O狗的就不行？
我看到的消息是说Syncrosoft推出了64位驱动，你那个是32位的？
那个SYNSOPOS.EXE是一个进程，不是驱动。驱动都是由kernel加载的，必须和kernel一样都是64bit
我看到你装了Daemon-Tools，应该是x64版的吧？道理和dongle应该差不多的，真的CD-ROM的话，32/64位系统都可以直接支持，不需要驱动。但是用软件模拟，就必须用驱动的形式，一般应用程序做不到(无法访问kernel space)，而做成驱动了就有32/64bit的讲究
至于察看进程，我的系统很干净，负荷也不大，所以一般用用Windows自带的就够了
你图里那个看上去很不错啊
这句话我不太理解，是不是说那个Steinberg USB狗？
正版的用户用原来32-bit的驱动可以在XP x64上面用，而用H2O狗的就不行？
我看到的消息是说Syncrosoft推出了64位驱动，你那个是32位的？
那个SYNSOPOS.EXE是一个进程，不是驱动。驱动都是由kernel加载的，必须和kernel一样都是64bit
我看到你装了Daemon-Tools，应该是x64版的吧？道理和dongle应该差不多的，真的CD-ROM的话，32/64位系统都可以直接支持，不需要驱动。但是用软件模拟，就必须用驱动的形式，一般应用程序做不到(无法访问kernel space)，而做成驱动了就有32/64bit的讲究
至于察看进程，我的系统很干净，负荷也不大，所以一般用用Windows自带的就够了
你图里那个看上去很不错啊