时间戳

首页 > 解决方案 > 代号一 iOS 64 位性能

ios - 代号一 iOS 64 位性能

问题描述

我的应用程序包含一个多线程引擎，可以玩可以与国际象棋相媲美的游戏。它对 64 位字执行大量按位运算（移位和等）。在 PC 上，64 位版本比 32 位版本快得多，而在最近的手机/平板电脑上，您会期望相同。下表包含一些测试结果（最好的结果是 100，越少意味着越慢）。基准包括并行添加数字 1 到 2 亿。我验证了 4 个线程比 2 个或 1 个更快。

hardware           os      build         threads benchmark search task
----------------------------------------------------------------------
MacBook            Windows 64-bit JVM       4          100         100
MacBook            Windows CN1 Simulator    4          100          42
iPhone X           iOS     debug armv7      4           14           2
iPhone X           iOS     debug arm64      4           14           2
Samsung Tab A 10.1 Android debug            4            8           1
Samsung Tab A 10.1 Android release          4           10           7

观察：

  1. 在 MacBook 上，搜索任务在模拟器中的执行速度是普通 64 位 JVM 的两倍多。大概这是因为没有对函数 Long.bitCount() 和 Long.numberOfTrailingZeros() 的（本机）支持，我不得不用（较慢的）代码替换它们。问题：有没有办法改善这种情况？
  2. iPhone X armv7 和 arm64 构建之间没有区别。这怎么可能？（在安装 arm64 版本之前，我尝试删除该应用并重新启动手机。当前的 AppStore 版本是 32 位，IIRC。）
  3. Android 发布版在搜索任务上的表现比调试版要好得多：快 7 倍！

在三星 Tab 上表现令人满意，在 iPhone XI 上会说它低于标准。比较 CPU（iPhone X：64 位 6 核 @ 2.39 和 1.42 GHz，Samsung Tab A 10.1：64 位 8 核 @1.6 GHz），iPhone X 不应慢 3.5 倍（得分 2 与 7）。

可以肯定的是，我使用 MacOS 的“文件”命令查看了 iOS arm64 调试构建 ipa，它说：Mach-0 64 位可执行文件。

所以我很困惑：为什么 arm64 不能在我的 iPhone X 上构建得更快？

我在某处读到“iPhone X 的处理器比最新的 MacBook Pro 更强大”（2017 年），这是不对的。（我认为我的 MacBook 是 2015 年的。）

顺便说一句，我使用一个外部库 Device 来检测设备是否是 iPhone X，并且我尝试使用 ios.add_libs=ExternalAccessory.framework。

编辑

有关 iOS ipa 文件的更多信息：

32 位 Main.ipa 7.3 MB 文件：Mach-0 可执行 arm

64 位 Main.ipa 7.1 MB 文件：Mach-0 64 位可执行文件

在 2012 iPad 4 上仅安装 32 位 ipa。（0-100 范围内的搜索任务性能为 0.4。）在 iPhone X 上，安装了 32 位和 64 位 ipa，但没有性能差异，这很奇怪。搜索任务性能为 2.0，与三星 Tab（7.0）相比较低。

标签： iosperformance64-bitcodenameoneiphone-x

解决方案

在 MacBook 上，搜索任务在模拟器中的执行速度是普通 64 位 JVM 的两倍多。大概这是因为没有对函数 Long.bitCount() 和 Long.numberOfTrailingZeros() 的（本机）支持，我不得不用（较慢的）代码替换它们。问题：有没有办法改善这种情况？

您可以使用本机接口并将 JavaSE 部分实现为Long.bitCount()或Long.numberOfTrailingZeros()。这将在模拟器上以同样快的速度运行。

另一种方法是实现一个 Codename One API，它在重要的操作系统上本地执行此操作，并使用模拟作为您不支持的事物的后备。然后向 Codename One 提交 PR。您可以通过修改CodenameOneImplementation.java后备代码然后更新JavaSEPort.java,AndroidImplementation.java等来做到这一点IOSImplementation.java。

然后，您将以某种方式向用户公开这些 API，这通常是通过 Display 进行的，但在这种情况下，可能不是理想的用户 API 场所。

iPhone X armv7 和 arm64 构建之间没有区别。这怎么可能？（在安装 arm64 版本之前，我尝试删除该应用并重新启动手机。当前的 AppStore 版本是 32 位，IIRC。）

苹果现在需要 64 位，因此我们不再支持没有它的构建。

Android 发布版在搜索任务上的表现比调试版要好得多：快 7 倍！

这些事情很难说。它可能是 iOS 不允许的 Android JIT，也可能是我们未能优化的一段代码。我们需要对生成的代码进行微基准测试来判断。

但是，JavaSE JIT 速度惊人，可以围绕我们抛出的任何本机编译基准运行。这不是 AoT VM 可以与之竞争的东西。我们确实有其他优势，例如运行时更一致的行为和更少的打嗝。

推荐阅读