I meant both. For OpenCL/CUDA it is important that serialized parts are as efficient as possible. (At bare minimum it would allow one core to handle more GPUs or at least give some extra cycles to CPU version)
As for optimization, that was five years ago. Since then there were lots of major versions for GCC (about five). Good probability we can get some speed up even from compiler upgrade.

Two notes. I am working on out-of-band caching for OpenCL version using intercept library and looking at improvements CUDA might have mostly advantage in compilation/caching. And if I could get GetDecics to compile I'd like to make CUDA version for Windows too.

I'd be curious to see how you get a CUDA Windows app. I cross compile using mingw and at the time it was not possible to cross compile with CUDA, hence I went the route of OpenCL where the compiling is off loaded to the user's GPU at runtime.

Specify the directory in which the host compiler executable resides. The host compiler executable name can be also specified to ensure that the correct host compiler is selected. In addition, driver prefix options ('--input-drive-prefix', '--dependency-drive-prefix', or '--drive-prefix') may need to be specified, if nvcc is executed in a Cygwin shell or a MinGW shell on Windows.

Just little warning, I was looking at code and trying to get it compile and have it run correctly and so far I failed (using current GCC and MSYS2/Mingw64). If you get it to compile, could you please use GMP compiled with "--enable-fat", so all assembler optimizations are included it woudl be great. (Mingw64 already ships such version and it can be used as is) Even better if one could bump GMP and PARI to current versions (for PARI it is required for current GCC or compile fails).

Note: author of libGMP is bit crazy and vast majority of optimizations are in assembler and as such correct compilation is needed to get most of performance out of it.

Note 2: Currently in my compile GetDecics stops on nfinit0 which complains that used polynomial is not irreducible. Cause for this spurious error is so far unknown. (GP as published accepts it without any problems)

You must be referring to the CPU app. The current executables are built with O3 optimization and are about as efficient as possible for the gnu compiler. With that said, I was unaware of the enable-fat option with gmp. It would be interesting to see how much faster the code runs on various cpus with this option. Agreed that any new build should use the latest stable version of Pari (as well as boinc and gmp).

I wonder if you were advised about the current FB Challenge.? I have been trying to get work for over an hour but no luck.

You have multiple systems that have work, and a couple that don't.
Check the Event log in those that don't have work for why not.


Oh, and your i7-14700F that has returned some work; i'd checkout what's going on with that system- taking 3 hours to do 1 hours work on the CPU indicates a massively overcommitted system.

Thank you Grant for your help. I checked the manager, I could not find anything wrong. I reset all to default and am now getting work. It is frustrating when you can't find the reason.

Thinking about this, there are only two options: Anonymous platform or removing signature and its requirement from gpuLookupTable.txt. Both require changing server-side settings. (I don't like downgrading BOINC for too many versions.)

Even if I wanted to, I don't think it's possible to change the signature requirement. That is there so the client knows it's running the true executable from the project and not some hacker's version that made its way onto your computer.

I did a quick search and I couldn't find anything about how to enable anonymous platforms on the project server. But I did find this:

<verify_files_on_app_start/>
    Before starting or restarting an app, check contents of input files and app version files by either MD5 or digital signature check. Detects user tampering with file (but doesn't really increase security, since user could also change MD5s or signatures in client state file). 

This option was not in the project config file, so I added it and set it to 0. Maybe the default value was on? We'll see if this changes anything...

<platform>
<name>anonymous</name>
<user_friendly_name>anonymous</user_friendly_name>
</platform>

Have either of you considered using the configuration option

<dont_check_file_sizes>0|1</dont_check_file_sizes>
Normally, the size of application and input files are compared with the project-supplied values after the files are downloaded, and just before starting an application. If this flag is set, this check is skipped. Use it if you need to modify files locally for some reason.

(details in the User manual)

This experiment is unlikely to work. Apparently BOINC gets somewhat confused, deletes/resets file as corrupted, while somehow erroring out all GPU tasks by failing to copy over either version of file.

Maybe anonymous platform might provide a way to test this, but I haven't yet used it.

ETA: It looks like it affects only newer versions. One of my computers is still on version 7.16.20 and modification works, while all others are on 7.22.2 and failed.

You might be right. It works with all my managers, but I only run linux and my versions are 70.20.2 or older.

Hello,

What is the sequence of next searches?