代号一 iOS 64 位性能

Question

我的应用程序包含一个多线程引擎，可以玩类似于国际象棋的游戏。它对 64 位字执行大量按位运算（移位和等）。在 PC 上，64 位版本比 32 位版本快得多，在最近的 phone/tablet 上，您会期望相同。下面的 table 包含一些测试结果（最好的结果是 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

观察：

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

在 Samsung Tab 上的表现令人满意，在 iPhone X 上我会说它低于标准水平。比较 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 'file' 命令查看了 iOS arm64 debug build ipa，它说：Mach-0 64-bit executable.

所以我很困惑：为什么我的 iPhone X 上的 arm64 编译速度不快？

我在某处读到 'The iPhone X’s processor is more powerful than the newest MacBook Pro' (2017)，这不对。（我想我的 MacBook 是 2015 年的。）

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

编辑

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

32 位 Main.ipa 7.3 MB 文件：Mach-0 executable arm

64 位 Main.ipa 7.1 MB 文件：Mach-0 64 位 executable

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

Answer 1

On the MacBook the search task is performed more than twice as slow in the simulator compared to a normal 64-bit JVM. Presumably this is because there is no (native) support for the functions Long.bitCount() and Long.numberOfTrailingZeros(), which I had to replace by (slower) code. Question: is there a way to improve this?

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

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

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

There is no difference between the iPhone X armv7 and arm64 builds. How is this possible? (I tried removing the app and restarting the phone before installing the arm64 version. The current AppStore version is 32-bit, IIRC.)

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

The Android release version does a much better job on the search task than the debug version: 7 times faster!

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

然而，JavaSE JIT 的速度惊人地快，并且将运行绕过我们抛出的任何本机编译基准测试。这不是 AoT VM 可以与之竞争的东西。我们确实有其他优势，例如在运行ning.

时更一致的行为和更少的打嗝

代号一 iOS 64 位性能

Codename One iOS 64-bit performance

ios

performance

64-bit

codenameone

iphone-x