By the way, i've tested the runtime performance of the non static and static builds from Koivisto. I did not see any differences between them. So we can not say, non static builds have less performance in general. I would say, if the static builds works for you, they are not so bad at all.
I will test tonight.
When i say it is not optimum it's because they are not pgo builds and i don't know if your builds are making use of Neon, popcnt, prefetch of Rpi4.
Specifically for Android, position independent executables (PIE) are required, and I remember problems with static linkage because PIEs are technically dynamic libraries, just as executables.
If you can help about compiling from other platform than Rpi4 usind target aarch64-linux-gnu you are very welcome
That's indeed difficult because binary compatibility under Linux is flat out bad. That's the main reason why Linux distros have always had a package manager, and why container formats such as Flatpak have emerged as dirty workaround.
For targeting 32bit Raspbian, I'm using a ready-made Windows (!) GCC toolchain and run that under Wine.
Ras wrote: ↑Sun Dec 20, 2020 1:30 pm
For targeting 32bit Raspbian, I'm using a ready-made Windows (!) GCC toolchain and run that under Wine.
So what we need is an expert in those things that create a nice toolchain for aarch64-linux-gnu for raspi4 under gcc or clang, under Windows or Linux and we are done !
Pi4Chess wrote: ↑Sun Dec 20, 2020 1:09 pmI will test tonight.
When i say it is not optimum it's because they are not pgo builds and i don't know if your builds are making use of Neon, popcnt, prefetch of Rpi4.
Yes of course, e. g. all arm64-v8a devices are able to use neon instructions. Android NDK is aware of that. And if there are source dependent compiler definitions for supporting such instructions, like -DUSE_NEON, -DHAS_PREFETCH and so on, i used them for optimal runtime performance. In very rare cases, not all compiler definitions can be used, because the clang compiler produces a lot of errors and i'm not willing to rewrite a lot of code only for successful compiling for Android. And with the clang compiler, you have to change very often the source code for successful compiling, but always in a minimal invasive way.
As long the static builds are appreciated, i will update them, when i compile a new version for Android. But i will compile only those chess engines as static builds which you are missing. Seems to be a not so bad interim solution.
Archimedes wrote: ↑Sun Dec 20, 2020 2:58 pm
I've also added the last Cheng version.
As long the static builds are appreciated, i will update them, when i compile a new version for Android. But i will compile only those chess engines as static builds which you are missing. Seems to be a not so bad interim solution.
Thank you for your implication and help. I will test all new static builds you put in and the 2 Ethereal builds but later tonight.
You wrote about lagging threads with Rodent engines. I found out, that the thread feature in the Rodent engines doesn't work on Android. My first compiles only works for 32 bit and introducing more than 1 thread do nothing for better runtime performance. 64 bit versions crashes after the first moves.
Then i encountered, with disabling the thread feature, with the compiler definition -DNO_THREADS, 64 bit versions now also working, without any crashes.
Archimedes wrote: ↑Sun Dec 20, 2020 8:09 pm
You wrote about lagging threads with Rodent engines. I found out, that the thread feature in the Rodent engines doesn't work on Android. My first compiles only works for 32 bit and introducing more than 1 thread do nothing for better runtime performance. 64 bit versions crashes after the first moves.
Then i encountered, with disabling the thread feature, with the compiler definition -DNO_THREADS, 64 bit versions now also working, without any crashes.
Yes it is with Rodent IV ! Thanks for the tip ! I will see how i compiled and will change the threads flag then.
A little feedback about your static android compilations : after bit set Cheng, Tucano and Xiphos are working fine ! They all 3 are at 2000-2200 kns so pretty smooth.
On the other hand the 2 non-static Ethereal builds are not working at all on rpi4.
