My app contains a multithreaded engine that plays a game which can be compared to chess. It performs a lot of bitwise operations (shift, and, etc.) on 64-bit words. On a PC the 64-bit version is much faster than the 32-bit version, and on a recent phone/tablet you would expect the same. The table below contains some test results (best result is 100, less means slower). The benchmark consists of adding the numbers 1 through 200 million in parallel. I verified that 4 threads is faster than 2 or 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
Observations:
On the Samsung Tab the performance is satisfactory, on the iPhone X I would say it is below par. Comparing the CPUs (iPhone X: 64-bit 6-core @ 2.39 & 1.42 GHz, Samsung Tab A 10.1: 64-bit 8-core @ 1.6 GHz) the iPhone X should not be 3.5 times slower (score 2 vs 7).
To be sure, I looked at the iOS arm64 debug build ipa with the MacOS 'file' command and it says: Mach-0 64-bit executable.
So I am confused: why isn't the arm64 build faster on my iPhone X?
I read somewhere that 'The iPhone X’s processor is more powerful than the newest MacBook Pro' (2017), that can't be right. (My MacBook is 2015 I think.)
BTW, I use one external library, Device, to detect if a device is an iPhone X, and I tried using ios.add_libs=ExternalAccessory.framework.
EDIT
Some more information on the iOS ipa files:
32-bit Main.ipa 7.3 MB file: Mach-0 executable arm
64-bit Main.ipa 7.1 MB file: Mach-0 64-bit executable
On a 2012 iPad 4 only the 32-bit ipa installs. (The search task performance on a scale of 0-100 is 0.4.) On an iPhone X both the 32-bit and 64-bit ipa's install, but there is no performance difference, which is odd. The search task performance is 2.0, which is low compared to the Samsung Tab (7.0).
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?
You can use a native interface and implement the JavaSE portion as the Long.bitCount() or Long.numberOfTrailingZeros(). This will work as fast on the simulator.
Another approach is to implement a Codename One API that does that natively to the important OS's and uses a simulation as a fallback for things you don't support. Then submit a PR to Codename One. You can do that by modifying CodenameOneImplementation.java with the fallback code then updating JavaSEPort.java, AndroidImplementation.java, IOSImplementation.java etc.
You would then expose these APIs somehow to the user which normally we do via Display but in this case might not be the ideal user API venue.
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.)
64 bit is now required by apple so we no longer support building without it.
The Android release version does a much better job on the search task than the debug version: 7 times faster!
These things are hard to tell. It could be the Android JIT which iOS doesn't allow or it could be a piece of code we failed to optimize. We would need to microbenchmark the resulting code to tell.
However, the JavaSE JIT is amazingly fast and will run circles around any native compilation benchmark we throw its way. That's just not something an AoT VM can compete with. We do have other advantages such as more consistent behavior and less hiccups when running.