3
|
Kristopher Johnson · 技术社区 · 15 年前 |
![]() |
1
3
如果你不是绝对的 需要 地址空间的增加,那么我就不需要64位构建了。这里的问题是,尽管您已经获得了地址空间,但是您使用的任何指针现在都是64位的,并且任何对齐的数据结构的大小都可能增加,这取决于编译器的设置。您最终可能无法在缓存中容纳足够多的内容,并且无论可用内存大小如何,缓存的大小都是固定的。所以你很可能 失去 性能。这是这些缓存效果和地址空间增益之间的平衡:您真的需要做一些度量来查看整体效果。如果你正在努力寻找64位端口,或者你没有幽默的记忆需求,我不会麻烦你。 Otoh,如果您正在编写下一个sqlserver/oracle,那么这项工作可能是值得的:—) |
![]() |
2
4
|
![]() |
3
2
我建议您提供通用的32位和64位二进制文件。这将为您提供最灵活的选择,并且仍然能够利用10.6的改进。 64位应用程序的好处是:
如今,当几乎所有的雪豹应用程序都是64位的时候,苹果建议开发人员也将其应用程序设为64位。即使您不需要额外的地址空间,它总体上仍然会更有效。它们强调了一点,即你不希望自己的应用程序成为系统中唯一的32位应用程序(启动时间会非常慢!)因此,进行64位构建确实有好处。 优化32位的Objective-C运行时的工作由于必须保持ABI兼容性而受到限制。但是有了64位运行时,他们能够开发出一种更高效、更快的新ABI。因此,您可以在应用程序和所有Cocoa框架中获得性能改进的所有好处。 32/64通用二进制是个好主意。单独下载只会让您的用户感到困惑。您可以对其进行压缩以减小下载大小。 请注意,内核的类型独立于框架。在10.6中有相当多的混淆,因为内核在默认情况下会引导到32位模式。但它仍然能够承载64位应用程序和框架。 你做 不 需要运行64位内核才能运行64位应用程序。雪豹是为64位优化,你的应用程序需要64位来利用这一点。 关于这个话题的苹果文档非常值得一读(并涵盖了上述神话): |
![]() |
4
1
值得一试。例如,64位编程模型有更多的寄存器,并且可能允许编译器生成更好的指令,所有这些都可能导致更高的性能。 |
![]() |
5
1
由于Mac OS X 10.6是纯64位操作系统,因此它不会加载32位库,除非某些32位应用程序需要它们。 因此,如果您设法只使用64位应用程序,那么就可以节省一些内存,因为您根本不需要加载32位版本的库。 |
![]() |
6
0
一般来说,最好的答案是了解你的用户。 如果您的用户主要都是64位的,那么需要花费时间和精力进行转换。如果您的用户主要都是32位的,那么您将花费时间和精力来获得微不足道的回报。 如果你有带宽,我建议是的,提供一个64位的可执行文件是最好的,因为至少你正在扩大你可能的受众。如果您通过一个网站交付您的应用程序,您可以附加监视器来查看最常下载的包。这样您就可以获得有关用户的额外信息。 |
![]() |
7
0
如果只是一个构建设置:使两者都可用。64位用户将希望使用64位版本保存32位库加载,而32位用户则没有选择。 |
![]() |
8
-2
一般来说,使用64位模式会导致性能降低,因为寄存器和内存地址的宽度现在是原来的两倍,因此移动的时间是原来的两倍。64位的确允许更多的内存同时提供给应用程序,所以如果您需要同时处理超过4GB的用户内存,那么64位可能是解决问题的方法(这里的4GB意味着4GB减去内核空间所占的空间,我不确定它对于OS-X是什么。对于Linux,通常是1GB)。 也就是说,在64位模式下,您的软件使用一些更容易优化的指令组合的可能性(虽然不是很大),SIMD通常是一个很好的候选者,在这种情况下,您可以获得一些性能优势。 更糟的是,如果您用C或类似语言编写软件,那么到64位就需要确保您使用的所有整数和长整型都是正确的64位安全的。这可能很难,也可能不难,而且可能需要更多的调试时间。 结论: 从表面上看,如果你不需要内存,也不希望获得性能,那么我不会担心它。即使是64位操作系统也不可能加载32位共享库。 编辑: “常识”是64位要比32位好,因为64>32位,因此这种观点经常受到人们的反对,并且可能由于不受欢迎而被贬低。我仍然建议仔细检查一下64位移动带来的收益和损失,这很少是一个无痛的过程。 |