Has anyone else noticed a drop in their RAC over the last 2 days?

As far as a i can tell, run times are unchanged, Credit per Task is unchanged, Estimated completion times are around the same, but the RAC on both of my systems has dropped by roughly 5,000 on one and 4,000 on the other (roughly the same percentage drop on both).
RAC was pretty much steady up to the 30/4, then since the 1/5 the drop.

When will this project get Android support?

Is this a hardware upgrade? You got a new server for the project? Or are we just talking about updating the software?

I can't help with the software, but could donations help? In any case, is there a page to donate to the project, or would it be better to donate to ASU?

Linear programming is for a certain class of problems that have linear relations, which we don't have here. Even if we did, the real bottleneck is with the large precision integers, since GPUs don't have native data types for that, so you have to create your own (think creating 128bit adders/multipliers from 64bit native versions).

So what's known as Bignum Arithmetic/ Arbitrary-Precision Arithmetic? (but some quick searches on those show some results for libraries, but many of them appear to have little to no documentation...).

Edit- and searches on CUDA_int128 return some articles on it being introduced in CUDA 11.5 (eg), but not much else.

I was wondering if you had come across this article previously (and if it's even relevant to NumberFields processing).
Accelerate Large Linear Programming Problems with NVIDIA cuOpt

Synopsys

The evolution of linear programming (LP) solvers has been marked by significant milestones over the past century, from Simplex to the interior point method (IPM). The introduction of primal-dual linear programming (PDLP) has brought another significant advancement.

NVIDIA cuOpt has now implemented PDLP with GPU acceleration. Using cutting-edge algorithms, NVIDIA hardware, dedicated CUDA features, and NVIDIA GPU libraries, the cuOpt LP solver achieves over 5,000x faster performance compared to CPU-based solvers.

This post examines the key components of LP solver algorithms, GPU acceleration in LP, and cuOpt performance on Mittelmann’s benchmark and Min Cost Flow problem instances.

If i remember correctly, back in the very early days of Seti@home before GPUs were a thing, Nvidia actually helped develop the first code to make use of their GPUs in order to promote CUDA for such work.
While they won't do that these days thanks to AI/LLMs being all the rage, a post on their developers boards asking for some insights might prove useful, possibly gaining the interest of someone that wants to work on their coding and optimisation skills.

While more computing power is always beneficial, what else does the project need most at this stage?

Are there specific areas where volunteers can contribute beyond donating crunching power?

For example, are there needs related to software development, outreach, documentation, or anything else that could help this projects thrive?

Well, it's reporting "Warning: Undefined variable $v in /home/boincadm/projects/NumberFields/html/user/host_stats.php on line 93" now.

https://numberfields.asu.edu/NumberFields/host_stats.php

On the page linked above, the first half of the page is just the following error/warning repeated over and over again:

"Warning: Undefined variable $v in /home/boincadm/projects/NumberFields/html/user/host_stats.php on line 94"

What's going on here?

I first read about this a week or two ago, but it looks like it's becoming a bigger issue than it might have first appeared to have been.
For the latest Blackwell cards (the RTX 5xxx series that are rarer than hen's teeth and require you to sell body parts to be able to afford one), Nvidia has dropped all support for 32bit CUDA, which means they have also dropped support for 32bit OpenCL.
The result- some benchmarks are giving less than impressive results for the new cards, and some older games are almost unplayable on the new video cards (unless you have a second card of an older series to take care of the 32bit PhysX which is also impacted).

And so i was wondering- is the present OpenCL Numberfields@home application 32bit or 64bit? (Supposedly the PassMark benchmark is meant to be 64bit, but the lack of 32bit support has impacted it, severely).

Strange GeForce RTX 50-series benchmark issues solved but new problem for gamers arises.

To answer the first thing, that's totally fair, it's just cause I've seen other projects where it said Intel and ARM Macs, even though this was also Rosetta 2, or where the Apple Silicon Mac got both ARM and x86 tasks, with no option to choose which tasks to get.

And no, I didn't do anything "extra", just selected the project, entered my login info, and the tasks downloaded :)

Update:

Just tried this project anyway on my M4 Mac mini, and I immediately got 10 concurrent CPU tasks, one for each of my 10 CPU cores.

These were running under Rosetta 2 though, so not native, but still, it works, which means you can add MacOS ARM to the Applications page :)

I am getting only open_cl work units for my GTX 1650 Super under Win10.
Are there any CUDA work units being sent out?

There's only a CUDA app for linux. The openCL version is not too much slower than CUDA.

I noticed that with my RTX 4060Ti Super running under Windows, the run times were slightly longer & the APR slightly lower than yours running under LINUX, then i noticed the OpenCL v CUDA initialisation line in the Stderr output files.

Looking in my Stderr output for a Valid Task, i noticed that it appears to be compiling the OpenCL kernel on every run. One thing that would help performance on all systems using OpenCL would be if the application made use of the OpenCL Compiler Cache.
On the initial run, the kernel is compiled (and on that initial compilation it can be done for all possible valid settings values). On subsequent runs, the appropriate cached pre-compiled kernel is used (unless there is a hardware change in which case the cache is cleared & the kernels re-compiled till the next hardware change).


The other thing i noticed was that on a system with two very different video cards, all work is reported as being done with the most powerful card in the system (as reported by BOINC).
eg for a while for me it was a GTX 1070 & a RTX 2060 Super. Even the work processed by the GTX 1070 was reported as being processed by the RTX 2060 Super in Stderr output.
For the caching to work, i suspect that this might need to be resolved- when the GPU application starts up, it needs to query the hardware it is starting on and not use the BOINC reported hardware, in order to make use of the right OpenCL kernel (although thinking about it, the present system seems to work OK making use of default values, and the lookup table, so just caching & re-using kernels compiled on those inputs should still work).


EDIT- although i notice in the CUDA Stderr output the line

Setting GPU device number 0.

which doesn't appear in the OpenCL Stderr output.

Hey Grant - thanks for pointing out the issue with the intel drivers. I didn't realize they were that bad. Hopefully they will get updated soon.

By the way, the NumberFields app takes up 5GB VRAM on Intel Arc B580. Is that normal?

I don't think so. My 4070Ti only uses 522MB per thread. That's with default GPU settings. Did you happen to change the gpuLookupTable_v402.txt file?

I didn't change it, and B580 doesn't appear in it. Any suggested change I can apply? Is numBlocks the number of blocks of VRAM available for the card? How to determine how large each block is? And threadsPerBlock is 32 for most cards? Will there be threadsPerBlock*numBlocks threads in one NumberFields app? I think I can try playing around with different values...