Things seem to be better at the moment. Let's hope it stays that way.

Yep, things are good at present, and have been for a while now. Fingers crossed that's the worst of it.

And then the Web site goes MIA again, along with stalled uploads, downloads etc. ANs then it's back again.

Things are not well here.

If I understand correctly, the current PARI version is quite old. Has anyone tried a more recent release, or is updating it particularly difficult?

Since PARI is updated regularly, it might include improvements that would also benefit computations.

There's always a risk of breaking something when you upgrade to a newer library. The current apps are very stable so I'd rather not change anything unless there is a good reason.

As it turns out, I recently ran some single prime decic cases offline using the latest stable PARI library. There was no noticeable improvement in speed.

Interesting you got it running. Which version? I tried to compile and test GetDecis with PARI 2.17.4 (using last GMP as included with Mingw64) and got PARI error "incorrect type in idealhnf [fake prime ideal]".

Sidenote: PARI is unlikely to make GetDecisc faster because it is only small part of runtime. However it would be nice if getDecics could be recompiled with last GMP with all per-arch optimizations.

I used PARI version 2.17.3, but that shouldn't make a difference for you. I used the system provided libgmp.a which comes from the package: gmp-static-6.3.0-4.fc43.x86_64
So it looks like I built with relatively recent libraries.

I started with the NumberFields source code and tweaked it for my special case of a single prime. To build it I needed to change several things - if I recall, some function names changed and some interfaces changed. But I don't remember any changes required for the idealhermite function. Maybe you could send me your build log and I could take a look. Or let me know which line of the code is causing problems. Or if you can wait, I can get the source code to build with the latest libraries and merge the fixes into the baseline on github.

Since you are building for Windows, that is also a potential source of problems.

Maybe if you have time, could you please post diff? I can then cherry pick changes to apply. Otherwise I can wait, no rush there... ;) Many thanks.

--- TgtMartinet.cpp.Orig        2026-08-20 14:30:56.257915279 -0700
+++ TgtMartinet.cpp     2026-08-20 14:30:57.561916567 -0700
@@ -1363,7 +1363,7 @@
 
 
       // Check if f_L is irreducible:
-      if(isirreducible(f_L))
+      if(polisirreducible(f_L))
         {
         // Increment the irreducibilty counter.
         (*irrCount)++;
@@ -1394,7 +1394,7 @@
           free(OutStr);
           }
 
-        } // Matches: if(isirreducible(f_L))
+        } // Matches: if(polisirreducible(f_L))
 
       // Restore pointer to top of pari stack
       avma = ltop;

If I understand correctly, the current PARI version is quite old. Has anyone tried a more recent release, or is updating it particularly difficult?

Since PARI is updated regularly, it might include improvements that would also benefit computations.

There's always a risk of breaking something when you upgrade to a newer library. The current apps are very stable so I'd rather not change anything unless there is a good reason.

As it turns out, I recently ran some single prime decic cases offline using the latest stable PARI library. There was no noticeable improvement in speed.

Interesting you got it running. Which version? I tried to compile and test GetDecis with PARI 2.17.4 (using last GMP as included with Mingw64) and got PARI error "incorrect type in idealhnf [fake prime ideal]".

Sidenote: PARI is unlikely to make GetDecisc faster because it is only small part of runtime. However it would be nice if getDecics could be recompiled with last GMP with all per-arch optimizations.

If I understand correctly, the current PARI version is quite old. Has anyone tried a more recent release, or is updating it particularly difficult?

Since PARI is updated regularly, it might include improvements that would also benefit computations.

Also, if your CPU has hyper threading, I find it best to set CPU usage to between 60% and 75% of the CPUs, otherwise you get too much resource contention between threads and the WUs take much longer to run.

Interesting and very useful information. Does this mean that a typical NumberFields work unit use/has about 60% - 75% FP32 instruction workload during the entire computation time since running a theoretical workload with 100% FP32 will pretty much saturate a full physical core (i.e. 50% with HT will work well) as opposed to running integer operations where running 100% with HT on seems to be more beneficial? Will this change over different work unit batches?

I told Walli about a similar setup I did on Free-DC back in Janurary for them to pull the stats directly from Free-DC.

https://api.free-dc.org/projects/gerasim/stats/

Nothing ever came of that. So I wouldn't hold your breath.

Since both WUs have the same name GetDecics I cannot find a way to control them both.
The problem is that this project sends far too many CPU WUs and triggers tagging them as High Priority.
When this happens often the GPU WU stops running to allow the many HP CPU WUs to take over. Exacerbating the problem when a mix of deadlines appear and the closer ones run as HP and the ones that have already started switch to Waiting To Run.
I've tried everything I can think of in my app_config but nothing seems to work.
The easiest fix would be to do like every other BOINC project and give them different names, e.g. GetDecicsCPU and GetDecicsGPU.

From my understanding, the root cause of the problem is that Russia is blocking BOINCstats from accessing the Gerasim server.

Since NumberFields can access the Gerasim server, I wrote a curl script which pulls the export files from Gerasim's server to the NumberFields server, and this runs daily. We are now waiting on BOINCstats to modify their scripts to pull the data from the NumberFields server.

Well done Eric.

Are there any improvements pending on age of the Credit stat's for Export ?

Last update user XML 2026-06-18 05:58:01 UTC (9 days 13:49:38 old)
Last update host XML 2025-12-07 13:58:00 UTC (202 days 05:49:39 old)
Last update team XML 2026-06-27 17:58:00 UTC (01:49:39 old)

Normally most Projects generate daily updates.

Respectfully
Bill F
Dallas TX

So that's how you get static library out of new version of PARI.

BETA Status

Is it time to review the Beta status for removal ?

It has been a number of years

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.

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

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?

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?

Please contact Yoyo from the Yoyo@home project to shift the processing from Gerasim to Yoyo@home as a new subproject.
Gerasim simply is not reliable at all.

Michael.

P.S.: For the second time, I lost massive credits - in fact, the entire output from 2026 is gone (not just a month or so...). It was about 4 million credits, which is half of my total output for that project so far. Most importantly, however, is the fact that all the results are gone. That is useless CO2 production to foster climate change at its best...