New optimized versions of the GetDecics app have been discussed in other threads, but I thought it best to start a new thread.

First, a thank you to Alperen for optimizing the current apps. Yes, he used Claude, but that's not necessarily a bad thing. I don't have the experience required or the time to learn the AVX tricks that were used here. So without Alperen and Claude, this probably never would have happened.

I have spent many hours going through the new code. The original code was basically left untouched, and the change was in the addition of a new subroutine that pre-filters the polynomials prior to the normal processing chain. This leaves just the one subroutine that needs validation. From a theoretical perspective, the method is sound. The method can be decomposed into 2 parts:

1. The first part was a simple trick (I wish I had seen this myself!) that allows us to deal with the polynomial discriminant modulo a small set of primes. This eliminates the need for the multi-precision integers that were growing to ~1000 bits, and gives the first speed improvement. This was simple enough I could independently code it up myself using Pari's built-in functions. In some offline tests I was seeing a speed improvement of between 2 and 3, just for this simple change.

2. The second improvement was in the coding of the resultant modulo q. This was essentially done in parallel using AVX2, which allows resultants to be computed for several primes simultaneously. This is the part that is very tricky and hard for me to follow. I welcome any expert in this kind of optimization to look at the code. Alperen has made it public here:
https://github.com/alplix/passiflora

So the method in general is sound, but the second part was hard for me to validate. For this reason, I will use sufficient testing to validate the new apps. The idea is to test each new app version on ~1000 old cases which can be taken as truth. This will be done using the "testDecics" app that was recently created. When an app is deemed good, it will be transitioned into an official app.

I will be creating a new app called fastGetDecics where the new validated apps will go. This will still allow me to keep the results separate. It will also allow me to create new WUs for the fast apps that will not put a burden on the server, while retaining older style WUs for the legacy apps. This will give me time to test and migrate the fast apps in pieces rather than all at once. App versions for the original GetDecics will be deprecated once the corresponding fast version has been deemed trustworthy.

So the guy who was just banned from the BOINC forums is now writing apps for this project?

Interesting.

So the guy who was just banned from the BOINC forums is now writing apps for this project?

Interesting.

Did you actually read the news post???
If it works and produces accurate and valid results, then why not use it??????

---

Grant
Darwin NT, Australia.

This was essentially done in parallel using AVX2, ...

Because this project uses a fixed value for the Credit granted, and I'm pretty sure the with present Credit system the Credit is set per Task and not per application, i suspect it will cause issues with credit received for work done.


With the standard BOINC Credit system, the amount of Credit is based on the amount of work done- using the project's stock application the amount of Credit will vary depending on the amount of time taken to process the Task (eg (made up numbers) 2 hrs gets 500. 1 hr gets 250. 4 hrs gets 1,000); but the awarded Credit per Task for the stock application and a higher performing optimised application is the same (eg 2 hrs stock but 1 hr optimised- both still get 500. 1 hr stock but 30 min optimised- both still get 250. 4 hrs stock but 2 hrs optimised- both still get 1,000.)
It still gets the same amount of Credit as the stock application for a given Task- but as the optimised application takes less time to do the same amount of work, it will get more Credit per hour.


While AVX2 has been around for a long time, there would still be quite a few systems without it- if you're going to continue to support non AVX2 systems it will result in those systems getting much less Credit per hour than they are currently getting if you reduce the Credit per Task (as been done for the present Test Tasks).

If all work is done using the new applications, no problems, although it will block older non AVX2 systems from participating.
But if there is a mix of AVX2 and non-AVX2, the lack of Credit for non-AVX2 produced results will discourage those from continuing.

---

Grant
Darwin NT, Australia.

Eric, thanks for the progress update. I think with the new fast app, the remaining work batches can be completed much faster, maybe around 20X faster based on my limited study on both CPUs and GPU that I currently owned.

As for credit, there is going to be some discussions if the current fixed credit should remain the same or not. There are two camps of boinc volunteers: those who go after credits and those who care for science but honestly having reasonable credit makes this whole boinc volunteer computing more fun.

For me, I'm leaning towards the principle of "Equal work for equal pay". On the hardware side, CPU and GPU continue to see architecture and speed improvement (and other things like memory speed, PCIE bandwidth, etc), software is written to utilize new instruction sets (e.g. old SSE4 vs AVX, AVX2, to new AVX-512) and also with the help of AI coding as a tool, software can be re-written quickly to optimize for speed. Like you said understanding the code or algorithm to ensure the method is logically sound is a different ball game altogether. Here the "equal work" means a completion of a work unit. A recent example is Einstein@Home project where initially using a datacenter/professional gpu card with good FP64 & high memory bandwidth completed the same work unit faster (and more power efficient) than the consumer grade gpu card (other than the enthusiast high end consumer card) while both still earn the same credit, "equal pay". Overtime optimized Einstein apps were developed and run faster (2X to 10X, depending on the hardware) than the stock default apps. Both still earn the same credit till today. Seems like having a credit inflation, lol.

Anyway, just my thought but I'm sure others here may have different opinions.

This was essentially done in parallel using AVX2, ...

Because this project uses a fixed value for the Credit granted, and I'm pretty sure the with present Credit system the Credit is set per Task and not per application, i suspect it will cause issues with credit received for work done.


With the standard BOINC Credit system, the amount of Credit is based on the amount of work done- using the project's stock application the amount of Credit will vary depending on the amount of time taken to process the Task (eg (made up numbers) 2 hrs gets 500. 1 hr gets 250. 4 hrs gets 1,000); but the awarded Credit per Task for the stock application and a higher performing optimised application is the same (eg 2 hrs stock but 1 hr optimised- both still get 500. 1 hr stock but 30 min optimised- both still get 250. 4 hrs stock but 2 hrs optimised- both still get 1,000.)
It still gets the same amount of Credit as the stock application for a given Task- but as the optimised application takes less time to do the same amount of work, it will get more Credit per hour.


While AVX2 has been around for a long time, there would still be quite a few systems without it- if you're going to continue to support non AVX2 systems it will result in those systems getting much less Credit per hour than they are currently getting if you reduce the Credit per Task (as been done for the present Test Tasks).

If all work is done using the new applications, no problems, although it will block older non AVX2 systems from participating.
But if there is a mix of AVX2 and non-AVX2, the lack of Credit for non-AVX2 produced results will discourage those from continuing.

AVX2 came out over a decade ago, which should apply to most Intel/AMD systems on this project. So I think your concerns apply more to non x86_64 systems, such as MacOS and the new ARM builds.

As a reminder - credit is fixed and is based on average run times. So if one batch of data averages 1 hour/WU and gets X credit, then a new batch which average 1.5 hours/WU will get 1.5*X credit. All timing is done offline using 100 WUs on the same system under the same conditions, to get the most accurate timing. I plan to do the same thing with the new fast apps, so that 1 hour of compute time pays the same credit whether it's with the fast app or the legacy app. That seems to be the fairest thing to do, especially during the transition period.

But as you point out, this creates a predicament for the non-AVX2 systems. I'm not sure if I will do this, but maybe give the non-AVX2 systems a bump up in their credits??

But as you point out, this creates a predicament for the non-AVX2 systems. I'm not sure if I will do this, but maybe give the non-AVX2 systems a bump up in their credits??

Honestly with the fast app introduction, contributions from those non-avx2 systems will be very insignificant in a grand scheme of things. Sorry not meant to push those contributors away. I leave it to you.

If my data is representative (small sample size on CPU and GPU), a 20X improvement (maybe 10x worst case??) in speed will cut the remaining ETA time by:
Batch progress current_ETA Fastapp_ETA
DS13x12 4.0 % 667.8 days → 33.4 days
DS14x12 4.0 % 720.0 days → 36 days
DS15x12 4.0 % 631.6 days → 31.6 days
DS16x10 94.5 % 16.3 days → < 1 day
DS16x11 ?
DS16x12 ?

Am I hallucinating that we will finish this project very soon?

BTW, what is the average speed improvement seen from the ~1000 tasks that were just completed recently? Not sure if you have the old run time for the ~1000 tasks or perhaps the overall average run time of the DS13x12 tasks?