Hello Everyone!

After getting a bit too much time to myself in college, I've decided to look into seeing just how viable it is to run Numberfields@home on ARM processors.
I've got a batch of older Chromebook Tablets that have decent processors in them (8x A53 cores each, which I had been using for Einstein@home for a long time) that I wanted to try with Numberfields.

So far I've gotten the source code on github by Eric complied on a raspberry pi I have lying around, and have ran 3 of the test files included with it (one from sf3, one from sf6, and one from sf7).
They match the truth files in everything but compute time (for the sf6 and sf7 test files I used, it was about double the time to finish compared to the truth file:

I tried to run the raspberry pi with the Anonymous platform feature BOINC has, but noticed that the server doesn't accept clients with that set for the architecture field.

I'm still trying it with other jobs my x86 computers are getting to see if the results differ, but so far they have not with the test files.
I also haven't messed with the numBlocks or the other arguments yet, but I don't know how much of a difference it would make.


Diff of the test files I've used so far:

sf3:

$ diff wu_sf3_DS-16x270_Grp74of3932160.out wu_sf3_DS-16x270_Grp74of3932160.out.truth
7c7
< #   Elapsed Time = 5646 (sec)
---
> #   Elapsed Time = 3542 (sec)

sf6:

$ diff wu_sf6_DS-7x10_Grp16925of160000.out wu_sf6_DS-7x10_Grp16925of160000.out.truth
6c6
< #   Elapsed Time = 1008 (sec)
---
> #   Elapsed Time = 627 (sec)

sf7:

$ diff wu_sf7_DS-12x12_Grp164787of1000000.out wu_sf7_DS-12x12_Grp164787of1000000.out.truth
10c10
< #   Elapsed Time = 7850 (sec)
---
> #   Elapsed Time = 4099 (sec)

Looking to see if maybe we could get ARM apps in the future if this works out.

That's great news!

Was there anything special you needed to do with the code to get it to build, other than tweaking the makefile? You don't need to worry about NumBlocks for cpu tasks, that's only meaningful for GPU tasks. I kept it in the code because the same code is used for building both CPU and GPU tasks.

Is your raspberry pi 64bit? If it is and you built with the -static compiler option then there is a good chance it could run on any aarch64 linux machine, including the new Qualcom desktops (running linux of course).

If you send me the executable, I could test it in a VM or emulator. Then I could create a beta app for it within the project.

That's great news!

Was there anything special you needed to do with the code to get it to build, other than tweaking the makefile? You don't need to worry about NumBlocks for cpu tasks, that's only meaningful for GPU tasks. I kept it in the code because the same code is used for building both CPU and GPU tasks.

Not really, I just changed the paths in the Makefile to match where I had it built.
For libraries, I am using the Pari version that was in the github repository (pari-2.8-1711-ge5c317c), but everything else is using the latest version (latest BOINC version from their github repository, libgmp-dev version 2:6.3.0+dfsg-3 since that was the latest in the Debian Trixie repositories).
I think I read in a different thread that you had gotten it to compile with a newer version of Pari, so I'll try that here soon.

Is your raspberry pi 64bit? If it is and you built with the -static compiler option then there is a good chance it could run on any aarch64 linux machine, including the new Qualcom desktops (running linux of course).

Yep, it's a Raspberry Pi 4B, with a 64bit Debian install.
The Makefile I used was the Makefile.cpu_linux64 one from the repository, which seems to have the -static option already included.

 STATIC_FLAGS = -static-libgcc -static-libstdc++ -static 

If you send me the executable, I could test it in a VM or emulator. Then I could create a beta app for it within the project.

Will do!
I'll also copy it over to one of my other ARM tablets and test it on there later this week, since that has a different install of Debian on it.

It wouldn't hurt to try the latest version of Pari. A couple of changes would be required to the code as described here:
https://numberfields.asu.edu/NumberFields/forum_thread.php?id=488&postid=4374#4374

Few updates:

1. I pulled 4 workunits that one of my x86 machines had been assigned by the project server here (sf6 tasks), and ran them both on the Raspberry Pi, as well as my personal laptop, to see if they differed at all.
No difference other than time (the Pi took about 2-2.5x longer than my laptop, which doesn't surprise me) for the output, between all 4 WUs.

2. I also had Pari recompile on the latest stable release (v2.17.4) on the Pi, and changed the function name as mentioned in the other thread, before recompiling the project.
Both Pari and the project code compiled with no errors, and the first test WU I used had no difference in output (again, other than time, which I need to run a few times to see if the newer Pari version makes a difference or not).

I also was able to copy the binary to a different Raspberry Pi that I have, and it ran with no issues at all on there.
Going to be testing with the tablet later today, as well as the other test WUs with the new Pari version.

Few updates:

1. I pulled 4 workunits that one of my x86 machines had been assigned by the project server here (sf6 tasks), and ran them both on the Raspberry Pi, as well as my personal laptop, to see if they differed at all.
No difference other than time (the Pi took about 2-2.5x longer than my laptop, which doesn't surprise me) for the output, between all 4 WUs.

2. I also had Pari recompile on the latest stable release (v2.17.4) on the Pi, and changed the function name as mentioned in the other thread, before recompiling the project.
Both Pari and the project code compiled with no errors, and the first test WU I used had no difference in output (again, other than time, which I need to run a few times to see if the newer Pari version makes a difference or not).

I also was able to copy the binary to a different Raspberry Pi that I have, and it ran with no issues at all on there.
Going to be testing with the tablet later today, as well as the other test WUs with the new Pari version.

I got your executable to run successfully. Since I don't have an ARM system, I had to use an emulator (QEMU), so it took about 9x longer to run. That's to be expected since each ARM64 instruction has to be translated into an x86_64 instruction and that apparently eats up a bunch of CPU cycles. What's important is that it gave the same results.

I will deploy this shortly as a beta app so others can start trying it out.

I just deployed it as a beta app. If the version with the latest Pari library is noticeably faster then we can update that later.

I just deployed it as a beta app. If the version with the latest Pari library is noticeably faster then we can update that later.

Initially, my devices didn't want to pull any tasks, but I checked this morning and it had 8 of them running, so it seems the beta app is working now.

Another update with the newer binary:
I have found an issue with the newer Pari version, specifically with sf3 tasks.
Whenever I run a sf3 task from the test files, it errors out with the same error that was in this post.

 $ cat stderr.txt
2026-09-24 00:18:56 (709543): Can't open init data file - running in standalone mode
  numBlocks = 10240.
  threadsPerBlock = 1.
  polyBufferSize = 10240.
CHECKPOINT_FILE = GetDecics_state.
Checkpoint Flag = 0.
Reading file in
    K = x^2 - 2
    S = [2, 5]
    Disc Bound = 80000000000000000
    Skip = (P^2)*(Q^7)
    Num Congruences = 5
    SCALE = 1.000000
    |dK| = 8
    Signature = [2,0]
Opening output file out
Now starting the targeted Martinet search:
  ***   incorrect type in idealhnf [fake prime ideal] (t_VEC).  ***   Error in the PARI system. End of program.

I don't know how much of an issue it'll be, since sf3 is complete, but I figured I should mention it for completeness.
The other two fields (sf6, sf7) didn't have this issue with the test files I used, but I do have one of the ARM tablets going through all of the other test files to see if any of them differ from the truth files for the new binary.

Time wise, the newer Pari version doesn't make much of a difference, as seen with the two files I used before on this Pi, so I don't think there is a benefit to using it with the newer library.
Output was the same as the binary with the older Pari version for those two files.

$ diff wu_sf6_DS-7x10_Grp16925of160000.out.new wu_sf6_DS-7x10_Grp16925of160000.out.old
6c6
< #   Elapsed Time = 1000 (sec)
---
> #   Elapsed Time = 1008 (sec)

$ diff wu_sf7_DS-12x12_Grp164787of1000000.out.new wu_sf7_DS-12x12_Grp164787of1000000.out.old
10c10
< #   Elapsed Time = 7871 (sec)
---
> #   Elapsed Time = 7850 (sec)

Another update with the newer binary:
I have found an issue with the newer Pari version, specifically with sf3 tasks.
Whenever I run a sf3 task from the test files, it errors out with the same error that was in this post.

I have figured out the source of this error. The input file is text representing modulus ideal, discriminant bound, and congruence vectors. The newer versions of Pari make reductions when reading the data. For example, if it reads the 2-vector [5,0]~ it will convert it into the integer 5. When this data is later passed into the Pari function idealhermite it looks corrupted and flags an error.

This is not an easy fix. For now I think we should just stick with the older version of the library.

Another update with the newer binary:
I have found an issue with the newer Pari version, specifically with sf3 tasks.
Whenever I run a sf3 task from the test files, it errors out with the same error that was in this post.

I have figured out the source of this error. The input file is text representing modulus ideal, discriminant bound, and congruence vectors. The newer versions of Pari make reductions when reading the data. For example, if it reads the 2-vector [5,0]~ it will convert it into the integer 5. When this data is later passed into the Pari function idealhermite it looks corrupted and flags an error.

This is not an easy fix. For now I think we should just stick with the older version of the library.

I went ahead and made the fix. The repair was non-trivial, so I made it a function call. Here is the patch:

 
22,23d21
< // Function prototypes
< void repairConVecs(GEN);
135,139d132
< 
<   //printf("ConVecs Before:  %s\n\n", GENtostr(ConVecs));
<   repairConVecs(ConVecs);  // This is needed for the newer versions of Pari.
<   //printf("ConVecs After:  %s\n\n", GENtostr(ConVecs));
< 
458d450
< 
1374c1366
<       if(polisirreducible(f_L))
---
>       if(isirreducible(f_L))
1405c1397
<         } // Matches: if(polisirreducible(f_L))
---
>         } // Matches: if(isirreducible(f_L))
1632,1681d1623
<   }
< 
< 
< 
< 
< 
< //******************************************************************************
< //* This function repairs the congruence vector data.  It is corrupted by the
< //* gp_read_str function in later versions of Pari which convert 2-vectors of
< //* the form [x,0]~ into Pari integers "x".  Conversely, the 5th element of
< //* an ideal needs to be collapsed if it represents a pure scalar integer.
< //******************************************************************************
< 
< void repairConVecs(GEN ConVecs)
<   {
< 
<   long N  = lg(ConVecs)-3;  // Number of congruences.
< 
<   GEN M = (GEN)ConVecs[1];
<   long numFactors = lg((GEN)M[1])-1;   // Number of rows in M
< 
<   for(long k=1; k<=numFactors; ++k) {
<     GEN P = (GEN)((GEN)M[1])[k];  //  col 1, row k
< 
<     //printf("P before =  %s\n\n", GENtostr(P));
<     
<     GEN p = gel(P,1);  // The prime below P
<     GEN x = gel(P,2);  // This is the element that get's collapsed [x,0]->x
<     if( typ(x)==t_INT && equalii(p,x) ) {
<       GEN xNew = cgetg(3, t_COL);
<       gel(xNew,1) = gcopy(p);
<       gel(xNew,2) = gen_0;
<       gel(P,2) = xNew;
<       }
< 
<     GEN beta = gel(P,5);
<     if( typ(beta)==t_COL && lg(beta)==3) {
<       GEN coord1 = gel(beta,1);
<       GEN coord2 = gel(beta,2);
<       // If it represents a pure scalar integer like [1, 0]~, collapse it to t_INT
<       if( typ(coord1)==t_INT && equalii(coord2,gen_0) ) {
<         gel(P,5) = gcopy(coord1); // Replaces [1, 0]~ with 1
<         }
<       }
< 
<     ((GEN)M[1])[k] = (long)P;
<     //printf("P after =  %s\n\n", GENtostr(P));
< 
<     }  // End of loop over prime factors
< 

Works great.
Runtime on a Rpi 5 between 3h30m and 4h15m.

I set up my PI4....

Hello Everyone!

After getting a bit too much time to myself in college, I've decided to look into seeing just how viable it is to run Numberfields@home on ARM processors.
I've got a batch of older Chromebook Tablets that have decent processors in them (8x A53 cores each, which I had been using for Einstein@home for a long time) that I wanted to try with Numberfields.

So far I've gotten the source code on github by Eric complied on a raspberry pi I have lying around, and have ran 3 of the test files included with it (one from sf3, one from sf6, and one from sf7).
They match the truth files in everything but compute time (for the sf6 and sf7 test files I used, it was about double the time to finish compared to the truth file:

I tried to run the raspberry pi with the Anonymous platform feature BOINC has, but noticed that the server doesn't accept clients with that set for the architecture field.

I'm still trying it with other jobs my x86 computers are getting to see if the results differ, but so far they have not with the test files.
I also haven't messed with the numBlocks or the other arguments yet, but I don't know how much of a difference it would make.


Diff of the test files I've used so far:

sf3:

$ diff wu_sf3_DS-16x270_Grp74of3932160.out wu_sf3_DS-16x270_Grp74of3932160.out.truth
7c7
< #   Elapsed Time = 5646 (sec)
---
> #   Elapsed Time = 3542 (sec)

sf6:

$ diff wu_sf6_DS-7x10_Grp16925of160000.out wu_sf6_DS-7x10_Grp16925of160000.out.truth
6c6
< #   Elapsed Time = 1008 (sec)
---
> #   Elapsed Time = 627 (sec)

sf7:

$ diff wu_sf7_DS-12x12_Grp164787of1000000.out wu_sf7_DS-12x12_Grp164787of1000000.out.truth
10c10
< #   Elapsed Time = 7850 (sec)
---
> #   Elapsed Time = 4099 (sec)

Looking to see if maybe we could get ARM apps in the future if this works out.

That's a great way to spend your time.
Well done, and thank you.

Works great.
Runtime on a Rpi 5 between 3h30m and 4h15m.

PI4.

26 Sep 2026, 19:42:06 UTC 27 Sep 2026, 2:34:30 UTC Terminé et validé 24,727.08 24,247.37 700.00 Get Decic Fields v4.00 (default)
aarch64-unknown-linux-gnu

26 Sep 2026, 19:42:06 UTC 27 Sep 2026, 2:19:12 UTC Terminé et validé 23,811.41 23,348.89 700.00 Get Decic Fields v4.00 (default)
aarch64-unknown-linux-gnu

26 Sep 2026, 19:40:02 UTC 27 Sep 2026, 2:36:35 UTC Terminé et validé 24,924.46 24,438.55 700.00 Get Decic Fields v4.00 (default)
aarch64-unknown-linux-gnu

Great work :)

Maybe a stupid question but an android application should also be possible if there is already an arm port?

Great work :)

Maybe a stupid question but an android application should also be possible if there is already an arm port?

It's possible, but it will require a separate build and separate executable. If somebody builds it, I could deploy it (after sufficient testing of course).

Works great.
Runtime on a Rpi 5 between 3h30m and 4h15m.

PI4.

26 Sep 2026, 19:42:06 UTC 27 Sep 2026, 2:34:30 UTC Terminé et validé 24,727.08 24,247.37 700.00 Get Decic Fields v4.00 (default)
aarch64-unknown-linux-gnu

26 Sep 2026, 19:42:06 UTC 27 Sep 2026, 2:19:12 UTC Terminé et validé 23,811.41 23,348.89 700.00 Get Decic Fields v4.00 (default)
aarch64-unknown-linux-gnu

26 Sep 2026, 19:40:02 UTC 27 Sep 2026, 2:36:35 UTC Terminé et validé 24,924.46 24,438.55 700.00 Get Decic Fields v4.00 (default)
aarch64-unknown-linux-gnu

That matches up with the average I'm seeing with my Pi 4 currently, I figure I'll post some more statistics once I get a greater amount of tasks done (currently at 36 WUs completed, I figure I'd wait till I was at 50 before getting an average, range, and other stats calculated.

I'd be curious to see how a Pi compares to something like the x86 chromebooks I've been using previously, wattage and compute wise, so I might do a separate thread on that in the future.

Another update with the newer binary:
I have found an issue with the newer Pari version, specifically with sf3 tasks.
Whenever I run a sf3 task from the test files, it errors out with the same error that was in this post.

I have figured out the source of this error. The input file is text representing modulus ideal, discriminant bound, and congruence vectors. The newer versions of Pari make reductions when reading the data. For example, if it reads the 2-vector [5,0]~ it will convert it into the integer 5. When this data is later passed into the Pari function idealhermite it looks corrupted and flags an error.

This is not an easy fix. For now I think we should just stick with the older version of the library.

I went ahead and made the fix. The repair was non-trivial, so I made it a function call. Here is the patch:

After fumbling for a few minutes with patching the file, I got it to patch successfully, recompiled, and currently running on a different Pi that doesn't have anything running currently.
The first sf3 task I tried with the new binary didn't immediately error out, and is currently running now on that Pi.
I also have the binary with the old version of Pari running with the same WUs as the new binary currently. I'll post the time diffs here once they finish.

The fix does work, and it seems that the newer Pari version still makes little difference over the few WUs I've tried so far.
Still running the rest of the sf3 and sf7 test tasks, which I'll put an average here between the test tasks to see which version of Pari is faster overall, if there is a difference.

Diffs:

$ diff old_pari/wu_sf3_DS-15x271_Grp47of6553600.out new_pari/wu_sf3_DS-15x271_Grp47of6553600.out 
6c6
< #   Elapsed Time = 2309 (sec)
---
> #   Elapsed Time = 2291 (sec)

$ diff old_pari/wu_sf6_DS-7x10_Grp16925of160000.out new_pari/wu_sf6_DS-7x10_Grp16925of160000.out 
6c6
< #   Elapsed Time = 1198 (sec)
---
> #   Elapsed Time = 1203 (sec)

$ diff old_pari/wu_sf7_DS-12x12_Grp164787of1000000.out new_pari/wu_sf7_DS-12x12_Grp164787of1000000.out 
10c10
< #   Elapsed Time = 9466 (sec)
---
> #   Elapsed Time = 9420 (sec)

Well, after a semi-major life incident, and a week of midterms/tests, I finally have some time to myself again.

For the Pi 4, with a sample size of n=72, I found that the average time to complete a task is 6 1/2 hours (23,736 seconds), with a range between 2 1/2 hours (9,216 seconds) and 10 1/4 hours (37,184 seconds) (I got a lucky task or two, and an unlucky task or two, which is why the range is so large). Computer ID is 2914517 if anyone is interested.

For the Pari builds, the old version of Pari had an average time (between all fields in the test files) of 7,978 seconds, while the new version of Pari had an average time of 7,967 seconds.
Looking at tasks individually, they all differ by only a few seconds each, and at most 10-20 seconds of completion time.

For now, I think I'm going to focus on trying to port the CPU app to android next, which I've gotten some progress on (I've been able to cross compile the boinc libraries for android, and have almost compiled Pari/GMP as well).
I'll make a new thread with instructions whenever I get to the point of compiling the app for android, since it is a bit more involved in order to build a boinc app for android.