- 第 3 页 -
kb_in_Deutschla 发表于 15-9-18 03:52
小兄弟真实在是电脑盲啊！
CPU从来就只有运算速度，如果CPU出现运算不精，你以为是在打算盘珠子哪？
所 ...
这根本就不是电脑基础知识,如果我猜的没错的话你可能是计算机专业毕业的,要不绝不会这么说,我在音频帮的群里就有上大学学计算机专业的,可能还有学过编程的,他们都搞不太明白,经过讨论才达成一致意见的!就算专业学过,不查查资料就敢说全明白,我觉得那是吹牛!
kb_in_Deutschla 发表于 15-9-18 03:57
就借此机会学学英语好么？
人们一般在网上讨论非基础理论的话题。
我不是说不会用翻译软件,关键英语水平有限,翻译软件难免翻译错误,如果谁英语好,翻译速度也会很快,质量还高,翻译过来不是更好吗,而且这也是做好事,大家也都能受益.我用翻译软件昨天下午加今天一天也翻译的差不多了,再仔细检查检查,没问题就发出来!
佐佐木史朗 发表于 15-9-19 18:30
建议LZ把思路重新梳理一遍，用相对更准确的用词说一下你的想法。现在完全不知道LZ到底想说什么。
LZ试试 ...
发完贴过一段时间就不能修改了,等我仔细检查没什么问题再发.
本帖最后由 wstsw888 于 15-9-22 19:44 编辑
https://www.meldaproduction.com/audiotutorials/32vs64.php 链接翻译
32-BIT VS. 64-BIT随着廉价的多核处理器和利用他们力量的最新操作系统的随后到来，越来越多的人需求64位系统和应用程序。但我们中有多少人真正理解64位意味着什么?
我们试图通过找寻每个系统的优缺点来清理混乱。
内存
让我们先来解释内存的基础。 RAM（随机存取存储器）是一种非常快的存储器，其用于存储所有当前正在运行的应用程序和所需要的相关联的数据。在我们的例子中，这将涉及到音频数据块，DAW软件及相关程序，虚拟乐器和采样等，如果用没有足够的RAM内存来存储所有这些数据，O / S（操作系统），它可以“交换”它的一部分到硬盘驱动器并在需要时加载它回到内存中。但是，这种交换是有代价的 - 速度。
RAM不是计算机中最快的存储器，实际上它相对于处理器速度比较慢。首先出现的是“高速缓冲”存储器，这是类似RAM，但是较接近CPU。而RAM通过电线被连接到许多厘米长的CPU，称为“系统总线”，高速缓存存储器通常在CPU本身内部集成。不幸的是，它也比RAM更昂贵，所以一般仅仅有几兆批次的提供。高速缓存位于CPU和RAM之间，所以寻找数据时，处理器先访问高速缓存，仅当它需要的信息不存在时才访问RAM。
最快的内存在计算机被称为“注册”，这实际上与CPU本身是一样快。大部分的工作是在它里面做，但它的大小是不以GB，兆字节，甚至千字节计。你只有几百字节，实际数量由CPU架构定义。
你真的需要更多的内存？
32位系统可以处理高达约3GB内存。这种限制必须满足整个系统和所有运行的应用程序，否则某些东西会被换。此外，还有另一种限制对不同的应用程序 - 通常2GB。这3GB的限制仍然显得大方，但除了实际取样也将包含所有可执行文件和临时文件等。在所有这些都考虑在内，你可能有大约1.5GB的自由内存为您的工程。
难道这还不够？它通常是，所以让我们来看看一个大的音频工程的例子。比方说，我们的工程需要3GB的内存。这1GB将由可执行文件和临时结构使用，因此实际上已失去。剩下2GB包含的数据从硬盘驱动器加载。这个数据通常是压缩的，因此我们可以预计，使用无损音频压缩和随机存取所需的结构，我们需要从磁盘加载约1GB。虽然现代的硬盘使用分段和同步操作已经成很快了，最快的加载速度的合理估计将约为每秒50MB。因此，加载所有的数据将需要20秒。添加到这样的时间来计算临时结构，甚至用8核处理器，这将需要25秒加载。
25秒加载一个工程！你真的要等那么久？好了，有时你没有选择，但这种情况确实凸显了使用这么多内存的缺点。
为什么会有64位架构开发？
坦率地说，不是为了音频。其主要发展原因是为了满足来自服务器的不断增长的需求。D.A.W.程序处理音频时基本上是独享的主程序，而服务器一次处理数百个使用兆兆位级数据库的请求。他们在实际上还访问数据以随机的顺序，因此，有必要保持尽可能多的数据在内存中可用。
现在，64位处理器已经被开发用于服务器，为什么不在其他应用程序中也使用它们呢？早在16位架构的日子，对于开发人员来说，内存是一个主要问题。随着32位系统的到来，速度成为了优先考虑，所以我们开始浪费内存，直到最后的极限为止。随着64位计算机的出现，同样的情况再次发生。所以，现在，我们需要大量的内存用于音频，视频，游戏等...
你需要转到64位？这是可能的，5年之内的大多数计算机将运行64位操作系统，因此大部分的应用程序也将是64位的。到那时，你能管住自己不升级吗？我们将介绍下面的一些关键细节，以帮助您决定。
你需要做什么“是64位”？
首先你需要一个64位兼容的处理器，几乎所有的它们都是64位的，在今天。除了基于“安腾”处理器的高端服务器（你可能不会遇到），所有的它们都同时向下兼容32位架构，所以笔记本运行着64位处理器安装着32位操作系统并不罕见。其次，你需要一个64位操作系统，视窗XP / Vista/7/8和Mac OS10.6现在都有64位的。接下来，您需要64位应用程序。这就让它变得更复杂了，因为许多宿主都只有32位。如果您在64位操作系统运行32位应用程序，CPU被切换到32位模式下，只有极小的性能下降，我们会在后面论述。
最后，你还需要64位插件。嗯，这不完全是这样。当开发者转换到64位宿主上，他们无法立即发布他们，因为人们仍然需要使用他们的插件，这些插件在64位平台上用不了。为了解决这个问题，他们不得不开发所谓的'桥梁'先。桥是运行在特别的插件和宿主之间的单独的应用程序。如果宿主需要用这个插件，它创建一个请求，该系统调度器切换到桥梁。这个桥实际上要求插件进行操作，然后将数据返回给宿主。相当复杂，不是吗？
用桥一切都变得更加复杂，更慢和更不可靠。因此，我强烈建议，如果没有其他的选择才使用桥梁。如果你的插件大多仅用于32位，并且你没有耗尽内存，那么建议是继续用32位宿主，即使宿主本身可作为64位。
金科玉律是 - 如果您使用的是32位宿主，使用32位插件。如果使用64位宿主，使用64位插件。
X32 VS. X64
现在，我们终于可以谈及32位与64位架构的问题。对于本教程的目的，我们不会考虑16位平台，因为他们基本上已经过时（甚至洗衣机现在使用32位处理器！）。
我们也将使用x64位标识符，用于指称64位架构，同样x32指称32位架构。
DOES X64提高音频质量？
不，x64是64位处理器内部工作的方式。它无关于实际计算。例如，处理音频往往需要乘法，所以处理器包含几个'乘法'单元并在需要时使用它们。不管它是在32位或64位模式，它最终将使用相同的单元，以得到正确的结果。
不要切换到x64，因为你想要你的音乐听起来更好！
内存
毫无疑问，x64可以利用更多的内存，毕竟，这是它的发展的原因。但是，使用这种额外的内存有效？
一切都更大
首先，x64的代码比x32代码大得多。由代码我们指的是可执行文件，和用于处理器的指令。按理说因此有理由相信，您的应用程序本身也会更大，而且因为他们需要保留在内存中（虽然这是略有简化），他们将占据更多的空间。你可能还记得，高速缓存快但是小，而RAM是慢和大。因此，一个应用程序运行时，它是从内存加载到缓存。然而，代码更大了，它可以放入高速缓存的就较少，所以它必须不断重新加载！
用64位，你还需要8个字节来唯一地标识内存中的任何地方，被称为“地址”，而使用x32，一个地址只能有4个字节。这种差异可能看起来微不足道，但现代的应用程序都包含大量的地址。因此再一次的，使用x64系统，在你的处理上你有了更多的内存，但你也必须用得更多。
最后，x64处理器需要的东西是“64位对齐”，这意味着如果一些东西，一个数字为例，实际上是小于8个字节，它会被四舍五入为使用8个字节不管。这使得处理更快，但再一次，我们已经浪费了一些内存。
虚拟地址空间
下一个问题涉及多一点，可能会有点难以理解。
现代操作系统使用'虚拟地址空间'。当一个应用程序正在访问内存的一部分，因为技术原因，它实际上并不知道寻址内存的哪一部分。只有操作系统和处理器保持该信息。我们可以把“页面交换“作为一个例子。当没有足够的内存可供应用程序使用时，系统定位坐落在内存并一段时间没有被使用的东西，将其移动到硬盘，并把该内存给予应用程序。这几乎可以发生在内存的任何部分,甚至有可能每一次应用程序接触数据时，它被存储在不同的位置！因此，所有内存中的数据都会逐渐变得更加分散，但CPU如何知道每个地址意味着什么？
在x32的系统中，有一个这些内存地址的小的数据库，并且CPU和系统二者知道其结构。所以每次系统需要访问内存，它都会在数据库中查看，并且知道数据实际在哪里。如果数据不存在于内存中，因为操作系统已经把它‘交换’到了硬盘上，那么它将产生一个中断，并且操作系统会修复它。
在x64的情况复杂得多。 64位空间仅仅是太大而不能存储在一个小型数据库，所以设计者不得不使用另一种方式。其结果是要使用一些所谓的“TLB”（转换后备缓冲器 a translation lookaside buffer)，这是一个小的哈希表，其作用就像一个高速缓存。 TLB中只包含最近使用的地址，所以每一次地址在里面没有被发现，中断必须被产生来强制操作系统进行修复。一方面，访问TLB比访问分布在x32的系统中的小型数据库更快，但中断更加频繁，并且中断都需要相当大量的处理能力。
性能和CPU功能
x64系统还提供了一些新的功能，虽然其中的一些被强制使用64位平台上的大内存，但还有更多的是在X32之上提供的改进。
总体OS的性能
操作系统使用相同的CPU功能为应用程序。在Windows，我切换到64位时，没有发现任何性能的改善或恶化，虽然加载可能比较慢，因为系统比较大。因为Windows7和8，你可以从一个单一的DVD同时安装x32和x64版本，你可以自己试试这个。
使用Mac OS X似乎10.6（64位）是快于10.5（32位）。但是在Mac OS X性能上的大的变化，也随着时间的推移被注意到，这可能是由系统造成的越来越凌乱和逐步更加支离破碎。如果你注意到性能逐渐退化，一个可能的解决方案或许是重新安装操作系统。除此之外，有可能使用10.6比10.5系统资源稍好。
寄存器
x64架构比与它对应的x32有更多的寄存器，因为所有的计算都是在寄存器内部进行的，从理论上说，更多会更好。但是，如果你正运行在32位模式下，即使是一个64位处理器，它仍然只能使用x32的寄存器组。此外，在运行x64时，编译器生成的应用程序代码必须小心地分配和使用寄存器，这并不简单。因此看来，尽管有更大的寄存器组存在，通常有很少或没有性能提升。
调用约定
试想象现代应用程序作为黑盒子的巨大模块需要彼此交谈。他们的通信方式是通过一个预先定义的通信协议，以使黑盒子相互理解。此协议称为“调用约定”。
例如，一个插件的前端'GUI'（图形用户接口），是由一个绘制它的黑盒子创建的。现在，这个黑盒子可能要求另一个黑盒子绘制线条，因此每次需要画线时，它必须发送指令给另一个黑盒子它需要画什么样的线。这就是调用约定。
虽然x32大多数数据已通过内存传输，在x64这是非常低效的，所以如果可能的话使用寄存器完成这个任务。那当然速度要快得多。
在X64上运行32位应用程序
正如前面提到的,在一切都可作为64位之前,要花一段时间,尤其是在苹果平台上。在此之前,这是不可避免的,有时我们需要运行一些32位应用程序。问题是,这是一个问题吗?
如果我们看一下当32位应用程序运行在x64时会发生什么，我们看到CPU切换到所谓的32位兼容模式下，它表现为任何的32位处理器。然而该系统不断地在很多应用程序之间切换，大约每秒数千次。这种切换被称为“调度”。每次调度器从一个应用程序切换到另一个，它也需要在x64和x32之间来回地切换CPU模式，这将不可避免地需要一定的时间。虽然到目前为止，这个额外的时间似乎可以忽略不计。
另一个考虑是，每个应用程序需要调用操作系统，因为它需要从它使用一些服务。但因为操作系统是64位的，这些调用必须首先从32位转换到64位，然后通过“分配器”运行。幸运的是，这目前似乎没有造成任何显著的开销。
得出的结论是，在64位操作系统运行32位应用程序，这是完全没有问题的。如果有任何减速确实发生，这将是极小的。
结论
x64拥有超过x32几个优点，但也有一些问题需要注意。当涉及到性能，他们没有太大的区别。 一个64位系统，不管怎样可以访问你的所有内存，这应该是让你做出切换到64位的唯一原因。当使用64位宿主，你也应该使用x64的插件，反之亦然。 x64和音频质量无关。在64位操作系统运行32位应用程序，这是完全没有问题的。
现在，我们已经介绍了主要的区别，你是否希望或确实需要作出这样的转变，由你来做出更明智的决定。
------------------------------------------------------------------------------------------------------------
本人英语水平有限,借助网页翻译,费挺大个劲,但也就这水平了,希望对英语不好的朋友有帮助!
https://www.meldaproduction.com/audiotutorials/32vs64.php 链接翻译
32-BIT VS. 64-BIT随着廉价的多核处理器和利用他们力量的最新操作系统的随后到来，越来越多的人需求64位系统和应用程序。但我们中有多少人真正理解64位意味着什么?
我们试图通过找寻每个系统的优缺点来清理混乱。
内存
让我们先来解释内存的基础。 RAM（随机存取存储器）是一种非常快的存储器，其用于存储所有当前正在运行的应用程序和所需要的相关联的数据。在我们的例子中，这将涉及到音频数据块，DAW软件及相关程序，虚拟乐器和采样等，如果用没有足够的RAM内存来存储所有这些数据，O / S（操作系统），它可以“交换”它的一部分到硬盘驱动器并在需要时加载它回到内存中。但是，这种交换是有代价的 - 速度。
RAM不是计算机中最快的存储器，实际上它相对于处理器速度比较慢。首先出现的是“高速缓冲”存储器，这是类似RAM，但是较接近CPU。而RAM通过电线被连接到许多厘米长的CPU，称为“系统总线”，高速缓存存储器通常在CPU本身内部集成。不幸的是，它也比RAM更昂贵，所以一般仅仅有几兆批次的提供。高速缓存位于CPU和RAM之间，所以寻找数据时，处理器先访问高速缓存，仅当它需要的信息不存在时才访问RAM。
最快的内存在计算机被称为“注册”，这实际上与CPU本身是一样快。大部分的工作是在它里面做，但它的大小是不以GB，兆字节，甚至千字节计。你只有几百字节，实际数量由CPU架构定义。
你真的需要更多的内存？
32位系统可以处理高达约3GB内存。这种限制必须满足整个系统和所有运行的应用程序，否则某些东西会被换。此外，还有另一种限制对不同的应用程序 - 通常2GB。这3GB的限制仍然显得大方，但除了实际取样也将包含所有可执行文件和临时文件等。在所有这些都考虑在内，你可能有大约1.5GB的自由内存为您的工程。
难道这还不够？它通常是，所以让我们来看看一个大的音频工程的例子。比方说，我们的工程需要3GB的内存。这1GB将由可执行文件和临时结构使用，因此实际上已失去。剩下2GB包含的数据从硬盘驱动器加载。这个数据通常是压缩的，因此我们可以预计，使用无损音频压缩和随机存取所需的结构，我们需要从磁盘加载约1GB。虽然现代的硬盘使用分段和同步操作已经成很快了，最快的加载速度的合理估计将约为每秒50MB。因此，加载所有的数据将需要20秒。添加到这样的时间来计算临时结构，甚至用8核处理器，这将需要25秒加载。
25秒加载一个工程！你真的要等那么久？好了，有时你没有选择，但这种情况确实凸显了使用这么多内存的缺点。
为什么会有64位架构开发？
坦率地说，不是为了音频。其主要发展原因是为了满足来自服务器的不断增长的需求。D.A.W.程序处理音频时基本上是独享的主程序，而服务器一次处理数百个使用兆兆位级数据库的请求。他们在实际上还访问数据以随机的顺序，因此，有必要保持尽可能多的数据在内存中可用。
现在，64位处理器已经被开发用于服务器，为什么不在其他应用程序中也使用它们呢？早在16位架构的日子，对于开发人员来说，内存是一个主要问题。随着32位系统的到来，速度成为了优先考虑，所以我们开始浪费内存，直到最后的极限为止。随着64位计算机的出现，同样的情况再次发生。所以，现在，我们需要大量的内存用于音频，视频，游戏等...
你需要转到64位？这是可能的，5年之内的大多数计算机将运行64位操作系统，因此大部分的应用程序也将是64位的。到那时，你能管住自己不升级吗？我们将介绍下面的一些关键细节，以帮助您决定。
你需要做什么“是64位”？
首先你需要一个64位兼容的处理器，几乎所有的它们都是64位的，在今天。除了基于“安腾”处理器的高端服务器（你可能不会遇到），所有的它们都同时向下兼容32位架构，所以笔记本运行着64位处理器安装着32位操作系统并不罕见。其次，你需要一个64位操作系统，视窗XP / Vista/7/8和Mac OS10.6现在都有64位的。接下来，您需要64位应用程序。这就让它变得更复杂了，因为许多宿主都只有32位。如果您在64位操作系统运行32位应用程序，CPU被切换到32位模式下，只有极小的性能下降，我们会在后面论述。
最后，你还需要64位插件。嗯，这不完全是这样。当开发者转换到64位宿主上，他们无法立即发布他们，因为人们仍然需要使用他们的插件，这些插件在64位平台上用不了。为了解决这个问题，他们不得不开发所谓的'桥梁'先。桥是运行在特别的插件和宿主之间的单独的应用程序。如果宿主需要用这个插件，它创建一个请求，该系统调度器切换到桥梁。这个桥实际上要求插件进行操作，然后将数据返回给宿主。相当复杂，不是吗？
用桥一切都变得更加复杂，更慢和更不可靠。因此，我强烈建议，如果没有其他的选择才使用桥梁。如果你的插件大多仅用于32位，并且你没有耗尽内存，那么建议是继续用32位宿主，即使宿主本身可作为64位。
金科玉律是 - 如果您使用的是32位宿主，使用32位插件。如果使用64位宿主，使用64位插件。
X32 VS. X64
现在，我们终于可以谈及32位与64位架构的问题。对于本教程的目的，我们不会考虑16位平台，因为他们基本上已经过时（甚至洗衣机现在使用32位处理器！）。
我们也将使用x64位标识符，用于指称64位架构，同样x32指称32位架构。
DOES X64提高音频质量？
不，x64是64位处理器内部工作的方式。它无关于实际计算。例如，处理音频往往需要乘法，所以处理器包含几个'乘法'单元并在需要时使用它们。不管它是在32位或64位模式，它最终将使用相同的单元，以得到正确的结果。
不要切换到x64，因为你想要你的音乐听起来更好！
内存
毫无疑问，x64可以利用更多的内存，毕竟，这是它的发展的原因。但是，使用这种额外的内存有效？
一切都更大
首先，x64的代码比x32代码大得多。由代码我们指的是可执行文件，和用于处理器的指令。按理说因此有理由相信，您的应用程序本身也会更大，而且因为他们需要保留在内存中（虽然这是略有简化），他们将占据更多的空间。你可能还记得，高速缓存快但是小，而RAM是慢和大。因此，一个应用程序运行时，它是从内存加载到缓存。然而，代码更大了，它可以放入高速缓存的就较少，所以它必须不断重新加载！
用64位，你还需要8个字节来唯一地标识内存中的任何地方，被称为“地址”，而使用x32，一个地址只能有4个字节。这种差异可能看起来微不足道，但现代的应用程序都包含大量的地址。因此再一次的，使用x64系统，在你的处理上你有了更多的内存，但你也必须用得更多。
最后，x64处理器需要的东西是“64位对齐”，这意味着如果一些东西，一个数字为例，实际上是小于8个字节，它会被四舍五入为使用8个字节不管。这使得处理更快，但再一次，我们已经浪费了一些内存。
虚拟地址空间
下一个问题涉及多一点，可能会有点难以理解。
现代操作系统使用'虚拟地址空间'。当一个应用程序正在访问内存的一部分，因为技术原因，它实际上并不知道寻址内存的哪一部分。只有操作系统和处理器保持该信息。我们可以把“页面交换“作为一个例子。当没有足够的内存可供应用程序使用时，系统定位坐落在内存并一段时间没有被使用的东西，将其移动到硬盘，并把该内存给予应用程序。这几乎可以发生在内存的任何部分,甚至有可能每一次应用程序接触数据时，它被存储在不同的位置！因此，所有内存中的数据都会逐渐变得更加分散，但CPU如何知道每个地址意味着什么？
在x32的系统中，有一个这些内存地址的小的数据库，并且CPU和系统二者知道其结构。所以每次系统需要访问内存，它都会在数据库中查看，并且知道数据实际在哪里。如果数据不存在于内存中，因为操作系统已经把它‘交换’到了硬盘上，那么它将产生一个中断，并且操作系统会修复它。
在x64的情况复杂得多。 64位空间仅仅是太大而不能存储在一个小型数据库，所以设计者不得不使用另一种方式。其结果是要使用一些所谓的“TLB”（转换后备缓冲器 a translation lookaside buffer)，这是一个小的哈希表，其作用就像一个高速缓存。 TLB中只包含最近使用的地址，所以每一次地址在里面没有被发现，中断必须被产生来强制操作系统进行修复。一方面，访问TLB比访问分布在x32的系统中的小型数据库更快，但中断更加频繁，并且中断都需要相当大量的处理能力。
性能和CPU功能
x64系统还提供了一些新的功能，虽然其中的一些被强制使用64位平台上的大内存，但还有更多的是在X32之上提供的改进。
总体OS的性能
操作系统使用相同的CPU功能为应用程序。在Windows，我切换到64位时，没有发现任何性能的改善或恶化，虽然加载可能比较慢，因为系统比较大。因为Windows7和8，你可以从一个单一的DVD同时安装x32和x64版本，你可以自己试试这个。
使用Mac OS X似乎10.6（64位）是快于10.5（32位）。但是在Mac OS X性能上的大的变化，也随着时间的推移被注意到，这可能是由系统造成的越来越凌乱和逐步更加支离破碎。如果你注意到性能逐渐退化，一个可能的解决方案或许是重新安装操作系统。除此之外，有可能使用10.6比10.5系统资源稍好。
寄存器
x64架构比与它对应的x32有更多的寄存器，因为所有的计算都是在寄存器内部进行的，从理论上说，更多会更好。但是，如果你正运行在32位模式下，即使是一个64位处理器，它仍然只能使用x32的寄存器组。此外，在运行x64时，编译器生成的应用程序代码必须小心地分配和使用寄存器，这并不简单。因此看来，尽管有更大的寄存器组存在，通常有很少或没有性能提升。
调用约定
试想象现代应用程序作为黑盒子的巨大模块需要彼此交谈。他们的通信方式是通过一个预先定义的通信协议，以使黑盒子相互理解。此协议称为“调用约定”。
例如，一个插件的前端'GUI'（图形用户接口），是由一个绘制它的黑盒子创建的。现在，这个黑盒子可能要求另一个黑盒子绘制线条，因此每次需要画线时，它必须发送指令给另一个黑盒子它需要画什么样的线。这就是调用约定。
虽然x32大多数数据已通过内存传输，在x64这是非常低效的，所以如果可能的话使用寄存器完成这个任务。那当然速度要快得多。
在X64上运行32位应用程序
正如前面提到的,在一切都可作为64位之前,要花一段时间,尤其是在苹果平台上。在此之前,这是不可避免的,有时我们需要运行一些32位应用程序。问题是,这是一个问题吗?
如果我们看一下当32位应用程序运行在x64时会发生什么，我们看到CPU切换到所谓的32位兼容模式下，它表现为任何的32位处理器。然而该系统不断地在很多应用程序之间切换，大约每秒数千次。这种切换被称为“调度”。每次调度器从一个应用程序切换到另一个，它也需要在x64和x32之间来回地切换CPU模式，这将不可避免地需要一定的时间。虽然到目前为止，这个额外的时间似乎可以忽略不计。
另一个考虑是，每个应用程序需要调用操作系统，因为它需要从它使用一些服务。但因为操作系统是64位的，这些调用必须首先从32位转换到64位，然后通过“分配器”运行。幸运的是，这目前似乎没有造成任何显著的开销。
得出的结论是，在64位操作系统运行32位应用程序，这是完全没有问题的。如果有任何减速确实发生，这将是极小的。
结论
x64拥有超过x32几个优点，但也有一些问题需要注意。当涉及到性能，他们没有太大的区别。 一个64位系统，不管怎样可以访问你的所有内存，这应该是让你做出切换到64位的唯一原因。当使用64位宿主，你也应该使用x64的插件，反之亦然。 x64和音频质量无关。在64位操作系统运行32位应用程序，这是完全没有问题的。
现在，我们已经介绍了主要的区别，你是否希望或确实需要作出这样的转变，由你来做出更明智的决定。
------------------------------------------------------------------------------------------------------------
本人英语水平有限,借助网页翻译,费挺大个劲,但也就这水平了,希望对英语不好的朋友有帮助!
本帖最后由 wstsw888 于 15-9-20 23:20 编辑
1）CPU位数
反映CPU计算能力的另外一个重要指标是计算机的字长。字长是CPU整体进行基本计算的二进制位数，实际上可以简单地理解成CPU内部寄存器的位数。我们通常所说的8位、16位、或者32位CPU就是指字长。计算机的字长越长，那么CPU的运算数据量就越大，因而计算速度能得到提高，同时，CPU的字长也会影响计算机的计算精确度，例如字长越长，可以用来表示数字的有效位数就越多（特别是浮点数），因此计算机的精确度也就越高。
CPU的字长通常是指其数据总线宽度，单位是二进制的位（bit）。它是CPU数据处理能力的重要指标，反映了CPU能够处理的数据宽度、精度和速度等，因此常常以字长位数来称呼CPU。
2）操作系统位数
CPU位数与操作系统位数，这二者有区别也有联系，操作系统位数的概念是基于CPU的位数的。 CPU的位数是指CPU能一次同时寄存和处理二进制数码的位数，这和CPU中寄存器的位数对应。 操作系统的位数是说其所依赖的指令集的位数。计算机系统一般都应有向上兼容性，所以也可有64位CPU上运行32位操作系统、32位CPU上运行16位操作系统的情况。操作系统位数应该是根据指针类型的位数来定的。整数类型不一定跟位数相等，CPU位数准确地说应该是CPU一次能够并行处理的数据宽度，一般就是指数据总线宽度。
3）很多软件文件名的x86.x64是什么意思?
CPU分为 64位 与 32位。 64位与 32位 的指令集不同。
X64 指该版本专为 64 位CPU设计， X86 指该版本为 32位CPU设计。一些小软件由于编译生成的文件小，可以将 32位 与 64位 组合起来，但一些大的软件就不行，为减小体积，必须予以分开。
X64 只支持 64位 CPU 与 系统，而 X86 可以同时支持两种CPU，只是在 X64 CPU上会有性能损失。最好的方法就是确定你的 Windows 体系架构，然后下载对应版本的软件。如果是 Windows XP，则几乎是 X86. 若是 Windows Vista, Windows 7, Windows 8, Windows 8.1 等，则可以在系统属性中找到：XX位操作系统，基于XX位的处理器。
若是 32位 ， 则选择 X86，反之请选择 X64.
4）处理精度
单精度数据类型是float，双精度数据类型是double其实最通俗的讲的话，后者所能表示小数的范围比前者大双精度类型的变量能表示15位有效数字，单精度类型变量只能表示7位有效数字双精度类型变量占用8个字宽内存，单精度类型变量占用4个字宽内存
单精度浮点数(Single)
占用4个字节（32位）存储空间，包括符号位1位，阶码8位，尾数23位。
双精度浮点数(double)
用8个字节（64位）存储空间，包括符号位1位，阶码11位，尾数52位。
----------------------------------------
Studio One 的处理精度 我觉得可以理解为软件处理数据的精度，也可以理解为软件告诉CPU我给你的数据你处理成什么精度，比如是单精度还是双精度，所以实质上是CPU的处理精度。
插件的精度也有32位，64位或者其他精度。比如：ProTools 10 HD 就是48位处理精度（具体不太清楚）
举例：我的CPU是64位的，我安装了64位的Windows7，然后安装了64位的Studio One。
Studio One里可以设置处理精度是32位还是64位的。我设置成64，这样Studio One的处理精度是64位浮点。
64位的Studio One只能扫到64位的插件，插件是64位处理精度。
Studio One的处理精度是64位，如果桥接使用32位的插件，而插件的处理精度是32位,整体处理精度就下降了。
1）CPU位数
反映CPU计算能力的另外一个重要指标是计算机的字长。字长是CPU整体进行基本计算的二进制位数，实际上可以简单地理解成CPU内部寄存器的位数。我们通常所说的8位、16位、或者32位CPU就是指字长。计算机的字长越长，那么CPU的运算数据量就越大，因而计算速度能得到提高，同时，CPU的字长也会影响计算机的计算精确度，例如字长越长，可以用来表示数字的有效位数就越多（特别是浮点数），因此计算机的精确度也就越高。
CPU的字长通常是指其数据总线宽度，单位是二进制的位（bit）。它是CPU数据处理能力的重要指标，反映了CPU能够处理的数据宽度、精度和速度等，因此常常以字长位数来称呼CPU。
2）操作系统位数
CPU位数与操作系统位数，这二者有区别也有联系，操作系统位数的概念是基于CPU的位数的。 CPU的位数是指CPU能一次同时寄存和处理二进制数码的位数，这和CPU中寄存器的位数对应。 操作系统的位数是说其所依赖的指令集的位数。计算机系统一般都应有向上兼容性，所以也可有64位CPU上运行32位操作系统、32位CPU上运行16位操作系统的情况。操作系统位数应该是根据指针类型的位数来定的。整数类型不一定跟位数相等，CPU位数准确地说应该是CPU一次能够并行处理的数据宽度，一般就是指数据总线宽度。
3）很多软件文件名的x86.x64是什么意思?
CPU分为 64位 与 32位。 64位与 32位 的指令集不同。
X64 指该版本专为 64 位CPU设计， X86 指该版本为 32位CPU设计。一些小软件由于编译生成的文件小，可以将 32位 与 64位 组合起来，但一些大的软件就不行，为减小体积，必须予以分开。
X64 只支持 64位 CPU 与 系统，而 X86 可以同时支持两种CPU，只是在 X64 CPU上会有性能损失。最好的方法就是确定你的 Windows 体系架构，然后下载对应版本的软件。如果是 Windows XP，则几乎是 X86. 若是 Windows Vista, Windows 7, Windows 8, Windows 8.1 等，则可以在系统属性中找到：XX位操作系统，基于XX位的处理器。
若是 32位 ， 则选择 X86，反之请选择 X64.
4）处理精度
单精度数据类型是float，双精度数据类型是double其实最通俗的讲的话，后者所能表示小数的范围比前者大双精度类型的变量能表示15位有效数字，单精度类型变量只能表示7位有效数字双精度类型变量占用8个字宽内存，单精度类型变量占用4个字宽内存
单精度浮点数(Single)
占用4个字节（32位）存储空间，包括符号位1位，阶码8位，尾数23位。
双精度浮点数(double)
用8个字节（64位）存储空间，包括符号位1位，阶码11位，尾数52位。
----------------------------------------
Studio One 的处理精度 我觉得可以理解为软件处理数据的精度，也可以理解为软件告诉CPU我给你的数据你处理成什么精度，比如是单精度还是双精度，所以实质上是CPU的处理精度。
插件的精度也有32位，64位或者其他精度。比如：ProTools 10 HD 就是48位处理精度（具体不太清楚）
举例：我的CPU是64位的，我安装了64位的Windows7，然后安装了64位的Studio One。
Studio One里可以设置处理精度是32位还是64位的。我设置成64，这样Studio One的处理精度是64位浮点。
64位的Studio One只能扫到64位的插件，插件是64位处理精度。
Studio One的处理精度是64位，如果桥接使用32位的插件，而插件的处理精度是32位,整体处理精度就下降了。
南宫浩 发表于 15-9-20 21:45
然而~~~~你弄个X32的Studio One看看，我猜（我没用过Studio One，只能猜），它照样能用64位双精度处理音频 ...
你说的没错，我在11楼也发过图.
wstsw888 发表于 15-9-20 22:23
你说的没错，我在11楼也发过图.
那么。。。这是为什么呢？明明支持64位处理精度，却不支持64位插件，这是为什么呢？
本帖最后由 wstsw888 于 15-9-22 10:42 编辑
这句可能有问题：（插件的精度也有32位，64位或者其他精度。）因为插件的处理精度到底有没有32位的，我真不清楚，那就应该改成：插件的精度也有48位，64位，或许也有其他精度。
我这个观点：（64位的Studio One只能扫到64位的插件，插件是64位处理精度。Studio One的处理精度是64位，如果桥接使用32位的插件，而插件的处理精度是32位,整体处理精度就下降了。）确实是错了。虽然我知道软件的位数跟软件的处理精度是两回事，但我以为通常32位插件的处理精度就是32位，64位插件的处理精度就是64位，所以就搞错了！
感谢elunxp 的科普，在这我修改下：
插件的处理精度跟插件的位数无关，插件不管是32位（x86）还是64位（x64）通常都是同样的处理精度。但是桥接使用插件，会变慢，而且不稳定！
所以，如果您使用的是32位宿主，使用32位插件。如果使用64位宿主，使用64位插件。
借用我上面翻译的一句话：你是否希望或确实需要作出这样的转变，由你来做出更明智的决定。
这句可能有问题：（插件的精度也有32位，64位或者其他精度。）因为插件的处理精度到底有没有32位的，我真不清楚，那就应该改成：插件的精度也有48位，64位，或许也有其他精度。
我这个观点：（64位的Studio One只能扫到64位的插件，插件是64位处理精度。Studio One的处理精度是64位，如果桥接使用32位的插件，而插件的处理精度是32位,整体处理精度就下降了。）确实是错了。虽然我知道软件的位数跟软件的处理精度是两回事，但我以为通常32位插件的处理精度就是32位，64位插件的处理精度就是64位，所以就搞错了！
感谢elunxp 的科普，在这我修改下：
插件的处理精度跟插件的位数无关，插件不管是32位（x86）还是64位（x64）通常都是同样的处理精度。但是桥接使用插件，会变慢，而且不稳定！
所以，如果您使用的是32位宿主，使用32位插件。如果使用64位宿主，使用64位插件。
借用我上面翻译的一句话：你是否希望或确实需要作出这样的转变，由你来做出更明智的决定。
南宫浩 发表于 15-9-20 22:25
那么。。。这是为什么呢？明明支持64位处理精度，却不支持64位插件，这是为什么呢？
我猜，可能是软件开发者为了让我们有更多选择！
