Just got a new X2 Elite Extreme Snapdragon laptop. The CPU single and multi core speed is insane. Performance could be much better with native ARM64 support.

x86 emulation hits these chips harder than Apple Silicon on MacOS. Please consider adding native Windows ARM64 support. I would be happy to test this out.

I can also do the work myself if I get access to relevant project files. My 18-core setup is ready for testing. Data shows native apps run much faster than emulated ones on Oryon.

Let me know what you need from me.

Since its openSource everyone can try to port it: https://github.com/drivere/get-decics-numberfields
You already got the answer in your appe topic ;)
https://numberfields.asu.edu/NumberFields/forum_thread.php?id=680#4165

Subject: Benchmarks ready from other projects - Looking for native GetDecics Windows ARM64 binary

Thanks for the source link, Stiwi.

I’ve been testing native Windows ARM64 builds on other projects with my 18-core Snapdragon X2 Elite Extreme. On Asteroids@home, I’m seeing runtimes of ~45 minutes for 18 concurrent tasks at only 25-30W CPU power—massively outperforming x86 emulation.

The build process for GetDecics seems straightforward but requires pre-building PARI and GMP. Since I have the hardware ready for 24/7 testing and benchmarking, would anyone (perhaps @ahorek if you're reading this) be interested in providing a native MSVC or Clang build for Windows ARM64?

I can provide immediate feedback on SIMD performance and stability on the Oryon architecture. If a binary is made available, I’ll deploy it right away and post the performance delta here.

Here's my 2 cents worth... I built all the project executables by cross compiling using the gnu C++ compiler. It required me to put some pre-processor directives in the code and tweak the makefile, but after that I pretty much build with a single make file. For anyone who is good with linux and prefers its build environment, this is the way to go.

Getting updated libraries for PARI and BOINC will probably be a pain in the butt.

This is the output of Google Gemini; It looks promising but take it with a grain of salt:

Yes, you can cross-compile for Windows ARM64 on Linux, but it is not yet as straightforward as targeting standard x86_64 Windows. While the traditional GNU GCC toolchain for Windows ARM64 is still in active development, there are reliable ways to achieve this using specific toolchains.

1. The Recommended Approach: LLVM-MinGW
Because official GCC support for Windows on ARM is still being upstreamed, the most mature and widely used toolchain for this specific task is llvm-mingw. It uses Clang as the compiler but provides a MinGW-w64 environment, allowing you to use standard C++ and link against Windows libraries.

Why use it: It supports all four modern Windows architectures (i686, x86_64, armv7, and aarch64) with a single toolchain.
Availability: You can download prebuilt binaries for Linux from the llvm-mingw releases page.
Usage: After extracting the toolchain, you can compile for ARM64 using:

./bin/aarch64-w64-mingw32-clang++ main.cpp -o app.exe

Thanks for the input, Eric. That llvm-mingw approach looks like exactly the right path to bypass the complexity of the native Windows toolchains.

I understand that maintaining a new architecture adds overhead to your workload. Since I have the hardware (Snapdragon X2 Elite Extreme) and the desire to see this project run efficiently on it, I’m happy to take the heavy lifting off your plate.

If I can get a build environment running on my Linux partition (or via WSL), I’ll attempt to cross-compile the GetDecics binary using the llvm-mingw method you outlined.

A couple of quick questions to ensure I’m not heading down a blind alley:

Is there a specific version of the PARI/GMP libraries that the project currently relies on, or should I just target the latest stable releases?

If I successfully produce a stable ARM64 binary, are you open to me hosting it for testing, or would you prefer I submit a PR/patch to your repository so you can verify the build process yourself?

I’m happy to document the build process for others if we get this working. My goal is just to get these 18 cores crunching at full efficiency rather than struggling through x86 emulation.

Also, PrimeGrid just got official Adreno iGPU support, on top of Native ARM64 CPU tasks, for the applications Genefer 16-21!

I’ve already successfully implemented this on the Asteroids@home project (thread #9485), where we hit full native stability on the Snapdragon X2 Elite using an MSVC build. I’m seeing ~45-minute task completion times with excellent thermal efficiency, and I’m ready to replicate that exact success here for NumberFields.

Regarding hardware acceleration: I noticed you have OpenCL support for various GPUs. While I understand Adreno/ARM iGPUs may have FP64 limitations for this specific application, my testing on Asteroids showed that the raw throughput of the Snapdragon's native CPU-side compute is so efficient that it easily outruns the x86-emulated tasks, effectively serving as a high-performance alternative to GPU-offloading for these specific workloads.

Looking forward to your guidance on the build dependencies.

Is there a specific version of the PARI/GMP libraries that the project currently relies on, or should I just target the latest stable releases?

The latest stable release should be good.

If I successfully produce a stable ARM64 binary, are you open to me hosting it for testing, or would you prefer I submit a PR/patch to your repository so you can verify the build process yourself?

If you want to host it for testing, that's okay with me. Once we confirm it runs a few test cases and gives the exact same answer as the x86 version, then I could add it to the project as a beta app for further testing.



This brings up another question. If you get this working on Windows ARM64, how hard would it be to get it working on Android ARM64? It would be cool to get this running on my cell phone (I attempted this about 5 years ago and failed).

Android ARM64 is a different beast compared to Windows ARM64 primarily due to the Bionic libc and the NDK requirements.

It would definitely require a dedicated effort using the Android NDK to handle those specific library linkages and system-level API differences.

I am focused on the Windows ARM64 target right now to get that native efficiency established first.

Once we confirm the Windows build is solid, I would be more than happy to dive into an Android port.

Do you have any existing notes or specific roadblocks from your attempt 5 years ago that I should look out for?

Android ARM64 is a different beast compared to Windows ARM64 primarily due to the Bionic libc and the NDK requirements.

It would definitely require a dedicated effort using the Android NDK to handle those specific library linkages and system-level API differences.

I am focused on the Windows ARM64 target right now to get that native efficiency established first.

Once we confirm the Windows build is solid, I would be more than happy to dive into an Android port.

Do you have any existing notes or specific roadblocks from your attempt 5 years ago that I should look out for?

I got it to build and it ran in the emulator, but when I deployed it on BOINC it would randomly crash about 20% of the time. I could never replicate the crashes so it was extremely hard to debug; and it would never crash when running in the debugger. I gave up after one weekend, especially since I was busy with other stuff.

Regarding roadblocks with building that may be relevant to the Windows build, I will look at my notes and get back to you. I sent you a pm yesterday with one gotcha to look out for - Pari assumes that long and long* are the same size; this was the biggest roadblock for the 64bit Windows build which I eventually overcame. I don't know about the ARM64 architecture, but this is something to be aware of.

Update:

I am writing to report on my attempt to build the GetDecics application for native Windows ARM64 support.

While I have managed to set up the build environment using the provided MinGW toolchain, the compilation process for the GetDecics.o object file consistently fails due to invalid assembly constraints.

It appears the project's PARI dependency is heavily reliant on x86-specific kernel headers that cannot be easily bypassed with standard cross-compilation flags.

I would appreciate any insight from the project developers on how to properly build this application for ARM64 or if there are plans to update the build system to support non-x86 architectures.

This level of hardware optimization is necessary to realize the performance potential of new ARM-based chips in distributed computing.

Update:

I am writing to report on my attempt to build the GetDecics application for native Windows ARM64 support.

While I have managed to set up the build environment using the provided MinGW toolchain, the compilation process for the GetDecics.o object file consistently fails due to invalid assembly constraints.

It appears the project's PARI dependency is heavily reliant on x86-specific kernel headers that cannot be easily bypassed with standard cross-compilation flags.

I would appreciate any insight from the project developers on how to properly build this application for ARM64 or if there are plans to update the build system to support non-x86 architectures.

This level of hardware optimization is necessary to realize the performance potential of new ARM-based chips in distributed computing.

The first step is to build libpari.a. To do this, when you configure Pari, you need to use the generic kernel which will disable the x86 assembly.

After extracting the source code, try this from the top level of the source tree:

./Configure --host=aarch64-w64-mingw32 --kernel=none
make all
make install-lib-sta

Note the last line may fail due to permissions, but it should still create the libpari.a file which is all you need.