32位应用程序和64位应用程序的区别

[CaesireKin]

如题，我最近做开发的时候想考虑针对不同的系统，硬件做相对应的优化，但却对此不甚了解，烦请前辈们指点一二，谢谢

[whoho]

64位系统不只是意味着寻址范围的增加…… 整套指令系统都拓展了，总线也有变化 至少可以从数据并行优化的角度去作很多工作 另：据说Windows64位版本对32位程序的兼容性很好，比以前16位到32位的情况要好得多，不需要一个专门的虚拟机

[树叶上的蜗牛]

32位操作系统针对的32位的CPU设计。 64位操作系统针对的64位的CPU设计。操作系统只是硬件和应用软件中间的一个平台。 32位操作系统针对的32位的CPU设计。 64位操作系统针对的64位的CPU设计。 我们的CPU从原来的8位，16位，到现在的32位和64位。 cpu处理计算的时候“数据”和“指令”是不同对待的。 8位的CPU,一次只能处理一个8位的“数据”或者一个8位的"指令"。比如'00001101'. 又比如：“+1”这个运算，你要先指示CPU做“+”，完成后再输入“1”数据给CPU。 8位的CPU优点是设计简单，处理速度比较快。 缺点就是：软件设计复杂，繁琐。不利于计算机的发展。 后来推出了16位的CPU，我们就可以一次处理两个字节（16位）的数据了，比如“加1”这个命令。“加”是一个指令，占用8个位，余下的8位我们可以存放数据“1”了。 32位的CPU就更加方便了，我们就可以一次处理一个a=a+b这样的命令了。 优点：简化了软件设计的复杂度 缺点：硬件设计更加复杂，计算速度下降。 一般来讲32位的CPU对于我们来讲是最理性的CPU，对于软件开发来讲足够了。 但是2的32次方 = 4294967296bit = 4G左右 很显然32位CPU只有4G左右的内存寻址空间，对于一些服务器来讲4G的内存的远远不够的了。我们需要更加大的内存寻址空间的话就需要对CPU进升级。64位CPU就这样诞生了。64位CPU的内存寻址空间是多少你算算看！呵呵。 2的64次方（理论上）。 但是现在的AMD和Inter的64位CPU并不是真正意义上的64CPU，只是进行了部分64位的改进，比如64位的内存寻址等。 要是真的全部都是64位的了，那么现在市场上的软件将全部被淘汰不能使用了~呵呵，想像一下会是什么样子。 64位的操作系统针对64位CPU设计的，增加了一些64位的指令，但还是和32兼容的。对于我们普通用户来讲64位系统意义不大。 强烈要求加分！！！~~ 我们的CPU从原来的8位，16位，到现在的32位和64位。 cpu处理计算的时候“数据”和“指令”是不同对待的。 8位的CPU,一次只能处理一个8位的“数据”或者一个8位的"指令"。比如'00001101'. 8位的CPU优点是设计简单，处理速度比较快。 缺点就是：软件设计复杂，繁琐。不利于计算机的发展。 后来推出了16位的CPU，我们就可以一次处理两个字节（16位）的数据了，比如“加1”这个命令。“加”是一个指令，占用8个位，余下的8位我们可以存放数据“1”了。 32位的CPU就更加方便了，我们就可以一次处理一个a=a+b这样的命令了。 优点：简化了软件设计的复杂度 缺点：硬件设计更加复杂，计算速度下降。 一般来讲32位的CPU对于我们来讲是最理性的CPU，对于软件开发来讲足够了。 但是2的32次方 = 4294967296bit = 4G左右 很显然32位CPU只有4G左右的内存寻址空间，对于一些服务器来讲4G的内存的远远不够的了。我们需要更加大的内存寻址空间的话就需要对CPU进升级。64位CPU就这样诞生了。64位CPU的内存寻址空间是多少你算算看！呵呵， 2的64次方（理论上）。 但是现在的AMD和Inter的64位CPU并不是真真意义上的64CPU，只是进行了部分64位的改进，比如内存寻址。 要是真的全部都是64位的了，那么现在市场上的软件将全部被淘汰不能使用了~呵呵，想像一下会使什么样子。 64位的操作系统针对64位CPU设计的，增加了一些64位的指令，但还是和32兼容的。对于我们普通用户来讲64位系统意义不大。

[赵4老师]

《The Intel 64 and IA-32 Architectures Software Developer's Manual》

[movsd]

64位主要就是为了使单个进程使用超4G的内存，另外对性能的提升，除非在你的算法中使用的int64这样的64位变量，否则和32位性能一样。

[Happy杰]

我好像也有类似的问题，为什么我的64位机，使用64位的VS2013，在创建工程时，还是win32控制程序？这个win32是什么意思啊？？

[赵4老师]

在64位Windows下： 64位exe和dll在目录c:\windows\system32目录下； 32位exe和dll在目录c:\windows\syswow64目录下； 所以要注意： 在win64位系统下注册32位ocx或dll需要将32位ocx或dll拷贝到c:\windows\syswow64\目录下。 且注册要用c:\windows\syswow64\regsvr32 xxxxxxx.ocx或dll

[CaesireKin]

引用 4 楼 sunnyhappyjie 的回复:

我好像也有类似的问题，为什么我的64位机，使用64位的VS2013，在创建工程时，还是win32控制程序？这个win32是什么意思啊？？

Win32是一个API，这是API的名字而已，和32位64位没多大关系，我个人对于32位和64位的理解，其实和前面的想法差不多，是硬件在处理指令以及数据时的差别

[CaesireKin]

引用 6 楼 whoho 的回复:

64位系统不只是意味着寻址范围的增加…… 整套指令系统都拓展了，总线也有变化 至少可以从数据并行优化的角度去作很多工作 另：据说Windows64位版本对32位程序的兼容性很好，比以前16位到32位的情况要好得多，不需要一个专门的虚拟机

这个我也略有听闻，毕竟如上面的朋友说的，64位也并不是完全的，只是部分的针对性修改，其实我一直有一个想法，如果32位的应用程序意味着CPU可以同时处理4条8位的指令或数据，是不是意味着64位的CPU可以一次性处理8条8位的指令或数据，这就是我主要考虑的，所谓的优化

[CaesireKin]

引用 3 楼 movsd 的回复:

64位主要就是为了使单个进程使用超4G的内存，另外对性能的提升，除非在你的算法中使用的int64这样的64位变量，否则和32位性能一样。

我确实使用了64位的数据，因为我需要程序考虑4G以上可用内存的情况，另外问下，linux下能理解_int8,_int16,_int 32,_int64这样的数据么，我知道这个数据是VS的拓展，那是否意味着GCC或其他linux下的编译器也有类似的拓展？

[wxf54318]

如果需要做兼容处理，应该考虑数据类型的大小区别，如定义INT32 、INT64表示32位整型和64位整型等

[whoho]

引用 9 楼 chn3698 的回复:

[quote=引用 3 楼 movsd 的回复:] 64位主要就是为了使单个进程使用超4G的内存，另外对性能的提升，除非在你的算法中使用的int64这样的64位变量，否则和32位性能一样。

我确实使用了64位的数据，因为我需要程序考虑4G以上可用内存的情况，另外问下，linux下能理解_int8,_int16,_int 32,_int64这样的数据么，我知道这个数据是VS的拓展，那是否意味着GCC或其他linux下的编译器也有类似的拓展？[/quote] 这个基本上都有支持啦，不要使用平台特有的，int64_t是标准的类型(stdint.h)，在非64位平台上，有可能不是真正的原生类型 稍慢一些 不过依我之间，较少有直接需要64位整数的场合——数值计算领域可能是另外一回事，还有加密算法……等等

[辰岡墨竹]

引用 8 楼 chn3698 的回复:

[quote=引用 6 楼 whoho 的回复:] 64位系统不只是意味着寻址范围的增加…… 整套指令系统都拓展了，总线也有变化 至少可以从数据并行优化的角度去作很多工作 另：据说Windows64位版本对32位程序的兼容性很好，比以前16位到32位的情况要好得多，不需要一个专门的虚拟机

这个我也略有听闻，毕竟如上面的朋友说的，64位也并不是完全的，只是部分的针对性修改，其实我一直有一个想法，如果32位的应用程序意味着CPU可以同时处理4条8位的指令或数据，是不是意味着64位的CPU可以一次性处理8条8位的指令或数据，这就是我主要考虑的，所谓的优化[/quote] 没你想的那么简单。常规的x86 CPU指令，32位和64位，比如add指令，64位只不过是一次可以处理一个64位立即数或64位寄存器或64位内存变量，并不是一次可以处理两个32位加法。而且占用的CPU指令周期还是一样的。而且C/C++编译器也不会那么智能，你写a=1+2，运行时间时一样的。 如果想要一次性处理多个数据，请使用MMX、SSE/SSE2等SIMD（单指令多数据）指令集。这个时候64位的优点就能体现出来了。所以除非你专门进行了汇编级别的算法优化，性能不会提升的。目前64位系统更多的意义是使用大于4GB的内存空间。

[CaesireKin]

引用

没你想的那么简单。常规的x86 CPU指令，32位和64位，比如add指令，64位只不过是一次可以处理一个64位立即数或64位寄存器或64位内存变量，并不是一次可以处理两个32位加法。而且占用的CPU指令周期还是一样的。而且C/C++编译器也不会那么智能，你写a=1+2，运行时间时一样的。 如果想要一次性处理多个数据，请使用MMX、SSE/SSE2等SIMD（单指令多数据）指令集。这个时候64位的优点就能体现出来了。所以除非你专门进行了汇编级别的算法优化，性能不会提升的。目前64位系统更多的意义是使用大于4GB的内存空间。

SSE我知道，而且目前已经在使用了，只是SSE好像x86平台才支持这个指令集。如果我要求软件全部使用64位int作为标准int，那么，在现今的intel和amd CPU上，这样做是否会造成性能下滑？我对寄存器还没怎么了解过，所以只能推断，假设一个寄存器一次能存入32位的整数，那么我用64位int作为标准，这样是不是就意味着要两个周期才能完成数据的加载？另外x86平台所谓的64位CPU，是否是指所有的寄存器都已拓展到了64位的宽度？= =还有。。64位系统是否意味着在这样的环境下，所有不足64位的数据都会被默认拓展为64位的？

[CaesireKin]

引用 12 楼 Bokutake 的回复:

没你想的那么简单。常规的x86 CPU指令，32位和64位，比如add指令，64位只不过是一次可以处理一个64位立即数或64位寄存器或64位内存变量，并不是一次可以处理两个32位加法。而且占用的CPU指令周期还是一样的。而且C/C++编译器也不会那么智能，你写a=1+2，运行时间时一样的。 如果想要一次性处理多个数据，请使用MMX、SSE/SSE2等SIMD（单指令多数据）指令集。这个时候64位的优点就能体现出来了。所以除非你专门进行了汇编级别的算法优化，性能不会提升的。目前64位系统更多的意义是使用大于4GB的内存空间。

SSE我知道，而且目前已经在使用了，只是SSE好像x86平台才支持这个指令集。如果我要求软件全部使用64位int作为标准int，那么，在现今的intel和amd CPU上，这样做是否会造成性能下滑？我对寄存器还没怎么了解过，所以只能推断，假设一个寄存器一次能存入32位的整数，那么我用64位int作为标准，这样是不是就意味着要两个周期才能完成数据的加载？另外x86平台所谓的64位CPU，是否是指所有的寄存器都已拓展到了64位的宽度？= =还有。。64位系统是否意味着在这样的环境下，所有不足64位的数据都会被默认拓展为64位的？

[CaesireKin]

引用 12 楼 Bokutake 的回复:

没你想的那么简单。常规的x86 CPU指令，32位和64位，比如add指令，64位只不过是一次可以处理一个64位立即数或64位寄存器或64位内存变量，并不是一次可以处理两个32位加法。而且占用的CPU指令周期还是一样的。而且C/C++编译器也不会那么智能，你写a=1+2，运行时间时一样的。 如果想要一次性处理多个数据，请使用MMX、SSE/SSE2等SIMD（单指令多数据）指令集。这个时候64位的优点就能体现出来了。所以除非你专门进行了汇编级别的算法优化，性能不会提升的。目前64位系统更多的意义是使用大于4GB的内存空间。

另外，在这种情况下，假设我的CPU是寄存器是32位，我是否可以将两个short结合成一个int放入寄存器，随后再做处理，这种类似于SSE的做法，是否有任何理论依据，不用汇编是否可行？

[辰岡墨竹]

会造成性能下滑。而且在64位系统里给一个64位整数赋值是原子操作，但是在32位系统里就不是了。 通用寄存器是64位的，原来的32、16位寄存器仍然可以访问，原来的32位、16位内存操作也可以用。不会自动把你的数据扩展到64位。

[CaesireKin]

引用 16 楼 Bokutake 的回复:

会造成性能下滑。而且在64位系统里给一个64位整数赋值是原子操作，但是在32位系统里就不是了。 通用寄存器是64位的，原来的32、16位寄存器仍然可以访问，原来的32位、16位内存操作也可以用。不会自动把你的数据扩展到64位。

谢谢，你的回答让我感觉思路清晰了非常非常多，真的非常有用